From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 07:06:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EAEC16A4CE for ; Sun, 10 Apr 2005 07:06:43 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F8943D54 for ; Sun, 10 Apr 2005 07:06:43 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DKWWl-000AAW-0G; Sun, 10 Apr 2005 09:06:39 +0200 Date: Sun, 10 Apr 2005 09:06:38 +0200 From: Kirill Ponomarew To: Doug White Message-ID: <20050410070638.GB38785@voodoo.oberon.net> References: <20050406084615.GF15165@voodoo.oberon.net> <20050408101149.T63303@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050408101149.T63303@carver.gumbysoft.com> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: freebsd-stable@FreeBSD.org Subject: Re: 4.11R panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 07:06:43 -0000 On Fri, Apr 08, 2005 at 10:14:17AM -0700, Doug White wrote: > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x20202020 > > Hm, something ran into a bunch of ASCII spaces.. > > Can you jump to frame #6 and print *kbp? It appears the kernel malloc > bucket list is corrupted, so I'm curious just how badly that struct is > spammed. #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) up 6 #6 0xc0193533 in malloc (size=324, type=0xc030d780, flags=9) at /usr/src/sys/kern/kern_malloc.c:243 243 va = kbp->kb_next; (kgdb) print *kbp $1 = {kb_next = 0x20202020
, kb_last = 0xcc8fa000 "", kb_calls = 5704, kb_total = 448, kb_elmpercl = 8, kb_totalfree = 13, kb_highwat = 40, kb_couldfree = 0} -Kirill From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 08:27:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BFF416A4CE for ; Sun, 10 Apr 2005 08:27:56 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D6A43D2F for ; Sun, 10 Apr 2005 08:27:56 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from localhost ([127.0.0.1] ident=www) by anduin.net with esmtp (Exim 4.50 (FreeBSD)) id 1DKXnN-00033C-Rn for stable@freebsd.org; Sun, 10 Apr 2005 10:27:55 +0200 Received: from ranger.anduin.net (ranger.anduin.net [81.0.162.52]) by anduin.net (Horde) with HTTP for ; Sun, 10 Apr 2005 10:27:53 +0200 Message-ID: <20050410102753.d63hhe8vpcs8wsgg@anduin.net> Date: Sun, 10 Apr 2005 10:27:53 +0200 From: ltning@anduin.net To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Spam-Score: -2.9 X-Spam-Level: -- Subject: Panic when logging out from serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 08:27:56 -0000 Hi all, warning: This report might be somewhat vague. For quite a while now I`ve been plagued with the problem that logging out from a serial console causes the box to panic. For a while I`ve been sure this was isolated to one of my boxen, because it`s been acting up in other ways as well, but today it happened on two other boxes too! And these boxes have been rock stable for the last two years. I`m running a fairly recent variation of RELENG-5 on all the boxes; one of them is amd64, the two others - including the one I`ve pasted from - are plain old p3 machines. They are all dual-CPU though. I have no clue what I can do from here; has anyone seen this before? I can`t always reproduce it, but the risk is fairly high - around 33% I`d say. Anyone? Thanks for your attention, details below. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc0620b5f stack pointer = 0x10:0xdadbd988 frame pointer = 0x10:0xdadbd994 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 51999 (getty) trap number = 12 panic: page fault cpuid = 1 boot() called on cpu#0 Uptime: 66d11h24m50s /Eirik ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 11:42:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5073816A4CE for ; Sun, 10 Apr 2005 11:42:14 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06BF143D2F for ; Sun, 10 Apr 2005 11:42:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1314346B49; Sun, 10 Apr 2005 07:42:13 -0400 (EDT) Date: Sun, 10 Apr 2005 12:42:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: ltning@anduin.net In-Reply-To: <20050410102753.d63hhe8vpcs8wsgg@anduin.net> Message-ID: <20050410124013.W4310@fledge.watson.org> References: <20050410102753.d63hhe8vpcs8wsgg@anduin.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: stable@freebsd.org Subject: Re: Panic when logging out from serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 11:42:14 -0000 On Sun, 10 Apr 2005 ltning@anduin.net wrote: > warning: This report might be somewhat vague. For quite a while now I`ve > been plagued with the problem that logging out from a serial console > causes the box to panic. For a while I`ve been sure this was isolated to > one of my boxen, because it`s been acting up in other ways as well, but > today it happened on two other boxes too! And these boxes have been rock > stable for the last two years. > > I`m running a fairly recent variation of RELENG-5 on all the boxes; one > of them is amd64, the two others - including the one I`ve pasted from - > are plain old p3 machines. They are all dual-CPU though. I've seen precisely this panic -- in fact, I saw it yesterday on a RELENG_5 box, and under identical circumstances -- it looks like it happens if a last process in a login session on a serial console closes the tty, and then getty re-opens it while there's console output coming from syslog. I was able to get a core dump, but haven't made much headway on it yet. It looks like the tty structure has been released -- the refcount on the tty is 0, and the mutex pointers in the kqueue state have been cleared (hence the null pointer dereference you see). Now, the question is why -- I've added some debugging output to the local box I saw it on, and will see if I can reproduce it. Robert N M Watson > > I have no clue what I can do from here; has anyone seen this before? I can`t > always reproduce it, but the risk is fairly high - around 33% I`d say. > > Anyone? > > Thanks for your attention, details below. > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0x1c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0620b5f > stack pointer = 0x10:0xdadbd988 > frame pointer = 0x10:0xdadbd994 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 51999 (getty) > trap number = 12 > panic: page fault > cpuid = 1 > boot() called on cpu#0 > Uptime: 66d11h24m50s > > > > /Eirik > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 13:39:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31C0116A4CE; Sun, 10 Apr 2005 13:39:42 +0000 (GMT) Received: from markdnet.demon.co.uk (cpc1-oxfd2-6-0-cust136.oxfd.cable.ntl.com [81.103.191.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BAC543D54; Sun, 10 Apr 2005 13:39:41 +0000 (GMT) (envelope-from mark@markdnet.demon.co.uk) Received: from localhost ([::1]) by markdnet.demon.co.uk with esmtp (Exim 4.50 (FreeBSD)) id 1DKceZ-0000Or-Qn; Sun, 10 Apr 2005 14:39:07 +0100 From: Mark Dixon To: stable@freebsd.org, multimedia@freebsd.org Date: Sun, 10 Apr 2005 14:39:00 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1874841.X6Vb5ee2W3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504101439.06815.mark@markdnet.demon.co.uk> Subject: bktr and Interlacing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 13:39:42 -0000 --nextPart1874841.X6Vb5ee2W3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, As I'm without a TV at the moment, I decided to plug my XBox into my TV car= d=20 (via bktr driver) and attempt to play the brilliant Burnout 3 via my monito= r=20 and mplayer. Unfortunately, as soon as things get busy (as they inevitably = do=20 in this game), the screen started to show signs of interlacing all over the= =20 place, and as you can imagine, when driving into oncoming traffic at 200mph= ,=20 interlacing is not very helpful.=20 I had a quick look at the source and can't see any obvious interlace contro= ls=20 =2D although there is one slightly worrying comment: /* * XXX NOTE (Luigi): * currently we only support 3 capture modes: odd only, even only, * odd+evgen interlaced (odd field first). A fourth mode (non interlaced, * either even OR odd) could provide 60 (50 for PAL) pictures per * second, but it would require this routine to toggle the desired frame * each time, and one more different DMA program for the Bt848. * As a consequence, this fourth mode is currently unsupported. */ Does anyone know if there is a simple switch that needs setting somewhere t= o=20 make the card not do this, or if its simply a performance problem with=20 something (my computer, mplayer, bktr driver) not being able to keep up wit= h=20 the amount of activity the XBox is throwing at the screen. Mark --nextPart1874841.X6Vb5ee2W3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCWSx6LqgJ90OcaiARAjwkAKCc4qWcG+bkCfBlzQXHBJcNL3PfbwCePXJ+ SH5MmDqj1ggeDS0luJD/OFA= =stPX -----END PGP SIGNATURE----- --nextPart1874841.X6Vb5ee2W3-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 13:49:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0667616A4CE for ; Sun, 10 Apr 2005 13:49:24 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941F643D2D for ; Sun, 10 Apr 2005 13:49:23 +0000 (GMT) (envelope-from omniBSD@speakeasy.net) Received: (qmail 15892 invoked from network); 10 Apr 2005 13:49:23 -0000 Received: from acute.anhedonia.com (HELO [10.20.30.10]) (omni@[66.93.24.213]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Apr 2005 13:49:22 -0000 Message-ID: <42592FBD.1070903@speakeasy.net> Date: Sun, 10 Apr 2005 08:53:01 -0500 From: Ash User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041104 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <4258324D.8070405@speakeasy.net> <20050409220331.GF89047@cirb503493.alcatel.com.au> In-Reply-To: <20050409220331.GF89047@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: 5.4-RC1 Freezing, but pingable (may be related to gvinum) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 13:49:24 -0000 Peter Jeremy wrote: > On Sat, 2005-Apr-09 14:51:41 -0500, Ash wrote: > > This is consistent with the kernel continuing to run normally but being > unable to schedule userland processes - usually due to a deadlock. > > Do the caps-lock, num-lock, scroll-lock buttons on a local keyboard > still toggle the relevant LEDs? > > Assuming the LEDs toggle: Do you have "options DDB" and "options KDB" > in your kernel? If so, can you break into DDB? (If not, I think > you'll need to build a kernel with DDB). Once the system has hung, > you need to enter DDB and run 'ps'. The output from that will give > (hopefully) give an indication as to what is going wrong (and where to > look next). If you've build the kernel with debugging symbols and got > a dump device enabled, "call doadump()" should also generate a > crashdump which will be much easier to examine. > Peter, Thanks for the reply. I should have included this information in my initial e-mail: I did not have a keyboard connected to the system before either crash. I did plug a keyboard in after the crash out of desperation. The keyboard LEDs were not responsive. However, it's a ps/2 keyboard, which does not get detected by this system unless it's plugged in before the machine POSTs. I did not have DDB/KDB compiled in my kernel at the time, so I wasn't able to try to break into a debugger from the serial console. Shortly after the second crash I recompiled the kernel with DDB/KDB. Essentially at this point I'm just waiting for another crash to see if I can get get into DDB from the serial console. I was hoping that someone on the list may have run into a similar issue with 5_4_0 so that I could at least figure out how to reproduce the problem rather than simply waiting for the machine to hang again. Patience is not my greatest virtue :) -Ash From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 14:20:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B571316A4CE; Sun, 10 Apr 2005 14:20:48 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A14C43D1F; Sun, 10 Apr 2005 14:20:48 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-35-78.dynamic.qsc.de ([212.202.35.78] helo=bsd.trippelsdorf.de) by falcon.loomes.de with asmtp (Exim 4.30) id 1DKdIp-0004ma-0X; Sun, 10 Apr 2005 16:20:43 +0200 Date: Sun, 10 Apr 2005 16:20:39 +0200 From: Markus Trippelsdorf To: Mark Dixon Message-ID: <20050410142039.GA51256@bsd.trippelsdorf.de> References: <200504101439.06815.mark@markdnet.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504101439.06815.mark@markdnet.demon.co.uk> User-Agent: Mutt/1.5.9i cc: stable@freebsd.org cc: multimedia@freebsd.org Subject: Re: bktr and Interlacing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 14:20:48 -0000 On Sun, Apr 10, 2005 at 02:39:00PM +0100, Mark Dixon wrote: > > Does anyone know if there is a simple switch that needs setting somewhere to > make the card not do this, or if its simply a performance problem with > something (my computer, mplayer, bktr driver) not being able to keep up with > the amount of activity the XBox is throwing at the screen. You could try one of mplayers postprocessing deinterlacers. mplayer -pphelp will show you the available options. (for example: -vf pp=ci) -- Markus From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 18:53:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A45116A4CE for ; Sun, 10 Apr 2005 18:53:34 +0000 (GMT) Received: from skipjack.no-such-agency.net (skipjack.no-such-agency.net [64.142.114.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id B557B43D2F for ; Sun, 10 Apr 2005 18:53:33 +0000 (GMT) (envelope-from jpp@cloudview.com) Received: from skipjack.no-such-agency.net (localhost [127.0.0.1]) by skipjack.no-such-agency.net (Postfix) with ESMTP id 4857034DA11; Sun, 10 Apr 2005 11:53:32 -0700 (PDT) Received: from [192.168.2.120] (blackhole.no-such-agency.net [64.142.103.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skipjack.no-such-agency.net (Postfix) with ESMTP id ACA4C34DA0F; Sun, 10 Apr 2005 11:53:32 -0700 (PDT) Message-ID: <4259762C.2040700@cloudview.com> Date: Sun, 10 Apr 2005 11:53:32 -0700 From: John Pettitt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ash References: <4258324D.8070405@speakeasy.net> <20050409220331.GF89047@cirb503493.alcatel.com.au> <42592FBD.1070903@speakeasy.net> In-Reply-To: <42592FBD.1070903@speakeasy.net> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: by skipjack cc: Peter Jeremy cc: freebsd-stable@freebsd.org Subject: Re: 5.4-RC1 Freezing, but pingable (may be related to gvinum) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 18:53:34 -0000 Ash wrote: > > > I was hoping that someone on the list may have run into a similar > issue with 5_4_0 so that I could at least figure out how to reproduce > the problem rather than simply waiting for the machine to hang again. > Patience is not my greatest virtue :) > I'm seeing a similar symptom but only with gstripe and only on usb disks (the same drives on Firewire work fine) - I can reproduce it (all be it slowly) by dumping a big file system and restoring it to a gstripe pair of usb drives - it will will after up to 2 hours. Unfortunately the machine is a semi-production server so I have to time my test window - I have built a DDB/KDB kernel for it and sometime this week I'll try and get a trace. John P.S. there is a bug report for this - i386/79169 http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/79169 From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 19:16:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BDB416A4CE for ; Sun, 10 Apr 2005 19:16:01 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B0C43D4C for ; Sun, 10 Apr 2005 19:16:00 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from localhost.localdomain (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 5857D81 for ; Sun, 10 Apr 2005 15:15:54 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: stable@freebsd.org Content-Type: multipart/mixed; boundary="=-cpZA0LUKnN3g1YaSQKjm" Date: Sun, 10 Apr 2005 15:16:41 -0400 Message-Id: <1113160601.37307.9.camel@rushlight.kf8nh.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Subject: 5.3-S (Mar 6) softdep stack backtrace from getdirtybuf()... problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 19:16:01 -0000 --=-cpZA0LUKnN3g1YaSQKjm Content-Type: text/plain Content-Transfer-Encoding: 7bit I have twice so far had the kernel syslog a stack backtrace with no other information. Inspection of the kernel source, to the best of my limited understanding, suggests that getdirtybuf() was handed a buffer without an associated vnode. Kernel config file and make.conf attached. Should I be concerned? Note that this system is an older 600MHz Athlon with only 256MB RAM, and both times this triggered it was thrashing quite a bit (that's more or less its usual state...). KDB: stack backtrace: kdb_backtrace(c06fbf78,2,c63ca26c,0,22) at kdb_backtrace+0x2e getdirtybuf(d3196bac,0,1,c63ca26c,1) at getdirtybuf+0x2b flush_deplist(c1a8544c,1,d3196bd4,d3196bd8,0) at flush_deplist+0x49 flush_inodedep_deps(c11eb800,5858f,c1ea723c,d3196c34,c052952f) at flush_inodedep_deps+0x9e softdep_sync_metadata(d3196ca4,c1ea7210,50,c06c9a19,0) at softdep_sync_metadata+0x9d ffs_fsync(d3196ca4,0,0,0,0) at ffs_fsync+0x487 fsync(c1b367d0,d3196d14,4,c10f9700,0) at fsync+0x196 syscall(2f,2f,2f,8327600,5e) at syscall+0x300 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x29152d6f, esp = 0xbf5a8d5c, ebp = 0xbf5a8d78 --- FreeBSD rushlight.kf8nh.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Sun Mar 6 02:56:16 EST 2005 root@rushlight.kf8nh.com:/usr/src/sys/i386/compile/RUSHLIGHT i386 -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH --=-cpZA0LUKnN3g1YaSQKjm Content-Disposition: attachment; filename=RUSHLIGHT Content-Type: text/plain; name=RUSHLIGHT; charset=UTF-8 Content-Transfer-Encoding: 7bit # # RUSHLIGHT -- Based on generic kernel configuration file for FreeBSD/i386 # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413 2004/08/11 01:34:18 rwatson Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident RUSHLIGHT # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options SCHED_4BSD # ULE scheduler is broken options SCHED_ULE # ...not any more! options PREEMPTION # faster response options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. #options GDB # Support remote GDB. #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 options INCLUDE_CONFIG_FILE # Include this file in kernel # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # local options options CPU_FASTER_5X86_FPU options SHMMAXPGS=16384 options SHMMNI=8192 options SHMSEG=4096 options DEVICE_POLLING options HZ=1000 options VESA device isa #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') #device sk # SysKonnect SK-984x and SK-982x gigabit ethernet # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device wlan # 802.11 support #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP #device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) #device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) # Local additions device tdfxdrm device sound # Sound device "snd_via82c686" # Sound hardware #device speaker # Play IBM BASIC-style noises out your speaker device uvisor device ucom device atapicam --=-cpZA0LUKnN3g1YaSQKjm Content-Disposition: attachment; filename=make.conf Content-Type: text/plain; name=make.conf; charset=UTF-8 Content-Transfer-Encoding: 7bit KERNCONF = RUSHLIGHT USA_RESIDENT = no COMPAT4X = yes MAKE_IDEA = yes CFLAGS = -O -pipe -g PPP_NOSUID = yes NOPROFILE = yes ENABLE_SUID_K5SU = yes CPUTYPE = athlon X_WINDOW_SYSTEM = xorg # global ports build options .if ${.CURDIR:M/usr/ports/*} WITH_OPTIMIZED_CFLAGS = yes .endif # per-port build options .if ${.CURDIR:M/usr/ports/*/ImageMagick} USA_RESIDENT = yes .endif .if ${.CURDIR:M/usr/ports/*/bochs} WITH_BOCHS_VESA = yes WITH_NE2000 = yes WITH_SOUND = yes .endif .if ${.CURDIR:M/usr/ports/*/cclient} WITH_SSL_AND_PLAINTEXT = yes .endif .if ${.CURDIR:M/usr/ports/*/cli} I_AGREE_TO_LICENSE_TERMS = yes NO_IGNORE = yes .endif .if ${.CURDIR:M/usr/ports/*/djbfft} WITH_OPT_PPRO = yes .endif .if ${.CURDIR:M/usr/ports/*/evolution} WITH_LDAP = yes .endif .if ${.CURDIR:M/usr/ports/*/fltk} WITH_THREADS = yes .endif .if ${.CURDIR:M/usr/ports/*/gaim} WITH_GNUTLS = yes .endif .if ${.CURDIR:M/usr/ports/*/gst-plugins} WITH_AALIB = yes WITH_ARTS = yes WITH_CDPARANOIA = yes WITH_CDROM_DEVICE = /dev/cd0 WITH_ESOUND = yes WITH_FAAC = yes WITH_FAAD = yes WITH_FLAC = yes WITH_FREETYPE = yes WITH_GDKPIXBUF = yes WITH_GSM = yes WITH_KIO = yes WITH_JPEG = yes WITH_LADSPA = yes WITH_LAME = yes WITH_LIBA52 = yes WITH_LIBAUDIOFILE = yes WITH_LIBCACA = yes WITH_LIBDV = yes WITH_LIBDVDNAV = yes WITH_LIBDVDREAD = yes WITH_LIBFAME = yes WITH_LIBMIKMOD = yes WITH_LIBMPEG2 = yes WITH_LIBMUSICBRAINZ = yes WITH_LIBSHOUT = yes WITH_LIBSIDPLAY = yes WITH_LIBSNDFILE = yes WITH_LIBTHEORA = yes WITH_PANGO = yes WITH_PNG = yes WITH_SDL = yes WITH_SMOOTHWAVE = yes WITH_SPEEX = yes WITH_SWFDEC = yes WITH_VORBIS = yes #WITH_VORBISIDEC = yes WITH_XINE = yes WITH_XVID = yes .endif .if ${.CURDIR:M/usr/ports/*/kde3} BATCH = yes .endif .if ${.CURDIR:M/usr/ports/*/kdebase*} WITH_MOTIF = yes .endif .if ${.CURDIR:M/usr/ports/*/kdegraphics*} WITH_GPHOTO2 = yes WITH_SANE = yes .endif .if ${.CURDIR:M/usr/ports/*/koffice} WITH_WV2 = yes .endif .if ${.CURDIR:M/usr/ports/*/libdvdread} WITH_OPTIMIZED_BYTESWAP = yes .endif .if ${.CURDIR:M/usr/ports/*/logjam*} #WITH_XMMS = yes WITH_GTKSPELL = yes WITH_GTKHTML = yes WITH_RSVG = yes .endif .if ${.CURDIR:M/usr/ports/*/lyx} WITH_QT = yes WITH_ASPELL = yes .endif .if ${.CURDIR:M/usr/ports/*/mozilla*} WITH_CALENDAR = yes .endif .if ${.CURDIR:M/usr/ports/*/mplayer} WITH_GUI = yes WITH_FREETYPE = yes .endif .if ${.CURDIR:M/usr/ports/*/nautilus} WITH_FULL_MOZILLA = yes .endif .if ${.CURDIR:M/usr/ports/*/ogle} WITH_OPTIMIZED_BYTESWAP = yes .endif .if ${.CURDIR:M/usr/ports/*/openoffice} WITH_TTF_BYTECODE_ENABLED = yes WITH_BSD_JDK = yes WITH_GIF_LZW_COMPRESSION = yes .endif .if ${.CURDIR:M/usr/ports/*/plugger} WITH_GNOME2 = yes WITH_MTV = yes .endif .if ${.CURDIR:M/usr/ports/*/subversion} JAVA_HOME = /usr/local/jdk1.4.1 WITH_APACHE2_APR = yes .endif .if ${.CURDIR:M/usr/ports/*/tinyfugue} WITH_MCCP = yes .endif .if ${.CURDIR:M/usr/ports/*/vim*} WITH_GTK2 = yes .endif .if ${.CURDIR:M/usr/ports/*/webfonts} WITH_ARIAL_UNICODE = yes .endif .if ${.CURDIR:M/usr/ports/*/windowmaker} WITH_KDE = yes WITH_XKB_STATUS = yes .endif .if ${.CURDIR:M/usr/ports/*/xemacs*-mule} WANT_MOTIF = yes .endif .if ${.CURDIR:M/usr/ports/*/zinf} WITH_ALL_PLUGINS = yes .endif # added by use.perl 2005-03-06 03:18:16 PERL_VER=5.8.6 PERL_VERSION=5.8.6 --=-cpZA0LUKnN3g1YaSQKjm Content-Disposition: attachment; filename=sysctl-a.out Content-Type: text/plain; name=sysctl-a.out; charset=UTF-8 Content-Transfer-Encoding: 7bit kern.ostype: FreeBSD kern.osrelease: 5.3-STABLE kern.osrevision: 199506 kern.version: FreeBSD 5.3-STABLE #0: Sun Mar 6 02:56:16 EST 2005 root@rushlight.kf8nh.com:/usr/src/sys/i386/compile/RUSHLIGHT kern.maxvnodes: 17814 kern.maxproc: 2020 kern.maxfiles: 4040 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: rushlight.kf8nh.com kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1112786449, usec = 366517 } Wed Apr 6 07:20:49 2005 kern.domainname: kern.osreldate: 503102 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 3636 kern.maxprocperuid: 1818 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 40 kern.ipc.max_hdr: 56 kern.ipc.max_datalen: 152 kern.ipc.nmbclusters: 9024 kern.ipc.maxpipekva: 4308992 kern.ipc.pipes: 238 kern.ipc.pipekva: 1802240 kern.ipc.pipefragretry: 0 kern.ipc.pipeallocfail: 0 kern.ipc.piperesizefail: 0 kern.ipc.piperesizeallowed: 1 kern.ipc.msgmax: 16384 kern.ipc.msgmni: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgtql: 40 kern.ipc.msgssz: 8 kern.ipc.msgseg: 2048 kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 67108864 kern.ipc.shmmin: 1 kern.ipc.shmmni: 8192 kern.ipc.shmseg: 4096 kern.ipc.shmall: 32768 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 1 kern.ipc.numopensockets: 278 kern.ipc.maxsockets: 9024 kern.ipc.nsfbufs: 2512 kern.ipc.nsfbufspeak: 6 kern.ipc.nsfbufsused: 0 kern.dummy: 0 kern.ps_strings: 3217031152 kern.usrstack: 3217031168 kern.logsigexit: 1 kern.iov_max: 1024 kern.cam.scsi_delay: 15000 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.cd.changer.max_busy_seconds: 15 kern.cam.cd.0.minimum_cmd_size: 10 kern.cam.cd.1.minimum_cmd_size: 10 kern.cam.da.retry_count: 4 kern.cam.da.default_timeout: 60 kern.disks: cd1 cd0 ad0 kern.geom.debugflags: 0 kern.geom.collectstats: 1 kern.elf32.fallback_brand: -1 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.cp_time: 7090166 3564998 2222160 591284 34399419 kern.openfiles: 692 kern.polling.burst: 5 kern.polling.each_burst: 5 kern.polling.burst_max: 150 kern.polling.idle_poll: 0 kern.polling.poll_in_trap: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 20 kern.polling.short_ticks: 0 kern.polling.lost_polls: 0 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 0 kern.polling.enable: 0 kern.polling.phase: 0 kern.polling.suspect: 0 kern.polling.stalled: 0 kern.polling.idlepoll_sleeping: 1 kern.kq_calloutmax: 4096 kern.stackprot: 7 kern.ps_arg_cache_limit: 256 kern.lastpid: 40989 kern.randompid: 0 kern.ktrace.genio_size: 4096 kern.ktrace.request_pool: 100 kern.module_path: /boot/kernel;/boot/modules kern.malloc: Type InUse MemUse HighUse Requests Size(s) linux 10 1K 1K 10 32 file desc 177 46K 54K 44293 16,32,256,512,1024,2048 cdev 78 20K 20K 78 256 atkbddev 2 1K 1K 2 32 $PIR 4 1K 1K 4 32 drm 75 14K 14K 160 16,32,64,4096 nexusdev 2 1K 1K 2 16 memdesc 1 4K 8K 38 32,4096 legacydrv 4 1K 1K 4 16 UMAHash 2 2K 3K 6 256,512,1024 VM pgdata 2 17K 17K 2 64 ATA generic 6 2K 3K 23 16,512 ATA CAM transport 2 1K 3K 44 32,64,256,1024 ISOFS mount 1 64K 64K 1 UFS mount 3 7K 7K 3 256,2048,4096 UFS ihash 1 64K 64K 1 UFS dirhash 219 41K 102K 7410 16,32,64,128,256,512 newdirblk 0 0K 1K 22 16 dirrem 1 1K 24K 61400 32 mkdir 0 0K 1K 172 32 diradd 2 1K 4K 62100 32 freefile 1 1K 29K 33698 32 freeblks 1 1K 226K 29713 256 freefrag 1 1K 5K 144307 32 allocindir 0 0K 157K 763343 64 indirdep 0 0K 49K 5226 32 allocdirect 2 1K 35K 185672 128 bmsafemap 2 1K 1K 21067 32 newblk 1 1K 1K 949016 64,256 inodedep 5 65K 180K 74207 128,256 pagedep 3 9K 10K 21377 64 p1003.1b 1 1K 1K 1 16 agp 2 257K 257K 2 16 NFS hash 1 64K 64K 1 syncache 1 8K 8K 1 isadev 36 3K 3K 36 64 hostcache 1 24K 24K 1 in_multi 2 1K 1K 2 32 routetbl 11 1K 2K 27 16,32,64,128,256 GEOM 80 15K 24K 337 16,32,64,128,256,512,1024,2048,4096 pfs_vncache 1 1K 1K 17 32 lo 1 1K 1K 1 1024 clone 1 4K 4K 1 4096 ether_multi 7 1K 1K 7 16,32,64 ifaddr 11 4K 4K 11 32,256,512,2048 BPF 2 1K 1K 2 64 mount 25 5K 5K 30 16,32,128,1024 pfs_fileno 2 40K 40K 2 vnodes 27 7K 7K 157 16,32,64,128,256 cluster_save buffer 0 0K 1K 32331 32,64 vfscache 1 128K 128K 1 BIO buffer 204 408K 760K 7927 2048 pfs_nodes 49 7K 7K 49 128 pcb 30 5K 6K 75872 16,32,64,2048 soname 126 15K 16K 175133 16,32,64,128 tag 0 0K 1K 2 32 ptys 13 2K 2K 13 128 ttys 2391 311K 324K 121041 128,512 shm 18 928K 1024K 2039 sem 4 7K 7K 4 512,1024,4096 msg 4 25K 25K 4 512,4096 iov 0 0K 1K 23159795 16,64,128,256,512 ioctlops 0 0K 4K 34 256,512,1024,2048,4096 turnstiles 241 16K 16K 241 64 taskqueue 5 1K 1K 5 64 DEVFS 164 24K 24K 257 16,32,128,4096 USBHC 2 1K 1K 2 16,64 sleep queues 241 8K 8K 241 32 sbuf 0 0K 21K 316 16,32,64,128,256,512,1024,2048,4096 rman 116 8K 8K 514 16,64 USBdev 4 1K 5K 13 64,128,512 USB 51 5K 5K 52 16,32,64,128,256 ACD driver 2 4K 4K 2 2048 kobj 108 216K 222K 238620 2048 eventhandler 31 2K 2K 31 32,128 devstat 6 13K 13K 6 16,4096 AD driver 1 1K 1K 1 128 bus-sc 45 20K 22K 280 16,32,64,128,256,512,1024,2048,4096 bus 552 24K 82K 1673 16,32,64,128,1024 SWAP 2 141K 141K 2 64 sysctltmp 0 0K 1K 96052 16,32,64,128 sysctloid 1751 52K 52K 1751 16,32,64 sysctl 0 0K 1K 936962 16,32,64 uidinfo 4 1K 1K 1880 32,256 plimit 15 4K 5K 22547 256 ATA DMA 2 1K 1K 2 128 cred 53 7K 8K 2567770 128 subproc 430 627K 724K 111084 32,256,4096 proc 2 2K 2K 2 1024 session 35 5K 5K 4754 128 pgrp 42 3K 3K 5001 64 mixer 1 1K 1K 1 1024 mtx_pool 1 8K 8K 1 module 183 12K 12K 183 64 ratefeed 1 20K 40K 10481 fmtfeed 0 0K 8K 20676 temp 11 116K 125K 83343 16,32,64,128,256,512,1024,2048,4096 devbuf 474 2131K 2567K 18031 16,32,64,128,256,512,1024,2048,4096 lockf 5 1K 1K 12298 64 feeder 57 2K 2K 298282 16,64 linker 54 181K 186K 106 16,32,256,1024,4096 ac97 2 1K 1K 2 16,256 entropy 1024 64K 64K 1024 64 KTRACE 100 13K 13K 100 128 ppbusdev 1 1K 1K 1 128 ithread 47 5K 5K 48 64,128 zombie 0 0K 3K 40846 128 proc-args 95 8K 9K 110788 16,32,64,128,256 kqueue 2 2K 6K 18346 128,1024 kenv 100 6K 6K 101 16,32,64,2048 sigio 2 1K 1K 6 32 kern.ident: RUSHLIGHT kern.maxusers: 125 kern.fallback_elf_brand: -1 kern.kstack_pages: 2 kern.sync_on_panic: 0 kern.shutdown.poweroff_delay: 5000 kern.shutdown.kproc_shutdown_wait: 60 kern.sugid_coredump: 0 kern.coredump: 1 kern.nodump_coredump: 0 kern.corefile: %N.core kern.fscale: 2048 kern.timecounter.stepwarnings: 0 kern.timecounter.nbinuptime: 1005809864 kern.timecounter.nnanouptime: 0 kern.timecounter.nmicrouptime: 41027 kern.timecounter.nbintime: 462922663 kern.timecounter.nnanotime: 202685020 kern.timecounter.nmicrotime: 260237626 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 63949938 kern.timecounter.ngetmicrouptime: 196341648 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetmicrotime: 2 kern.timecounter.nsetclock: 3 kern.timecounter.hardware: TSC kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000) kern.timecounter.tick: 1 kern.threads.thr_scope_sys: 0 kern.threads.thr_concurrency: 0 kern.threads.debug: 0 kern.threads.max_threads_per_proc: 1500 kern.threads.max_groups_per_proc: 1500 kern.threads.max_threads_hits: 0 kern.threads.virtual_cpu: 1 kern.ccpu: 1948 kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.devstat.numdevs: 5 kern.devstat.generation: 87 kern.devstat.version: 6 kern.kobj_methodcount: 108 kern.log_wakeups_per_second: 5 kern.log_console_output: 1 kern.always_console_output: 0 kern.msgbuf: kern.msgbuf_clear: 0 kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 kern.nselcoll: 4 kern.drainwait: 300 kern.tty_nin: 7540360 kern.tty_nout: 103614062 kern.console: consolectl,/ttyd0,consolectl, kern.consmute: 0 kern.consmsgbuf_size: 8192 kern.constty_wakeups_per_second: 5 kern.rootdev: ad0s1a kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 kern.minvnodes: 4453 kern.chroot_allow_open_directories: 1 kern.rpc.retries: 0 kern.rpc.request: 0 kern.rpc.timeouts: 0 kern.rpc.unexpected: 0 kern.rpc.invalid: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 6 Disk Wait: 0 Page Wait: 0 Sleep: 115) Virtual Memory: (Total: 2098004K, Active 921368K) Real Memory: (Total: 249172K Active 182228K) Shared Virtual Memory: (Total: 430864K Active: 295304K) Shared Real Memory: (Total: 53776K Active: 42404K) Free Memory Pages: 9060K vm.loadavg: { 0.32 0.38 0.39 } vm.v_free_min: 478 vm.v_free_target: 2076 vm.v_free_reserved: 164 vm.v_inactive_target: 3114 vm.v_cache_min: 2076 vm.v_cache_max: 4152 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size: 86257664 vm.kmem_size_max: 335544320 vm.kmem_size_scale: 3 vm.swap_async_max: 4 vm.dmmax: 32 vm.nswapdev: 1 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 vm.v_free_severe: 321 vm.stats.sys.v_swtch: 511344800 vm.stats.sys.v_trap: 131535570 vm.stats.sys.v_syscall: 1037956627 vm.stats.sys.v_intr: 583448656 vm.stats.sys.v_soft: 48816775 vm.stats.vm.v_vm_faults: 36478571 vm.stats.vm.v_cow_faults: 2183547 vm.stats.vm.v_cow_optim: 1121 vm.stats.vm.v_zfod: 18978619 vm.stats.vm.v_ozfod: 17034236 vm.stats.vm.v_swapin: 1373218 vm.stats.vm.v_swapout: 1249457 vm.stats.vm.v_swappgsin: 2645128 vm.stats.vm.v_swappgsout: 2832166 vm.stats.vm.v_vnodein: 292128 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodepgsin: 1199917 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_intrans: 1381886 vm.stats.vm.v_reactivated: 1613620 vm.stats.vm.v_pdwakeups: 29342 vm.stats.vm.v_pdpages: 279585378 vm.stats.vm.v_dfree: 1105 vm.stats.vm.v_pfree: 6937946 vm.stats.vm.v_tfree: 34427946 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_page_count: 63178 vm.stats.vm.v_free_reserved: 164 vm.stats.vm.v_free_target: 2076 vm.stats.vm.v_free_min: 478 vm.stats.vm.v_free_count: 166 vm.stats.vm.v_wire_count: 14807 vm.stats.vm.v_active_count: 40429 vm.stats.vm.v_inactive_target: 3114 vm.stats.vm.v_inactive_count: 5485 vm.stats.vm.v_cache_count: 2098 vm.stats.vm.v_cache_min: 2076 vm.stats.vm.v_cache_max: 4152 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_forks: 38053 vm.stats.vm.v_vforks: 2888 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_kthreads: 48 vm.stats.vm.v_forkpages: 29932794 vm.stats.vm.v_vforkpages: 208178 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.misc.zero_page_count: 117 vm.stats.misc.cnt_prezero: 20001128 vm.max_proc_mmap: 12684 vm.msync_flush_flags: 3 vm.old_msync: 0 vm.old_contigmalloc: 0 vm.idlezero_enable: 1 vm.idlezero_maxrun: 16 vm.max_launder: 32 vm.pageout_stats_max: 2076 vm.pageout_full_stats_interval: 20 vm.pageout_stats_interval: 5 vm.swap_idle_enabled: 0 vm.defer_swapspace_pageouts: 0 vm.disable_swapspace_pageouts: 0 vm.pageout_lock_miss: 0 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS FFS2 dinode: 256, 0, 9643, 47, 1838192 FFS1 dinode: 128, 0, 0, 0, 0 FFS inode: 140, 0, 9643, 45, 1838192 SWAPMETA: 276, 31598, 7267, 1063, 323245 rtentry: 132, 0, 4, 54, 4 unpcb: 140, 9044, 248, 60, 9013 ripcb: 180, 9042, 0, 44, 27 sackhole: 16, 0, 0, 203, 207 tcpreass: 20, 676, 0, 169, 37792 hostcache: 88, 15400, 13, 75, 520 syncache: 108, 15372, 0, 72, 1369 tcptw: 56, 1809, 0, 134, 2170 tcpcb: 452, 9027, 26, 28, 19027 inpcb: 180, 9042, 26, 40, 19027 udpcb: 180, 9042, 1, 109, 58307 socket: 324, 9024, 278, 82, 86375 KNOTE: 68, 0, 3, 109, 392403 AIOLIO: 44, 0, 0, 0, 0 AIOL: 64, 0, 0, 0, 0 AIOCB: 120, 0, 0, 0, 0 AIOP: 16, 0, 0, 0, 0 AIO: 88, 0, 0, 0, 0 PIPE: 384, 0, 119, 51, 44501 NFSNODE: 452, 0, 0, 0, 0 NFSMOUNT: 432, 0, 0, 0, 0 DIRHASH: 1024, 0, 312, 176, 9267 L VFS Cache: 291, 0, 19, 345, 21771 S VFS Cache: 68, 0, 10240, 2920, 2331997 NAMEI: 1024, 0, 0, 20, 81706945 VNODEPOLL: 64, 0, 1, 117, 1 VNODE: 264, 0, 9709, 11, 9709 ata_request: 200, 0, 0, 38, 3935442 g_bio: 132, 0, 0, 145, 15450873 MbufClust: 2048, 9024, 256, 6, 256 Mbuf: 256, 0, 259, 131, 42797684 Packet: 256, 0, 235, 155, 28753748 VMSPACE: 300, 0, 96, 47, 40936 UPCALL: 44, 0, 16, 140, 394 KSEGRP: 108, 0, 197, 48, 386 TID: 140, 0, 1, 53, 1 THREAD: 396, 0, 223, 17, 21916661 PROC: 452, 0, 143, 46, 40986 Files: 68, 0, 692, 148, 1940783 4096: 4096, 0, 202, 37, 48771 2048: 2048, 0, 339, 81, 246649 1024: 1024, 0, 47, 85, 21271 512: 512, 0, 146, 150, 36080 256: 256, 0, 506, 379, 102950 128: 128, 0, 3136, 374, 3028499 64: 64, 0, 2393, 1324, 25348162 32: 32, 0, 949, 520, 887743 16: 16, 0, 1912, 321, 810773 DP fakepg: 72, 0, 96, 63, 194 PV ENTRY: 24, 469655, 93681, 99024, 99694080 MAP ENTRY: 68, 0, 8281, 1183, 3859209 KMAP ENTRY: 68, 16016, 83, 141, 412845 MAP: 192, 0, 7, 33, 5 VM OBJECT: 132, 0, 13363, 1253, 1461975 128 Bucket: 524, 0, 603, 20, 0 64 Bucket: 268, 0, 20, 22, 0 32 Bucket: 140, 0, 30, 26, 0 16 Bucket: 76, 0, 13, 37, 0 UMA Hash: 128, 0, 4, 26, 0 UMA RCntSlab: 104, 0, 131, 17, 0 UMA Slabs: 64, 0, 733, 93, 0 UMA Zones: 88, 0, 65, 15, 0 UMA Kegs: 136, 0, 65, 7, 0 vm.kvm_size: 1073737728 vm.kvm_free: 750776320 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_mem: 348743 vfs.ufs.dirhash_docheck: 0 vfs.nfs4.access_cache_timeout: 60 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.realign_test: 0 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 4 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.access_cache_timeout: 60 vfs.nfs.nfsv3_commit_on_close: 0 vfs.devfs.noverflow: 32768 vfs.devfs.generation: 128 vfs.devfs.inodes: 128 vfs.devfs.topinode: 131 vfs.pfs.vncache.entries: 1 vfs.pfs.vncache.maxentries: 2 vfs.pfs.vncache.hits: 26 vfs.pfs.vncache.misses: 17 vfs.vmiodirenable: 1 vfs.runningbufspace: 0 vfs.bufspace: 36519936 vfs.maxbufspace: 37240832 vfs.bufmallocspace: 415744 vfs.maxmallocbufspace: 1829273 vfs.lobufspace: 36519936 vfs.hibufspace: 36585472 vfs.bufreusecnt: 2229 vfs.buffreekvacnt: 0 vfs.bufdefragcnt: 0 vfs.lorunningspace: 524288 vfs.hirunningspace: 1048576 vfs.dirtybufferflushes: 0 vfs.altbufferflushes: 0 vfs.recursiveflushes: 0 vfs.numdirtybuffers: 45 vfs.lodirtybuffers: 294 vfs.hidirtybuffers: 588 vfs.dirtybufthresh: 529 vfs.numfreebuffers: 2228 vfs.lofreebuffers: 131 vfs.hifreebuffers: 262 vfs.getnewbufcalls: 1217091 vfs.getnewbufrestarts: 0 vfs.flushwithdeps: 0 vfs.cache.numneg: 641 vfs.cache.numcache: 10259 vfs.cache.numcalls: 420132422 vfs.cache.dothits: 80921 vfs.cache.dotdothits: 207934 vfs.cache.numchecks: 475189708 vfs.cache.nummiss: 2393182 vfs.cache.nummisszap: 59159 vfs.cache.numposzaps: 28756 vfs.cache.numposhits: 413325875 vfs.cache.numnegzaps: 4210 vfs.cache.numneghits: 4032385 vfs.cache.nchstats: 413325875 4032385 32966 0 2452341 0 163448 203054 vfs.cache.numcwdcalls: 9767 vfs.cache.numcwdfail1: 3 vfs.cache.numcwdfail2: 2 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 0 vfs.cache.numcwdfound: 9762 vfs.cache.numfullpathcalls: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail3: 0 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 0 vfs.write_behind: 1 vfs.read_max: 8 vfs.opv_numops: 64 vfs.usermount: 0 vfs.numvnodes: 9709 vfs.wantfreevnodes: 25 vfs.freevnodes: 6953 vfs.reassignbufcalls: 3070198 vfs.nameileafonly: 0 vfs.timestamp_precision: 0 vfs.worklist_len: 5 vfs.ffs.doasyncfree: 1 vfs.ffs.doreallocblks: 1 vfs.aio.max_aio_procs: 32 vfs.aio.num_aio_procs: 0 vfs.aio.target_aio_procs: 4 vfs.aio.max_aio_queue: 1024 vfs.aio.num_queue_count: 0 vfs.aio.num_buf_aio: 0 vfs.aio.aiod_timeout: 10000 vfs.aio.aiod_lifetime: 30000 vfs.aio.unloadable: 0 vfs.aio.max_aio_per_proc: 32 vfs.aio.max_aio_queue_per_proc: 256 vfs.aio.max_buf_aio: 16 net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.inflight: 0 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomtime: 45 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.process_options: 1 net.inet.ip.maxfragpackets: 282 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.sendsourcequench: 0 net.inet.ip.random_id: 0 net.inet.ip.check_interface: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.maskfake: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.icmplim_output: 1 net.inet.icmp.reply_src: net.inet.icmp.bmcastecho: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.count: 13 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 0 net.inet.tcp.rfc3042: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.reass.maxsegments: 564 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.overflows: 0 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 4 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.newreno: 1 net.inet.tcp.sack.enable: 1 net.inet.tcp.minmss: 216 net.inet.tcp.minmssoverload: 0 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 26 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.stab: 20 net.inet.tcp.syncookies: 1 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 3 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 41600 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.udp.strict_mcast_mship: 0 net.inet.raw.maxdgram: 8192 net.inet.raw.recvspace: 8192 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 2 net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.ipfw: 0 net.isr.enable: 0 net.isr.count: 3124348 net.isr.directed: 0 net.isr.deferred: 3124348 net.isr.queued: 2709337 net.isr.drop: 0 net.isr.swi_count: 5829052 net.route.netisr_maxqlen: 256 debug.ddb_use_printf: 0 debug.doslowdown: 0 debug.elf32_trace: 0 debug.elf32_legacy_coredump: 0 debug.boothowto: -2147483648 debug.bootverbose: 0 debug.free_devt: 0 debug.sizeof.g_class: 68 debug.sizeof.g_geom: 68 debug.sizeof.g_provider: 88 debug.sizeof.g_consumer: 60 debug.sizeof.g_bioq: 48 debug.sizeof.vnode: 264 debug.sizeof.proc: 452 debug.sizeof.cdev: 232 debug.sizeof.bio: 132 debug.sizeof.buf: 436 debug.sizeof.kinfo_proc: 648 debug.sizeof.devstat: 240 debug.debugger_on_panic: 1 debug.trace_on_panic: 0 debug.to_avg_depth: 1134 debug.to_avg_gcalls: 6 debug.to_avg_mpcalls: 997 debug.kdb.available: ddb debug.kdb.current: ddb debug.kdb.enter: 0 debug.rman_debug: 0 debug.ttydebug: 0 debug.dobkgrdwrite: 1 debug.nchash: 32767 debug.ncnegfactor: 16 debug.numneg: 641 debug.numcache: 10259 debug.numcachehv: 1293 debug.vfscache: 1 debug.vnsize: 264 debug.ncsize: 36 debug.hashstat.nchash: 32768 8817 4 2690 debug.hashstat.nfsnode: 16384 0 0 0 debug.disablecwd: 0 debug.disablefullpath: 0 debug.rush_requests: 0 debug.vnlru_nowhere: 0 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 debug.mpsafenet: 1 debug.dopersistence: 0 debug.snapdebug: 0 debug.collectsnapstats: 0 debug.max_softdeps: 71256 debug.tickdelay: 2 debug.maxindirdeps: 50 debug.worklist_push: 0 debug.blk_limit_push: 0 debug.ino_limit_push: 0 debug.blk_limit_hit: 0 debug.ino_limit_hit: 0 debug.sync_limit_hit: 0 debug.indir_blk_ptrs: 314 debug.inode_bitmap: 7594 debug.direct_blk_ptrs: 5214 debug.dir_entry: 13788 debug.bigcgs: 0 debug.dircheck: 0 debug.mpsafevm: 1 debug.nosleepwithlocks: 0 debug.fdc.fifo: 8 debug.fdc.debugflags: 0 debug.fdc.retries: 10 debug.fdc.spec1: 175 debug.fdc.spec2: 16 debug.fdc.settle: 125 debug.PMAP1changed: 344813455 debug.PMAP1unchanged: 190541983 debug.psmhz: 20 debug.psm_soft_timeout: 500000 debug.psmerrsecs: 2 debug.psmerrusecs: 0 debug.psmsecs: 0 debug.psmusecs: 500000 debug.psmpkterrthresh: 2 debug.psmloglevel: 0 hw.machine: i386 hw.model: AMD Athlon(tm) Processor hw.ncpu: 1 hw.byteorder: 1234 hw.physmem: 263692288 hw.usermem: 203030528 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.cardbus.debug: 0 hw.cardbus.cis_debug: 0 hw.pccard.debug: 0 hw.pccard.cis_debug: 0 hw.cbb.start_memory: 2281701376 hw.cbb.start_16_io: 256 hw.cbb.start_32_io: 4096 hw.cbb.debug: 0 hw.pcic.intr_mask: 57016 hw.pci.enable_io_modes: 1 hw.pci.do_powerstate: 0 hw.pci.host_mem_start: 2147483648 hw.pci.irq_override_mask: 57080 hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 0 hw.snd.pcm0.buffersize: 4096 hw.snd.pcm0.vchans: 6 hw.intr_storm_threshold: 500 hw.availpages: 64378 hw.bus.devctl_disable: 0 hw.kbd.keymap_restrict_change: 0 hw.syscons.saver.keybonly: 1 hw.syscons.bell: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.busdma.total_bpages: 33 hw.busdma.zone0.total_bpages: 32 hw.busdma.zone0.free_bpages: 32 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 2 hw.busdma.zone0.boundary: 65536 hw.busdma.zone1.total_bpages: 1 hw.busdma.zone1.free_bpages: 1 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.boundary: 0 hw.clockrate: 751 hw.instruction_sse: 0 hw.dri.0.name: tdfx 0xf100 pci:0000:00:08.0 hw.dri.0.vm: slot offset size type flags address mtrr 0 0xc1b8f000 0x00002000 SHM 0x20 0xc1b8f000 no 1 0xd6000000 0x02000000 FB 0x00 0x00000000 yes 2 0xd4000000 0x02000000 REG 0x00 0xd0f4c000 no hw.dri.0.clients: a dev pid uid magic ioctls y 0 3733 0 0 1209822 machdep.adjkerntz: 0 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 0 machdep.conrclk: 1843200 machdep.gdbspeed: 9600 machdep.conspeed: 9600 machdep.enable_panic_key: 0 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.guessed_bootdev: 2686451712 machdep.kdb_on_nmi: 1 machdep.panic_on_nmi: 1 machdep.tsc_freq: 751709583 machdep.i8254_freq: 1193182 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 200112 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: 16 p1003_1b.aio_max: 1024 p1003_1b.aio_prio_delta_max: 0 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 compat.linux.osname: Linux compat.linux.osrelease: 2.4.2 compat.linux.oss_version: 198144 security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.getfsstatroot_only: 1 security.jail.allow_raw_sockets: 0 security.jail.jailed: 0 security.bsd.suser_enabled: 1 security.bsd.see_other_uids: 1 security.bsd.see_other_gids: 1 security.bsd.conservative_signals: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_uid: 0 security.bsd.hardlink_check_gid: 0 security.bsd.unprivileged_get_quota: 0 dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.npx.0.%desc: math processor dev.npx.0.%driver: npx dev.npx.0.%parent: nexus0 dev.legacy.0.%desc: legacy system dev.legacy.0.%driver: legacy dev.legacy.0.%parent: nexus0 dev.pcib.0.%desc: Host to PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%parent: legacy0 dev.pcib.1.%desc: PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=1 function=0 dev.pcib.1.%pnpinfo: vendor=0x1106 device=0x8391 subvendor=0x0080 subdevice=0x0000 class=0x060400 dev.pcib.1.%parent: pci0 dev.pir.0.%desc: PCI Interrupt Routing Table: 7 Entries dev.pir.0.%driver: pir dev.pir.0.%parent: legacy0 dev.pci.0.%desc: PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.1.%desc: PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.agp.0.%desc: VIA 8371 (Apollo KX133) host to PCI bridge dev.agp.0.%driver: agp dev.agp.0.%location: slot=0 function=0 dev.agp.0.%pnpinfo: vendor=0x1106 device=0x0391 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.agp.0.%parent: pci0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=7 function=0 dev.isab.0.%pnpinfo: vendor=0x1106 device=0x0686 subvendor=0x1106 subdevice=0x0000 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.atapci.0.%desc: VIA 82C686A UDMA66 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=7 function=1 dev.atapci.0.%pnpinfo: vendor=0x1106 device=0x0571 subvendor=0x0000 subdevice=0x0000 class=0x01018a dev.atapci.0.%parent: pci0 dev.ata.0.%driver: ata dev.ata.0.%parent: atapci0 dev.ata.1.%driver: ata dev.ata.1.%parent: atapci0 dev.uhci.0.%desc: VIA 83C572 USB controller dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=7 function=2 dev.uhci.0.%pnpinfo: vendor=0x1106 device=0x3038 subvendor=0x0925 subdevice=0x1234 class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.1.%desc: VIA 83C572 USB controller dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=7 function=3 dev.uhci.1.%pnpinfo: vendor=0x1106 device=0x3038 subvendor=0x0925 subdevice=0x1234 class=0x0c0300 dev.uhci.1.%parent: pci0 dev.usb.0.%desc: VIA 83C572 USB controller dev.usb.0.%driver: usb dev.usb.0.%parent: uhci0 dev.usb.1.%desc: VIA 83C572 USB controller dev.usb.1.%driver: usb dev.usb.1.%parent: uhci1 dev.uhub.0.%desc: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 dev.uhub.1.%driver: uhub dev.uhub.1.%location: port=0 dev.uhub.1.%pnpinfo: vendor=0x0451 product=0x2046 devclass=0x09 devsubclass=0x00 sernum="" dev.uhub.1.%parent: uhub0 dev.uhub.2.%desc: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usb1 dev.ums.0.%desc: Kensington Kensington USB Wheel Mouse, rev 1.10/1.00, addr 3, iclass 3/1 dev.ums.0.%driver: ums dev.ums.0.%location: port=0 interface=0 dev.ums.0.%pnpinfo: vendor=0x047d product=0x1012 devclass=0x00 devsubclass=0x00 sernum="" intclass=0x03 intsubclass=0x01 dev.ums.0.%parent: uhub1 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=7 function=4 dev.hostb.0.%pnpinfo: vendor=0x1106 device=0x3057 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.0.%parent: pci0 dev.pcm.0.%desc: VIA VT82C686A dev.pcm.0.%driver: pcm dev.pcm.0.%location: slot=7 function=5 dev.pcm.0.%pnpinfo: vendor=0x1106 device=0x3058 subvendor=0x1106 subdevice=0x4511 class=0x040100 dev.pcm.0.%parent: pci0 dev.drm.0.%desc: 3dfx Voodoo3 3000 dev.drm.0.%driver: drm dev.drm.0.%location: slot=8 function=0 dev.drm.0.%pnpinfo: vendor=0x121a device=0x0005 subvendor=0x121a subdevice=0x0057 class=0x030000 dev.drm.0.%parent: pci0 dev.sis.0.%desc: NatSemi DP8381[56] 10/100BaseTX dev.sis.0.%driver: sis dev.sis.0.%location: slot=9 function=0 dev.sis.0.%pnpinfo: vendor=0x100b device=0x0020 subvendor=0x1385 subdevice=0xf311 class=0x020000 dev.sis.0.%parent: pci0 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: sis0 dev.ukphy.0.%desc: Generic IEEE 802.3u media interface dev.ukphy.0.%driver: ukphy dev.ukphy.0.%parent: miibus0 dev.sym.0.%desc: 875 dev.sym.0.%driver: sym dev.sym.0.%location: slot=10 function=0 dev.sym.0.%pnpinfo: vendor=0x1000 device=0x000f subvendor=0x1000 subdevice=0x1000 class=0x010000 dev.sym.0.%parent: pci0 dev.cpu.0.%driver: cpu dev.cpu.0.%parent: legacy0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%parent: isa0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.fdc.0.%desc: Enhanced floppy controller dev.fdc.0.%driver: fdc dev.fdc.0.%parent: isa0 dev.fd.0.%desc: 1440-KB 3.5" drive dev.fd.0.%driver: fd dev.fd.0.%parent: fdc0 dev.ppc.0.%desc: Parallel port dev.ppc.0.%driver: ppc dev.ppc.0.%parent: isa0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.sio.0.%driver: sio dev.sio.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%parent: isa0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%parent: isa0 dev.attimer.1.%desc: AT realtime clock dev.attimer.1.%driver: attimer dev.attimer.1.%parent: isa0 dev.npxisa.0.%desc: Legacy ISA coprocessor support dev.npxisa.0.%driver: npxisa dev.npxisa.0.%parent: isa0 dev.sysresource.0.%desc: System Memory dev.sysresource.0.%driver: sysresource dev.sysresource.0.%parent: isa0 dev.pcibus_pnp.0.%desc: PCI Bus dev.pcibus_pnp.0.%driver: pcibus_pnp dev.pcibus_pnp.0.%parent: isa0 --=-cpZA0LUKnN3g1YaSQKjm-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 10 20:13:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7EC116A4CE for ; Sun, 10 Apr 2005 20:13:28 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22D3C43D45 for ; Sun, 10 Apr 2005 20:13:28 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) j3AKYREo087750; Sun, 10 Apr 2005 16:34:27 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [64.45.134.154] (dogpound.dyndns.org [64.45.134.154]) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id j3AKDBeE091596; Sun, 10 Apr 2005 16:13:11 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <425988DD.4040802@dmv.com> Date: Sun, 10 Apr 2005 16:13:17 -0400 From: Sven Willenberger User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brandon S. Allbery KF8NH" References: <1113160601.37307.9.camel@rushlight.kf8nh.com> In-Reply-To: <1113160601.37307.9.camel@rushlight.kf8nh.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 cc: stable@freebsd.org Subject: Re: 5.3-S (Mar 6) softdep stack backtrace from getdirtybuf()... problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 20:13:29 -0000 Brandon S. Allbery KF8NH presumably uttered the following on 04/10/05 15:16: > I have twice so far had the kernel syslog a stack backtrace with no > other information. Inspection of the kernel source, to the best of my > limited understanding, suggests that getdirtybuf() was handed a buffer > without an associated vnode. Kernel config file and make.conf attached. > > Should I be concerned? > > Note that this system is an older 600MHz Athlon with only 256MB RAM, and > both times this triggered it was thrashing quite a bit (that's more or > less its usual state...). > > KDB: stack backtrace: > kdb_backtrace(c06fbf78,2,c63ca26c,0,22) at kdb_backtrace+0x2e > getdirtybuf(d3196bac,0,1,c63ca26c,1) at getdirtybuf+0x2b > flush_deplist(c1a8544c,1,d3196bd4,d3196bd8,0) at flush_deplist+0x49 > flush_inodedep_deps(c11eb800,5858f,c1ea723c,d3196c34,c052952f) at flush_inodedep_deps+0x9e > softdep_sync_metadata(d3196ca4,c1ea7210,50,c06c9a19,0) at softdep_sync_metadata+0x9d > ffs_fsync(d3196ca4,0,0,0,0) at ffs_fsync+0x487 > fsync(c1b367d0,d3196d14,4,c10f9700,0) at fsync+0x196 > syscall(2f,2f,2f,8327600,5e) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x29152d6f, esp = 0xbf5a8d5c, ebp = 0xbf5a8d78 --- > > FreeBSD rushlight.kf8nh.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Sun Mar 6 02:56:16 EST 2005 root@rushlight.kf8nh.com:/usr/src/sys/i386/compile/RUSHLIGHT i386 > > I used to see this on a regular basis on several machines I had running early 5 through 5.2 releases and it seemed to have gone away (for me) with the 5.3 release(s). I never did hear of a definitive resolution for this issue; your backtrace is alarmingly similar to the one that I had seen. http://lists.freebsd.org/pipermail/freebsd-current/2004-July/031576.html Sven From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 00:23:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7F0916A4CE for ; Mon, 11 Apr 2005 00:23:58 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD8A43D31 for ; Mon, 11 Apr 2005 00:23:58 +0000 (GMT) (envelope-from ebm-freebsd-stable@swervinghead.com) Received: from remote.swervinghead.com (swervinghead.com[24.17.218.38]) by comcast.net (sccrmhc11) with SMTP id <2005041100235701100ekurce>; Mon, 11 Apr 2005 00:23:57 +0000 Received: (qmail 61860 invoked from network); 11 Apr 2005 00:23:56 -0000 Received: from unknown (HELO ?192.168.1.8?) (192.168.1.8) by remote.swervinghead.com with SMTP; 11 Apr 2005 00:23:56 -0000 Message-ID: <4259C39C.3010808@swervinghead.com> Date: Sun, 10 Apr 2005 17:23:56 -0700 From: Eric Marquez User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kernel errors : AE_NOT_FOUND X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ebm-freebsd-stable@swervinghead.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 00:23:58 -0000 I recently notice these errors in my dmesg. Can somebody help explain this to me. Do I need to worry about this? Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x80000800 real memory = 268419072 (255 MB) avail memory = 253014016 (241 MB) K6-family MTRR support enabled (2 registers) ACPI-0277: *** Warning: Invalid checksum in table [DSDT] (23, sum fc is not zero) ACPI-0452: *** Error: Looking up [PIRQ] in namespace, AE_NOT_FOUND ACPI-1303: *** Error: [NULL NAME], AE_NOT_FOUND ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: AE_NOT_FOUND ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NOT_FOUND ACPI: table load failed: AE_NOT_FOUND --ebm From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 00:27:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 252C616A4CE for ; Mon, 11 Apr 2005 00:27:01 +0000 (GMT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id F038B43D41 for ; Mon, 11 Apr 2005 00:27:00 +0000 (GMT) (envelope-from ebm-freebsd-stable@swervinghead.com) Received: from remote.swervinghead.com (swervinghead.com[24.17.218.38]) by comcast.net (rwcrmhc14) with SMTP id <20050411002700014002tis1e>; Mon, 11 Apr 2005 00:27:00 +0000 Received: (qmail 61944 invoked from network); 11 Apr 2005 00:26:59 -0000 Received: from unknown (HELO ?192.168.1.8?) (192.168.1.8) by remote.swervinghead.com with SMTP; 11 Apr 2005 00:26:59 -0000 Message-ID: <4259C453.9040008@swervinghead.com> Date: Sun, 10 Apr 2005 17:26:59 -0700 From: Eric Marquez User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4259C39C.3010808@swervinghead.com> In-Reply-To: <4259C39C.3010808@swervinghead.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kernel errors : AE_NOT_FOUND X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ebm-freebsd-stable@swervinghead.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 00:27:01 -0000 I forgot to add this part :-) FreeBSD 5.3-RELEASE #3: Sun Apr 10 17:11:03 PDT 2005 Eric Marquez wrote: > I recently notice these errors in my dmesg. Can somebody help explain > this to me. Do I need to worry about this? > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 > Features=0x8021bf > AMD Features=0x80000800 > real memory = 268419072 (255 MB) > avail memory = 253014016 (241 MB) > K6-family MTRR support enabled (2 registers) > ACPI-0277: *** Warning: Invalid checksum in table [DSDT] (23, sum > fc is not zero) > ACPI-0452: *** Error: Looking up [PIRQ] in namespace, AE_NOT_FOUND > ACPI-1303: *** Error: [NULL NAME], AE_NOT_FOUND > ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: > AE_NOT_FOUND > ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: > AE_NOT_FOUND > ACPI: table load failed: AE_NOT_FOUND > > --ebm > From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 03:32:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0EDD16A4DA for ; Mon, 11 Apr 2005 03:32:35 +0000 (GMT) Received: from neptune.atopia.net (neptune.atopia.net [209.128.231.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2BD343D49 for ; Mon, 11 Apr 2005 03:32:35 +0000 (GMT) (envelope-from dcp1990@neptune.atopia.net) Received: by neptune.atopia.net (Postfix, from userid 1034) id E84654114; Sun, 10 Apr 2005 23:32:34 -0400 (EDT) Date: Sun, 10 Apr 2005 23:32:34 -0400 From: Dan Ponte To: freebsd-stable@freebsd.org Message-ID: <20050411033234.GA7326@neptune.atopia.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <4259C39C.3010808@swervinghead.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <4259C39C.3010808@swervinghead.com> User-Agent: Mutt/1.5.8i Subject: Re: kernel errors : AE_NOT_FOUND X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 03:32:36 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 10, 2005 at 05:23:56PM -0700, Eric Marquez was witnessed plotting the following conspiracy: > I recently notice these errors in my dmesg. Can somebody help explain=20 > this to me. Do I need to worry about this? >=20 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x591 Stepping =3D 1 > Features=3D0x8021bf > AMD Features=3D0x80000800 > real memory =3D 268419072 (255 MB) > avail memory =3D 253014016 (241 MB) > K6-family MTRR support enabled (2 registers) > ACPI-0277: *** Warning: Invalid checksum in table [DSDT] (23, sum fc= =20 > is not zero) > ACPI-0452: *** Error: Looking up [PIRQ] in namespace, AE_NOT_FOUND > ACPI-1303: *** Error: [NULL NAME], AE_NOT_FOUND > ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace:=20 > AE_NOT_FOUND > ACPI-0213: *** Error: AcpiLoadTables: Could not load tables:=20 > AE_NOT_FOUND > ACPI: table load failed: AE_NOT_FOUND >=20 > --ebm >=20 You could try flashing your motherboard's BIOS to see if it mitigates it. -Dan --=20 Dan Ponte http://www.theamigan.net/ Hydrogen: A colorless, odorless, lighter than air gas which, given time, turns into people. -- Harlow Shapley --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWe/S8dUD8SpKFR8RAicXAJ4xBvzVCkLoux9jzOKfblt1fU2QDACfSBlZ Lt3RFVzTcVIjYROugrQ3ntU= =p0Kk -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 03:37:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E1BF16A4CE; Mon, 11 Apr 2005 03:37:50 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2C4443D55; Mon, 11 Apr 2005 03:37:48 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 458378568C; Mon, 11 Apr 2005 13:07:46 +0930 (CST) Date: Mon, 11 Apr 2005 13:07:46 +0930 From: Greg 'groggy' Lehey To: David O'Brien Message-ID: <20050411033746.GF84649@wantadilla.lemis.com> References: <200503301525.37798.peter@wemm.org> <20050331184524.GB1687@dragon.NUXI.org> <20050330222439.GU84137@wantadilla.lemis.com> <20050330223546.GA4705@troutmask.apl.washington.edu> <20050330224445.GW84137@wantadilla.lemis.com> <200503311032.33718.doconnor@gsoft.com.au> <20050331015429.GH6252@wantadilla.lemis.com> <20050331185902.GF1687@dragon.NUXI.org> <20050405003911.GT867@wantadilla.lemis.com> <20050408200418.GC3738@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z0eOaCaDLjvTGF2l" Content-Disposition: inline In-Reply-To: <20050408200418.GC3738@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-stable@FreeBSD.org cc: FreeBSD-amd64@FreeBSD.org Subject: Re: Problems with AMD64 and 8 GB RAM? (solved) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 03:37:50 -0000 --z0eOaCaDLjvTGF2l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 8 April 2005 at 13:04:18 -0700, David O'Brien wrote: > On Tue, Apr 05, 2005 at 10:09:11AM +0930, Greg 'groggy' Lehey wrote: >> The moral of the story is, I suppose, "don't buy the MSI K8T >> Master2-FAR". I was warned about the motherboard before I bought it, > > WHY?? There is nothing wrong with that motherboard -- I have three of > them. You are at fault for trying to treat a consumer desktop 2P mobo as > a high-end server one. "You are at fault for trying to used a mobo in an advertised configuration". Sorry, David. If a board doesn't perform as advertised, it's inferior. If you can find a way to work around, fine. I can too, and I have done. But the ability to find a workaround for a deficiency is no reason to say "There is nothing wrong with that motherboard". > People do not run 2GB DIMM's in an MSI K8T Master2-FAR. Indeed. You can't. > The MSI K8T Master2-FAR works fine with 1GB DIMM's. Where on MSI's > website did they state 2GB double-stacked DIMM's were supported? I can't be bothered to search their web site. It's on page 2-8 of the instructions supplied with the motherboard (document G52-S9130X3, version 1.2). Greg -- See complete headers for address and phone numbers. --z0eOaCaDLjvTGF2l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCWfEKIubykFB6QiMRAmlIAJ9O/6gH3evN+9RYEKKZyeZoPHTNUQCfYje7 0H8d5Ua9O/gdoZDY1UVG/js= =PDit -----END PGP SIGNATURE----- --z0eOaCaDLjvTGF2l-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 03:59:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B1B516A4CE for ; Mon, 11 Apr 2005 03:59:35 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B8143D1D for ; Mon, 11 Apr 2005 03:59:34 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 5FC461492B; Sun, 10 Apr 2005 22:59:34 -0500 (CDT) Date: Sun, 10 Apr 2005 22:59:34 -0500 (CDT) From: Mark Linimon X-X-Sender: linimon@pancho To: freebsd-stable@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: proposed changes to the PR submission article (fwd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 03:59:35 -0000 FYI: I have posted a CFD to freebsd-doc for some proposed changes to the above article to try to address some common problems we keep seeing with incoming PRs. Discussion should take place there. mcl From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 04:21:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 751B216A4CE for ; Mon, 11 Apr 2005 04:21:00 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E46243D41 for ; Mon, 11 Apr 2005 04:20:59 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j3B4Kwj2052660 for ; Sun, 10 Apr 2005 23:20:58 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Sun Apr 10 23:20:58 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j3B4KwAM052658; Sun, 10 Apr 2005 23:20:58 -0500 (CDT) (envelope-from karl) Message-ID: <20050410232058.A52635@denninger.net> Date: Sun, 10 Apr 2005 23:20:58 -0500 From: Karl Denninger To: "Matthew N. Dodd" References: <20050329200841.A772@denninger.net> <20050329233843.L328@sasami.jurai.net> <20050329234318.A3883@denninger.net> <20050330230046.A68235@denninger.net> <20050331110608.A81295@denninger.net> <20050405205000.A805@denninger.net> <20050407232725.F79906@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20050407232725.F79906@sasami.jurai.net>; from Matthew N. Dodd on Thu, Apr 07, 2005 at 11:28:18PM -0400 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! cc: freebsd-stable@freebsd.org Subject: Re: DANGER WILL ROBINSON! SERIOUS problem with current5.4-PRERELEASE - APPEARS FIXED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 04:21:00 -0000 It appears that this commit is good. Testing has been limited so far, but I've been unable to get it to misbehave. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Apr 07, 2005 at 11:28:18PM -0400, Matthew N. Dodd wrote: > Ok, I've committed code from -CURRENT that should correctly deal with this > situation. > > Let me know. > > (and thanks for tracking this down.) > > -- > 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [freebsd], message ok From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 05:11:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9C1016A4CE for ; Mon, 11 Apr 2005 05:11:54 +0000 (GMT) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2592243D45 for ; Mon, 11 Apr 2005 05:11:54 +0000 (GMT) (envelope-from dsze@alumni.uwaterloo.ca) Received: from eeyore.distrust.net (CPE00a0c978120d-CM00122570472e.cpe.net.cable.rogers.com [70.24.0.197]) (authenticated bits=0) by mail.distrust.net (8.13.1/8.12.11) with ESMTP id j3B5Bmbb039197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Apr 2005 00:11:51 -0500 (CDT) (envelope-from dsze@alumni.uwaterloo.ca) Message-Id: <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Apr 2005 01:12:10 -0400 To: Scott Long From: David Sze In-Reply-To: <4257F20C.70004@samsco.org> References: <4257F20C.70004@samsco.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_525762265==_" X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 19:01:27 2005 on mail.distrust.net X-Virus-Status: Clean cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 05:11:54 -0000 --=====================_525762265==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:17 AM 09/04/2005 -0600, Scott Long wrote this to All: >All, > >Thanks to the keen eye of David Sze, the cause of the instability in the >ips driver in FreeBSD 4.x might have been found. If it's affecting you, >please try the attached patch and let me know the results. I'll commit it >when everyone is happy with it. Scott, I think there's a problem with the ips_commands.c patch. After the bufq_first call succeeds, bufq_remove must be called before the splx or else the iobuf can get issued twice. However, if the subsequent ips_get_free_cmd fails, the iobuf must be put back on the bufq. Two patches are attached to this message: 1. ips.RELENG_4.stability.patch is just the stability patch as described. 2. ips.RELENG_4.mfc-and-stability.patch is an MFC of your IPS cleanup and optimization that you committed to HEAD on 01/28/05, plus the stability patch as described. Both patches survived a "make -j8 buildworld" for me. The problem I'm having now is that ips does not appear to be PAE-ified. With either patch the bus_dmamap_create call fails. Any pointers would be appreciated, this is new territory for me. >Thanks, > >Scott > > >Index: ips_commands.c >=================================================================== >RCS file: /usr/ncvs/src/sys/dev/ips/ips_commands.c,v >retrieving revision 1.11.6.1 >diff -u -r1.11.6.1 ips_commands.c >--- ips_commands.c 13 Jan 2005 00:46:40 -0000 1.11.6.1 >+++ ips_commands.c 9 Apr 2005 15:09:50 -0000 >@@ -162,8 +162,11 @@ > void ips_start_io_request(ips_softc_t *sc) > { > struct buf *iobuf; >+ int s > >+ s = splbio(); > iobuf = bufq_first(&sc->queue); >+ splx(s); > if(!iobuf) { > return; > } >@@ -171,8 +174,10 @@ > if(ips_get_free_cmd(sc, ips_send_io_request, iobuf, > IPS_NOWAIT_FLAG)){ > return; > } >- >+ >+ s = splbio(); > bufq_remove(&sc->queue, iobuf); >+ splx(s); > return; > } > >Index: ips_disk.c >=================================================================== >RCS file: /usr/ncvs/src/sys/dev/ips/ips_disk.c,v >retrieving revision 1.6.6.1 >diff -u -r1.6.6.1 ips_disk.c >--- ips_disk.c 13 Jan 2005 00:46:40 -0000 1.6.6.1 >+++ ips_disk.c 9 Apr 2005 15:07:50 -0000 >@@ -128,12 +128,15 @@ > static void ipsd_strategy(struct buf *iobuf) > { > ipsdisk_softc_t *dsc; >+ int s; > > dsc = iobuf->b_dev->si_drv1; > DEVICE_PRINTF(8,dsc->dev,"in strategy\n"); > devstat_start_transaction(&dsc->stats); > iobuf->b_driver1 = (void > *)(uintptr_t)dsc->sc->drives[dsc->disk_number].drivenum; >- bufqdisksort(&dsc->sc->queue, iobuf); >+ s = splbio(); >+ bufq_insert_tail(&dsc->sc->queue, iobuf); >+ splx(s); > ips_start_io_request(dsc->sc); > } > --=====================_525762265==_ Content-Type: application/octet-stream; name="ips.RELENG_4.stability.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ips.RELENG_4.stability.patch" SW5kZXg6IGlwc19jb21tYW5kcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvbmN2cy9zcmMv c3lzL2Rldi9pcHMvaXBzX2NvbW1hbmRzLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTEuNi4x CmRpZmYgLXUgLXIxLjExLjYuMSBpcHNfY29tbWFuZHMuYwotLS0gaXBzX2NvbW1hbmRzLmMJMTMg SmFuIDIwMDUgMDA6NDY6NDAgLTAwMDAJMS4xMS42LjEKKysrIGlwc19jb21tYW5kcy5jCTExIEFw ciAyMDA1IDA0OjUwOjUzIC0wMDAwCkBAIC0xNjIsMTcgKzE2MiwyNCBAQAogdm9pZCBpcHNfc3Rh cnRfaW9fcmVxdWVzdChpcHNfc29mdGNfdCAqc2MpCiB7CiAJc3RydWN0IGJ1ZiAqaW9idWY7CisJ aW50cm1hc2tfdCBtYXNrOwogCisJbWFzayA9IHNwbGJpbygpOwogCWlvYnVmID0gYnVmcV9maXJz dCgmc2MtPnF1ZXVlKTsKIAlpZighaW9idWYpIHsKKwkJc3BseChtYXNrKTsKIAkJcmV0dXJuOwog CX0KKwlidWZxX3JlbW92ZSgmc2MtPnF1ZXVlLCBpb2J1Zik7CisJc3BseChtYXNrKTsKIAogCWlm KGlwc19nZXRfZnJlZV9jbWQoc2MsIGlwc19zZW5kX2lvX3JlcXVlc3QsIGlvYnVmLCBJUFNfTk9X QUlUX0ZMQUcpKXsKKwkJbWFzayA9IHNwbGJpbygpOworCQlidWZxX2luc2VydF90YWlsKCZzYy0+ cXVldWUsIGlvYnVmKTsKKwkJc3BseChtYXNrKTsKIAkJcmV0dXJuOwogCX0KIAkKLQlidWZxX3Jl bW92ZSgmc2MtPnF1ZXVlLCBpb2J1Zik7CiAJcmV0dXJuOwogfQogCkluZGV4OiBpcHNfZGlzay5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvbmN2cy9zcmMvc3lzL2Rldi9pcHMvaXBzX2Rpc2su Yyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS42LjYuMQpkaWZmIC11IC1yMS42LjYuMSBpcHNfZGlz ay5jCi0tLSBpcHNfZGlzay5jCTEzIEphbiAyMDA1IDAwOjQ2OjQwIC0wMDAwCTEuNi42LjEKKysr IGlwc19kaXNrLmMJMTEgQXByIDIwMDUgMDM6MTk6NTIgLTAwMDAKQEAgLTEyOCwxMiArMTI4LDE1 IEBACiBzdGF0aWMgdm9pZCBpcHNkX3N0cmF0ZWd5KHN0cnVjdCBidWYgKmlvYnVmKQogewogCWlw c2Rpc2tfc29mdGNfdCAqZHNjOworCWludHJtYXNrX3QgbWFzazsKIAogCWRzYyA9IGlvYnVmLT5i X2Rldi0+c2lfZHJ2MTsJCiAJREVWSUNFX1BSSU5URig4LGRzYy0+ZGV2LCJpbiBzdHJhdGVneVxu Iik7CiAJZGV2c3RhdF9zdGFydF90cmFuc2FjdGlvbigmZHNjLT5zdGF0cyk7CiAJaW9idWYtPmJf ZHJpdmVyMSA9ICh2b2lkICopKHVpbnRwdHJfdClkc2MtPnNjLT5kcml2ZXNbZHNjLT5kaXNrX251 bWJlcl0uZHJpdmVudW07Ci0JYnVmcWRpc2tzb3J0KCZkc2MtPnNjLT5xdWV1ZSwgaW9idWYpOwor CW1hc2sgPSBzcGxiaW8oKTsKKwlidWZxX2luc2VydF90YWlsKCZkc2MtPnNjLT5xdWV1ZSwgaW9i dWYpOworCXNwbHgobWFzayk7CiAJaXBzX3N0YXJ0X2lvX3JlcXVlc3QoZHNjLT5zYyk7CiB9CiAK --=====================_525762265==_ Content-Type: application/octet-stream; name="ips.RELENG_4.mfc-and-stability.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ips.RELENG_4.mfc-and-stability.patch" SW5kZXg6IGlwcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvbmN2cy9zcmMvc3lzL2Rldi9p cHMvaXBzLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMuNi4xCmRpZmYgLXUgLXIxLjEzLjYu MSBpcHMuYwotLS0gaXBzLmMJMTMgSmFuIDIwMDUgMDA6NDY6NDAgLTAwMDAJMS4xMy42LjEKKysr IGlwcy5jCTkgQXByIDIwMDUgMTM6NDA6MzAgLTAwMDAKQEAgLTEwOSw3ICsxMDksNyBAQAogfQog CiAvKiBpcyBsb2NraW5nIG5lZWRlZD8gd2hhdCBsb2NraW5nIGd1YXJlbnRlZXMgYXJlIHRoZXJl IG9uIHJlbW92YWw/ICovCi1zdGF0aWMgX19pbmxpbmVfXyBpbnQgaXBzX2NtZHF1ZXVlX2ZyZWUo aXBzX3NvZnRjX3QgKnNjKQorc3RhdGljIGludCBpcHNfY21kcXVldWVfZnJlZShpcHNfc29mdGNf dCAqc2MpCiB7CiAJaW50IGksIGVycm9yID0gLTE7CiAJaXBzX2NvbW1hbmRfdCAqY29tbWFuZDsK QEAgLTEyOCwyMiArMTI4LDMyIEBACiAJCQlidXNfZG1hbWVtX2ZyZWUoc2MtPmNvbW1hbmRfZG1h dGFnLCAKIAkJCQkJY29tbWFuZC0+Y29tbWFuZF9idWZmZXIsCiAJCQkJCWNvbW1hbmQtPmNvbW1h bmRfZG1hbWFwKTsKKwkJCWlmIChjb21tYW5kLT5kYXRhX2RtYW1hcCAhPSBOVUxMKQorCQkJCWJ1 c19kbWFtYXBfZGVzdHJveShjb21tYW5kLT5kYXRhX2RtYXRhZywKKwkJCQkgICAgY29tbWFuZC0+ ZGF0YV9kbWFtYXApOwogCQl9CiAJCWVycm9yID0gMDsKIAkJc2MtPnN0YXRlIHw9IElQU19PRkZM SU5FOwogCX0KKwlzYy0+c3RhdGljY21kID0gTlVMTDsKKwlmcmVlKHNjLT5jb21tYW5kYXJyYXks IE1fREVWQlVGKTsKIAlzcGx4KG1hc2spOwogCXJldHVybiBlcnJvcjsKIH0KIAogLyogcGxhY2Vz IGFsbCBpcHMgY29tbWFuZCBzdHJ1Y3RzIG9uIHRoZSBmcmVlIGNvbW1hbmQgcXVldWUuICBObyBs b2NraW5nIGFzIGlmIHNvbWVvbmUgZWxzZSB0cmllcwogICogdG8gYWNjZXNzIHRoaXMgZHVyaW5n IGluaXQsIHdlIGhhdmUgYmlnZ2VyIHByb2JsZW1zICovCi1zdGF0aWMgX19pbmxpbmVfXyBpbnQg aXBzX2NtZHF1ZXVlX2luaXQoaXBzX3NvZnRjX3QgKnNjKQorc3RhdGljIGludCBpcHNfY21kcXVl dWVfaW5pdChpcHNfc29mdGNfdCAqc2MpCiB7CiAJaW50IGk7CiAJaXBzX2NvbW1hbmRfdCAqY29t bWFuZDsKKworCXNjLT5jb21tYW5kYXJyYXkgPSAoaXBzX2NvbW1hbmRfdCAqKW1hbGxvYyhzaXpl b2YoaXBzX2NvbW1hbmRfdCkgKgorCSAgICBzYy0+bWF4X2NtZHMsIE1fREVWQlVGLCBNX05PV0FJ VHxNX1pFUk8pOworCWlmIChzYy0+Y29tbWFuZGFycmF5ID09IE5VTEwpCisJCXJldHVybiAoRU5P TUVNKTsKKwogCVNMSVNUX0lOSVQoJnNjLT5mcmVlX2NtZF9saXN0KTsKLQlTVEFJTFFfSU5JVCgm c2MtPmNtZF93YWl0X2xpc3QpOwogCWZvcihpID0gMDsgaSA8IHNjLT5tYXhfY21kczsgaSsrKXsK IAkJY29tbWFuZCA9ICZzYy0+Y29tbWFuZGFycmF5W2ldOwogCQljb21tYW5kLT5pZCA9IGk7CkBA IC0xNjEsNyArMTcxLDE0IEBACiAJCQlnb3RvIGVycm9yOwogCQl9CiAKLQkJU0xJU1RfSU5TRVJU X0hFQUQoJnNjLT5mcmVlX2NtZF9saXN0LCBjb21tYW5kLCBuZXh0KTsJCisgCQlpZiAoaSAhPSAw KSB7CisgCQkJY29tbWFuZC0+ZGF0YV9kbWF0YWcgPSBzYy0+c2dfZG1hdGFnOworIAkJCWlmIChi dXNfZG1hbWFwX2NyZWF0ZShjb21tYW5kLT5kYXRhX2RtYXRhZywgMCwKKyAJCQkgICAgJmNvbW1h bmQtPmRhdGFfZG1hbWFwKSkKKyAJCQkJZ290byBlcnJvcjsKKyAJCQlTTElTVF9JTlNFUlRfSEVB RCgmc2MtPmZyZWVfY21kX2xpc3QsIGNvbW1hbmQsIG5leHQpOwkKKyAJCX0gZWxzZQorIAkJCXNj LT5zdGF0aWNjbWQgPSBjb21tYW5kOwogCX0KIAlzYy0+c3RhdGUgJj0gfklQU19PRkZMSU5FOwog CXJldHVybiAwOwpAQCAtMTcwLDc1ICsxODcsMTIgQEAKIAlyZXR1cm4gRU5PTUVNOwogfQogCi1z dGF0aWMgaW50IGlwc19hZGRfd2FpdGluZ19jb21tYW5kKGlwc19zb2Z0Y190ICpzYywgaW50ICgq Y2FsbGJhY2spKGlwc19jb21tYW5kX3QgKiksIHZvaWQgKmRhdGEsIHVuc2lnbmVkIGxvbmcgZmxh Z3MpCi17Ci0JaW50cm1hc2tfdCBtYXNrOwotCWlwc19jb21tYW5kX3QgKmNvbW1hbmQ7Ci0JaXBz X3dhaXRfbGlzdF90ICp3YWl0ZXI7Ci0JdW5zaWduZWQgbG9uZyBtZW1mbGFncyA9IDA7Ci0JaWYo SVBTX05PV0FJVF9GTEFHICYgZmxhZ3MpCi0JCW1lbWZsYWdzID0gTV9OT1dBSVQ7Ci0Jd2FpdGVy ID0gbWFsbG9jKHNpemVvZihpcHNfd2FpdF9saXN0X3QpLCBNX0lQU0JVRiwgbWVtZmxhZ3MpOwot CWlmKCF3YWl0ZXIpCi0JCXJldHVybiBFTk9NRU07Ci0JbWFzayA9IHNwbGJpbygpOwotCWlmKHNj LT5zdGF0ZSAmIElQU19PRkZMSU5FKXsKLQkJc3BseChtYXNrKTsKLQkJZnJlZSh3YWl0ZXIsIE1f SVBTQlVGKTsKLQkJcmV0dXJuIEVJTzsKLQl9Ci0JY29tbWFuZCA9IFNMSVNUX0ZJUlNUKCZzYy0+ ZnJlZV9jbWRfbGlzdCk7Ci0JaWYoY29tbWFuZCAmJiAhKHNjLT5zdGF0ZSAmIElQU19USU1FT1VU KSl7Ci0JCVNMSVNUX1JFTU9WRV9IRUFEKCZzYy0+ZnJlZV9jbWRfbGlzdCwgbmV4dCk7Ci0JCShz Yy0+dXNlZF9jb21tYW5kcykrKzsKLQkJc3BseChtYXNrKTsKLQkJY2xlYXJfaXBzX2NvbW1hbmQo Y29tbWFuZCk7Ci0JCWJ6ZXJvKGNvbW1hbmQtPmNvbW1hbmRfYnVmZmVyLCBJUFNfQ09NTUFORF9M RU4pOwotCQlmcmVlKHdhaXRlciwgTV9JUFNCVUYpOwotCQljb21tYW5kLT5hcmcgPSBkYXRhOwot CQlyZXR1cm4gY2FsbGJhY2soY29tbWFuZCk7Ci0JfQotCURFVklDRV9QUklOVEYoMSwgc2MtPmRl diwgImFkZGluZyBjb21tYW5kIHRvIHRoZSB3YWl0IHF1ZXVlXG4iKTsgCi0Jd2FpdGVyLT5jYWxs YmFjayA9IGNhbGxiYWNrOyAKLQl3YWl0ZXItPmRhdGEgPSBkYXRhOwotCVNUQUlMUV9JTlNFUlRf VEFJTCgmc2MtPmNtZF93YWl0X2xpc3QsIHdhaXRlciwgbmV4dCk7Ci0Jc3BseChtYXNrKTsKLQly ZXR1cm4gMDsKLX0KLQotc3RhdGljIHZvaWQgaXBzX3J1bl93YWl0aW5nX2NvbW1hbmQoaXBzX3Nv ZnRjX3QgKnNjKQotewotCWlwc193YWl0X2xpc3RfdCAqd2FpdGVyOwotCWlwc19jb21tYW5kX3QJ KmNvbW1hbmQ7Ci0JaW50ICgqY2FsbGJhY2spKGlwc19jb21tYW5kX3QqKTsKLQlpbnRybWFza190 IG1hc2s7Ci0KLQltYXNrID0gc3BsYmlvKCk7Ci0Jd2FpdGVyID0gU1RBSUxRX0ZJUlNUKCZzYy0+ Y21kX3dhaXRfbGlzdCk7Ci0JY29tbWFuZCA9IFNMSVNUX0ZJUlNUKCZzYy0+ZnJlZV9jbWRfbGlz dCk7Ci0JaWYoIXdhaXRlciB8fCAhY29tbWFuZCl7Ci0JCXNwbHgobWFzayk7Ci0JCXJldHVybjsK LQl9Ci0JREVWSUNFX1BSSU5URigxLCBzYy0+ZGV2LCAicmVtb3ZpbmcgY29tbWFuZCBmcm9tIHdh aXQgcXVldWVcbiIpOwotCVNMSVNUX1JFTU9WRV9IRUFEKCZzYy0+ZnJlZV9jbWRfbGlzdCwgbmV4 dCk7Ci0JU1RBSUxRX1JFTU9WRV9IRUFEKCZzYy0+Y21kX3dhaXRfbGlzdCwgbmV4dCk7Ci0JKHNj LT51c2VkX2NvbW1hbmRzKSsrOwotCXNwbHgobWFzayk7Ci0JY2xlYXJfaXBzX2NvbW1hbmQoY29t bWFuZCk7Ci0JYnplcm8oY29tbWFuZC0+Y29tbWFuZF9idWZmZXIsIElQU19DT01NQU5EX0xFTik7 Ci0JY29tbWFuZC0+YXJnID0gd2FpdGVyLT5kYXRhOwotCWNhbGxiYWNrID0gd2FpdGVyLT5jYWxs YmFjazsKLQlmcmVlKHdhaXRlciwgTV9JUFNCVUYpOwotCWNhbGxiYWNrKGNvbW1hbmQpOwotCXJl dHVybjsJCi19CiAvKiByZXR1cm5zIGEgZnJlZSBjb21tYW5kIHN0cnVjdCBpZiBvbmUgaXMgYXZh aWxhYmxlLiAKICAqIEl0IGFsc28gYmxhbmtzIG91dCBhbnl0aGluZyB0aGF0IG1heSBiZSBhIHdp bGQgcG9pbnRlci92YWx1ZS4KICAqIEFsc28sIGNvbW1hbmQgYnVmZmVycyBhcmUgbm90IGZyZWVk LiAgVGhleSBhcmUKICAqIHNtYWxsIHNvIHRoZXkgYXJlIHNhdmVkIGFuZCBrZXB0IGRtYW1hcHBl ZCBhbmQgbG9hZGVkLgogICovCi1pbnQgaXBzX2dldF9mcmVlX2NtZChpcHNfc29mdGNfdCAqc2Ms IGludCAoKmNhbGxiYWNrKShpcHNfY29tbWFuZF90ICopLCB2b2lkICpkYXRhLCB1bnNpZ25lZCBs b25nIGZsYWdzKQoraW50IGlwc19nZXRfZnJlZV9jbWQoaXBzX3NvZnRjX3QgKnNjLCBpcHNfY29t bWFuZF90ICoqY21kLCB1bnNpZ25lZCBsb25nIGZsYWdzKQogewogCWludHJtYXNrX3QgbWFzazsK IAlpcHNfY29tbWFuZF90ICpjb21tYW5kOwpAQCAtMjQ4LDIwICsyMDIsMjcgQEAKIAkJc3BseCht YXNrKTsKIAkJcmV0dXJuIEVJTzsKIAl9Ci0JY29tbWFuZCA9IFNMSVNUX0ZJUlNUKCZzYy0+ZnJl ZV9jbWRfbGlzdCk7Ci0JaWYoIWNvbW1hbmQgfHwgKHNjLT5zdGF0ZSAmIElQU19USU1FT1VUKSl7 Ci0JCXNwbHgobWFzayk7Ci0JCWlmKGZsYWdzICYgSVBTX05PV0FJVF9GTEFHKQorCWlmICgoZmxh Z3MgJiBJUFNfU1RBVElDX0ZMQUcpID09IDApIHsKKwkJY29tbWFuZCA9IFNMSVNUX0ZJUlNUKCZz Yy0+ZnJlZV9jbWRfbGlzdCk7CisJCWlmKCFjb21tYW5kIHx8IChzYy0+c3RhdGUgJiBJUFNfVElN RU9VVCkpeworCQkJc3BseChtYXNrKTsKKwkJCXJldHVybiBFQlVTWTsKKwkJfQorCQlTTElTVF9S RU1PVkVfSEVBRCgmc2MtPmZyZWVfY21kX2xpc3QsIG5leHQpOworCQkoc2MtPnVzZWRfY29tbWFu ZHMpKys7CisJfSBlbHNlIHsKKwkJaWYgKHNjLT5zdGF0ZSAmIElQU19TVEFUSUNfQlVTWSl7CisJ CQlzcGx4KG1hc2spOwogCQkJcmV0dXJuIEVBR0FJTjsKLQkJcmV0dXJuIGlwc19hZGRfd2FpdGlu Z19jb21tYW5kKHNjLCBjYWxsYmFjaywgZGF0YSwgZmxhZ3MpOworCQl9CisJCWNvbW1hbmQgPSBz Yy0+c3RhdGljY21kOworCQlzYy0+c3RhdGUgfD0gSVBTX1NUQVRJQ19CVVNZOwogCX0KLQlTTElT VF9SRU1PVkVfSEVBRCgmc2MtPmZyZWVfY21kX2xpc3QsIG5leHQpOwotCShzYy0+dXNlZF9jb21t YW5kcykrKzsKIAlzcGx4KG1hc2spOwogCWNsZWFyX2lwc19jb21tYW5kKGNvbW1hbmQpOwogCWJ6 ZXJvKGNvbW1hbmQtPmNvbW1hbmRfYnVmZmVyLCBJUFNfQ09NTUFORF9MRU4pOwotCWNvbW1hbmQt PmFyZyA9IGRhdGE7Ci0JcmV0dXJuIGNhbGxiYWNrKGNvbW1hbmQpOworCSpjbWQgPSBjb21tYW5k OworCXJldHVybiAwOwogfQogCiAvKiBhZGRzIGEgY29tbWFuZCBiYWNrIHRvIHRoZSBmcmVlIGNv bW1hbmQgcXVldWUgKi8KQEAgLTI3MCwxMSArMjMxLDEzIEBACiAJaW50cm1hc2tfdCBtYXNrOwog CW1hc2sgPSBzcGxiaW8oKTsKIAotCVNMSVNUX0lOU0VSVF9IRUFEKCZzYy0+ZnJlZV9jbWRfbGlz dCwgY29tbWFuZCwgbmV4dCk7Ci0JKHNjLT51c2VkX2NvbW1hbmRzKS0tOworCWlmIChjb21tYW5k ICE9IHNjLT5zdGF0aWNjbWQpIHsKKwkJU0xJU1RfSU5TRVJUX0hFQUQoJnNjLT5mcmVlX2NtZF9s aXN0LCBjb21tYW5kLCBuZXh0KTsKKwkJKHNjLT51c2VkX2NvbW1hbmRzKS0tOworCX0gZWxzZSB7 CisJCXNjLT5zdGF0ZSAmPSB+SVBTX1NUQVRJQ19CVVNZOworCX0KIAlzcGx4KG1hc2spOwotCWlm KCEoc2MtPnN0YXRlICYgSVBTX1RJTUVPVVQpKQotCQlpcHNfcnVuX3dhaXRpbmdfY29tbWFuZChz Yyk7CiB9CiBzdGF0aWMgY29uc3QgY2hhciogaXBzX2Rpc2tkZXZfc3RhdGVuYW1lKHVfaW50OF90 IHN0YXRlKQogewpAQCAtMzc5LDcgKzM0Miw2IEBACiAJCQkgICB3b3VsZCBnbyB0byB0aGUgY2Fy ZC4gVGhpcyBzdWNrcy4gKi8KIAkJfSBlbHNlCiAJCQlzYy0+c3RhdGUgJj0gfklQU19USU1FT1VU OwotCQlpcHNfcnVuX3dhaXRpbmdfY29tbWFuZChzYyk7CiAJfQogCWlmIChzYy0+c3RhdGUgIT0g SVBTX09GRkxJTkUpCiAJCXNjLT50aW1lciA9IHRpbWVvdXQoaXBzX3RpbWVvdXQsIHNjLCAxMCpo eik7CkluZGV4OiBpcHMuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdmFyL25jdnMvc3JjL3N5cy9k ZXYvaXBzL2lwcy5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjExLjYuMQpkaWZmIC11IC1yMS4x MS42LjEgaXBzLmgKLS0tIGlwcy5oCTEzIEphbiAyMDA1IDAwOjQ2OjQwIC0wMDAwCTEuMTEuNi4x CisrKyBpcHMuaAkxMSBBcHIgMjAwNSAwMTo1MTo0MyAtMDAwMApAQCAtNjksMTIgKzY5LDEzIEBA CiAjZGVmaW5lIElQU19NQVhfU0dfTEVOCQkJKHNpemVvZihpcHNfc2dfZWxlbWVudF90KSAqIElQ U19NQVhfU0dfRUxFTUVOVFMpCiAjZGVmaW5lIElQU19OVlJBTV9QQUdFX1NJWkUJCTEyOAogLyog dmFyaW91cyBmbGFncyAqLwotI2RlZmluZSBJUFNfTk9XQUlUX0ZMQUcJCQkxCisjZGVmaW5lIElQ U19TVEFUSUNfRkxBRwkJCTB4MDEKIAogLyogc3RhdGVzIGZvciB0aGUgY2FyZCB0byBiZSBpbiAq LwogI2RlZmluZSBJUFNfREVWX09QRU4JCQkweDAxCiAjZGVmaW5lIElQU19USU1FT1VUCQkJMHgw MiAvKiBjb21tYW5kIHRpbWUgb3V0LCBuZWVkIHJlc2V0ICovCiAjZGVmaW5lIElQU19PRkZMSU5F CQkJMHgwNCAvKiBjYW4ndCByZXNldCBjYXJkL2NhcmQgZmFpbHVyZSAqLworI2RlZmluZSBJUFNf U1RBVElDX0JVU1kJCQkweDA4CiAKIC8qIG1heCBudW1iZXIgb2YgY29tbWFuZHMgc2V0IHRvIHNv bWV0aGluZyBsb3cgZm9yIG5vdyAqLwogI2RlZmluZSBJUFNfTUFYX0NNRF9OVU0JCQkxMjgJCkBA IC0zNzcsMjQgKzM3OCwxOCBAQAogCXVfaW50OF90IAkJaWQ7CiAJdV9pbnQ4X3QJCXRpbWVvdXQ7 CiAJc3RydWN0IGlwc19zb2Z0YyAqCXNjOworCWJ1c19kbWFfdGFnX3QJCWRhdGFfZG1hdGFnOwor CWJ1c19kbWFtYXBfdAkJZGF0YV9kbWFtYXA7CiAJYnVzX2RtYW1hcF90CQljb21tYW5kX2RtYW1h cDsKIAl2b2lkICoJCQljb21tYW5kX2J1ZmZlcjsKIAl1X2ludDMyX3QJCWNvbW1hbmRfcGh5c19h ZGRyOy8qV0FSTklORyEgbXVzdCBiZSBjaGFuZ2VkIGlmIDY0Yml0IGFkZHJlc3NpbmcgZXZlciB1 c2VkKi8JCiAJaXBzX2NtZF9zdGF0dXNfdAlzdGF0dXM7CiAJU0xJU1RfRU5UUlkoaXBzX2NvbW1h bmQpCW5leHQ7Ci0JYnVzX2RtYV90YWdfdAkJZGF0YV9kbWF0YWc7Ci0JYnVzX2RtYW1hcF90CQlk YXRhX2RtYW1hcDsKIAl2b2lkICoJCQlkYXRhX2J1ZmZlcjsKLQl2b2lkICogCQkJYXJnOworCXZv aWQgKgkJCWFyZzsKIAl2b2lkCQkJKCogY2FsbGJhY2spKHN0cnVjdCBpcHNfY29tbWFuZCAqY29t bWFuZCk7CiB9aXBzX2NvbW1hbmRfdDsKIAotdHlwZWRlZiBzdHJ1Y3QgaXBzX3dhaXRfbGlzdHsK LQlTVEFJTFFfRU5UUlkoaXBzX3dhaXRfbGlzdCkgbmV4dDsKLQl2b2lkIAkJCSpkYXRhOwotCWlu dAkJCSgqIGNhbGxiYWNrKShpcHNfY29tbWFuZF90ICpjb21tYW5kKTsKLX1pcHNfd2FpdF9saXN0 X3Q7Ci0KIHR5cGVkZWYgc3RydWN0IGlwc19zb2Z0Y3sKICAgICAgICAgc3RydWN0IHJlc291cmNl ICogICAgICAgaW9yZXM7CiAgICAgICAgIHN0cnVjdCByZXNvdXJjZSAqICAgICAgIGlycXJlczsK QEAgLTQyMyw5ICs0MTgsOSBAQAogCXVfaW50OF90CQluZXh0X2RyaXZlOwogCXVfaW50OF90CQlt YXhfY21kczsKIAl2b2xhdGlsZSB1X2ludDhfdAl1c2VkX2NvbW1hbmRzOwotCWlwc19jb21tYW5k X3QJCWNvbW1hbmRhcnJheVtJUFNfTUFYX0NNRF9OVU1dOworCWlwc19jb21tYW5kX3QJCSpjb21t YW5kYXJyYXk7CisJaXBzX2NvbW1hbmRfdAkJKnN0YXRpY2NtZDsKIAlTTElTVF9IRUFEKGNvbW1h bmRfbGlzdCwgaXBzX2NvbW1hbmQpIGZyZWVfY21kX2xpc3Q7Ci0JU1RBSUxRX0hFQUQoY29tbWFu ZF93YWl0X2xpc3QsaXBzX3dhaXRfbGlzdCkgIGNtZF93YWl0X2xpc3Q7CiAJaW50CQkJKCogaXBz X2FkYXB0ZXJfcmVpbml0KShzdHJ1Y3QgaXBzX3NvZnRjICpzYywgCiAJCQkJCQkgICAgICAgaW50 IGZvcmNlKTsKICAgICAgICAgdm9pZCAgICAgICAgICAgICAgICAgICAgKCogaXBzX2FkYXB0ZXJf aW50cikodm9pZCAqc2MpOwpAQCAtNDUxLDggKzQ0Niw3IEBACiBleHRlcm4gaW50IGlwc19jbGVh cl9hZGFwdGVyKGlwc19zb2Z0Y190ICpzYyk7CiAKIC8qIGZ1bmN0aW9uIGRlZmluZXMgZnJvbSBp cHMuYyAqLwotZXh0ZXJuIGludCBpcHNfZ2V0X2ZyZWVfY21kKGlwc19zb2Z0Y190ICpzYywgaW50 ICgqY2FsbGJhY2spKGlwc19jb21tYW5kX3QgKiksIAotCQkJCXZvaWQgKmRhdGEsIHVuc2lnbmVk IGxvbmcgZmxhZ3MpOworZXh0ZXJuIGludCBpcHNfZ2V0X2ZyZWVfY21kKGlwc19zb2Z0Y190ICpz YywgaXBzX2NvbW1hbmRfdCAqKmNvbW1hbmQsIHVuc2lnbmVkIGxvbmcgZmxhZ3MpOwogZXh0ZXJu IHZvaWQgaXBzX2luc2VydF9mcmVlX2NtZChpcHNfc29mdGNfdCAqc2MsIGlwc19jb21tYW5kX3Qg KmNvbW1hbmQpOwogZXh0ZXJuIGludCBpcHNfYWRhcHRlcl9pbml0KGlwc19zb2Z0Y190ICpzYyk7 CiBleHRlcm4gaW50IGlwc19tb3JwaGV1c19yZWluaXQoaXBzX3NvZnRjX3QgKnNjLCBpbnQgZm9y Y2UpOwpJbmRleDogaXBzX2NvbW1hbmRzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Zhci9uY3Zz L3NyYy9zeXMvZGV2L2lwcy9pcHNfY29tbWFuZHMuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4x MS42LjEKZGlmZiAtdSAtcjEuMTEuNi4xIGlwc19jb21tYW5kcy5jCi0tLSBpcHNfY29tbWFuZHMu YwkxMyBKYW4gMjAwNSAwMDo0Njo0MCAtMDAwMAkxLjExLjYuMQorKysgaXBzX2NvbW1hbmRzLmMJ MTEgQXByIDIwMDUgMDE6NTc6NDEgLTAwMDAKQEAgLTM4LDEyICszOCw5IEBACiAgKi8KIHN0YXRp YyB2b2lkIGlwc193YWtldXBfY2FsbGJhY2soaXBzX2NvbW1hbmRfdCAqY29tbWFuZCkKIHsKLQlp cHNfY21kX3N0YXR1c190ICpzdGF0dXM7Ci0Jc3RhdHVzID0gY29tbWFuZC0+YXJnOwotCXN0YXR1 cy0+dmFsdWUgPSBjb21tYW5kLT5zdGF0dXMudmFsdWU7CiAJYnVzX2RtYW1hcF9zeW5jKGNvbW1h bmQtPnNjLT5jb21tYW5kX2RtYXRhZywgY29tbWFuZC0+Y29tbWFuZF9kbWFtYXAsIAogCQkJQlVT X0RNQVNZTkNfUE9TVFdSSVRFKTsKLQl3YWtldXAoc3RhdHVzKTsKKwl3YWtldXAoJmNvbW1hbmQt PnN0YXR1cyk7CiB9CiAvKiBCZWxvdyBhcmUgYSBzZXJpZXMgb2YgZnVuY3Rpb25zIGZvciBzZW5k aW5nIGFuIElPIHJlcXVlc3QKICAqIHRvIHRoZSBhZGFwdGVyLiAgVGhlIGZsb3cgb3JkZXIgaXM6 IHN0YXJ0LCBzZW5kLCBjYWxsYmFjaywgZmluaXNoLgpAQCAtNjEsNyArNTgsNiBAQAogCQkJCUJV U19ETUFTWU5DX1BPU1RXUklURSk7CiAJfQogCWJ1c19kbWFtYXBfdW5sb2FkKGNvbW1hbmQtPmRh dGFfZG1hdGFnLCBjb21tYW5kLT5kYXRhX2RtYW1hcCk7Ci0JYnVzX2RtYW1hcF9kZXN0cm95KGNv bW1hbmQtPmRhdGFfZG1hdGFnLCBjb21tYW5kLT5kYXRhX2RtYW1hcCk7CiAJaWYoQ09NTUFORF9F UlJPUigmY29tbWFuZC0+c3RhdHVzKSl7CiAJCWlvYnVmLT5iX2ZsYWdzIHw9Ql9FUlJPUjsKIAkJ aW9idWYtPmJfZXJyb3IgPSBFSU87CkBAIC04NCw3ICs4MCw2IEBACiAJaWYoZXJyb3IpewogCQlw cmludGYoImlwczogZXJyb3IgPSAlZCBpbiBpcHNfc2dfcmVxdWVzdF9jYWxsYmFja1xuIiwgZXJy b3IpOwogCQlidXNfZG1hbWFwX3VubG9hZChjb21tYW5kLT5kYXRhX2RtYXRhZywgY29tbWFuZC0+ ZGF0YV9kbWFtYXApOwotCQlidXNfZG1hbWFwX2Rlc3Ryb3koY29tbWFuZC0+ZGF0YV9kbWF0YWcs IGNvbW1hbmQtPmRhdGFfZG1hbWFwKTsKIAkJaW9idWYtPmJfZmxhZ3MgfD0gQl9FUlJPUjsKIAkJ aW9idWYtPmJfZXJyb3IgPSBFTk9NRU07CiAJCWlwc19pbnNlcnRfZnJlZV9jbWQoc2MsIGNvbW1h bmQpOwpAQCAtMTM4LDIwICsxMzMsMTAgQEAKIAlyZXR1cm47CiB9CiAKLXN0YXRpYyBpbnQgaXBz X3NlbmRfaW9fcmVxdWVzdChpcHNfY29tbWFuZF90ICpjb21tYW5kKQorc3RhdGljIGludCBpcHNf c2VuZF9pb19yZXF1ZXN0KGlwc19jb21tYW5kX3QgKmNvbW1hbmQsIHN0cnVjdCBidWYgKmlvYnVm KQogewotCWlwc19zb2Z0Y190ICpzYyA9IGNvbW1hbmQtPnNjOwotCXN0cnVjdCBidWYgKmlvYnVm ID0gY29tbWFuZC0+YXJnOwotCWNvbW1hbmQtPmRhdGFfZG1hdGFnID0gc2MtPnNnX2RtYXRhZzsK LQlpZihidXNfZG1hbWFwX2NyZWF0ZShjb21tYW5kLT5kYXRhX2RtYXRhZywgMCwgJmNvbW1hbmQt PmRhdGFfZG1hbWFwKSl7Ci0JCWRldmljZV9wcmludGYoc2MtPmRldiwgImRtYW1hcCBmYWlsZWRc biIpOwotCQlpb2J1Zi0+Yl9mbGFncyB8PSBCX0VSUk9SOwotCQlpb2J1Zi0+Yl9lcnJvciA9IEVO T01FTTsKLQkJaXBzX2luc2VydF9mcmVlX2NtZChzYywgY29tbWFuZCk7Ci0JCWlwc2RfZmluaXNo KGlvYnVmKTsKLQkJcmV0dXJuIDA7Ci0JfQogCWNvbW1hbmQtPmNhbGxiYWNrID0gaXBzX2lvX3Jl cXVlc3RfZmluaXNoOworCWNvbW1hbmQtPmFyZyA9IGlvYnVmOwogCVBSSU5URigxMCwgImlwcyB0 ZXN0OiA6IGJjb3VudCAlbGRcbiIsIGlvYnVmLT5iX2Jjb3VudCk7CiAJYnVzX2RtYW1hcF9sb2Fk KGNvbW1hbmQtPmRhdGFfZG1hdGFnLCBjb21tYW5kLT5kYXRhX2RtYW1hcCwKIAkJCWlvYnVmLT5i X2RhdGEsIGlvYnVmLT5iX2Jjb3VudCwKQEAgLTE2MiwxNyArMTQ3LDIzIEBACiB2b2lkIGlwc19z dGFydF9pb19yZXF1ZXN0KGlwc19zb2Z0Y190ICpzYykKIHsKIAlzdHJ1Y3QgYnVmICppb2J1ZjsK KwlpcHNfY29tbWFuZF90ICpjb21tYW5kOworCWludHJtYXNrX3QgbWFzayA9IHNwbGJpbygpOwog CiAJaW9idWYgPSBidWZxX2ZpcnN0KCZzYy0+cXVldWUpOwotCWlmKCFpb2J1ZikgeworCWlmKCFp b2J1Zil7CisJCXNwbHgobWFzayk7CiAJCXJldHVybjsKIAl9CiAKLQlpZihpcHNfZ2V0X2ZyZWVf Y21kKHNjLCBpcHNfc2VuZF9pb19yZXF1ZXN0LCBpb2J1ZiwgSVBTX05PV0FJVF9GTEFHKSl7CisJ aWYgKGlwc19nZXRfZnJlZV9jbWQoc2MsICZjb21tYW5kLCAwKSl7CisJCXNwbHgobWFzayk7CiAJ CXJldHVybjsKIAl9CiAJCiAJYnVmcV9yZW1vdmUoJnNjLT5xdWV1ZSwgaW9idWYpOworCXNwbHgo bWFzayk7CisJaXBzX3NlbmRfaW9fcmVxdWVzdChjb21tYW5kLCBpb2J1Zik7CiAJcmV0dXJuOwog fQogCkBAIC0xODcsOCArMTc4LDcgQEAKIAlpcHNfYWRhcHRlcl9pbmZvX2NtZCAqY29tbWFuZF9z dHJ1Y3Q7CiAJc2MgPSBjb21tYW5kLT5zYzsKIAlpZihlcnJvcil7Ci0JCWlwc19jbWRfc3RhdHVz X3QgKiBzdGF0dXMgPSBjb21tYW5kLT5hcmc7Ci0JCXN0YXR1cy0+dmFsdWUgPSBJUFNfRVJST1Jf U1RBVFVTOyAvKiBhIGxvdmVseSBlcnJvciB2YWx1ZSAqLworCQljb21tYW5kLT5zdGF0dXMudmFs dWUgPSBJUFNfRVJST1JfU1RBVFVTOyAvKiBhIGxvdmVseSBlcnJvciB2YWx1ZSAqLwogCQlpcHNf aW5zZXJ0X2ZyZWVfY21kKHNjLCBjb21tYW5kKTsKIAkJcHJpbnRmKCJpcHM6IGVycm9yID0gJWQg aW4gaXBzX2dldF9hZGFwdGVyX2luZm9cbiIsIGVycm9yKTsKIAkJcmV0dXJuOwpAQCAtMjExLDcg KzIwMSw2IEBACiB7CiAJaW50IGVycm9yID0gMDsKIAlpcHNfc29mdGNfdCAqc2MgPSBjb21tYW5k LT5zYzsKLQlpcHNfY21kX3N0YXR1c190ICpzdGF0dXMgPSBjb21tYW5kLT5hcmc7CiAKIAlpZiAo YnVzX2RtYV90YWdfY3JlYXRlKAkvKiBwYXJlbnQgICAgKi8Jc2MtPmFkYXB0ZXJfZG1hdGFnLAog CQkJCS8qIGFsaWduZW1udCAqLwkxLApAQCAtMjM1LDcgKzIyNCw3IEBACiAJCWdvdG8gZXhpdDsK IAl9CiAJY29tbWFuZC0+Y2FsbGJhY2sgPSBpcHNfd2FrZXVwX2NhbGxiYWNrOwotCWFzbGVlcChz dGF0dXMsIDAsICJpcHMiLCAzMCpoeik7CisJYXNsZWVwKCZjb21tYW5kLT5zdGF0dXMsIDAsICJp cHMiLCAzMCpoeik7CiAJYnVzX2RtYW1hcF9sb2FkKGNvbW1hbmQtPmRhdGFfZG1hdGFnLCBjb21t YW5kLT5kYXRhX2RtYW1hcCwgCiAJCQljb21tYW5kLT5kYXRhX2J1ZmZlcixJUFNfQURBUFRFUl9J TkZPX0xFTiwgCiAJCQlpcHNfYWRhcHRlcl9pbmZvX2NhbGxiYWNrLCBjb21tYW5kLCBCVVNfRE1B X05PV0FJVCk7CkBAIC0yNjEsMjEgKzI1MCwxNyBAQAogCiBpbnQgaXBzX2dldF9hZGFwdGVyX2lu Zm8oaXBzX3NvZnRjX3QgKnNjKQogeworCWlwc19jb21tYW5kX3QgKmNvbW1hbmQ7CiAJaW50IGVy cm9yID0gMDsKLQlpcHNfY21kX3N0YXR1c190ICpzdGF0dXM7Ci0Jc3RhdHVzID0gbWFsbG9jKHNp emVvZihpcHNfY21kX3N0YXR1c190KSwgTV9JUFNCVUYsIE1fTk9XQUlUfE1fWkVSTyk7Ci0JaWYo IXN0YXR1cykKLQkJcmV0dXJuIEVOT01FTTsKLQlpZihpcHNfZ2V0X2ZyZWVfY21kKHNjLCBpcHNf c2VuZF9hZGFwdGVyX2luZm9fY21kLCBzdGF0dXMsIAotCQkJICAgIElQU19OT1dBSVRfRkxBRykg PiAwKXsKKworCWlmIChpcHNfZ2V0X2ZyZWVfY21kKHNjLCAmY29tbWFuZCwgSVBTX1NUQVRJQ19G TEFHKSA+IDApewogCQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJ1bmFibGUgdG8gZ2V0IGFkYXB0 ZXIgY29uZmlndXJhdGlvblxuIik7Ci0JCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7CiAJCXJldHVy biBFTlhJTzsKIAl9Ci0JaWYgKENPTU1BTkRfRVJST1Ioc3RhdHVzKSl7CisJaXBzX3NlbmRfYWRh cHRlcl9pbmZvX2NtZChjb21tYW5kKTsKKwlpZiAoQ09NTUFORF9FUlJPUigmY29tbWFuZC0+c3Rh dHVzKSl7CiAJCWVycm9yID0gRU5YSU87CiAJfQotCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7CiAJ cmV0dXJuIGVycm9yOwogfQogCkBAIC0yOTAsOCArMjc1LDcgQEAKIAlpcHNfZHJpdmVfY21kICpj b21tYW5kX3N0cnVjdDsKIAlzYyA9IGNvbW1hbmQtPnNjOwogCWlmKGVycm9yKXsKLQkJaXBzX2Nt ZF9zdGF0dXNfdCAqIHN0YXR1cyA9IGNvbW1hbmQtPmFyZzsKLSAgICAgICAgICAgICAgICBzdGF0 dXMtPnZhbHVlID0gSVBTX0VSUk9SX1NUQVRVUzsKKyAgICAgICAgICAgICAgICBjb21tYW5kLT5z dGF0dXMudmFsdWUgPSBJUFNfRVJST1JfU1RBVFVTOwogCQlpcHNfaW5zZXJ0X2ZyZWVfY21kKHNj LCBjb21tYW5kKTsKIAkJcHJpbnRmKCJpcHM6IGVycm9yID0gJWQgaW4gaXBzX2dldF9kcml2ZV9p bmZvXG4iLCBlcnJvcik7CiAJCXJldHVybjsKQEAgLTMxMiw3ICsyOTYsNiBAQAogewogCWludCBl cnJvciA9IDA7CiAJaXBzX3NvZnRjX3QgKnNjID0gY29tbWFuZC0+c2M7Ci0JaXBzX2NtZF9zdGF0 dXNfdCAqc3RhdHVzID0gY29tbWFuZC0+YXJnOwogCWlwc19kcml2ZV9pbmZvX3QgKmRyaXZlaW5m bzsKIAogCWlmIChidXNfZG1hX3RhZ19jcmVhdGUoCS8qIHBhcmVudCAgICAqLwlzYy0+YWRhcHRl cl9kbWF0YWcsCkBAIC0zMzcsNyArMzIwLDcgQEAKIAkJZ290byBleGl0OwogCX0KIAljb21tYW5k LT5jYWxsYmFjayA9IGlwc193YWtldXBfY2FsbGJhY2s7Ci0JYXNsZWVwKHN0YXR1cywgMCwgImlw cyIsIDEwKmh6KTsKKwlhc2xlZXAoJmNvbW1hbmQtPnN0YXR1cywgMCwgImlwcyIsIDEwKmh6KTsK IAlidXNfZG1hbWFwX2xvYWQoY29tbWFuZC0+ZGF0YV9kbWF0YWcsIGNvbW1hbmQtPmRhdGFfZG1h bWFwLCAKIAkJCWNvbW1hbmQtPmRhdGFfYnVmZmVyLElQU19EUklWRV9JTkZPX0xFTiwgCiAJCQlp cHNfZHJpdmVfaW5mb19jYWxsYmFjaywgY29tbWFuZCwgQlVTX0RNQV9OT1dBSVQpOwpAQCAtMzY1 LDIwICszNDgsMTYgQEAKIGludCBpcHNfZ2V0X2RyaXZlX2luZm8oaXBzX3NvZnRjX3QgKnNjKQog ewogCWludCBlcnJvciA9IDA7Ci0JaXBzX2NtZF9zdGF0dXNfdCAqc3RhdHVzOwotCXN0YXR1cyA9 IG1hbGxvYyhzaXplb2YoaXBzX2NtZF9zdGF0dXNfdCksIE1fSVBTQlVGLCBNX05PV0FJVHxNX1pF Uk8pOwotCWlmKCFzdGF0dXMpCi0JCXJldHVybiBFTk9NRU07Ci0JaWYoaXBzX2dldF9mcmVlX2Nt ZChzYywgaXBzX3NlbmRfZHJpdmVfaW5mb19jbWQsIHN0YXR1cywgCi0JCQkgICAgSVBTX05PV0FJ VF9GTEFHKSA+IDApewotCQlmcmVlKHN0YXR1cywgTV9JUFNCVUYpOworCWlwc19jb21tYW5kX3Qg KmNvbW1hbmQ7CisKKwlpZiAoaXBzX2dldF9mcmVlX2NtZChzYywgJmNvbW1hbmQsIElQU19TVEFU SUNfRkxBRykgPiAwKXsKIAkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAidW5hYmxlIHRvIGdldCBk cml2ZSBjb25maWd1cmF0aW9uXG4iKTsKIAkJcmV0dXJuIEVOWElPOwogCX0KLQlpZihDT01NQU5E X0VSUk9SKHN0YXR1cykpeworCWlwc19zZW5kX2RyaXZlX2luZm9fY21kKGNvbW1hbmQpOworCWlm KENPTU1BTkRfRVJST1IoJmNvbW1hbmQtPnN0YXR1cykpewogCQllcnJvciA9IEVOWElPOwogCX0K LQlmcmVlKHN0YXR1cywgTV9JUFNCVUYpOwogCXJldHVybiBlcnJvcjsKIH0KIApAQCAtMzg3LDcg KzM2Niw2IEBACiBzdGF0aWMgaW50IGlwc19zZW5kX2ZsdXNoX2NhY2hlX2NtZChpcHNfY29tbWFu ZF90ICpjb21tYW5kKQogewogCWlwc19zb2Z0Y190ICpzYyA9IGNvbW1hbmQtPnNjOwotCWlwc19j bWRfc3RhdHVzX3QgKnN0YXR1cyA9IGNvbW1hbmQtPmFyZzsKIAlpcHNfZ2VuZXJpY19jbWQgKmNv bW1hbmRfc3RydWN0OwogCiAJUFJJTlRGKDEwLCJpcHMgdGVzdDogZ290IGEgY29tbWFuZCwgYnVp bGRpbmcgZmx1c2ggY29tbWFuZFxuIik7CkBAIC0zOTcsNyArMzc1LDcgQEAKIAljb21tYW5kX3N0 cnVjdC0+aWQgPSBjb21tYW5kLT5pZDsKIAlidXNfZG1hbWFwX3N5bmMoc2MtPmNvbW1hbmRfZG1h dGFnLCBjb21tYW5kLT5jb21tYW5kX2RtYW1hcCwgCiAJCQlCVVNfRE1BU1lOQ19QUkVXUklURSk7 Ci0JYXNsZWVwKHN0YXR1cywgMCwgInNsdXNoMiIsIDApOworCWFzbGVlcCgmY29tbWFuZC0+c3Rh dHVzLCAwLCAic2x1c2gyIiwgMCk7CiAJc2MtPmlwc19pc3N1ZV9jbWQoY29tbWFuZCk7CiAJYXdh aXQoLTEsIC0xKTsKIAlpcHNfaW5zZXJ0X2ZyZWVfY21kKHNjLCBjb21tYW5kKTsKQEAgLTQwNiwy MCArMzg0LDE2IEBACiAKIGludCBpcHNfZmx1c2hfY2FjaGUoaXBzX3NvZnRjX3QgKnNjKQogewot CWlwc19jbWRfc3RhdHVzX3QgKnN0YXR1czsKLQlzdGF0dXMgPSBtYWxsb2Moc2l6ZW9mKGlwc19j bWRfc3RhdHVzX3QpLCBNX0lQU0JVRiwgTV9OT1dBSVR8TV9aRVJPKTsKLQlpZighc3RhdHVzKQot CQlyZXR1cm4gRU5PTUVNOworCWlwc19jb21tYW5kX3QgKmNvbW1hbmQ7CisKIAlkZXZpY2VfcHJp bnRmKHNjLT5kZXYsICJmbHVzaGluZyBjYWNoZVxuIik7Ci0JaWYoaXBzX2dldF9mcmVlX2NtZChz YywgaXBzX3NlbmRfZmx1c2hfY2FjaGVfY21kLCBzdGF0dXMsIAotCQkJICAgIElQU19OT1dBSVRf RkxBRykpewotCQlmcmVlKHN0YXR1cywgTV9JUFNCVUYpOworCWlmIChpcHNfZ2V0X2ZyZWVfY21k KHNjLCAmY29tbWFuZCwgSVBTX1NUQVRJQ19GTEFHKSl7CiAJCWRldmljZV9wcmludGYoc2MtPmRl diwgIkVSUk9SOiB1bmFibGUgdG8gZ2V0IGEgY29tbWFuZCEgY2FuJ3QgZmx1c2ggY2FjaGUhXG4i KTsKIAl9Ci0JaWYoQ09NTUFORF9FUlJPUihzdGF0dXMpKXsKKwlpcHNfc2VuZF9mbHVzaF9jYWNo ZV9jbWQoY29tbWFuZCk7CisJaWYoQ09NTUFORF9FUlJPUigmY29tbWFuZC0+c3RhdHVzKSl7CiAJ CWRldmljZV9wcmludGYoc2MtPmRldiwgIkVSUk9SOiBjYWNoZSBmbHVzaCBjb21tYW5kIGZhaWxl ZCFcbiIpOwogCX0KLQlmcmVlKHN0YXR1cywgTV9JUFNCVUYpOwogCXJldHVybiAwOwogfQogCkBA IC00NjksNyArNDQzLDYgQEAKIHN0YXRpYyBpbnQgaXBzX3NlbmRfZmZkY19yZXNldF9jbWQoaXBz X2NvbW1hbmRfdCAqY29tbWFuZCkKIHsKIAlpcHNfc29mdGNfdCAqc2MgPSBjb21tYW5kLT5zYzsK LQlpcHNfY21kX3N0YXR1c190ICpzdGF0dXMgPSBjb21tYW5kLT5hcmc7CiAJaXBzX2FkYXB0ZXJf ZmZkY19jbWQgKmNvbW1hbmRfc3RydWN0OwogCiAJUFJJTlRGKDEwLCJpcHMgdGVzdDogZ290IGEg Y29tbWFuZCwgYnVpbGRpbmcgZmZkYyByZXNldCBjb21tYW5kXG4iKTsKQEAgLTQ4Myw3ICs0NTYs NyBAQAogCiAJYnVzX2RtYW1hcF9zeW5jKHNjLT5jb21tYW5kX2RtYXRhZywgY29tbWFuZC0+Y29t bWFuZF9kbWFtYXAsCiAJCQlCVVNfRE1BU1lOQ19QUkVXUklURSk7Ci0JYXNsZWVwKHN0YXR1cywg MCwgImlwc19mZmRjIiwgMCk7CisJYXNsZWVwKCZjb21tYW5kLT5zdGF0dXMsIDAsICJpcHNfZmZk YyIsIDApOwogCXNjLT5pcHNfaXNzdWVfY21kKGNvbW1hbmQpOwogCWF3YWl0KC0xLCAtMSk7CiAJ aXBzX2luc2VydF9mcmVlX2NtZChzYywgY29tbWFuZCk7CkBAIC00OTIsMTkgKzQ2NSwxNSBAQAog CiBpbnQgaXBzX2ZmZGNfcmVzZXQoaXBzX3NvZnRjX3QgKnNjKQogewotCWlwc19jbWRfc3RhdHVz X3QgKnN0YXR1czsKLQlzdGF0dXMgPSBtYWxsb2Moc2l6ZW9mKGlwc19jbWRfc3RhdHVzX3QpLCBN X0lQU0JVRiwgTV9OT1dBSVR8TV9aRVJPKTsKLQlpZighc3RhdHVzKQotCQlyZXR1cm4gRU5PTUVN OwotCWlmKGlwc19nZXRfZnJlZV9jbWQoc2MsIGlwc19zZW5kX2ZmZGNfcmVzZXRfY21kLCBzdGF0 dXMsCi0JCQkgICAgSVBTX05PV0FJVF9GTEFHKSl7Ci0JCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7 CisJaXBzX2NvbW1hbmRfdCAqY29tbWFuZDsKKworCWlmIChpcHNfZ2V0X2ZyZWVfY21kKHNjLCAm Y29tbWFuZCwgSVBTX1NUQVRJQ19GTEFHKSl7CiAJCWRldmljZV9wcmludGYoc2MtPmRldiwgIkVS Uk9SOiB1bmFibGUgdG8gZ2V0IGEgY29tbWFuZCEgY2FuJ3Qgc2VuZCBmZmRjIHJlc2V0IVxuIik7 CiAJfQotCWlmKENPTU1BTkRfRVJST1Ioc3RhdHVzKSl7CisJaXBzX3NlbmRfZmZkY19yZXNldF9j bWQoY29tbWFuZCk7CisJaWYoQ09NTUFORF9FUlJPUigmY29tbWFuZC0+c3RhdHVzKSl7CiAJCWRl dmljZV9wcmludGYoc2MtPmRldiwgIkVSUk9SOiBmZmRjIHJlc2V0IGNvbW1hbmQgZmFpbGVkIVxu Iik7CiAJfQotCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7CiAJcmV0dXJuIDA7CiB9CiAKQEAgLTU0 MSw4ICs1MTAsNyBAQAogCWlwc19yd19udnJhbV9jbWQgKmNvbW1hbmRfc3RydWN0OwogCXNjID0g Y29tbWFuZC0+c2M7CiAJaWYoZXJyb3IpewotCQlpcHNfY21kX3N0YXR1c190ICogc3RhdHVzID0g Y29tbWFuZC0+YXJnOwotICAgICAgICAgICAgICAgIHN0YXR1cy0+dmFsdWUgPSBJUFNfRVJST1Jf U1RBVFVTOworICAgICAgICAgICAgICAgIGNvbW1hbmQtPnN0YXR1cy52YWx1ZSA9IElQU19FUlJP Ul9TVEFUVVM7CiAJCWlwc19pbnNlcnRfZnJlZV9jbWQoc2MsIGNvbW1hbmQpOwogCQlwcmludGYo ImlwczogZXJyb3IgPSAlZCBpbiBpcHNfcmVhZF9udnJhbV9jYWxsYmFja1xuIiwgZXJyb3IpOwog CQlyZXR1cm47CkBAIC01NjEsMTAgKzUyOSwxMCBAQAogCXNjLT5pcHNfaXNzdWVfY21kKGNvbW1h bmQpOwogfQogCi1zdGF0aWMgaW50IGlwc19yZWFkX252cmFtKGlwc19jb21tYW5kX3QgKmNvbW1h bmQpeworc3RhdGljIGludCBpcHNfcmVhZF9udnJhbShpcHNfY29tbWFuZF90ICpjb21tYW5kKQor ewogCWludCBlcnJvciA9IDA7CiAJaXBzX3NvZnRjX3QgKnNjID0gY29tbWFuZC0+c2M7Ci0JaXBz X2NtZF9zdGF0dXNfdCAqc3RhdHVzID0gY29tbWFuZC0+YXJnOwogCiAJaWYgKGJ1c19kbWFfdGFn X2NyZWF0ZSgJLyogcGFyZW50ICAgICovCXNjLT5hZGFwdGVyX2RtYXRhZywKIAkJCQkvKiBhbGln bmVtbnQgKi8JMSwKQEAgLTU4OCw3ICs1NTYsNyBAQAogCQlnb3RvIGV4aXQ7CiAJfQogCWNvbW1h bmQtPmNhbGxiYWNrID0gaXBzX3dyaXRlX252cmFtOwotCWFzbGVlcChzdGF0dXMsIDAsICJpcHMi LCAwKTsKKwlhc2xlZXAoJmNvbW1hbmQtPnN0YXR1cywgMCwgImlwcyIsIDApOwogCWJ1c19kbWFt YXBfbG9hZChjb21tYW5kLT5kYXRhX2RtYXRhZywgY29tbWFuZC0+ZGF0YV9kbWFtYXAsIAogCQkJ Y29tbWFuZC0+ZGF0YV9idWZmZXIsSVBTX05WUkFNX1BBR0VfU0laRSwgCiAJCQlpcHNfcmVhZF9u dnJhbV9jYWxsYmFjaywgY29tbWFuZCwgQlVTX0RNQV9OT1dBSVQpOwpAQCAtNjEwLDE5ICs1Nzgs MTYgQEAKIAogaW50IGlwc191cGRhdGVfbnZyYW0oaXBzX3NvZnRjX3QgKnNjKQogewotCWlwc19j bWRfc3RhdHVzX3QgKnN0YXR1czsKLQlzdGF0dXMgPSBtYWxsb2Moc2l6ZW9mKGlwc19jbWRfc3Rh dHVzX3QpLCBNX0lQU0JVRiwgTV9OT1dBSVR8TV9aRVJPKTsKLQlpZighc3RhdHVzKQotCQlyZXR1 cm4gRU5PTUVNOwotCWlmKGlwc19nZXRfZnJlZV9jbWQoc2MsIGlwc19yZWFkX252cmFtLCBzdGF0 dXMsIElQU19OT1dBSVRfRkxBRykpewotCQlmcmVlKHN0YXR1cywgTV9JUFNCVUYpOworCWlwc19j b21tYW5kX3QgKmNvbW1hbmQ7CisKKwlpZiAoaXBzX2dldF9mcmVlX2NtZChzYywgJmNvbW1hbmQs IElQU19TVEFUSUNfRkxBRykpewogCQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJFUlJPUjogdW5h YmxlIHRvIGdldCBhIGNvbW1hbmQhIGNhbid0IHVwZGF0ZSBudnJhbVxuIik7CiAJCXJldHVybiAx OwogCX0KLQlpZihDT01NQU5EX0VSUk9SKHN0YXR1cykpeworCWlwc19yZWFkX252cmFtKGNvbW1h bmQpOworCWlmKENPTU1BTkRfRVJST1IoJmNvbW1hbmQtPnN0YXR1cykpewogCQlkZXZpY2VfcHJp bnRmKHNjLT5kZXYsICJFUlJPUjogbnZyYW0gdXBkYXRlIGNvbW1hbmQgZmFpbGVkIVxuIik7CiAJ fQotCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7CiAJcmV0dXJuIDA7CiAKIApAQCAtNjMyLDcgKzU5 Nyw2IEBACiBzdGF0aWMgaW50IGlwc19zZW5kX2NvbmZpZ19zeW5jX2NtZChpcHNfY29tbWFuZF90 ICpjb21tYW5kKQogewogCWlwc19zb2Z0Y190ICpzYyA9IGNvbW1hbmQtPnNjOwotCWlwc19jbWRf c3RhdHVzX3QgKnN0YXR1cyA9IGNvbW1hbmQtPmFyZzsKIAlpcHNfZ2VuZXJpY19jbWQgKmNvbW1h bmRfc3RydWN0OwogCiAJUFJJTlRGKDEwLCJpcHMgdGVzdDogZ290IGEgY29tbWFuZCwgYnVpbGRp bmcgZmx1c2ggY29tbWFuZFxuIik7CkBAIC02NDMsNyArNjA3LDcgQEAKIAljb21tYW5kX3N0cnVj dC0+cmVzZXJ2ZTIgPSBJUFNfUE9DTDsKIAlidXNfZG1hbWFwX3N5bmMoc2MtPmNvbW1hbmRfZG1h dGFnLCBjb21tYW5kLT5jb21tYW5kX2RtYW1hcCwgCiAJCQlCVVNfRE1BU1lOQ19QUkVXUklURSk7 Ci0JYXNsZWVwKHN0YXR1cywgMCwgImlwc3N5biIsIDApOworCWFzbGVlcCgmY29tbWFuZC0+c3Rh dHVzLCAwLCAiaXBzc3luIiwgMCk7CiAJc2MtPmlwc19pc3N1ZV9jbWQoY29tbWFuZCk7CiAJYXdh aXQoLTEsIC0xKTsKIAlpcHNfaW5zZXJ0X2ZyZWVfY21kKHNjLCBjb21tYW5kKTsKQEAgLTY1Myw3 ICs2MTcsNiBAQAogc3RhdGljIGludCBpcHNfc2VuZF9lcnJvcl90YWJsZV9jbWQoaXBzX2NvbW1h bmRfdCAqY29tbWFuZCkKIHsKIAlpcHNfc29mdGNfdCAqc2MgPSBjb21tYW5kLT5zYzsKLQlpcHNf Y21kX3N0YXR1c190ICpzdGF0dXMgPSBjb21tYW5kLT5hcmc7CiAJaXBzX2dlbmVyaWNfY21kICpj b21tYW5kX3N0cnVjdDsKIAogCVBSSU5URigxMCwiaXBzIHRlc3Q6IGdvdCBhIGNvbW1hbmQsIGJ1 aWxkaW5nIGVycm9ydGFibGUgY29tbWFuZFxuIik7CkBAIC02NjQsNyArNjI3LDcgQEAKIAljb21t YW5kX3N0cnVjdC0+cmVzZXJ2ZTIgPSBJUFNfQ1NMOwogCWJ1c19kbWFtYXBfc3luYyhzYy0+Y29t bWFuZF9kbWF0YWcsIGNvbW1hbmQtPmNvbW1hbmRfZG1hbWFwLCAKIAkJCUJVU19ETUFTWU5DX1BS RVdSSVRFKTsKLQlhc2xlZXAoc3RhdHVzLCAwLCAiaXBzZXRjIiwgMCk7CisJYXNsZWVwKCZjb21t YW5kLT5zdGF0dXMsIDAsICJpcHNldGMiLCAwKTsKIAlzYy0+aXBzX2lzc3VlX2NtZChjb21tYW5k KTsKIAlhd2FpdCgtMSwgLTEpOwogCWlwc19pbnNlcnRfZnJlZV9jbWQoc2MsIGNvbW1hbmQpOwpA QCAtNjc0LDM2ICs2MzcsMjkgQEAKIAogaW50IGlwc19jbGVhcl9hZGFwdGVyKGlwc19zb2Z0Y190 ICpzYykKIHsKLQlpcHNfY21kX3N0YXR1c190ICpzdGF0dXM7Ci0Jc3RhdHVzID0gbWFsbG9jKHNp emVvZihpcHNfY21kX3N0YXR1c190KSwgTV9JUFNCVUYsIE1fTk9XQUlUfE1fWkVSTyk7Ci0JaWYo IXN0YXR1cykKLQkJcmV0dXJuIEVOT01FTTsKKwlpcHNfY29tbWFuZF90ICpjb21tYW5kOworCiAJ ZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAic3luY2luZyBjb25maWdcbiIpOwotCWlmKGlwc19nZXRf ZnJlZV9jbWQoc2MsIGlwc19zZW5kX2NvbmZpZ19zeW5jX2NtZCwgc3RhdHVzLCAKLQkJCSAgICBJ UFNfTk9XQUlUX0ZMQUcpKXsKLQkJZnJlZShzdGF0dXMsIE1fSVBTQlVGKTsKKwlpZiAoaXBzX2dl dF9mcmVlX2NtZChzYywgJmNvbW1hbmQsIElQU19TVEFUSUNfRkxBRykpewogCQlkZXZpY2VfcHJp bnRmKHNjLT5kZXYsICJFUlJPUjogdW5hYmxlIHRvIGdldCBhIGNvbW1hbmQhIGNhbid0IHN5bmMg Y2FjaGUhXG4iKTsKIAkJcmV0dXJuIDE7CiAJfQotCWlmKENPTU1BTkRfRVJST1Ioc3RhdHVzKSl7 Ci0JCWZyZWUoc3RhdHVzLCBNX0lQU0JVRik7CisJaXBzX3NlbmRfY29uZmlnX3N5bmNfY21kKGNv bW1hbmQpOworCWlmKENPTU1BTkRfRVJST1IoJmNvbW1hbmQtPnN0YXR1cykpewogCQlkZXZpY2Vf cHJpbnRmKHNjLT5kZXYsICJFUlJPUjogY2FjaGUgc3luYyBjb21tYW5kIGZhaWxlZCFcbiIpOwog CQlyZXR1cm4gMTsKIAl9CiAKIAlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsICJjbGVhcmluZyBlcnJv ciB0YWJsZVxuIik7Ci0JaWYoaXBzX2dldF9mcmVlX2NtZChzYywgaXBzX3NlbmRfZXJyb3JfdGFi bGVfY21kLCBzdGF0dXMsIAotCQkJICAgIElQU19OT1dBSVRfRkxBRykpewotCQlmcmVlKHN0YXR1 cywgTV9JUFNCVUYpOworCWlmKGlwc19nZXRfZnJlZV9jbWQoc2MsICZjb21tYW5kLCBJUFNfU1RB VElDX0ZMQUcpKXsKIAkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiRVJST1I6IHVuYWJsZSB0byBn ZXQgYSBjb21tYW5kISBjYW4ndCBzeW5jIGNhY2hlIVxuIik7CiAJCXJldHVybiAxOwogCX0KLQlp ZihDT01NQU5EX0VSUk9SKHN0YXR1cykpeworCWlwc19zZW5kX2Vycm9yX3RhYmxlX2NtZChjb21t YW5kKTsKKwlpZihDT01NQU5EX0VSUk9SKCZjb21tYW5kLT5zdGF0dXMpKXsKIAkJZGV2aWNlX3By aW50ZihzYy0+ZGV2LCAiRVJST1I6IGV0YWJsZSBjb21tYW5kIGZhaWxlZCFcbiIpOwotCQlmcmVl KHN0YXR1cywgTV9JUFNCVUYpOwogCQlyZXR1cm4gMTsKIAl9CiAKLQlmcmVlKHN0YXR1cywgTV9J UFNCVUYpOwogCXJldHVybiAwOwogfQpJbmRleDogaXBzX2Rpc2suYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBm aWxlOiAvdmFyL25jdnMvc3JjL3N5cy9kZXYvaXBzL2lwc19kaXNrLmMsdgpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuNi42LjEKZGlmZiAtdSAtcjEuNi42LjEgaXBzX2Rpc2suYwotLS0gaXBzX2Rpc2su YwkxMyBKYW4gMjAwNSAwMDo0Njo0MCAtMDAwMAkxLjYuNi4xCisrKyBpcHNfZGlzay5jCTExIEFw ciAyMDA1IDAxOjU0OjQ0IC0wMDAwCkBAIC0xMjgsMTIgKzEyOCwxNSBAQAogc3RhdGljIHZvaWQg aXBzZF9zdHJhdGVneShzdHJ1Y3QgYnVmICppb2J1ZikKIHsKIAlpcHNkaXNrX3NvZnRjX3QgKmRz YzsKKwlpbnRybWFza190IG1hc2s7CiAKIAlkc2MgPSBpb2J1Zi0+Yl9kZXYtPnNpX2RydjE7CQog CURFVklDRV9QUklOVEYoOCxkc2MtPmRldiwiaW4gc3RyYXRlZ3lcbiIpOwogCWRldnN0YXRfc3Rh cnRfdHJhbnNhY3Rpb24oJmRzYy0+c3RhdHMpOwogCWlvYnVmLT5iX2RyaXZlcjEgPSAodm9pZCAq KSh1aW50cHRyX3QpZHNjLT5zYy0+ZHJpdmVzW2RzYy0+ZGlza19udW1iZXJdLmRyaXZlbnVtOwot CWJ1ZnFkaXNrc29ydCgmZHNjLT5zYy0+cXVldWUsIGlvYnVmKTsKKwltYXNrID0gc3BsYmlvKCk7 CisJYnVmcV9pbnNlcnRfdGFpbCgmZHNjLT5zYy0+cXVldWUsIGlvYnVmKTsKKwlzcGx4KG1hc2sp OwogCWlwc19zdGFydF9pb19yZXF1ZXN0KGRzYy0+c2MpOwogfQogCkluZGV4OiBpcHNfaW9jdGwu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09ClJDUyBmaWxlOiAvdmFyL25jdnMvc3JjL3N5cy9kZXYvaXBzL2lwc19pb2N0 bC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjUuNi4xCmRpZmYgLXUgLXIxLjUuNi4xIGlwc19p b2N0bC5jCi0tLSBpcHNfaW9jdGwuYwkxMyBKYW4gMjAwNSAwMDo0Njo0MCAtMDAwMAkxLjUuNi4x CisrKyBpcHNfaW9jdGwuYwk3IEFwciAyMDA1IDIzOjU2OjA4IC0wMDAwCkBAIC04NCw2ICs4NCw3 IEBACiAKIHN0YXRpYyBpbnQgaXBzX2lvY3RsX2NtZChpcHNfc29mdGNfdCAqc2MsIGlwc19pb2N0 bF90ICppb2N0bF9jbWQsIGlwc191c2VyX3JlcXVlc3QgKnVzZXJfcmVxdWVzdCkKIHsKKwlpcHNf Y29tbWFuZF90ICpjb21tYW5kOwogCWludCBlcnJvciA9IEVJTlZBTDsKIAogCWlmIChidXNfZG1h X3RhZ19jcmVhdGUoCS8qIHBhcmVudCAgICAqLwlzYy0+YWRhcHRlcl9kbWF0YWcsCkBAIC0xMDks MTAgKzExMCwxMiBAQAogCSAgICBpb2N0bF9jbWQtPmRhdGFzaXplKSkKIAkJZ290byBleGl0Owog CWlvY3RsX2NtZC0+c3RhdHVzLnZhbHVlID0gMHhmZmZmZmZmZjsKLQlpZigoZXJyb3IgPSBpcHNf Z2V0X2ZyZWVfY21kKHNjLCBpcHNfaW9jdGxfc3RhcnQsIGlvY3RsX2NtZCwwKSkgPiAwKXsKKwlp ZigoZXJyb3IgPSBpcHNfZ2V0X2ZyZWVfY21kKHNjLCAmY29tbWFuZCwgMCkpID4gMCl7CiAJCWVy cm9yID0gRU5PTUVNOwogCQlnb3RvIGV4aXQ7CiAJfQorCWNvbW1hbmQtPmFyZyA9IGlvY3RsX2Nt ZDsKKwlpcHNfaW9jdGxfc3RhcnQoY29tbWFuZCk7CiAJd2hpbGUoIGlvY3RsX2NtZC0+c3RhdHVz LnZhbHVlID09IDB4ZmZmZmZmZmYpCiAJCXRzbGVlcChpb2N0bF9jbWQsIDAsICJpcHMiLCBoei8x MCk7CiAJaWYoQ09NTUFORF9FUlJPUigmaW9jdGxfY21kLT5zdGF0dXMpKQo= --=====================_525762265==_-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 05:34:47 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81E7716A4CE for ; Mon, 11 Apr 2005 05:34:47 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7345443D39 for ; Mon, 11 Apr 2005 05:34:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3B5c9l4028563; Sun, 10 Apr 2005 23:38:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A0BB2.10704@samsco.org> Date: Sun, 10 Apr 2005 23:31:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Sze References: <4257F20C.70004@samsco.org> <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> In-Reply-To: <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 05:34:47 -0000 David Sze wrote: > At 09:17 AM 09/04/2005 -0600, Scott Long wrote this to All: > >> All, >> >> Thanks to the keen eye of David Sze, the cause of the instability in >> the ips driver in FreeBSD 4.x might have been found. If it's >> affecting you, >> please try the attached patch and let me know the results. I'll >> commit it when everyone is happy with it. > > > Scott, > > I think there's a problem with the ips_commands.c patch. After the > bufq_first call succeeds, bufq_remove must be called before the splx or > else the iobuf can get issued twice. However, if the subsequent > ips_get_free_cmd fails, the iobuf must be put back on the bufq. Yes, I forgot that synchronization is a bit different here than in 5.x/6.0. Your second patch with the MfC is exactly what I had in mind for the ips_start_io_request() function. > > Two patches are attached to this message: > > 1. ips.RELENG_4.stability.patch is just the stability patch as described. > > 2. ips.RELENG_4.mfc-and-stability.patch is an MFC of your IPS cleanup > and optimization that you committed to HEAD on 01/28/05, plus the > stability patch as described. > > Both patches survived a "make -j8 buildworld" for me. > > The problem I'm having now is that ips does not appear to be PAE-ified. > With either patch the bus_dmamap_create call fails. Any pointers would > be appreciated, this is new territory for me. > Making a driver PAE-ified means either teaching it to do 64-bit scatter-gather (assuming that the peripheral hardware can do this and that it's documented), or teaching the driver to correctly handle EINPROGRESS from bus_dmamap_load() along with using the proper busdma tag limits. The strategy I took with 6.x/5.x was the second one since I didn't have good IPS docs in front of me and I wanted it follow the APIs correctly. I did test it with 8GB of memory and it performed correctly under load. I haven't taken a close enough look at your MFC patch to say for sure if it's correct or not. I'm not sure if I'll have time to take another look in the next few days, unfortunately. Is there any chance you could test 5.x/6.0 under load with PAE just to validate the assertion that it works correctly there? Thanks, Scott From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 07:30:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20B2116A4CE for ; Mon, 11 Apr 2005 07:30:49 +0000 (GMT) Received: from fish.ish.com.au (adsl-52-22.swiftdsl.com.au [218.214.52.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5832043D5A for ; Mon, 11 Apr 2005 07:30:48 +0000 (GMT) (envelope-from ari@ish.com.au) Received: from [203.29.62.9] (helo=neuro.net.au) by fish.ish.com.au with esmtps (SSLv3:DES-CBC3-SHA:168) (Exim 4.43) id 1DKtJu-0007eT-93 for freebsd-stable@freebsd.org; Mon, 11 Apr 2005 17:26:57 +1000 Received: from [203.29.62.188] (HELO [203.29.62.188]) by neuro.net.au (CommuniGate Pro SMTP 4.3c2) with ESMTP id 1593718 for freebsd-stable@freebsd.org; Mon, 11 Apr 2005 17:30:42 +1000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-stable@freebsd.org From: Aristedes Maniatis Date: Mon, 11 Apr 2005 17:30:42 +1000 X-Mailer: Apple Mail (2.619.2) Subject: aac support for Adaptec 2020SA ZCR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 07:30:49 -0000 We have a motherboard (Supermicro X6DHT-G) with an Adaptec 2020SA SATA RAID controller. We have been unable to get any drives recognised by the FreeBSD 5.3 release installation CD, and we've been unable to find much discussion about the status of the AAC device and support for this chipset. Several other Adaptec SATA RAID controllers seem to be supported: 2410SA, 2810SA, 21610SA. The logical drive configured in the RAID controller is detected successfully in a Gentoo Linux 2004.3 environment. Has anyone had success with this controller? Any alternative you would recommend or will support be available in 5.4? I believe from the source code that the driver is maintained by Scott Long and that recent changes have been taking place. Thanks for any assistance. Ari Maniatis --------------------------> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 07:56:19 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C3216A4CE for ; Mon, 11 Apr 2005 07:56:19 +0000 (GMT) Received: from dev.bmby.co.il (l192-114-46-204.broadband.actcom.net.il [192.114.46.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2433943D53 for ; Mon, 11 Apr 2005 07:56:18 +0000 (GMT) (envelope-from uzi@bmby.com) Received: from [10.0.0.3] ([10.0.0.3]) by dev.bmby.co.il (8.12.9/8.12.9) with ESMTP id j3B7uFqx010508; Mon, 11 Apr 2005 10:56:15 +0300 Message-ID: <425A2DC3.9070904@bmby.com> Date: Mon, 11 Apr 2005 10:56:51 +0300 From: Uzi Klein User-Agent: Mozilla Thunderbird 1.0 (X11/20050111) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aristedes Maniatis References: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> In-Reply-To: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: aac support for Adaptec 2020SA ZCR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 07:56:19 -0000 Aristedes Maniatis wrote: > We have a motherboard (Supermicro X6DHT-G) with an Adaptec 2020SA SATA > RAID controller. We have been unable to get any drives recognised by the > FreeBSD 5.3 release installation CD, and we've been unable to find much > discussion about the status of the AAC device and support for this > chipset. Several other Adaptec SATA RAID controllers seem to be > supported: 2410SA, 2810SA, 21610SA. The logical drive configured in the > RAID controller is detected successfully in a Gentoo Linux 2004.3 > environment. > > Has anyone had success with this controller? Any alternative you would > recommend or will support be available in 5.4? I believe from the source > code that the driver is maintained by Scott Long and that recent changes > have been taking place. You might be interested in this article: http://hardware.slashdot.org/hardware/05/03/20/1944233.shtml?tid=198&tid=190&tid=172&tid=137&tid=7 I don't know how FreeBSD is related, but it's probably is. > > > Thanks for any assistance. > > Ari Maniatis > > > > --------------------------> > ish group pty ltd > http://www.ish.com.au > 7 Darghan St Glebe 2037 Australia > phone +61 2 9660 1400 fax +61 2 9660 7400 > PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Uzi Klein Software Development Executive http://www.bmby.com From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 08:07:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12D5016A4CE for ; Mon, 11 Apr 2005 08:07:08 +0000 (GMT) Received: from 62-15-209-148.inversas.jazztel.es (62-15-209-148.inversas.jazztel.es [62.15.209.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 704CD43D39 for ; Mon, 11 Apr 2005 08:07:06 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3B874HZ025518 for ; Mon, 11 Apr 2005 10:07:04 +0200 (CEST) (envelope-from freebsd@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3B873dq002104 for stable@FreeBSD.org; Mon, 11 Apr 2005 10:07:03 +0200 (CEST) (envelope-from freebsd@redesjm.local) From: Jose M Rodriguez To: stable@FreeBSD.org Date: Mon, 11 Apr 2005 10:07:03 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504111007.03460.freebsd@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.45; host: antares.redesjm.local) Subject: Problems with world build in RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 08:07:08 -0000 Hi, I found a little problem with RELENG_5_4 buildworld in my env. I have a little patched RELENG_5_4 src in a local cvs server, mounted ro,-L in the build machine (/usr/src) No rpc.lockd or rpc.statd daemon running in both machines. build machine timesync with cvs server by ntpdate before build. Every time I do a rm -rf /usr/obj/* && cd /usr/src && make buildworld I get: cc -Os -fno-strict-aliasing -mtune=athlon-xp -pipe -I. -I/usr/src/usr.sbin/confi g -I/usr/obj/usr/src/i386/legacy/usr/include -static -L/usr/obj/usr/src/i386/l egacy/usr/lib -o config config.o main.o lang.o mkmakefile.o mkheaders.o mkoption s.o -ll -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 config /usr/obj/usr/sr c/i386/legacy/usr/sbin -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE =pentium-mmx GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PA TH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/u sr/src/i386/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/i386 INSTAL L="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/us r/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/ob j/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/ games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/usr/s rc/i386 par-cleandir ===> share/info ===> include rm -f osreldate.h version vers.c rm: version: Read-only file system *** Error code 1 The only thing I change form previous week builds are the -L mount and disabling the rpc.lockd and rpc.statd daemons in both machines. I can solve the problem doing a make obj before make buildworld. Can someone reproduce this? thanks in advance, -- josemi From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 10:40:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C5BB16A4CE for ; Mon, 11 Apr 2005 10:40:14 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97ECD43D41 for ; Mon, 11 Apr 2005 10:40:13 +0000 (GMT) (envelope-from rob.pollock@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1095148rnf for ; Mon, 11 Apr 2005 03:40:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=IQZesc4dohib3kMlTtDK+9aYc2b0UAXjoqaRIPjaKuWUvJ4yekgc8gduTBMFVMw90d3ixEh+qfVbb6pAGnuktDQNC02eM9T3HM6j/2YP1IaXL0f91+2Tu7rU382TNsMsNyTw9/iHQoLWtLBHvb7TZ9e31LdSVgqN4QcSqwWljX4= Received: by 10.39.3.56 with SMTP id f56mr2630800rni; Mon, 11 Apr 2005 03:40:12 -0700 (PDT) Received: by 10.38.101.24 with HTTP; Mon, 11 Apr 2005 03:40:12 -0700 (PDT) Message-ID: Date: Mon, 11 Apr 2005 22:40:12 +1200 From: Rob Pollock To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: libieee1284 and canon parallel scanners X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rob Pollock List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 10:40:14 -0000 Hi, I'm desperately trying to get my parallel port scanner to work on FreeBSD 5-STABLE. It is a canon 640P scanner, that in theory should work with sane-backends and canon_pp driver (which depends on libieee1284). Instead, it can't detect the scanner. I posted to sane-devel to try to get some feedback, however there may be some FreeBSD-specific issues (see http://lists.alioth.debian.org/pipermail/sane-devel/2005-April/013400.html ). (please see the link for details). In summary: dmesg under FreeBSD shows: ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 libieee1284 is installed, if you run the test utility you get: Found 3 ports: 0x278: 0x378: 0x3bc: 0x278: 0x278 RAW NIBBLE BYTE COMPAT ECPSWE 0x378: 0x378 RAW NIBBLE BYTE COMPAT ECPSWE 0x3bc: 0x3bc RAW NIBBLE BYTE COMPAT ECPSWE But the scanner is not detected! Sorry if this post is a little off-topic, I'm looking for parallel port gurus who might be able to help. e.g. do I need some random SCSI driver or something. Cheers, Rob Pollock. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 10:43:17 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8D2F16A4CE for ; Mon, 11 Apr 2005 10:43:17 +0000 (GMT) Received: from obelix.sunrise.ch (mailrelay3.sunrise.ch [194.158.229.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8769243D3F for ; Mon, 11 Apr 2005 10:43:16 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (pop-be-3-2-dialup-50.freesurf.ch [194.230.165.50]) by obelix.sunrise.ch (8.12.10/8.12.10) with ESMTP id j3BAhEwt022070 for ; Mon, 11 Apr 2005 12:43:14 +0200 Received: from gicco.here (localhost [127.0.0.1]) by gicco.homeip.net (8.13.1/8.13.1) with ESMTP id j3BAh8HR002066 for ; Mon, 11 Apr 2005 12:43:08 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by gicco.here (8.13.1/8.12.11/Submit) id j3BAh7Wr002065 for freebsd-stable@freebsd.org; Mon, 11 Apr 2005 12:43:07 +0200 (CEST) (envelope-from hampi@rootshell.be) X-Authentication-Warning: gicco.here: idefix set sender to hampi@rootshell.be using -f Date: Mon, 11 Apr 2005 12:43:07 +0200 From: Hanspeter Roth To: freebsd-stable@freebsd.org Message-ID: <20050411104307.GA1981@gicco.homeip.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: accessing USB device with long Initialization X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 10:43:18 -0000 Hello, I've upgraded to 5.4-RC1 and I'd like to access an Mpman MP3 Player via USB. When I attach the USB device several messages appear and the Mpman displays "Starting" but then /dev/da0 is not available. The messages look like this: 11:12:22: umass0: vendor 0x10d6 Generic USB Disk Device, rev 1.10/1.00, addr 2 11:12:22: da0 at umass-sim0 bus 0 target 0 lun 0 11:12:22: da0: Removable Direct Access SCSI-2 device 11:12:22: da0: 1.000MB/s transfers 11:12:22: da0: 123MB (252509 512 byte sectors: 64H 32S/T 123C) 11:12:24: umass0: BBB reset failed, STALLED 11:12:24: umass0: BBB bulk-in clear stall failed, STALLED 11:12:24: umass0: BBB bulk-out clear stall failed, STALLED 11:12:24: (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 11:12:24: umass0: BBB reset failed, STALLED 11:12:24: umass0: BBB bulk-in clear stall failed, STALLED 11:12:24: umass0: BBB bulk-out clear stall failed, STALLED 11:12:24: umass0: BBB reset failed, STALLED 11:12:24: umass0: BBB bulk-in clear stall failed, STALLED 11:12:24: umass0: BBB bulk-out clear stall failed, STALLED 11:12:24: umass0: BBB reset failed, STALLED 11:12:24: umass0: BBB bulk-in clear stall failed, STALLED 11:12:24: umass0: BBB bulk-out clear stall failed, STALLED 11:12:24: umass0: BBB reset failed, STALLED 11:12:24: umass0: BBB bulk-in clear stall failed, STALLED 11:12:24: umass0: at uhub2 port 1 (addr 2) disconnected 11:12:24: (da0:umass-sim0:0:0:0): lost device 11:12:24: (da0:umass-sim0:0:0:0): removing device entry 11:12:24: Opened disk da0 -> 5 11:12:24: umass0: detached For comparison 5.3 calls the kernel debugger and NetBSD waits a little longer and then allows access on the Mpman. Can I make 5.4-RC1 allow accessing the Mpman? -Hanspeter From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 10:43:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53C9416A500 for ; Mon, 11 Apr 2005 10:43:21 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA92643D3F for ; Mon, 11 Apr 2005 10:43:20 +0000 (GMT) (envelope-from jacula@gmail.com) Received: by wproxy.gmail.com with SMTP id 49so720390wri for ; Mon, 11 Apr 2005 03:43:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=K/PU3OSU1yRU11PMvz0Bn4ZsJImzzDj+FdbExXruRharQySi2Ai1KBkJk1r/mrDu6lXFE3OQ1qkxGRs+ythDv3Lbzxh+UKcVUAnFM3URxZu3eBSiyCpIukCZTi2ulWWh9QErwPBAAtDT9fwAtxjSj6ZOVzf4PN4IaXMTOghmjWA= Received: by 10.54.59.20 with SMTP id h20mr3795920wra; Mon, 11 Apr 2005 03:43:19 -0700 (PDT) Received: from ?82.51.21.75? ([82.51.21.75]) by mx.gmail.com with ESMTP id 67sm771803wra.2005.04.11.03.43.18; Mon, 11 Apr 2005 03:43:19 -0700 (PDT) Message-ID: <425A54F5.3010803@gmail.com> Date: Mon, 11 Apr 2005 12:44:05 +0200 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050303 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ebm-freebsd-stable@swervinghead.com, freebsd-stable@freebsd.org References: <4259C39C.3010808@swervinghead.com> In-Reply-To: <4259C39C.3010808@swervinghead.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From: jacula Subject: Re: kernel errors : AE_NOT_FOUND X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 10:43:21 -0000 Eric Marquez wrote: > I recently notice these errors in my dmesg. Can somebody help explain > this to me. Do I need to worry about this? > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 > Features=0x8021bf > AMD Features=0x80000800 > real memory = 268419072 (255 MB) > avail memory = 253014016 (241 MB) > K6-family MTRR support enabled (2 registers) > ACPI-0277: *** Warning: Invalid checksum in table [DSDT] (23, sum fc > is not zero) > ACPI-0452: *** Error: Looking up [PIRQ] in namespace, AE_NOT_FOUND > ACPI-1303: *** Error: [NULL NAME], AE_NOT_FOUND > ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: > AE_NOT_FOUND > ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: > AE_NOT_FOUND > ACPI: table load failed: AE_NOT_FOUND > > --ebm > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > You could look: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html at the "11.16.4 ASL, acpidump, and IASL" point This is a DSDT problem. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 11:02:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3947816A4CE for ; Mon, 11 Apr 2005 11:02:48 +0000 (GMT) Received: from obelix.sunrise.ch (mailrelay3.sunrise.ch [194.158.229.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CA3743D31 for ; Mon, 11 Apr 2005 11:02:47 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (pop-zh-15-2-dialup-94.freesurf.ch [194.230.214.94]) by obelix.sunrise.ch (8.12.10/8.12.10) with ESMTP id j3BB2jwt031179 for ; Mon, 11 Apr 2005 13:02:45 +0200 Received: from gicco.here (localhost [127.0.0.1]) by gicco.homeip.net (8.13.1/8.13.1) with ESMTP id j3BB2enG002282 for ; Mon, 11 Apr 2005 13:02:40 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by gicco.here (8.13.1/8.12.11/Submit) id j3BB2eYN002281 for freebsd-stable@freebsd.org; Mon, 11 Apr 2005 13:02:40 +0200 (CEST) (envelope-from hampi@rootshell.be) X-Authentication-Warning: gicco.here: idefix set sender to hampi@rootshell.be using -f Date: Mon, 11 Apr 2005 13:02:40 +0200 From: Hanspeter Roth To: freebsd-stable@freebsd.org Message-ID: <20050411110240.GA2118@gicco.homeip.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: minority tolarated? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 11:02:48 -0000 Hello, The Beastie menu makes it convenient choosing boot options. The Beastie decorating space right to the menu reflects the preference of the majority or all of the FreeBSD developers. Their opinion is documented in http://www.freebsd.org/copyright/daemon.html . However there are users which have a different opinion and which don't like the Beastie mascot to be displayed during boot time. However there are users which have a different opinion and which don't like the Beastie mascot to be displayed during boot time. The question is: are such users - welcome - tolerated - disliked. In case they are more or less tolerated what should they do in order to switch the Beastie splash screen? - renounce of the Beastie menu (beastie_disable="YES") ? - spend some hours to dig in mailing lists or dig in http://www.forth.org/tutorials.html ? - or have an convenient flag in loaders.conf that allows to run Beastie menu but display some other decoration? The patch 74577 offers a convenient flag to disable the display of the Beastie while being compatible with the majority of the FreeBSD developers. http://www.freebsd.org/cgi/query-pr.cgi?pr=74577 There were talks that the FreeBSD logo will change anyway. But so far this has not affected 5.4-RC1. -Hanspeter From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 12:24:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78CB316A4D1 for ; Mon, 11 Apr 2005 12:24:06 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9015143D41 for ; Mon, 11 Apr 2005 12:24:05 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so2583141wra for ; Mon, 11 Apr 2005 05:24:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=huxbJdHkPwaxqxxBeoZcfYxS21pWCf8B24ek+M6L9hhpi8a/Aal6gNv1vntD94/kgZ/ExvYkc3vRUi9J+V/3nk//6YY7KHOCUsdx9j5wGiIZgfedfC3ug0MW1sNobSYS7WBVl8HKIM4e7cOoQ2GwWm/5IN3I2FbSQ8QV/fnBfGE= Received: by 10.54.21.37 with SMTP id 37mr2041663wru; Mon, 11 Apr 2005 05:24:02 -0700 (PDT) Received: by 10.54.56.4 with HTTP; Mon, 11 Apr 2005 05:24:01 -0700 (PDT) Message-ID: <59e2ee81050411052460f8bc0c@mail.gmail.com> Date: Mon, 11 Apr 2005 14:24:01 +0200 From: Rostislav Krasny To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: two mysterious files in RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rostislav Krasny List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 12:24:06 -0000 Hello all. I have FreeBSD 5.4-RC1 installed from FTP. Today I ran cvsup to get the latest RELENG_5_4 src-all. I've seen two strange files were checkouted by cvsup: Checkout src/installworld_newk Checkout src/installworld_oldk I don't see those files on http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_5_4 but I see them on http://www.freebsd.org/cgi/cvsweb.cgi/src/Attic/ According to the cvsweb logs those files were removed in HEAD but still exist in RELENG_5_4. But why I don't see them on the cvsweb by the first URL and why they didn't exist in my 5.4-RC1 before cvsup? Or, if they were removed in the RELENG_5_4 too, why cvsup checkouted them today? Following is my cvsup supfile: # Defaults that apply to all the collections # *default host=cvsup.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_5_4 *default delete use-rel-suffix *default compress ## Main Source Tree. # src-all From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 13:59:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 275F616A4CE for ; Mon, 11 Apr 2005 13:59:18 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98EEC43D58 for ; Mon, 11 Apr 2005 13:59:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3BE2iq1031078; Mon, 11 Apr 2005 08:02:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A81F7.7040109@samsco.org> Date: Mon, 11 Apr 2005 07:56:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aristedes Maniatis References: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> In-Reply-To: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-stable@freebsd.org Subject: Re: aac support for Adaptec 2020SA ZCR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 13:59:18 -0000 Aristedes Maniatis wrote: > We have a motherboard (Supermicro X6DHT-G) with an Adaptec 2020SA SATA > RAID controller. We have been unable to get any drives recognised by the > FreeBSD 5.3 release installation CD, and we've been unable to find much > discussion about the status of the AAC device and support for this > chipset. Several other Adaptec SATA RAID controllers seem to be > supported: 2410SA, 2810SA, 21610SA. The logical drive configured in the > RAID controller is detected successfully in a Gentoo Linux 2004.3 > environment. > > Has anyone had success with this controller? Any alternative you would > recommend or will support be available in 5.4? I believe from the source > code that the driver is maintained by Scott Long and that recent changes > have been taking place. > > > Thanks for any assistance. > > Ari Maniatis > > The 2020 seems to be in a pre-release phase just for SuperMicro. It's not mentioned at all on the Adaptec website. I've been in contact with Adaptec engineers who are preparing updates for the FreeBSD driver for it, but it's looking unlikely that they will be done in time for the 5.4 release. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 14:01:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20B3D16A4CE for ; Mon, 11 Apr 2005 14:01:05 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 667F143D31 for ; Mon, 11 Apr 2005 14:01:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3BE4LUq031087; Mon, 11 Apr 2005 08:04:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A8259.9050607@samsco.org> Date: Mon, 11 Apr 2005 07:57:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Uzi Klein References: <8e131b2855562f4bf32410218f53ee1c@ish.com.au> <425A2DC3.9070904@bmby.com> In-Reply-To: <425A2DC3.9070904@bmby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-stable@freebsd.org Subject: Re: aac support for Adaptec 2020SA ZCR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 14:01:05 -0000 Uzi Klein wrote: > Aristedes Maniatis wrote: > >> We have a motherboard (Supermicro X6DHT-G) with an Adaptec 2020SA SATA >> RAID controller. We have been unable to get any drives recognised by >> the FreeBSD 5.3 release installation CD, and we've been unable to find >> much discussion about the status of the AAC device and support for >> this chipset. Several other Adaptec SATA RAID controllers seem to be >> supported: 2410SA, 2810SA, 21610SA. The logical drive configured in >> the RAID controller is detected successfully in a Gentoo Linux 2004.3 >> environment. >> >> Has anyone had success with this controller? Any alternative you would >> recommend or will support be available in 5.4? I believe from the >> source code that the driver is maintained by Scott Long and that >> recent changes have been taking place. > > > You might be interested in this article: > http://hardware.slashdot.org/hardware/05/03/20/1944233.shtml?tid=198&tid=190&tid=172&tid=137&tid=7 > > I don't know how FreeBSD is related, but it's probably is. > FreeBSD != OpenBSD. Let's please not drag that rubbish flamewar onto our technical lists. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 16:07:16 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D771916A4CE for ; Mon, 11 Apr 2005 16:07:16 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86DB243D45 for ; Mon, 11 Apr 2005 16:07:16 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 9EB66DB6B; Mon, 11 Apr 2005 12:07:15 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 0F71A1A08C0; Mon, 11 Apr 2005 12:07:08 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.41132.3567.487154@canoe.dclg.ca> Date: Mon, 11 Apr 2005 12:07:08 -0400 To: freebsd-stable@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: netstat -m broken. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 16:07:16 -0000 I'm runing 5.4-STABLE on an dual processor amd64. I'm using the network pretty heavily (dual GigE interfaces doing 300 megabit each) and my netstat -m is giving odd results: [1:31:331]root@m0:~> netstat -m 25927 mbufs in use 18446744073709547405/512000 mbuf clusters in use (current/max) 0/0/0 sfbufs in use (current/peak/max) 18014398509480043 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines [1:37:337]root@m1:~> netstat -m 18446744073709550967 mbufs in use 4315/512000 mbuf clusters in use (current/max) 0/0/0 sfbufs in use (current/peak/max) 8467 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ... many of the numbers get really big like that. this machine was just booted. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 16:41:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C84316A4CE; Mon, 11 Apr 2005 16:41:24 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBE143D1F; Mon, 11 Apr 2005 16:41:23 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001313858.msg; Mon, 11 Apr 2005 17:38:15 +0100 Message-ID: <014301c53eb5$42638bf0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Mon, 11 Apr 2005 17:01:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 11 Apr 2005 17:38:15 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Mon, 11 Apr 2005 17:38:17 +0100 Subject: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 16:41:24 -0000 Just had a problem with a box where it looks like it ran out of swap due to a problem process, not a problem. The problem was that it seems the kernel on detecting this starts killing off seeming random processes, the first one being sshd hence making the machine inaccessible. So the question is: Does the kernel kill random processes when out of swap or does it kill any processes that require more memory when out of swap? Which leads to the question would it not be more sensible to kill off the largest process first as its more than likely that it is responsible for the problem? [quote] Apr 10 20:09:25 appledore kernel: pid 414 (sshd), uid 0, was killed: out of swap space [/quote] Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 16:42:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856C416A4CE for ; Mon, 11 Apr 2005 16:42:49 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 811BD43D49 for ; Mon, 11 Apr 2005 16:42:48 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j3BGgjXk008185; Mon, 11 Apr 2005 20:42:45 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 11 Apr 2005 20:42:45 +0400 (MSD) From: Maxim Konovalov To: David Gilbert In-Reply-To: <16986.41132.3567.487154@canoe.dclg.ca> Message-ID: <20050411204208.N8102@mp2.macomnet.net> References: <16986.41132.3567.487154@canoe.dclg.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: netstat -m broken. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 16:42:49 -0000 On Mon, 11 Apr 2005, 12:07-0400, David Gilbert wrote: > I'm runing 5.4-STABLE on an dual processor amd64. I'm using the > network pretty heavily (dual GigE interfaces doing 300 megabit each) > and my netstat -m is giving odd results: FAQ. Documented in 5.3 errata: http://www.freebsd.org/releases/5.3R/errata.html -- Maxim Konovalov From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 16:47:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A47E616A4CE for ; Mon, 11 Apr 2005 16:47:06 +0000 (GMT) Received: from gort.hpl.hp.com (gort.hpl.hp.com [192.6.10.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id F398843D58 for ; Mon, 11 Apr 2005 16:47:05 +0000 (GMT) (envelope-from jhr@ballard.hpl.hp.com) Received: from ballard.hpl.hp.com (ballard.hpl.hp.com [15.144.26.39]) by gort.hpl.hp.com (8.12.10/8.12.10) with ESMTP id j3BGkhon027053 for ; Mon, 11 Apr 2005 17:46:44 +0100 (BST) Received: by ballard.hpl.hp.com (Postfix, from userid 1001) id 4215193; Mon, 11 Apr 2005 17:46:43 +0100 (BST) From: John Hawkes-Reed Organization: The Ministry for the Prevention of Stupidity To: freebsd-stable@freebsd.org Date: Mon, 11 Apr 2005 17:46:42 +0100 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504111746.42804.hirez@libeljournal.com> X-HPL-MailScanner-Information: Please contact the Helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.153, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL -0.31) X-MailScanner-From: jhr@ballard.hpl.hp.com Subject: Hp dc7100 installs 5.4-rc1 from CD but won't boot from HD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hirez@libeljournal.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 16:47:06 -0000 (Which I think covers the problem) Boots from CD ok, USB keyboard seems less than reliable, so I'm using a PS2 item. Running through 'standard' install appears to write data to the (SATA ICH6 controller) disk, but on reboot it sits at the F1: FreeBSD prompt beeping every ten seconds. Is there likely to be anything obvious I've missed? (Or indeed more useful data I can provide.) As a test, I installed a Debian Sarge CD. That works. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 17:01:39 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8079B16A4CE for ; Mon, 11 Apr 2005 17:01:39 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D2E43D1D for ; Mon, 11 Apr 2005 17:01:38 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C3D6.dip.t-dialin.net[84.163.195.214] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1DL2I2423C-0001Vp; Mon, 11 Apr 2005 19:01:34 +0200 From: Max Laier To: freebsd-stable@freebsd.org Date: Mon, 11 Apr 2005 19:01:21 +0200 User-Agent: KMail/1.8 References: <16986.41132.3567.487154@canoe.dclg.ca> <20050411204208.N8102@mp2.macomnet.net> In-Reply-To: <20050411204208.N8102@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1878036.eJXen7lt2A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504111901.29156.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 cc: David Gilbert Subject: Re: netstat -m broken. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 17:01:39 -0000 --nextPart1878036.eJXen7lt2A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 April 2005 18:42, Maxim Konovalov wrote: > On Mon, 11 Apr 2005, 12:07-0400, David Gilbert wrote: > > I'm runing 5.4-STABLE on an dual processor amd64. I'm using the > > network pretty heavily (dual GigE interfaces doing 300 megabit each) > > and my netstat -m is giving odd results: > > FAQ. Documented in 5.3 errata: > http://www.freebsd.org/releases/5.3R/errata.html Maybe we should add that: $vmstat -z | grep Mbuf gives an idea of the actual memory usage for mbufs. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1878036.eJXen7lt2A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCWq1pXyyEoT62BG0RAp7VAJ95C1XmPvALNHtCb6z5PT5dCTA43wCaA9Y3 gEJiLNkVRxa4jTb5INYMrR0= =4WEs -----END PGP SIGNATURE----- --nextPart1878036.eJXen7lt2A-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 17:55:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D324616A4CE for ; Mon, 11 Apr 2005 17:55:28 +0000 (GMT) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4502D43D1F for ; Mon, 11 Apr 2005 17:55:28 +0000 (GMT) (envelope-from brett@lariat.org) Received: (from root@localhost) by lariat.org (8.9.3/8.9.3) id LAA16933 for stable@freebsd.org; Mon, 11 Apr 2005 11:55:22 -0600 (MDT) Date: Mon, 11 Apr 2005 11:55:22 -0600 (MDT) From: Brett Glass Message-Id: <200504111755.LAA16933@lariat.org> To: stable@freebsd.org Subject: Ready for dual core Opterons? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 17:55:28 -0000 According to the article at http://www.techweb.com/wire/hardware/160503169 AMD is going to be launching dual core Opterons this month. Will FreeBSD 5.4 be ready to handle them? Also, will the "nve" driver (which is needed to run the Ethernet interface on AMD-based boards with NVidia chipsets) be in 5.4? --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 17:59:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3871116A4CE for ; Mon, 11 Apr 2005 17:59:53 +0000 (GMT) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8234543D46 for ; Mon, 11 Apr 2005 17:59:52 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr8so.prod.shaw.ca (pd3mr8so-qfe3.prod.shaw.ca [10.0.141.24])2004)) with ESMTP id <0IES00G5UNABSUD1@l-daemon> for stable@freebsd.org; Mon, 11 Apr 2005 11:58:59 -0600 (MDT) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd3mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IES002KXNABNM90@pd3mr8so.prod.shaw.ca> for stable@freebsd.org; Mon, 11 Apr 2005 11:58:59 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IES00A19NABX3@l-daemon> for stable@freebsd.org; Mon, 11 Apr 2005 11:58:59 -0600 (MDT) Date: Mon, 11 Apr 2005 10:58:50 -0700 From: Colin Percival In-reply-to: <200504111755.LAA16933@lariat.org> To: Brett Glass Message-id: <425ABADA.8000403@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <200504111755.LAA16933@lariat.org> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: stable@freebsd.org Subject: Re: Ready for dual core Opterons? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 17:59:53 -0000 Brett Glass wrote: > According to the article at > > http://www.techweb.com/wire/hardware/160503169 > > AMD is going to be launching dual core Opterons this month. Will FreeBSD 5.4 > be ready to handle them? My understanding is that dual core opterons just look like multiple processors to the operating system, so there should be no problems. For that matter, my understanding is that dual core opterons *are* separate processors, connected only via their normal external interface. Colin Percival From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 18:03:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50D5316A4CE; Mon, 11 Apr 2005 18:03:05 +0000 (GMT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7581843D70; Mon, 11 Apr 2005 18:03:02 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3BI30b4069719; Mon, 11 Apr 2005 20:03:01 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j3BI309w058217; Mon, 11 Apr 2005 20:03:00 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3BI30xM058216; Mon, 11 Apr 2005 20:03:00 +0200 (CEST) (envelope-from wb) Date: Mon, 11 Apr 2005 20:03:00 +0200 From: Wilko Bulte To: Colin Percival Message-ID: <20050411180300.GA58175@freebie.xs4all.nl> References: <200504111755.LAA16933@lariat.org> <425ABADA.8000403@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425ABADA.8000403@freebsd.org> X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Brett Glass cc: stable@freebsd.org Subject: Re: Ready for dual core Opterons? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 18:03:05 -0000 On Mon, Apr 11, 2005 at 10:58:50AM -0700, Colin Percival wrote.. > Brett Glass wrote: > > According to the article at > > > > http://www.techweb.com/wire/hardware/160503169 > > > > AMD is going to be launching dual core Opterons this month. Will FreeBSD 5.4 > > be ready to handle them? > > My understanding is that dual core opterons just look like multiple > processors to the operating system, so there should be no problems. > > For that matter, my understanding is that dual core opterons *are* > separate processors, connected only via their normal external > interface. Ask David (obrien) I suppose. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 19:10:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4550F16A4CE for ; Mon, 11 Apr 2005 19:10:00 +0000 (GMT) Received: from smtp809.mail.sc5.yahoo.com (smtp809.mail.sc5.yahoo.com [66.163.168.188]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B7DB43D41 for ; Mon, 11 Apr 2005 19:09:59 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.200.153 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 11 Apr 2005 18:56:32 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 5DF29615C; Mon, 11 Apr 2005 13:56:31 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06460-17; Mon, 11 Apr 2005 13:56:29 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id C61B2612C; Mon, 11 Apr 2005 13:56:29 -0500 (CDT) Message-ID: <425AC85D.2010607@alumni.rice.edu> Date: Mon, 11 Apr 2005 13:56:29 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rostislav Krasny References: <59e2ee81050411052460f8bc0c@mail.gmail.com> In-Reply-To: <59e2ee81050411052460f8bc0c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: freebsd-stable@freebsd.org Subject: Re: two mysterious files in RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 19:10:00 -0000 On 4/11/2005 7:24 AM, Rostislav Krasny wrote: > Hello all. > > I have FreeBSD 5.4-RC1 installed from FTP. Today I ran cvsup to get > the latest RELENG_5_4 src-all. I've seen two strange files were > checkouted by cvsup: > > Checkout src/installworld_newk > Checkout src/installworld_oldk > > I don't see those files on > http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_5_4 > but I see them on http://www.freebsd.org/cgi/cvsweb.cgi/src/Attic/ > According to the cvsweb logs those files were removed in HEAD but > still exist in RELENG_5_4. But why I don't see them on the cvsweb by > the first URL and why they didn't exist in my 5.4-RC1 before cvsup? > Or, if they were removed in the RELENG_5_4 too, why cvsup checkouted > them today? *sigh* The files were removed from HEAD but still exist in RELENG_5 and children (like RELENG_5_4). What you are experiencing is a limitation of CVSweb: files in the Attic are not handled well (the newest release, 3.0.5, doesn't do this correctly either). I recently started working on CVSweb and this is one of the things on my TODO list. I'm not sure why the 5.4-RC1 src didn't include them; perhaps files are excluded from the src depending on which arch the release is targeting? These particular files are only used for sparc64. Jon From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 19:29:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6398116A4CE for ; Mon, 11 Apr 2005 19:29:28 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE31B43D2F for ; Mon, 11 Apr 2005 19:29:27 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1458457wra for ; Mon, 11 Apr 2005 12:29:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=fDDc2eMbuw6nONSX98QoQtv8l2eeZkAfGk5zG/nGU71+/zSl8l6x/7N159ttENW+66Z4aZv3w++UcRHSXhtu/QEaf6NCfGkkeuQPPB0xWWXG8Q7lTrmRPKzHdwqt007dqVIETXl0XfLdrnz7f07tUSFv7MreAowhOKCKVOko650= Received: by 10.54.24.49 with SMTP id 49mr5373746wrx; Mon, 11 Apr 2005 12:29:27 -0700 (PDT) Received: by 10.54.7.56 with HTTP; Mon, 11 Apr 2005 12:29:27 -0700 (PDT) Message-ID: <6eb82e05041112292f93e2d5@mail.gmail.com> Date: Tue, 12 Apr 2005 03:29:27 +0800 From: Rong-En Fan To: "Brandon S. Allbery KF8NH" In-Reply-To: <1113160601.37307.9.camel@rushlight.kf8nh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1113160601.37307.9.camel@rushlight.kf8nh.com> cc: stable@freebsd.org Subject: Re: 5.3-S (Mar 6) softdep stack backtrace from getdirtybuf()... problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rong-En Fan List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 19:29:28 -0000 On Apr 11, 2005 3:16 AM, Brandon S. Allbery KF8NH wrote: > I have twice so far had the kernel syslog a stack backtrace with no > other information. Inspection of the kernel source, to the best of my > limited understanding, suggests that getdirtybuf() was handed a buffer > without an associated vnode. Kernel config file and make.conf attached. > > Should I be concerned? > > Note that this system is an older 600MHz Athlon with only 256MB RAM, and > both times this triggered it was thrashing quite a bit (that's more or > less its usual state...). I saw these similar trace on a 5.4-RC1/amd64 with 9 NFS mount. I suspect this is a issue with busy NFS server? rafan. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 19:31:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 289AE16A4CE for ; Mon, 11 Apr 2005 19:31:54 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE5D043D7C for ; Mon, 11 Apr 2005 19:31:53 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from PYANFAR.ECE.CMU.EDU (PYANFAR.ECE.CMU.EDU [128.2.136.40]) by bache.ece.cmu.edu (Postfix) with ESMTP id 57F6D72; Mon, 11 Apr 2005 15:31:52 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: Rong-En Fan In-Reply-To: <6eb82e05041112292f93e2d5@mail.gmail.com> References: <1113160601.37307.9.camel@rushlight.kf8nh.com> <6eb82e05041112292f93e2d5@mail.gmail.com> Content-Type: text/plain Date: Mon, 11 Apr 2005 15:31:51 -0400 Message-Id: <1113247911.1405.0.camel@pyanfar.ece.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: stable@freebsd.org Subject: Re: 5.3-S (Mar 6) softdep stack backtrace from getdirtybuf()... problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 19:31:54 -0000 On Tue, 2005-04-12 at 03:29 +0800, Rong-En Fan wrote: > I saw these similar trace on a 5.4-RC1/amd64 with 9 NFS mount. I suspect > this is a issue with busy NFS server? No, no NFS involved at all, nor any other network filesystem, client or server. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 20:49:07 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE5516A4CE for ; Mon, 11 Apr 2005 20:49:07 +0000 (GMT) Received: from bloom.cse.buffalo.edu (bloom.cse.Buffalo.EDU [128.205.32.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F7643D1D for ; Mon, 11 Apr 2005 20:49:07 +0000 (GMT) (envelope-from kensmith@FreeBSD.org) Received: from bloom.cse.buffalo.edu (localhost.cse.buffalo.edu [127.0.0.1]) by bloom.cse.buffalo.edu (8.13.3/8.12.4) with ESMTP id j3BKn6NZ026887 for ; Mon, 11 Apr 2005 16:49:06 -0400 (EDT) Received: (from kensmith@localhost) by bloom.cse.buffalo.edu (8.13.3/8.13.1/Submit) id j3BKn6Ei026886 for freebsd-stable@freebsd.org; Mon, 11 Apr 2005 16:49:06 -0400 (EDT) (envelope-from kensmith) Date: Mon, 11 Apr 2005 16:49:06 -0400 From: Ken Smith To: freebsd-stable@freebsd.org Message-ID: <20050411204906.GA26872@bloom.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: FreeBSD 5.4-RC2 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 20:49:08 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Announcement ------------ The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 5.4-RC2, the second Release Candidate of the FreeBSD 5.4 release cycle. We encourage people to help with testing so any final bugs can be identified and worked out. At this point the only major problem has been reports of large server (4 processors or more) hanging under extreme load conditions (varied load of local processes like database and heavy network load). Details to help with debugging have been hard to obtain so if anyone is in a position to help with trying to reproduce this it would be appreciated. Availability of ISO images and support for doing FTP based installs is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_5_4. Problem reports can be submitted using the send-pr(1) command, and/or posted to the "freebsd-stable@freebsd.org" mailing list. A schedule and the current todo list for the 5.4 Release Cycle are available: http://www.freebsd.org/releases/5.4R/schedule.html http://www.freebsd.org/releases/5.4R/todo.html The packages being provided as part of RC2 are what is expected to come with the final release for the amd64, i386, pc98, and sparc64 architectures. Packages for alpha and ia64 are still being worked on. Availability ------------ The RC2 ISOs and FTP support for all architectures are available now on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s of the ISO images are: MD5 (5.4-RC2-alpha-bootonly.iso) = 2238c45b5907931d248487cac55f1c5f MD5 (5.4-RC2-alpha-disc1.iso) = 89ecfdb35ea3cd92716686116b664ea5 MD5 (5.4-RC2-alpha-disc2.iso) = 678581d5b6ae049f18491e203ebadd20 MD5 (5.4-RC2-amd64-bootonly.iso) = 50db1883edf34ff15834da03654d79c3 MD5 (5.4-RC2-amd64-disc1.iso) = a18c728f6259847a1538b03815bfc640 MD5 (5.4-RC2-amd64-disc2.iso) = a0686aa29eca455436f7d9cb0164f055 MD5 (5.4-RC2-i386-bootonly.iso) = 66303d342f235870572b8bd882425445 MD5 (5.4-RC2-i386-disc1.iso) = 08b9ae45f5f6873468d03a3915f55de4 MD5 (5.4-RC2-i386-disc2.iso) = 115fd80bfaa54b94ef194d104e7a803f MD5 (5.4-RC2-ia64-bootonly.iso) = 2e459a193e00f499371252ea98291af4 MD5 (5.4-RC2-ia64-disc1.iso) = 31914a284b740c32e8808e7bfaf408c0 MD5 (5.4-RC2-ia64-disc2.iso) = 875b59e9435ca7e79ab36562cf5c1e88 MD5 (5.4-RC2-ia64-livefs.iso) = 0ae9868c11a46e9f7e56f1e4d71f2e7e MD5 (5.4-RC2-pc98-disc1.iso) = 12f527c1ed165101ff36053c29440212 MD5 (5.4-RC2-sparc64-bootonly.iso) = 6f087402361627a1e6c52c134152c52f MD5 (5.4-RC2-sparc64-disc1.iso) = 411916559bd5ebe03f6ae65622b02e5f MD5 (5.4-RC2-sparc64-disc2.iso) = 1300c0abeda2d00bb859adbc8a1d7a9a -ken --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWuLB/G14VSmup/YRAuBAAJ42BBjnAM5NWnhUNtCz/nTQdTfuUACgliru BZUDqn2uzFbEHGwAVM5UdNE= =i9UI -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 22:45:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A12716A4CE for ; Mon, 11 Apr 2005 22:45:09 +0000 (GMT) Received: from knuth.hurstdog.org (knuth.hurstdog.org [69.55.236.147]) by mx1.FreeBSD.org (Postfix) with SMTP id 00B0243D4C for ; Mon, 11 Apr 2005 22:45:09 +0000 (GMT) (envelope-from tim.howe@celebrityresorts.com) Received: (qmail 7400 invoked from network); 11 Apr 2005 22:38:01 -0000 Received: from knuth.hurstdog.org (HELO fred.colohowes.org) (69.55.236.147) by knuth.hurstdog.org with SMTP; 11 Apr 2005 22:38:01 -0000 Received: from piro.quadium.net (piro.colohowes.org [10.27.56.90]) by fred.colohowes.org (Postfix) with ESMTP id 268608FE41 for ; Mon, 11 Apr 2005 16:39:31 -0600 (MDT) Received: from beaker.data-secure.net (localhost [127.0.0.1]) by piro.quadium.net (8.12.6/8.12.6) with ESMTP id j3BMSqTR051366 for ; Mon, 11 Apr 2005 18:28:53 -0400 (EDT) (envelope-from tim.howe@celebrityresorts.com) Received: by beaker.data-secure.net (Postfix, from userid 1000) id CEB2E39885; Mon, 11 Apr 2005 18:37:59 -0400 (EDT) To: freebsd-stable@freebsd.org From: Tim Howe Date: Mon, 11 Apr 2005 17:24:15 -0400 Message-ID: <87oecl57nk.fsf@beaker.data-secure.net> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, berkeley-unix) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Subject: Kodak USB flash reader causes freezes, panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 22:45:09 -0000 I'm not sure if this should go here or to -bugs, but the other USB-related reports put me in good company, I'm hoping... I'm having a problem with a Kodak USB flash reader. "camcontrol inquiry" gives me: pass0: Removable Direct Access SCSI-0 device pass0: Serial Number pass0: 1.000MB/s transfers The device has printed on it: Kodak Multi-Card Reader CE2A012 KP P/N 7E3771 ITEM# 20209416 P/N 680-070-563 Reproducibly, if I begin copying data to a Lexar 256MB CF card (P/N 2250, Rev. A), it works for a while, then freezes the system. The first time this happened it was when trying to unmount the filesystem. The second time was in the midst of copying data. Both times the system was completely frozen; not even the keyboard LEDs toggled. Strangely, I could connect on the SSH and FTP ports, but received no welcome banner. The third time I modified the script I was using to copy my files to sync and sleep after each file. This time the system seemed to freeze, then lurch through handling several interrupts (mouse pointer moved and a menu popped up from right-clicking), then froze again. Initially connecting to the SSH port brought up the banner after a very long delay, but an attempt to reproduce this was unsuccessful, and I was unable to actually SSH in. Mounting the filesystem synchronously doesn't seem to help. The first time it worked, but then when I unmounted and remounted it and copied some more files it froze midway through. I'm running FreeBSD 5.3: FreeBSD beaker.data-secure.net 5.3-RELEASE-p8 FreeBSD 5.3-RELEASE-p8 #1: Mon Apr 11 15:20:08 EDT 2005 root@beaker.data-secure.net:/usr/obj/usr/src/sys/GENERIC i386 I will be fairly busy for the next few days but later this week I should be able to try out patches or set up a machine running a more cutting-edge source tree, if necessary. I've got FreeBSD 5.4-RC2 building today, actually; is it likely that this will solve my problem? Thanks in advance for any assistance. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 11 23:01:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75DB516A4CE for ; Mon, 11 Apr 2005 23:01:09 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3373D43D46 for ; Mon, 11 Apr 2005 23:01:09 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3BN175j026788; Mon, 11 Apr 2005 16:01:07 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3BN17Jb026787; Mon, 11 Apr 2005 16:01:07 -0700 Date: Mon, 11 Apr 2005 16:01:07 -0700 From: Brooks Davis To: Tim Howe Message-ID: <20050411230107.GA11717@odin.ac.hmc.edu> References: <87oecl57nk.fsf@beaker.data-secure.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <87oecl57nk.fsf@beaker.data-secure.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-stable@freebsd.org Subject: Re: Kodak USB flash reader causes freezes, panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 23:01:09 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 05:24:15PM -0400, Tim Howe wrote: > I'm not sure if this should go here or to -bugs, but the other > USB-related reports put me in good company, I'm hoping... >=20 > I'm having a problem with a Kodak USB flash reader. "camcontrol > inquiry" gives me: >=20 > pass0: Removable Direct Access SCSI-0 device= =20 > pass0: Serial Number=20 > pass0: 1.000MB/s transfers=20 >=20 > The device has printed on it: >=20 > Kodak Multi-Card Reader CE2A012 > KP P/N 7E3771 > ITEM# 20209416 > P/N 680-070-563 >=20 > Reproducibly, if I begin copying data to a Lexar 256MB CF card (P/N > 2250, Rev. A), it works for a while, then freezes the system. The first > time this happened it was when trying to unmount the filesystem. The > second time was in the midst of copying data. Both times the system was > completely frozen; not even the keyboard LEDs toggled. Strangely, I > could connect on the SSH and FTP ports, but received no welcome banner. >=20 > The third time I modified the script I was using to copy my files to > sync and sleep after each file. This time the system seemed to freeze, > then lurch through handling several interrupts (mouse pointer moved and > a menu popped up from right-clicking), then froze again. Initially > connecting to the SSH port brought up the banner after a very long > delay, but an attempt to reproduce this was unsuccessful, and I was > unable to actually SSH in. >=20 > Mounting the filesystem synchronously doesn't seem to help. The first > time it worked, but then when I unmounted and remounted it and copied > some more files it froze midway through. >=20 > I'm running FreeBSD 5.3: >=20 > FreeBSD beaker.data-secure.net 5.3-RELEASE-p8 FreeBSD 5.3-RELEASE-p8 #1: = Mon Apr 11 15:20:08 EDT 2005 root@beaker.data-secure.net:/usr/obj/usr/s= rc/sys/GENERIC i386 >=20 > I will be fairly busy for the next few days but later this week I should > be able to try out patches or set up a machine running a more > cutting-edge source tree, if necessary. I've got FreeBSD 5.4-RC2 > building today, actually; is it likely that this will solve my problem? It is quite likely that 5.4 fixed your problem. Not certain, of course, but many problems have been fixed recently. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCWwGzXY6L6fI4GtQRAlh8AJ9HcpBKzjFi4L/RI76x1oBQu1wjNwCg2fw5 ftHqB6GuQON+zDxJqgij1BE= =Yk2U -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 01:24:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D25916A4CE for ; Tue, 12 Apr 2005 01:24:46 +0000 (GMT) Received: from mta206-rme.xtra.co.nz (mta206-rme.xtra.co.nz [210.86.15.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ACFB43D48 for ; Tue, 12 Apr 2005 01:24:45 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from pop2-rme.xtra.co.nz ([210.86.15.240]) by mta206-rme.xtra.co.nz with ESMTP <20050412012442.HDRK2171.mta206-rme.xtra.co.nz@pop2-rme.xtra.co.nz> for ; Tue, 12 Apr 2005 13:24:42 +1200 Received: from [10.58.3.145] ([222.152.246.166]) by pop2-rme.xtra.co.nz with ESMTP id <20050412012441.UQZR16943.pop2-rme.xtra.co.nz@[10.58.3.145]> for ; Tue, 12 Apr 2005 13:24:41 +1200 Mime-Version: 1.0 (Apple Message framework v619.2) To: freebsd-stable@freebsd.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-15--329589554 From: Philip Murray Date: Tue, 12 Apr 2005 13:24:40 +1200 X-Mailer: Apple Mail (2.619.2) Subject: Intel 6300ESB (ICH) SMBus controller not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 01:24:46 -0000 --Apple-Mail-15--329589554 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver doesn't want to work with it, I get the following on boot: ichsmb0: port 0x8c0-0x8df irq 17 at device 31.3 on pci0 device_attach: ichsmb0 attach returned 6 It then doesn't load smb or smbus. I had a look in the source and it is supposed to work with this controller. Is this something wrong with the driver? or have I left out some bit of configuration? Attached is the output from boot -v and my kernel configuration. Is there any other debugging output that would be useful? Cheers, Phil -- --Apple-Mail-15--329589554 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0444; name="ALEXIS.txt" Content-Disposition: attachment; filename=ALEXIS.txt include GENERIC ident ALEXIS options HZ=1000 options MAXDSIZ="(1024*1024*1024)" options MAXSSIZ="(1024*1024*1024)" options DFLDSIZ="(1024*1024*1024)" options SEMMNI=256 options SEMMNS=512 options SEMMNU=256 options SEMMAP=256 options SHMMAXPGS=4096 options ACCEPT_FILTER_HTTP device smb device smbus device ichsmb device iic device iicbus device iicbb device iicsmb device usb device uhci device ehci --Apple-Mail-15--329589554 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-15--329589554 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0444; name="boot_verbose.txt" Content-Disposition: attachment; filename=boot_verbose.txt /boot/kernel/acpi.ko text=0x41480 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=01 base=0000000000100000 len=000000007fec0000 SMAP type=02 base=000000007ffcfc00 len=0000000000000400 SMAP type=03 base=000000007ffc0000 len=000000000000fc00 SMAP type=02 base=000000007ffd0000 len=0000000000020000 SMAP type=02 base=000000007fff0000 len=000000000000f000 SMAP type=02 base=00000000fed20000 len=000000000006ffff SMAP type=02 base=00000000fec00000 len=0000000000090000 SMAP type=02 base=00000000fee00000 len=0000000000010000 SMAP type=02 base=00000000ffb00000 len=0000000000500000 Copyright (c) 1992-2005 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.4-STABLE #4: Mon Apr 11 12:24:01 NZST 2005 root@alexis.open2view.com:/usr/obj/usr/src/sys/ALEXIS Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a45000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a4526c. Calibrating clock(s) ... i8254 clock: 1193174 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3400136841 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.40GHz (3400.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2147221504 (2047 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000007db90fff, 2096545792 bytes (511852 pages) avail memory = 2095755264 (1998 MB) Table 'FACP' at 0xfdc84 Table 'APIC' at 0xfdcf8 MADT: Found table at 0xfdcf8 MP Configuration Table version 1.4 found at 0xc00f0000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 1 ACPI ID 2: enabled ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xc9de pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Found IO APIC ID 3, Interrupt 24 at 0xfec10000 ioapic1: Changing APIC ID to 3 ioapic1: intpin 0 -> PCI IRQ 24 (level, low) ioapic1: intpin 1 -> PCI IRQ 25 (level, low) ioapic1: intpin 2 -> PCI IRQ 26 (level, low) ioapic1: intpin 3 -> PCI IRQ 27 (level, low) ioapic1: intpin 4 -> PCI IRQ 28 (level, low) ioapic1: intpin 5 -> PCI IRQ 29 (level, low) ioapic1: intpin 6 -> PCI IRQ 30 (level, low) ioapic1: intpin 7 -> PCI IRQ 31 (level, low) ioapic1: intpin 8 -> PCI IRQ 32 (level, low) ioapic1: intpin 9 -> PCI IRQ 33 (level, low) ioapic1: intpin 10 -> PCI IRQ 34 (level, low) ioapic1: intpin 11 -> PCI IRQ 35 (level, low) ioapic1: intpin 12 -> PCI IRQ 36 (level, low) ioapic1: intpin 13 -> PCI IRQ 37 (level, low) ioapic1: intpin 14 -> PCI IRQ 38 (level, low) ioapic1: intpin 15 -> PCI IRQ 39 (level, low) ioapic1: intpin 16 -> PCI IRQ 40 (level, low) ioapic1: intpin 17 -> PCI IRQ 41 (level, low) ioapic1: intpin 18 -> PCI IRQ 42 (level, low) ioapic1: intpin 19 -> PCI IRQ 43 (level, low) ioapic1: intpin 20 -> PCI IRQ 44 (level, low) ioapic1: intpin 21 -> PCI IRQ 45 (level, low) ioapic1: intpin 22 -> PCI IRQ 46 (level, low) ioapic1: intpin 23 -> PCI IRQ 47 (level, low) lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: active-high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> mem: Pentium Pro MTRR support enabled null: random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000ec2c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25788086) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fc570 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 31 B 0x61 3 4 5 6 7 10 11 embedded 0 29 A 0x60 3 4 5 6 7 10 11 embedded 0 29 B 0x63 3 4 5 6 7 10 11 embedded 0 29 D 0x6b 3 4 5 6 7 10 11 embedded 1 1 A 0x62 3 4 5 6 7 10 11 embedded 3 2 A 0x69 3 4 5 6 7 10 11 slot 1 3 3 A 0x6a 3 4 5 6 7 10 11 slot 1 3 3 B 0x69 3 4 5 6 7 10 11 slot 1 3 3 C 0x6a 3 4 5 6 7 10 11 slot 1 3 3 D 0x69 3 4 5 6 7 10 11 slot 2 2 1 A 0x6a 3 4 5 6 7 10 11 slot 2 2 1 B 0x6a 3 4 5 6 7 10 11 slot 2 2 1 C 0x6a 3 4 5 6 7 10 11 slot 2 2 1 D 0x6a 3 4 5 6 7 10 11 slot 3 2 2 A 0x6a 3 4 5 6 7 10 11 slot 3 2 2 B 0x6a 3 4 5 6 7 10 11 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base fe800000, size 22, enabled found-> vendor=0x8086, dev=0x2578, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x257b, revid=0x02 bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25ae, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0030, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000cce0, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x25a9, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 map[20]: type 4, range 32, base 0000ccc0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x25aa, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=19 found-> vendor=0x8086, dev=0x25ab, revid=0x02 bus=0, slot=29, func=4 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25ac, revid=0x02 bus=0, slot=29, func=5 class=08-00-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base fe300000, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x25ad, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=23 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x244e, revid=0x0a bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25a1, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x014f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fea0, size 4, enabled found-> vendor=0x8086, dev=0x25a3, revid=0x02 bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02a8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 000008c0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x25a4, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 pcib1: at device 3.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfe100000-0xfe2fffff pcib1: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fe1e0000, size 17, enabled pcib1: device (null) requested decoded memory range 0xfe1e0000-0xfe1fffff map[18]: type 4, range 32, base 0000ece0, size 5, enabled pcib1: device (null) requested decoded I/O range 0xece0-0xecff pcib1: matched entry for 1.1.INTA pcib1: slot 1 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1075, revid=0x00 bus=1, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0238, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 em0: port 0xece0-0xecff mem 0xfe1e0000-0xfe1fffff irq 18 at device 1.0 on pci1 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe1e0000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xece0 em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:11:43:ce:9e:6c em0: Speed:N/A Duplex:N/A pcib2: at device 28.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: pci2: on pcib2 pci2: physical bus=2 uhci0: port 0xcce0-0xccff irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xccc0-0xccdf irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xccc0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) ehci0: mem 0xfe300000-0xfe3003ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe300000 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xd000-0xdfff pcib3: memory decode 0xfc000000-0xfdffffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. ACPI PCI link initial configuration: pci3: on pcib3 pci3: physical bus=3 map[10]: type 1, range 32, base fdee0000, size 17, enabled pcib3: device (null) requested decoded memory range 0xfdee0000-0xfdefffff map[18]: type 4, range 32, base 0000dcc0, size 6, enabled pcib3: device (null) requested decoded I/O range 0xdcc0-0xdcff pcib3: matched entry for 3.2.INTA pcib3: slot 2 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1076, revid=0x00 bus=3, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=21 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fc000000, size 24, enabled pcib3: device (null) requested decoded memory range 0xfc000000-0xfcffffff map[14]: type 4, range 32, base 0000d800, size 8, enabled pcib3: device (null) requested decoded I/O range 0xd800-0xd8ff map[18]: type 1, range 32, base fdedf000, size 12, enabled pcib3: device (null) requested decoded memory range 0xfdedf000-0xfdedffff found-> vendor=0x1002, dev=0x4752, revid=0x27 bus=3, slot=14, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x00a7, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 em1: port 0xdcc0-0xdcff mem 0xfdee0000-0xfdefffff irq 21 at device 2.0 on pci3 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdee0000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 em1: [MPSAFE] em1: bpf attached em1: Ethernet address: 00:11:43:ce:9e:6d em1: Speed:N/A Duplex:N/A pci3: at device 14.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfea0-0xfeaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfea0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=01 ata0-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata0-slave: stat=0x01 err=0x04 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=01 devices=0x4 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata1-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] ichsmb0: port 0x8c0-0x8df irq 17 at device 31.3 on pci0 ichsmb0: can't map I/O device_attach: ichsmb0 attach returned 6 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x4001 0x4011 0x4001 0x4001 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xec000-0xeffff,0xc9000-0xc9fff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4001 0x4001 0x4001 0x4001 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 06 40 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 134358 -> 100000 procfs registered Timecounter "TSC" frequency 3400136841 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin acd0: CDROM drive at ata0 as master acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata1-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ad2: ATA-7 disk at ata1-master ad2: 238418MB (488281250 sectors), 484406 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, SATA150 ar: FreeBSD check1 failed ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 GEOM: new disk ad2 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:488279547 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 249999128064 end 249999160319 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad2s1a, start 0 length 1073741824 end 1073741823 GEOM: Configure ad2s1b, start 1073741824 length 4294967296 end 5368709119 GEOM: Configure ad2s1c, start 0 length 249999128064 end 249999128063 GEOM: Configure ad2s1d, start 5368709120 length 1073741824 end 6442450943 GEOM: Configure ad2s1e, start 6442450944 length 1073741824 end 7516192767 GEOM: Configure ad2s1f, start 7516192768 length 242482935296 end 249999128063 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad2s1a start_init: trying /sbin/init Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad2s1b as swap device Starting file system checks: /dev/ad2s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad2s1a: clean, 478280 free (656 frags, 59703 blocks, 0.1% fragmentation) /dev/ad2s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad2s1d: clean, 506475 free L(43 frags, 63304i blocks, 0.0% frnagmentation) /duev/ad2s1f: FILE xSYSTEM CLEAN; SK IPPING CHECKS /Edev/ad2s1f: cleaLn, 112571103 freFe (32135 frags, 14067371 blocks,e 0.0% fragmentatxion) /dev/ad2s1ee: FILE SYSTEM CcLEAN; SKIPPING C HECKS /dev/ad2sh1e: clean, 48215a2 free (248 fragns, 60238 blocks,d 0.0% fragmentatlion) er installed linprocfs registered Setting hostname: alexis.open2view.com. em0: flags=8843 mtu 1500 options=b inet 203.97.20.198 netmask 0xfffffff8 broadcast 203.97.20.199 inet6 fe80::211:43ff:fece:9e6c%em0 prefixlen 64 tentative scopeid 0x1 inet 10.58.4.8 netmask 0xffffff00 broadcast 10.58.4.255 ether 00:11:43:ce:9e:6c media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 add net default: gateway 203.97.20.193 add net 10.58.0.0: gateway 10.58.4.1 Additional routing options:. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting usbd. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support: linuxem0: Link is up 100 Mbps Full Duplex . Starting cron. Local package initialization: tomcat50Starting mysql. . Additional TCP options:. Starting background file system checks in 60 seconds. Mon Apr 11 12:54:18 NZST 2005 FreeBSD/i386 (alexis.open2view.com) (ttyd0) login: --Apple-Mail-15--329589554-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 02:12:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C75D816A4CE for ; Tue, 12 Apr 2005 02:12:33 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A5B343D46 for ; Tue, 12 Apr 2005 02:12:33 +0000 (GMT) (envelope-from aaronsummers@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so1033578nzf for ; Mon, 11 Apr 2005 19:12:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=EDgO5eFI76vijh0tvRrdDVKjJ2mQwNmSlCcjgCD+l8jz98nceV/zVds51HUguMI9EdGEn00QKLej31+hMAHCJncMTk+dI6TGwDmEVqgf1eAsv6QwSPnYQifzIgWRFdlSoJP9Xl6qKBYsBhsFkwVdqCc9BIODjKiJB6YL8oZ+H68= Received: by 10.36.77.15 with SMTP id z15mr224590nza; Mon, 11 Apr 2005 19:12:32 -0700 (PDT) Received: by 10.36.4.16 with HTTP; Mon, 11 Apr 2005 19:12:32 -0700 (PDT) Message-ID: <6cd6260405041119126b78c33@mail.gmail.com> Date: Mon, 11 Apr 2005 22:12:32 -0400 From: Aaron Summers To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Summers List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 02:12:33 -0000 Greetings, We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD, SCSI controller, etc. To no avail. We are running SMP GENERIC Kernel. I cannot get the system to panic, leave a core dump, etc. It just always freezes. The server functions as a web server in a HSphere Cluster. I am about out of options besides loading 4.11 (since our 4 series servers never die). Any help, feedback, clues, similar experiences, etc would be greatly appreciated. On SCSI: The onboard Adaptec 7902 gives a dump on bootup but appears to work. I read the archived post about this issue. The system still locked up with an Adaptec 7982B that did not give this message. DMESG: Copyright (c) 1992-2005 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.4-STABLE #2: Sat Apr 9 09:16:44 EST 2005 root@unix17:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073217536 (1023 MB) avail memory = 1040605184 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci1 pci2: on pcib2 pci1: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci1 pci3: on pcib3 em0: port 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 28 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:2d:0a:2c em0: Speed:N/A Duplex:N/A em1: port 0x3040-0x307f mem 0xfc220000-0xfc23ffff irq 29 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:2d:0a:2d em1: Speed:N/A Duplex:N/A pcib4: at device 3.0 on pci0 pci4: on pcib4 pci4: at device 28.0 (no driver attached) pcib5: at device 29.0 on pci4 pci5: on pcib5 pci4: at device 30.0 (no driver attached) pcib6: at device 31.0 on pci4 pci6: on pcib6 ahd0: port 0x4000-0x40ff,0x4400-0x44ff mem 0xfc400000-0xfc401fff irq 76 at device 2.0 on pci6 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs ahd1: port 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc402000-0xfc403fff irq 77 at device 2.1 on pci6 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs uhci0: port 0x2000-0x201f 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 0x2020-0x203f 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 0x2040-0x205f 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 pcib7: at device 30.0 on pci0 pci7: on pcib7 pci7: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x2060-0x206f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xe0000-0xe3fff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec acd0: CDROM at ata0-master PIO4 Waiting 15 seconds for SCSI devices to settle ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x23b Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x2] SELID[0x40] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x4] KERNEL_QFREEZE_COUNT[0x4] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0xb NEXTSCB 0xff40 qinstart = 46 qinfifonext = 47 QINFIFO: 0x9 WAITING_TID_QUEUES: Pending list: 9 FIFO_USE[0x0] SCB_CONTROL[0x48]:(STATUS_RCVD|DISCENB) SCB_SCSIID[0x27] Total 1 Kernel Free SCB list: 11 13 15 1 2 3 4 5 6 7 8 10 12 14 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xd SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0x9 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xd 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0xac95, SINDEX = 0x10e, DINDEX = 0x106 ahd0: SCBPTR == 0xd, SCB_NEXT == 0xff40, SCB_NEXT2 == 0xff8d CDB 12 20 0 80 88 53 STACK: 0x236 0x2 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! da2 at ahd0 bus 0 target 4 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) Mounting root from ufs:/dev/da0s1a -- Aaron Summers aaronsummers@gmail.com http://insight.ath.cx From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 02:18:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90CB316A4CE for ; Tue, 12 Apr 2005 02:18:20 +0000 (GMT) Received: from knuth.hurstdog.org (knuth.hurstdog.org [69.55.236.147]) by mx1.FreeBSD.org (Postfix) with SMTP id 1BFE443D4C for ; Tue, 12 Apr 2005 02:18:20 +0000 (GMT) (envelope-from tim.howe@celebrityresorts.com) Received: (qmail 42013 invoked from network); 12 Apr 2005 02:14:17 -0000 Received: from knuth.hurstdog.org (HELO fred.colohowes.org) (69.55.236.147) by knuth.hurstdog.org with SMTP; 12 Apr 2005 02:14:17 -0000 Received: from piro.quadium.net (piro.colohowes.org [10.27.56.90]) by fred.colohowes.org (Postfix) with ESMTP id 7B4A98FE41 for ; Mon, 11 Apr 2005 20:15:47 -0600 (MDT) Received: from beaker.data-secure.net (localhost [127.0.0.1]) by piro.quadium.net (8.12.6/8.12.6) with ESMTP id j3C255TR051867 for ; Mon, 11 Apr 2005 22:05:07 -0400 (EDT) (envelope-from tim.howe@celebrityresorts.com) Received: by beaker.data-secure.net (Postfix, from userid 1000) id 5DDB739886; Mon, 11 Apr 2005 22:14:14 -0400 (EDT) To: freebsd-stable@freebsd.org References: <87oecl57nk.fsf@beaker.data-secure.net> <20050411230107.GA11717@odin.ac.hmc.edu> In-Reply-To: <20050411230107.GA11717@odin.ac.hmc.edu> From: Tim Howe Date: Mon, 11 Apr 2005 22:14:14 -0400 Message-ID: <87y8boeo7d.fsf@beaker.data-secure.net> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Kodak USB flash reader causes freezes, panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 02:18:20 -0000 Brooks Davis writes: > On Mon, Apr 11, 2005 at 05:24:15PM -0400, Tim Howe wrote: > > > Reproducibly, if I begin copying data to a [...] CF card [...] it > > works for a while, then freezes the system. > > It is quite likely that 5.4 fixed your problem. Unfortunately not. I was able, having mounted the filesystem with no synchronization options, to copy 171MiB of data onto it and unmount. However when I re-mounted it with the same options and tried to copy 71MiB more, it again froze midway through. Everything else (X11, sound, printing, input) seems to be working perfectly with 5.4, but I did notice something new and strange with regard to umass. I still have to run "true > /dev/da0" to get the slice to show up, but now I get the following: [1042] ~ # true > /dev/da0 [1043] ~ # camcontrol rescan 0 Re-scan of bus 0 was successful [1044] ~ # ls -l /dev/da0* crw-r----- 1 root operator 4, 21 Apr 11 21:45 /dev/da0 crw-r----- 1 root operator 4, 28 Apr 11 21:45 /dev/da0s1 crw-r----- 1 root operator 4, 29 Apr 11 21:45 /dev/da0s1s1 [1045] ~ # mount_msdosfs /dev/da0s1 /mnt/cf [1046] ~ # umount /mnt/cf [1047] ~ # mount_msdosfs /dev/da0s1s1 /mnt/cf [1048] ~ # umount /mnt/cf Thoughts? FreeBSD beaker.data-secure.net 5.4-RC2 FreeBSD 5.4-RC2 #2: Mon Apr 11 20:31:53 EDT 2005 root@beaker.data-secure.net:/usr/obj/usr/src/sys/GENERIC i386 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 02:37:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2864216A4CE for ; Tue, 12 Apr 2005 02:37:35 +0000 (GMT) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AA0F43D1F for ; Tue, 12 Apr 2005 02:37:34 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) j3C2uiWa080211; Mon, 11 Apr 2005 22:56:44 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [64.45.134.154] (dogpound.dyndns.org [64.45.134.154]) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id j3C2bVeE062608; Mon, 11 Apr 2005 22:37:32 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <425B3476.6050208@dmv.com> Date: Mon, 11 Apr 2005 22:37:42 -0400 From: Sven Willenberger User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Summers References: <6cd6260405041119126b78c33@mail.gmail.com> In-Reply-To: <6cd6260405041119126b78c33@mail.gmail.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 cc: stable@freebsd.org Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 02:37:35 -0000 Aaron Summers presumably uttered the following on 04/11/05 22:12: > Greetings, > > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server > running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD, > SCSI controller, etc. To no avail. We are running SMP GENERIC > Kernel. I cannot get the system to panic, leave a core dump, etc. It > just always freezes. The server functions as a web server in a > HSphere Cluster. I am about out of options besides loading 4.11 > (since our 4 series servers never die). Any help, feedback, clues, > similar experiences, etc would be greatly appreciated. > > On SCSI: The onboard Adaptec 7902 gives a dump on bootup but appears > to work. I read the archived post about this issue. The system still > locked up with an Adaptec 7982B that did not give this message. > > DMESG: > > da2 at ahd0 bus 0 target 4 lun 0 > da2: Fixed Direct Access SCSI-3 device > da2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da2: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > da0 at ahd0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > da1 at ahd0 bus 0 target 2 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > Mounting root from ufs:/dev/da0s1a > We had many issues with Seagate drives and and S/M boards with the onboard Adaptec scsi controllers. Seagate offered no help other than to suggest putting in a network card (in lieu of the onboard) and/or disabling SMP; neither solution was acceptable so we switched to IBM/Hitachi drives and the problems disappeared. By the way, the problems manifested themselves in those servers where we had more than just one hard drive installed. This was even after updating to the latest firmware etc; Seagate insists no problem with their drives although other drives work perfectly well. YMMV I do see you say you tried other harddrives .. which ones did you use? Sven From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 02:39:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5C3E16A4CE for ; Tue, 12 Apr 2005 02:39:06 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C23F43D1F for ; Tue, 12 Apr 2005 02:39:06 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3C2d7xo066022; Mon, 11 Apr 2005 22:39:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 65946-01; Mon, 11 Apr 2005 22:39:06 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3C2d672066002; Mon, 11 Apr 2005 22:39:06 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.12.11) with ESMTP id j3C2cwgO019493; Mon, 11 Apr 2005 22:38:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050411223651.04f62e18@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Apr 2005 22:38:16 -0400 To: Philip Murray , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b Subject: Re: Intel 6300ESB (ICH) SMBus controller not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 02:39:06 -0000 At 09:24 PM 11/04/2005, Philip Murray wrote: >Hi, > >I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver doesn't >want to work with it, I get the following on boot: > >ichsmb0: port 0x8c0-0x8df irq 17 at >device 31.3 on pci0 >device_attach: ichsmb0 attach returned 6 Does it work if you add debug.acpi.disabled="sysresource" to /boot/loader.conf ---Mike From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 03:59:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBC7D16A4CE for ; Tue, 12 Apr 2005 03:59:57 +0000 (GMT) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95AB943D5F for ; Tue, 12 Apr 2005 03:59:57 +0000 (GMT) (envelope-from dsze@alumni.uwaterloo.ca) Received: from eeyore.distrust.net (CPE00a0c978120d-CM00122570472e.cpe.net.cable.rogers.com [70.24.0.197]) (authenticated bits=0) by mail.distrust.net (8.13.1/8.12.11) with ESMTP id j3C3xqfC044905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Apr 2005 22:59:56 -0500 (CDT) (envelope-from dsze@alumni.uwaterloo.ca) Message-Id: <6.2.1.2.2.20050411234713.069afb28@mail.distrust.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Apr 2005 00:00:04 -0400 To: Scott Long From: David Sze In-Reply-To: <425A0BB2.10704@samsco.org> References: <4257F20C.70004@samsco.org> <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> <425A0BB2.10704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/820/Mon Apr 11 14:46:51 2005 on mail.distrust.net X-Virus-Status: Clean cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 03:59:58 -0000 At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All: >Making a driver PAE-ified means either teaching it to do 64-bit >scatter-gather (assuming that the peripheral hardware can do this >and that it's documented), or teaching the driver to correctly handle >EINPROGRESS from bus_dmamap_load() along with using the proper busdma >tag limits. The strategy I took with 6.x/5.x was the second one since >I didn't have good IPS docs in front of me and I wanted it follow the >APIs correctly. I did test it with 8GB of memory and it performed >correctly under load. I haven't taken a close enough look at your >MFC patch to say for sure if it's correct or not. I'm not sure if >I'll have time to take another look in the next few days, unfortunately. >Is there any chance you could test 5.x/6.0 under load with PAE just to >validate the assertion that it works correctly there? I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE, and SMP-PAE kernels (the last one is just PAE with "options SMP"). To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz (non-E64MT), ServeRAID-7K. GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE paniced reproducibly doing the same. The DDB stack trace doesn't appear to be anywhere near the IPS driver though, so I'm way out of my league. ========== PAE panic kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03d48eb stack pointer = 0x10:0xeb133b28 frame pointer = 0x10:0xeb133b3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 146 (syncer) [thread pid 146 tid 100157 ] Stopped at propagate_priority+0x7f: movl 0x24(%eax),%eax db> trace Tracing pid 146 tid 100157 td 0xc68cba80 propagate_priority turnstile_wait _mtx_lock_sleep vfs_clean_pages bdwrite ffs_blkfree handle_workitem_freefrag process_worklist_item softdep_process_worklist sched_sync fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xeb133d7c, ebp = 0 --- ========== End PAE panic ========== SMP-PAE panic kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03d7cd3 stack pointer = 0x10:0xeb0d0b7c frame pointer = 0x10:0xeb0d0b90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 149 (syncer) [thread pid 149 tid 100160 ] Stopped at propagate_priority+0x7f: movl 0x24(%eax),%eax db> trace Tracing pid 149 tid 100160 td 0xc68b2000 propagate_priority turnstile_wait _mtx_lock_sleep vfs_busy_pages ibwrite bwrite vfs_bio_awrite vop_stdfsync spec_fsync spec_vnoperate sched_sync fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xeb0d0d7c, ebp = 0 --- ========== End PAE panic From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 04:49:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A677A16A4CE for ; Tue, 12 Apr 2005 04:49:29 +0000 (GMT) Received: from ns-0.net (ns-0.net [64.76.16.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 920E643D3F for ; Tue, 12 Apr 2005 04:49:28 +0000 (GMT) (envelope-from carlos@infodrive.com.ar) Received: from CUCO (200-127-11-74.cab.prima.net.ar [200.127.11.74]) by ns-0.net (Postfix) with ESMTP id 3474727AD87; Tue, 12 Apr 2005 01:49:26 -0300 (ART) Message-ID: <09a201c53f1a$fff4a590$6400a8c0@CUCO> From: "Carlos Horowicz" To: "Aaron Summers" References: <6cd6260405041119126b78c33@mail.gmail.com> Date: Tue, 12 Apr 2005 01:49:23 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: stable@freebsd.org Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 04:49:29 -0000 Hi, I had exactly the same issue with a X5DPR-iG2+ Supermicro motherboard, but solved it after just disabling Power Mgmt and Hyperthreading in the BIOS. In my case, it had nothing to do with the FreeBSD version or kernel , the machine was freezing couple of times a week during months with different 4.x and 5.x stable versions. -Carlos ----- Original Message ----- From: "Aaron Summers" To: Sent: Monday, April 11, 2005 11:12 PM Subject: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze > Greetings, > > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server > running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD, > SCSI controller, etc. To no avail. We are running SMP GENERIC > Kernel. I cannot get the system to panic, leave a core dump, etc. It > just always freezes. The server functions as a web server in a > HSphere Cluster. I am about out of options besides loading 4.11 > (since our 4 series servers never die). Any help, feedback, clues, > similar experiences, etc would be greatly appreciated. > > On SCSI: The onboard Adaptec 7902 gives a dump on bootup but appears > to work. I read the archived post about this issue. The system still > locked up with an Adaptec 7982B that did not give this message. > > DMESG: > > Copyright (c) 1992-2005 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.4-STABLE #2: Sat Apr 9 09:16:44 EST 2005 > root@unix17:/usr/obj/usr/src/sys/SMP > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory = 1073217536 (1023 MB) > avail memory = 1040605184 (992 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > ioapic3 irqs 72-95 on motherboard > ioapic4 irqs 96-119 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pci1: at device 28.0 (no > driver attached) > pcib2: at device 29.0 on pci1 > pci2: on pcib2 > pci1: at device 30.0 (no > driver attached) > pcib3: at device 31.0 on pci1 > pci3: on pcib3 > em0: port > 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 28 at device 2.0 on pci3 > em0: Ethernet address: 00:30:48:2d:0a:2c > em0: Speed:N/A Duplex:N/A > em1: port > 0x3040-0x307f mem 0xfc220000-0xfc23ffff irq 29 at device 2.1 on pci3 > em1: Ethernet address: 00:30:48:2d:0a:2d > em1: Speed:N/A Duplex:N/A > pcib4: at device 3.0 on pci0 > pci4: on pcib4 > pci4: at device 28.0 (no > driver attached) > pcib5: at device 29.0 on pci4 > pci5: on pcib5 > pci4: at device 30.0 (no > driver attached) > pcib6: at device 31.0 on pci4 > pci6: on pcib6 > ahd0: port > 0x4000-0x40ff,0x4400-0x44ff mem 0xfc400000-0xfc401fff irq 76 at device > 2.0 on pci6 > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs > ahd1: port > 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc402000-0xfc403fff irq 77 at device > 2.1 on pci6 > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs > uhci0: port > 0x2000-0x201f 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 > 0x2020-0x203f 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 > 0x2040-0x205f 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 > pcib7: at device 30.0 on pci0 > pci7: on pcib7 > pci7: at device 1.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x2060-0x206f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on > pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on > acpi0 > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > orm0: at iomem > 0xe0000-0xe3fff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 > pmtimer0 on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 10.000 msec > acd0: CDROM at ata0-master PIO4 > Waiting 15 seconds for SCSI devices to settle > ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< > ahd0: Dumping Card State at program address 0x23b Mode 0x0 > Card was paused > INTSTAT[0x0] SELOID[0x2] SELID[0x40] HS_MAILBOX[0x0] > INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] > DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) > SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] > LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] > SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] > SEQINTCTL[0x6]:(INTMASK1|INTMASK2) > SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x4] > KERNEL_QFREEZE_COUNT[0x4] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] > SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] > SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] > LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] > LQOSTAT2[0x0] > > SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0xb NEXTSCB 0xff40 > qinstart = 46 qinfifonext = 47 > QINFIFO: 0x9 > WAITING_TID_QUEUES: > Pending list: > 9 FIFO_USE[0x0] SCB_CONTROL[0x48]:(STATUS_RCVD|DISCENB) SCB_SCSIID[0x27] > Total 1 > Kernel Free SCB list: 11 13 15 1 2 3 4 5 6 7 8 10 12 14 0 > Sequencer Complete DMA-inprog list: > Sequencer Complete list: > Sequencer DMA-Up and Complete list: > Sequencer On QFreeze and Complete list: > > > ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xd > SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) > SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) > SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] > SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 > HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) > > ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0x9 > SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) > SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) > SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] > SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 > HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) > LQIN: 0x8 0x0 0x0 0xd 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 > ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 > ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 > ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 > > SIMODE0[0xc]:(ENOVERRUN|ENIOERR) > CCSCBCTL[0x4]:(CCSCBDIR) > ahd0: REG0 == 0xac95, SINDEX = 0x10e, DINDEX = 0x106 > ahd0: SCBPTR == 0xd, SCB_NEXT == 0xff40, SCB_NEXT2 == 0xff8d > CDB 12 20 0 80 88 53 > STACK: 0x236 0x2 0x0 0x0 0x0 0x0 0x0 0x0 > <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> > ses0 at ahd0 bus 0 target 6 lun 0 > ses0: Fixed Processor SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > da2 at ahd0 bus 0 target 4 lun 0 > da2: Fixed Direct Access SCSI-3 device > da2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da2: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > da0 at ahd0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > da1 at ahd0 bus 0 target 2 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > Mounting root from ufs:/dev/da0s1a > > -- > Aaron Summers > aaronsummers@gmail.com > http://insight.ath.cx > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 05:03:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3593D16A4CE for ; Tue, 12 Apr 2005 05:03:34 +0000 (GMT) Received: from mta202-rme.xtra.co.nz (mta202-rme.xtra.co.nz [210.86.15.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F5543D4C for ; Tue, 12 Apr 2005 05:03:33 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from mta3-rme.xtra.co.nz ([210.86.15.240]) by mta202-rme.xtra.co.nz with ESMTP <20050412050313.VZBS28243.mta202-rme.xtra.co.nz@mta3-rme.xtra.co.nz>; Tue, 12 Apr 2005 17:03:13 +1200 Received: from [10.58.3.145] ([222.152.246.166]) by mta3-rme.xtra.co.nz with ESMTP id <20050412050313.BZYZ4411.mta3-rme.xtra.co.nz@[10.58.3.145]>; Tue, 12 Apr 2005 17:03:13 +1200 In-Reply-To: <6.2.1.2.0.20050411223651.04f62e18@64.7.153.2> References: <6.2.1.2.0.20050411223651.04f62e18@64.7.153.2> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Murray Date: Tue, 12 Apr 2005 17:03:12 +1200 To: Mike Tancsa X-Mailer: Apple Mail (2.619.2) cc: freebsd-stable@freebsd.org Subject: Re: Intel 6300ESB (ICH) SMBus controller not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 05:03:34 -0000 On 12/04/2005, at 2:38 PM, Mike Tancsa wrote: > At 09:24 PM 11/04/2005, Philip Murray wrote: >> Hi, >> >> I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver >> doesn't want to work with it, I get the following on boot: >> >> ichsmb0: port 0x8c0-0x8df irq >> 17 at device 31.3 on pci0 >> device_attach: ichsmb0 attach returned 6 > > Does it work if you add > > debug.acpi.disabled="sysresource" > > to /boot/loader.conf > > Thanks for that, It kind of worked. Am I correct in thinking that, that prevents ACPI attaching to the controller so that the ichsmb driver can? In which case, if ACPI does attach to it, does that mean I'd get temperature values in the hw.acpi.thermal tree? sysutils/xmbmon and sysutils/healthd can't seem to read anything from it anyway. Is this because the SMBus has no temperature sensors tied to it? It has them in the BIOS, so I assumed I could read them in FreeBSD. I get ichsmb0: irq 0x04 during -1 in dmesg when trying healthd and root@alexis:~/ > healthd -S ioctl(SMB_WRITEB): Permission denied Cheers, Phil From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 06:21:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69ACC16A4CE for ; Tue, 12 Apr 2005 06:21:34 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9ED143D2D for ; Tue, 12 Apr 2005 06:21:33 +0000 (GMT) (envelope-from heavenwill@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so2857716wra for ; Mon, 11 Apr 2005 23:21:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=LlRLbQMwz7/QT3Li9K1ChLJQ+AblK+JsD3qEvu+LVfqjyBDFrEUc8q4mSHh/ZQQISYJdCTS8qnzzsHZlxlIQ4L5QvALI5wjLkrWfp9el4S7+EYe8DpJrqzINS38/Y9BYuEpCV5FHGUE+xcW4x78HaNPvcrkkqxSGowXvZrjckIU= Received: by 10.54.53.77 with SMTP id b77mr64375wra; Mon, 11 Apr 2005 23:21:33 -0700 (PDT) Received: by 10.54.81.3 with HTTP; Mon, 11 Apr 2005 23:21:33 -0700 (PDT) Message-ID: <1cd91a1e050411232178175d5b@mail.gmail.com> Date: Tue, 12 Apr 2005 14:21:33 +0800 From: "N ;-)" To: freebsd-stable@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6918_6105814.1113286893052" Subject: [RELENG_5] Unresponsive system using ULE+HTT with 2 Xeon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "N ;-\)" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 06:21:34 -0000 ------=_Part_6918_6105814.1113286893052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hi all: I just installed FreeBSD 5.3R on Dell PE 2850,and cvsuped the src,build my own SMP kernel(HTT on), then builded the kernel(SCHED_ULE),got this 5.4-STABLE FreeBSD 5.4-STABLE #0 system. After i installed mysql-client-4.0.24_1,and i run /usr/local/bin/mysql_install_db to initialize mysql, it unresponsive! Ctrl+C not worked, #uname -a FreeBSD ibsd.xxx.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Apr 12 10:34:52 CST 2005 root@ibsd.xxx.com:/usr/obj/usr/src/sys/DSMP i386 My kernel configfile and /var/run/dmesg.boot were attached. But when i turned off the HTT, /usr/local/bin/mysql_install_db runed successfully. After i had configed the mysql,and turn HTT on again, mysql worked right. ------=_Part_6918_6105814.1113286893052 Content-Type: text/plain; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuNC1TVEFCTEUgIzA6IFR1ZSBBcHIgMTIgMTA6MzQ6NTIg Q1NUIDIwMDUKICAgIHJvb3RAaWJzZC54eHguY29tOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0RTTVAK QUNQSSBBUElDIFRhYmxlOiA8REVMTCAgIFBFIEJLQyAgPgpUaW1lY291bnRlciAiaTgyNTQiIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEludGVsKFIpIFhlb24oVE0pIENQVSAy LjgwR0h6ICgyNzkzLjIwLU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50 ZWwiICBJZCA9IDB4ZjQxICBTdGVwcGluZyA9IDEKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxW TUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1Ys UEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBC RT4KICBIeXBlcnRocmVhZGluZzogMiBsb2dpY2FsIENQVXMKcmVhbCBtZW1vcnkgID0gMzIyMDk2 MzMyOCAoMzA3MSBNQikKYXZhaWwgbWVtb3J5ID0gMzE1NDgyOTMxMiAoMzAwOCBNQikKRnJlZUJT RC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCiBjcHUwIChCU1Ap OiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElE OiAgNgogY3B1MyAoQVApOiBBUElDIElEOiAgNwppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRv IDgKaW9hcGljMTogQ2hhbmdpbmcgQVBJQyBJRCB0byA5CmlvYXBpYzE6IFdBUk5JTkc6IGludGJh c2UgMzIgIT0gZXhwZWN0ZWQgYmFzZSAyNAppb2FwaWMyOiBDaGFuZ2luZyBBUElDIElEIHRvIDEw CmlvYXBpYzI6IFdBUk5JTkc6IGludGJhc2UgNjQgIT0gZXhwZWN0ZWQgYmFzZSA1Ngppb2FwaWMz OiBDaGFuZ2luZyBBUElDIElEIHRvIDExCmlvYXBpYzM6IFdBUk5JTkc6IGludGJhc2UgOTYgIT0g ZXhwZWN0ZWQgYmFzZSA4OAppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkCmlvYXBpYzEgPFZlcnNpb24gMi4wPiBpcnFzIDMyLTU1IG9uIG1vdGhlcmJvYXJkCmlv YXBpYzIgPFZlcnNpb24gMi4wPiBpcnFzIDY0LTg3IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzMgPFZl cnNpb24gMi4wPiBpcnFzIDk2LTExOSBvbiBtb3RoZXJib2FyZApucHgwOiA8bWF0aCBwcm9jZXNz b3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxERUxMIFBF IEJLQz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3Vu dGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3Rp bWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBh Y3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMi4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKcGNpMjogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjIKbXB0MDogPExTSUxvZ2ljIDEwMzAgVWx0cmE0IEFkYXB0ZXI+IHBvcnQg MHhlYzAwLTB4ZWNmZiBtZW0gMHhkZmVlMDAwMC0weGRmZWVmZmZmLDB4ZGZlZjAwMDAtMHhkZmVm ZmZmZiBpcnEgMzQgYXQgZGV2aWNlIDUuMCBvbiBwY2kyCm1wdDE6IDxMU0lMb2dpYyAxMDMwIFVs dHJhNCBBZGFwdGVyPiBwb3J0IDB4ZTgwMC0weGU4ZmYgbWVtIDB4ZGZlYzAwMDAtMHhkZmVjZmZm ZiwweGRmZWQwMDAwLTB4ZGZlZGZmZmYgaXJxIDMzIGF0IGRldmljZSA1LjEgb24gcGNpMgpwY2li MzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIgb24gcGNpMQpwY2kzOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSA0LjAgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2liNTogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA1LjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24g cGNpNQpwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgplbTA6IDxJbnRlbChSKSBQUk8vMTAw MCBOZXR3b3JrIENvbm5lY3Rpb24sIFZlcnNpb24gLSAxLjcuMzU+IHBvcnQgMHhkY2MwLTB4ZGNm ZiBtZW0gMHhkZmJlMDAwMC0weGRmYmZmZmZmIGlycSA2NCBhdCBkZXZpY2UgNy4wIG9uIHBjaTYK ZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMTo0MzplMDozMTpkYgplbTA6ICBTcGVlZDpOL0Eg IER1cGxleDpOL0EKcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4yIG9u IHBjaTUKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKZW0xOiA8SW50ZWwoUikgUFJPLzEw MDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0gMS43LjM1PiBwb3J0IDB4Y2NjMC0weGNj ZmYgbWVtIDB4ZGY5ZTAwMDAtMHhkZjlmZmZmZiBpcnEgNjUgYXQgZGV2aWNlIDguMCBvbiBwY2k3 CmVtMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MTE6NDM6ZTA6MzE6ZGMKZW0xOiAgU3BlZWQ6Ti9B ICBEdXBsZXg6Ti9BCnBjaWI4OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBv biBwY2kwCnBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI4CnBjaWI5OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2k4CnBjaTk6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI5CnBjaWIxMDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIgb24gcGNpOApw Y2kxMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEwCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0 IGRldmljZSAyOS4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIxMTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpMTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIxMQpwY2kxMTogPHVua25vd24+IGF0IGRldmljZSA1LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkK cGNpMTE6IDx1bmtub3duPiBhdCBkZXZpY2UgNS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTEx OiA8dW5rbm93bj4gYXQgZGV2aWNlIDUuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQphdGFwY2kwOiA8 U2lJIDA2ODAgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4YmM3MC0weGJjN2YsMHhiY2QwLTB4 YmNkMywweGJjZDgtMHhiY2RmLDB4YmNlNC0weGJjZTcsMHhiY2YwLTB4YmNmNyBpcnEgMjMgYXQg ZGV2aWNlIDYuMCBvbiBwY2kxMQphdGEyOiBjaGFubmVsICMwIG9uIGF0YXBjaTAKYXRhMzogY2hh bm5lbCAjMSBvbiBhdGFwY2kwCnBjaTExOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMTMuMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEu MCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kxOiA8SW50ZWwgSUNINSBV RE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHhmYzAwLTB4ZmMwZiwweDM3NiwweDE3MC0weDE3Nyww eDNmNiwweDFmMC0weDFmNyBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IGNoYW5uZWwgIzAg b24gYXRhcGNpMQphdGExOiBjaGFubmVsICMxIG9uIGF0YXBjaTEKYXRrYmRjMDogPEtleWJvYXJk IGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDY0LDB4NjAgaXJxIDEgb24gYWNwaTAKYXRrYmQw OiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKc2lvMDogY29u ZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBt YXkgbm90IGJlIGVuYWJsZWQKc2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0 IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEK b3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhlYzAwMC0weGVmZmZmLDB4ZDQwMDAt MHhkNGZmZiwweGNjMDAwLTB4Y2ZmZmYsMHhjYjAwMC0weGNiZmZmLDB4YzAwMDAtMHhjYWZmZiBv biBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDog VkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNB IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApz aW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8x OiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAg bXNlYwphY2QwOiBDRFJPTSA8VEVBQyBDRC1ST00gQ0QtMjI0RS9LLjlBPiBhdCBhdGEwLW1hc3Rl ciBQSU80CmF0YTItbWFzdGVyOiBGQUlMVVJFIC0gU0VURkVBVFVSRVMgU0VUIFRSQU5TRkVSIE1P REUgc3RhdHVzPTQxPFJFQURZLEVSUk9SPiBlcnJvcj00PEFCT1JURUQ+CmF0YTItc2xhdmU6IEZB SUxVUkUgLSBTRVRGRUFUVVJFUyBTRVQgVFJBTlNGRVIgTU9ERSBzdGF0dXM9NDE8UkVBRFksRVJS T1I+IGVycm9yPTQ8QUJPUlRFRD4KYWNkMTogQ0RST00gPFZJUlRVQUxDRFJPTSBEUklWRS8+IGF0 IGF0YTItc2xhdmUgQklPU1BJTwpXYWl0aW5nIDIgc2Vjb25kcyBmb3IgU0NTSSBkZXZpY2VzIHRv IHNldHRsZQpzZXMwIGF0IG1wdDAgYnVzIDAgdGFyZ2V0IDYgbHVuIDAKc2VzMDogPFBFL1BWIDF4 NiBTQ1NJIEJQIDEuMD4gRml4ZWQgUHJvY2Vzc29yIFNDU0ktMiBkZXZpY2UgCnNlczA6IDMuMzAw TUIvcyB0cmFuc2ZlcnMKc2VzMDogU0FGLVRFIENvbXBsaWFudCBEZXZpY2UKZGEwIGF0IG1wdDAg YnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8U0VBR0FURSBTVDM3MzIwN0xDIEQ3MDE+IEZpeGVk IERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmljZSAKZGEwOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMg KDE2MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZApk YTA6IDcwMDA3TUIgKDE0MzM3NDY1MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDg5MjRD KQpkYTEgYXQgbXB0MCBidXMgMCB0YXJnZXQgMSBsdW4gMApkYTE6IDxTRUFHQVRFIFNUMzczMjA3 TEMgRDcwMT4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIApkYTE6IDMyMC4wMDBN Qi9zIHRyYW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0IDYzLCAxNmJpdCksIFRhZ2dlZCBRdWV1 ZWluZyBFbmFibGVkCmRhMTogNzAwMDdNQiAoMTQzMzc0NjUwIDUxMiBieXRlIHNlY3RvcnM6IDI1 NUggNjNTL1QgODkyNEMpClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMSBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCnBpZCAzODogY29ycmVjdGVkIHNsb3Qg Y291bnQgKDAtPjEpCk1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMmEK ------=_Part_6918_6105814.1113286893052 Content-Type: application/octet-stream; name="DSMP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DSMP" IyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgRnJlZUJT RC9pMzg2CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSByZWFk IHRoZSBoYW5kYm9vayBzZWN0aW9uIG9uCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6CiMK IyAgICBodHRwOi8vd3d3LkZyZWVCU0Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvaGFu ZGJvb2sva2VybmVsY29uZmlnLWNvbmZpZy5odG1sCiMKIyBUaGUgaGFuZGJvb2sgaXMgYWxzbyBh dmFpbGFibGUgbG9jYWxseSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vawojIGlmIHlvdSd2ZSBp bnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90aGVyd2lzZSBhbHdheXMgc2VlIHRoZQoj IEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8vd3d3LkZyZWVCU0Qub3JnLykg Zm9yIHRoZQojIGxhdGVzdCBpbmZvcm1hdGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBv cHRpb25zIGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2UgbGlu ZXMgaXMgYWxzbyBwcmVzZW50IGluIHRoZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBmaWxl cy4KIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0eSBv ZiBhIGxpbmUsIGNoZWNrIGZpcnN0CiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogc3JjL3N5cy9p Mzg2L2NvbmYvR0VORVJJQyx2IDEuNDEzLjIuMTMgMjAwNS8wNC8wMiAxNjozNzo1OCBzY290dGwg RXhwICQKCm1hY2hpbmUJCWkzODYKY3B1CQlJNjg2X0NQVQppZGVudAkJaUJTRAoKIyBUbyBzdGF0 aWNhbGx5IGNvbXBpbGUgaW4gZGV2aWNlIHdpcmluZyBpbnN0ZWFkIG9mIC9ib290L2RldmljZS5o aW50cwojaGludHMJCSJHRU5FUklDLmhpbnRzIgkJIyBEZWZhdWx0IHBsYWNlcyB0byBsb29rIGZv ciBkZXZpY2VzLgoKI29wdGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXIKb3B0aW9u cwkJU0NIRURfVUxFIApvcHRpb25zIAlJTkVUCQkJIyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJ RkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSMg RW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBw b3J0IGZvciBhY2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXBy b3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25zIAlQUk9DRlMJCQkjIFBy b2Nlc3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9wdGlvbnMgCVBTRVVET0ZTCQkj IFBzZXVkby1maWxlc3lzdGVtIGZyYW1ld29yawpvcHRpb25zIAlHRU9NX0dQVAkJIyBHVUlEIFBh cnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUNPTVBBVF80MwkJIyBDb21wYXRpYmxlIHdpdGggQlNE IDQuMyBbS0VFUCBUSElTIV0Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUg d2l0aCBGcmVlQlNENApvcHRpb25zIAlTQ1NJX0RFTEFZPTIwMDAJCSMgRGVsYXkgKGluIG1zKSBi ZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgCVNZU1ZTSE0JCQkjIFNZU1Ytc3R5bGUgc2hhcmVk IG1lbW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJIyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9w dGlvbnMgCVNZU1ZTRU0JCQkjIFNZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlfS1BPU0lY X1BSSU9SSVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9u cwpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2Rl dgpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJIyBHaWFudCBtdXRleCBpcyBhZGFwdGl2ZS4KCiMg U01QIFN1cHBvcnQKb3B0aW9ucyAJU01QIAkJCSMgU3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtl cm5lbApkZXZpY2UJCWFwaWMJCQkjIEkvTyBBUElDCgojb3B0aW9ucwkJUEFFCQkJIyBQaHlzaWNh bCBBZGRyZXNzIEV4dGVuc2lvbnMgS2VybmVsCgojIEhUVCBTdXBwb3J0CiNvcHRpb25zICAgICAg ICAgTVBUQUJMRV9GT1JDRV9IVFQgICAgICAgIyBFbmFibGUgSFRUIENQVXMgd2l0aCB0aGUgTVAg VGFibGUKI29wdGlvbnMgICAgICAgICBOT19NSVhFRF9NT0RFICAgICAgICAgICAjIERpc2FibGUg dXNlIG9mIG1peGVkIG1vZGUKCm9wdGlvbnMgCVFVT1RBCiNvcHRpb25zCQlERVZJQ0VfUE9MTElO RwpvcHRpb25zCQlUQ1BfRFJPUF9TWU5GSU4Kb3B0aW9ucwkJWkVST19DT1BZX1NPQ0tFVFMKI29w dGlvbnMJCUhaPTEwMDAKb3B0aW9ucwkJUEFOSUNfUkVCT09UX1dBSVRfVElNRT0wCm9wdGlvbnMg CUFVVE9fRU9JXzEKCm1ha2VvcHRpb25zIENPTkZfQ0ZMQUdTPS1mbm8tYnVpbHRpbgptYWtlb3B0 aW9ucwlOT19NT0RVTEVTPXllcwoKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBICm9wdGlvbnMgICAg ICAgICBORVRHUkFQSF9FVEhFUgpvcHRpb25zICAgICAgICAgTkVUR1JBUEhfU09DS0VUCm9wdGlv bnMgICAgICAgICBORVRHUkFQSF9QUFBPRQpvcHRpb25zICAgICAgICAgTkVUR1JBUEhfUFBQCm9w dGlvbnMgICAgICAgICBORVRHUkFQSF9CUEYKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1ZKQwpv cHRpb25zICAgICAgICAgTkVUR1JBUEhfSUZBQ0UKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1BQ VFBHUkUKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0tTT0NLRVQKb3B0aW9ucyAgICAgICAgIE5F VEdSQVBIX01QUENfRU5DUllQVElPTgoKZGV2aWNlICAgICAgICAgIHBmCmRldmljZSAgICAgICAg ICBwZmxvZwpkZXZpY2UgICAgICAgICAgcGZzeW5jCgojIEJ1cyBzdXBwb3J0LiAgRG8gbm90IHJl bW92ZSBpc2EsIGV2ZW4gaWYgeW91IGhhdmUgbm8gaXNhIHNsb3RzCmRldmljZQkJaXNhCmRldmlj ZQkJZWlzYQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCiNkZXZpY2UJCWZkYwoKCiMgQVRB IGFuZCBBVEFQSSBkZXZpY2VzCmRldmljZQkJYXRhCmRldmljZQkJYXRhZGlzawkJIyBBVEEgZGlz ayBkcml2ZXMKZGV2aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcwoKIyBTQ1NJIENv bnRyb2xsZXJzCmRldmljZQkJbXB0CQkjIExTSS1Mb2dpYyBNUFQtRnVzaW9uCgojIFNDU0kgcGVy aXBoZXJhbHMKZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpCmRl dmljZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nl c3MgKGRpc2tzKQpkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NT SSBhY2Nlc3MpCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5k IFNBRi1URSkKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBT LzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZpY2UJ CWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRldmljZQkJ dmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcgoKZGV2aWNlCQlzcGxhc2gJCSMgU3BsYXNoIHNj cmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKCiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBj b25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQpkZXZpY2UJCXNjCgojIEZs b2F0aW5nIHBvaW50IHN1cHBvcnQgLSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgKCiMgU2Vy aWFsIChDT00pIHBvcnRzCmRldmljZQkJc2lvCQkjIDgyNTAsIDE2WzQ1XTUwIGJhc2VkIHNlcmlh bCBwb3J0cwoKIyBQQ0kgRXRoZXJuZXQgTklDcy4KZGV2aWNlCQllbQkJIyBJbnRlbCBQUk8vMTAw MCBhZGFwdGVyIEdpZ2FiaXQgRXRoZXJuZXQgQ2FyZAoKIyBQc2V1ZG8gZGV2aWNlcy4KZGV2aWNl CQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQltZW0JCSMgTWVtb3J5IGFuZCBrZXJu ZWwgbWVtb3J5IGRldmljZXMKZGV2aWNlCQlpbwkJIyBJL08gZGV2aWNlCmRldmljZQkJcmFuZG9t CQkjIEVudHJvcHkgZGV2aWNlCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydApkZXZp Y2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKCiMgVGhlIGBicGYnIGRldmljZSBl bmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3YXJlIG9mIHRoZSBhZG1p bmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEKIyBOb3RlIHRoYXQgJ2Jw ZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBm aWx0ZXIK ------=_Part_6918_6105814.1113286893052-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 07:04:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EEEF16A4CE for ; Tue, 12 Apr 2005 07:04:11 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27D4A43D54 for ; Tue, 12 Apr 2005 07:04:11 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0C8405148C; Tue, 12 Apr 2005 00:04:09 -0700 (PDT) Date: Tue, 12 Apr 2005 00:04:09 -0700 From: Kris Kennaway To: "N ;-)" Message-ID: <20050412070409.GA23775@xor.obsecurity.org> References: <1cd91a1e050411232178175d5b@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <1cd91a1e050411232178175d5b@mail.gmail.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-stable@FreeBSD.org Subject: Re: [RELENG_5] Unresponsive system using ULE+HTT with 2 Xeon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 07:04:11 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 12, 2005 at 02:21:33PM +0800, N ;-) wrote: > hi all: > I just installed FreeBSD 5.3R on Dell PE 2850,and cvsuped the > src,build my own SMP kernel(HTT on), then builded the > kernel(SCHED_ULE),got this 5.4-STABLE FreeBSD 5.4-STABLE #0 system. ULE is known to still have bugs, so don't use it if you want a stable system. Kris --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW3LpWry0BWjoQKURAoerAKCKn5NQ+8USy9ZS4TElBOKuEC1o8wCeMf2s FipG21DfYBC6smQ19ZJQzHk= =EOwN -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 08:28:17 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37BD816A4CE for ; Tue, 12 Apr 2005 08:28:17 +0000 (GMT) Received: from mail.demax.sk (mail.demax.sk [213.215.102.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47ACB43D2D for ; Tue, 12 Apr 2005 08:28:16 +0000 (GMT) (envelope-from sebosik@demax.sk) Received: from mail.demax.sk (localhost [127.0.0.1]) by nod32.demax.sk (Postfix) with ESMTP id 3584742AD4 for ; Tue, 12 Apr 2005 10:28:10 +0200 (CEST) X-Virus-Scanner: This message was checked by NOD32 Antivirus system NOD32 for Linux Mail Server. For more information on NOD32 Antivirus System, please, visit our website: http://www.nod32.com/. Received: from [195.62.17.204] (2D204.demax.sk [195.62.17.204]) by mail.demax.sk (Postfix) with ESMTP id 194D442AC8 for ; Tue, 12 Apr 2005 10:28:09 +0200 (CEST) Message-ID: <425B86B4.9030203@demax.sk> Date: Tue, 12 Apr 2005 10:28:36 +0200 From: Jan Sebosik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 MultiZilla/1.7.0.2b X-Accept-Language: sk, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Package managment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 08:28:17 -0000 Hi I`ve got one simple question: if i`ve built packages on my freebsd 5.3-RELEASE system, do I need to rebuilt them again for 5.4-RELEASE (after downloading && compiling from sources) ? Best regards, Jan Sebosik From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 09:27:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A1816A4CE for ; Tue, 12 Apr 2005 09:27:28 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECB2B43D49 for ; Tue, 12 Apr 2005 09:27:27 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so1748290rne for ; Tue, 12 Apr 2005 02:27:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=tXWu6YHhqz5CaVJtT9DJCTBOCrLPsHVv+Bh3tp+5O1aWt6Wps68RNfhx9j6v+eHvYyxazeg+SyT+9sUwxkyIDoLDPrCBnNmNuhYBd8LO/Twp2MDDIyCfk0f4ZGnxRZ9sV3AXNRCN0BspcPJLzxl+vKFdYiNb724shXyExXipbqU= Received: by 10.38.207.30 with SMTP id e30mr3044666rng; Tue, 12 Apr 2005 02:27:27 -0700 (PDT) Received: by 10.38.149.53 with HTTP; Tue, 12 Apr 2005 02:27:27 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 11:27:27 +0200 From: Claus Guttesen To: freebsd-stable@freebsd.org In-Reply-To: <20050411204906.GA26872@bloom.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050411204906.GA26872@bloom.cse.buffalo.edu> Subject: Re: FreeBSD 5.4-RC2 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Claus Guttesen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 09:27:28 -0000 > We encourage people to help with testing so any final bugs can be identified > and worked out. At this point the only major problem has been reports > of large server (4 processors or more) hanging under extreme load conditions > (varied load of local processes like database and heavy network load). > Details to help with debugging have been hard to obtain so if anyone is > in a position to help with trying to reproduce this it would be appreciated. 5.4 RC1 is running on our webservers, a combo of dual Xeon's, Noconas and Opterons without any problems. It's also running on our firewall with pf and the performance is quite nice, less than 10 % utilization. I have a NFS-server running 5.3 beta 3 which is accessed by the webservers. The volume is lightly accessed. Next week it will host a new volume which will have a lot of activity, so I'd like to upgrade it to 5.4 RC2 before that (saturday). Looking at the only major problems left, I feel pretty comfortable that RC2 will be very stable. The NFS-server is a Compaq dual PIII at 1 GHz (G2), 3 GB RAM, Smart RAID 5 (ciss), qlogic 2310 hba and an Intel GBIC-card (em). The em-driver is mpsafe and the isp-driver is not, but overall the performance should be better with 5.4 compared to 5.3. Has anyone had the opportunity to compare NFS on 5.3 and 5.4? Should I play it safe and wait until May before I upgrade? regards Claus From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 10:05:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4739C16A4CE for ; Tue, 12 Apr 2005 10:05:08 +0000 (GMT) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9D8043D45 for ; Tue, 12 Apr 2005 10:05:05 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) j3CA53U7049850 for ; Tue, 12 Apr 2005 11:05:03 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) j3CA50Hs049904 for ; Tue, 12 Apr 2005 11:05:03 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: freebsd-stable@freebsd.org Date: Tue, 12 Apr 2005 11:05:00 +0100 Message-ID: <49903.1113300300@thrush.ravenbrook.com> Sender: nb@ravenbrook.com Subject: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 10:05:08 -0000 I run FreeBSD as my main desktop, but occasionally have to develop, build, or test software on a variety of other x86 operating systems (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the moment I have a row of mini-towers and a KVM switch. I'd much rather run these other machines as virtual machines under FreeBSD. Can anyone recommend virtualizing software for FreeBSD? I don't mind having to pay, as long as it really works. I see that VMWare, for instance, is not supported on FreeBSD. I'm running 4.9-RELENG at the moment, but considering an upgrade to 5.x. Nick Barnes From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 10:09:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1991716A4CE for ; Tue, 12 Apr 2005 10:09:38 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A648F43D39 for ; Tue, 12 Apr 2005 10:09:37 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so1478297rng for ; Tue, 12 Apr 2005 03:09:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kULwHlF+9nI4x8MoDL8rR3W34K1aV9rQt92AAWGOgi/bOJy74vON/E4nS1hSTrxG6HiassndLbTS/4QyhV/307LU4n3D/7pt2xMtiL74bzfR2V6pXe9BE+2Qia2n5MM2XF7156EtepB0B/STNerNu0zoiYPdPh3RHGPnilUBEyQ= Received: by 10.38.155.3 with SMTP id c3mr807762rne; Tue, 12 Apr 2005 03:09:37 -0700 (PDT) Received: by 10.38.149.56 with HTTP; Tue, 12 Apr 2005 03:09:37 -0700 (PDT) Message-ID: <79722fad0504120309579a94b3@mail.gmail.com> Date: Tue, 12 Apr 2005 10:09:37 +0000 From: Vlad GALU To: freebsd-stable@freebsd.org In-Reply-To: <49903.1113300300@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <49903.1113300300@thrush.ravenbrook.com> Subject: Re: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad GALU List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 10:09:38 -0000 On Apr 12, 2005 10:05 AM, Nick Barnes wrote: > I run FreeBSD as my main desktop, but occasionally have to develop, > build, or test software on a variety of other x86 operating systems > (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the > moment I have a row of mini-towers and a KVM switch. I'd much rather > run these other machines as virtual machines under FreeBSD. Can > anyone recommend virtualizing software for FreeBSD? I don't mind > having to pay, as long as it really works. > > I see that VMWare, for instance, is not supported on FreeBSD. > > I'm running 4.9-RELENG at the moment, but considering an upgrade to > 5.x. Actually, VMware 3.2.1 works quite OK on 4.x. I run it on 5.4-STABLE as well, but with SMP, acpi and apic all turned off. It's annoying, but it does the job. > > Nick Barnes > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 11:26:36 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C79F16A4CE for ; Tue, 12 Apr 2005 11:26:36 +0000 (GMT) Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209E543D48 for ; Tue, 12 Apr 2005 11:26:35 +0000 (GMT) (envelope-from rasputnik@hellooperator.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP <20050412112633.KHIG2577.mta13-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Tue, 12 Apr 2005 12:26:33 +0100 Received: from 9.hellooperator.net ([81.103.32.202]) by aamta04-winn.mailhost.ntl.com with ESMTP <20050412112633.RNXU1352.aamta04-winn.mailhost.ntl.com@9.hellooperator.net>; Tue, 12 Apr 2005 12:26:33 +0100 Received: from [10.4.0.5] (helo=eris.tenfour) by 9.hellooperator.net with esmtp (Exim 4.44) id 1DLJXJ-0005x7-5J; Tue, 12 Apr 2005 12:26:31 +0100 Received: from rasputnik by eris.tenfour with local (Exim 4.50 (FreeBSD)) id 1DLJXI-000G3q-Tr; Tue, 12 Apr 2005 12:26:28 +0100 Date: Tue, 12 Apr 2005 12:26:28 +0100 From: Dick Davies To: Nick Barnes Message-ID: <20050412112628.GG42167@eris.tenfour> References: <49903.1113300300@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49903.1113300300@thrush.ravenbrook.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Stable Users Subject: Re: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dick Davies List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 11:26:36 -0000 * Nick Barnes [0405 11:05]: > I run FreeBSD as my main desktop, but occasionally have to develop, > build, or test software on a variety of other x86 operating systems > (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the > moment I have a row of mini-towers and a KVM switch. I'd much rather > run these other machines as virtual machines under FreeBSD. Can > anyone recommend virtualizing software for FreeBSD? I don't mind > having to pay, as long as it really works. > > I see that VMWare, for instance, is not supported on FreeBSD. > > I'm running 4.9-RELENG at the moment, but considering an upgrade to > 5.x. xen is on the way, but don't think it's quite ready yet (and wont' do winders until Vanderpool ships). If you fancy a go, google for it - kip macy has been doing a lot of patches etc. to 5.x. -- 'Yeah, well I'm gonna build my own themepark! With blackjack aaand Hookers! Actually, forget the park. And the blackjack.' -- Bender Rasputin :: Jack of All Trades - Master of Nuns From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 11:31:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B6716A4CE for ; Tue, 12 Apr 2005 11:31:43 +0000 (GMT) Received: from lonsmime04.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8229643D1D for ; Tue, 12 Apr 2005 11:31:42 +0000 (GMT) (envelope-from Anthony.Downer@reuters.com) Received: from eupig1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 12 Apr 2005 11:31:35 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEU0071Q00NWL@eupig1.dtc.lon.ime.reuters.com>; Tue, 12 Apr 2005 11:31:35 +0000 (GMT) Received: from lonsmsxm01.emea.ime.reuters.com ([10.5.150.14]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Tue, 12 Apr 2005 12:31:34 +0100 Date: Tue, 12 Apr 2005 12:31:33 +0100 From: Anthony Downer To: David Sze , Scott Long MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [PATCH] Stability fixes for IPS driver for 4.x Thread-Index: AcU+VQcORrHgkb78SSeAZwxjnN8IDwA/Z0og Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Apr 2005 11:31:34.0299 (UTC) FILETIME=[2E62CEB0:01C53F53] cc: stable@freebsd.org cc: mb@imp.ch Subject: RE: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 11:31:43 -0000 Folks, I have patched and re-built the 4.11 kernel using the ips.RELENG_4.stability.patch. The IBM x342 with ServeRAID 4Lx now appears to work flawlessly, copying 500MB plus without a single error. Thank you both for your time and effort. Cheers, Anthony. -----Original Message----- From: David Sze [mailto:dsze@alumni.uwaterloo.ca]=20 Sent: 11 April 2005 06:12 To: Scott Long Cc: Anthony Downer; mb@imp.ch; stable@freebsd.org Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x At 09:17 AM 09/04/2005 -0600, Scott Long wrote this to All: >All, > >Thanks to the keen eye of David Sze, the cause of the instability in=20 >the ips driver in FreeBSD 4.x might have been found. If it's affecting >you, please try the attached patch and let me know the results. I'll=20 >commit it when everyone is happy with it. Scott, I think there's a problem with the ips_commands.c patch. After the bufq_first call succeeds, bufq_remove must be called before the splx or else the iobuf can get issued twice. However, if the subsequent ips_get_free_cmd fails, the iobuf must be put back on the bufq. Two patches are attached to this message: 1. ips.RELENG_4.stability.patch is just the stability patch as described. 2. ips.RELENG_4.mfc-and-stability.patch is an MFC of your IPS cleanup and optimization that you committed to HEAD on 01/28/05, plus the stability patch as described. Both patches survived a "make -j8 buildworld" for me. The problem I'm having now is that ips does not appear to be PAE-ified. With either patch the bus_dmamap_create call fails. Any pointers would be appreciated, this is new territory for me. >Thanks, > >Scott > > >Index: ips_commands.c >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >RCS file: /usr/ncvs/src/sys/dev/ips/ips_commands.c,v >retrieving revision 1.11.6.1 >diff -u -r1.11.6.1 ips_commands.c >--- ips_commands.c 13 Jan 2005 00:46:40 -0000 1.11.6.1 >+++ ips_commands.c 9 Apr 2005 15:09:50 -0000 >@@ -162,8 +162,11 @@ > void ips_start_io_request(ips_softc_t *sc) > { > struct buf *iobuf; >+ int s > >+ s =3D splbio(); > iobuf =3D bufq_first(&sc->queue); >+ splx(s); > if(!iobuf) { > return; > } >@@ -171,8 +174,10 @@ > if(ips_get_free_cmd(sc, ips_send_io_request, iobuf, =20 >IPS_NOWAIT_FLAG)){ > return; > } >- >+ >+ s =3D splbio(); > bufq_remove(&sc->queue, iobuf); >+ splx(s); > return; > } > >Index: ips_disk.c >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >RCS file: /usr/ncvs/src/sys/dev/ips/ips_disk.c,v >retrieving revision 1.6.6.1 >diff -u -r1.6.6.1 ips_disk.c >--- ips_disk.c 13 Jan 2005 00:46:40 -0000 1.6.6.1 >+++ ips_disk.c 9 Apr 2005 15:07:50 -0000 >@@ -128,12 +128,15 @@ > static void ipsd_strategy(struct buf *iobuf) > { > ipsdisk_softc_t *dsc; >+ int s; > > dsc =3D iobuf->b_dev->si_drv1; > DEVICE_PRINTF(8,dsc->dev,"in strategy\n"); > devstat_start_transaction(&dsc->stats); > iobuf->b_driver1 =3D (void > *)(uintptr_t)dsc->sc->drives[dsc->disk_number].drivenum; >- bufqdisksort(&dsc->sc->queue, iobuf); >+ s =3D splbio(); >+ bufq_insert_tail(&dsc->sc->queue, iobuf); >+ splx(s); > ips_start_io_request(dsc->sc); } > ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 12:04:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5C0716A4CE for ; Tue, 12 Apr 2005 12:04:50 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A7A1C43D55 for ; Tue, 12 Apr 2005 12:04:49 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: (qmail invoked by alias); 12 Apr 2005 12:04:48 -0000 Received: from pD955BCB0.dip.t-dialin.net (EHLO olaf) [217.85.188.176] by mail.gmx.net (mp016) with SMTP; 12 Apr 2005 14:04:48 +0200 X-Authenticated: #5707313 Date: Tue, 12 Apr 2005 14:04:43 +0200 From: Marius =?ISO-8859-1?Q?N=FCnnerich?= To: freebsd-stable@freebsd.org Message-ID: <20050412140443.61f9cc32@olaf> In-Reply-To: <49903.1113300300@thrush.ravenbrook.com> References: <49903.1113300300@thrush.ravenbrook.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Signature_Tue__12_Apr_2005_14_04_43_+0200_6TVXfHfwGss9IkoC; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Y-GMX-Trusted: 0 Subject: Re: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 12:04:50 -0000 --Signature_Tue__12_Apr_2005_14_04_43_+0200_6TVXfHfwGss9IkoC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, emulators/qemu could do the job for you :) cheers Marius --Signature_Tue__12_Apr_2005_14_04_43_+0200_6TVXfHfwGss9IkoC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW7lfFqu2z7AvZZQRAs80AJ9uPkuwq4tAWksgy8tC8Hw0VIj1fgCfXoyB ffxsBYQSeNomk/zdqPLMO6o= =Gkr+ -----END PGP SIGNATURE----- --Signature_Tue__12_Apr_2005_14_04_43_+0200_6TVXfHfwGss9IkoC-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 12:31:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9206416A4CE for ; Tue, 12 Apr 2005 12:31:49 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 132FD43D1D for ; Tue, 12 Apr 2005 12:31:49 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3CCVmTn060936; Tue, 12 Apr 2005 08:31:48 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 60302-08; Tue, 12 Apr 2005 08:31:47 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3CCVlBF060914; Tue, 12 Apr 2005 08:31:47 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.12.11) with ESMTP id j3CCVduv020721; Tue, 12 Apr 2005 08:31:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050412082221.04164328@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Apr 2005 08:31:00 -0400 To: Philip Murray From: Mike Tancsa In-Reply-To: References: <6.2.1.2.0.20050411223651.04f62e18@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-stable@freebsd.org Subject: Re: Intel 6300ESB (ICH) SMBus controller not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 12:31:49 -0000 At 01:03 AM 12/04/2005, Philip Murray wrote: >On 12/04/2005, at 2:38 PM, Mike Tancsa wrote: > >>At 09:24 PM 11/04/2005, Philip Murray wrote: >>>Hi, >>> >>>I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver >>>doesn't want to work with it, I get the following on boot: >>> >>>ichsmb0: port 0x8c0-0x8df irq 17 >>>at device 31.3 on pci0 >>>device_attach: ichsmb0 attach returned 6 >> >>Does it work if you add >> >>debug.acpi.disabled="sysresource" >> >>to /boot/loader.conf >> > >Thanks for that, It kind of worked. Am I correct in thinking that, that >prevents ACPI attaching to the controller so that the ichsmb driver can? >In which case, if ACPI does attach to it, does that mean I'd get >temperature values in the hw.acpi.thermal tree? Not sure of the full details as to what it disables, but I can still get it with it in my loader.conf sysctl -A hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 73.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 75.0C hw.acpi.thermal.tz0._ACx: 73.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 # grep -i smbu /var/run/dmesg.boot ichsmb0: port 0x5000-0x501f irq 10 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 # cat /boot/loader.conf debug.acpi.disabled="sysresource" Also, for xmbmon, it doesnt seem to need the smb device compiled into the kernel. I think the issue is the ICH6 info has changed and its just not parsing the information correctly. Try mbmom -D on your machine [verify1] /home/mdtancsa# mbmon -D Probe Request: none >>> Testing Reg's at SMBus <<< [Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6), IO-Base:0x5000] SMBus slave 0x5E(0x2F) found... SMBus slave 0x88(0x44) found... SMBus slave 0xA0(0x50) found... SMBus slave 0xA4(0x52) found... Set SMBus slave address: 0x5E Probing Winbond/Asus/LM78/79 chip: CR40:0xFF, CR41:0xFF, CR42:0xFF, CR43:0xFF CR44:0xFF, CR45:0xFF, CR46:0xFF, CR47:0xFF CR48:0xFF, CR49:0xFF, CR4A:0xFF, CR4B:0xFF CR4C:0xFF, CR4D:0xFF, CR4E:0xFF, CR4F:0xFF CR56:0xFF, CR58:0xFF, CR59:0xFF, CR5D:0x19 CR3E:0xFF, CR13:0xFF, CR17:0xFF, CRA1:0xFF CR20:0xFF, CR22:0xFF, CR23:0xFF, CR24:0xFF CR27:0xFF, CR29:0xFF, CR2A:0xFF, CR2B:0xFF Set SMBus slave address: 0x5E Probing Winbond W83L78x chip: CR40:0xFF, CR41:0xFF, CR42:0xFF, CR43:0xFF CR44:0xFF, CR45:0xFF, CR46:0xFF, CR47:0xFF CR48:0xFF, CR49:0xFF, CR4A:0xFF, CR4B:0xFF CR4C:0xFF, CR4D:0xFF, CR4E:0xFF, CR4F:0xFF CR20:0xFF, CR21:0xFF, CR22:0xFF, CR23:0xFF CR26:0xFF, CR27:0xFF, CR28:0xFF, CR29:0xFF CR2B:0xFF, CR2C:0xFF, CR2D:0xFF, CR2E:0xFF SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!! >>> Testing Reg's at ISA-IO <<< [ISA Port IO-Base:0x290] Probing Winbond/Asus/LM78/79 chip: CR40:0x01, CR41:0x00, CR42:0x00, CR43:0xFE CR44:0xFF, CR45:0x00, CR46:0x00, CR47:0xF0 CR48:0x2D, CR49:0x03, CR4A:0x01, CR4B:0xC4 CR4C:0x18, CR4D:0x15, CR4E:0x01, CR4F:0xA3 CR56:0x00, CR58:0xFF, CR59:0xFF, CR5D:0xFF CR3E:0x00, CR13:0x00, CR17:0x3C, CRA1:0xC7 CR20:0x82, CR22:0xD2, CR23:0xBE, CR24:0x5E CR27:0x20, CR29:0x3C, CR2A:0xFF, CR2B:0xF0 Probing ITE7805/7812/SIS950 chip: CR00:0x01, CR01:0xF0, CR02:0x01, CR03:0xF0 CR0A:0x01, CR48:0x2D, CR50:0xFF, CR51:0xFF CR20:0x82, CR21:0xC7, CR22:0xD2, CR23:0xBE CR24:0x5E, CR25:0x00, CR26:0x00, CR27:0x20 CR28:0xFF, CR29:0x3C, CR2A:0xFF, CR2B:0xF0 CR0B:0x01, CR0D:0x3C, CR0E:0x01, CR0F:0x01 Using ISA-IO access method!! * Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found. [verify1] /home/mdtancsa# On a 915 box I have, [verify1]% mbmon Temp.= 255.0, 240.0, 61.0; Rot.= 11250, 1350000, 675000 Vcore = 2.08, 3.20; Volt. = 3.34, 5.08, 5.78, -0.00, -0.00 ^C [verify1]% However, lmmon does seem to work [verify1] /home/mdtancsa# lmmon -p MB temp: 33C / 91F / 306K Fans: 1 : 0 rpm 2 : 2812 rpm 3 : 0 rpm Voltages: Vcore1 : +2.078V Vcore2 : +3.125V + 3.3V : +3.281V + 5.0V : +4.932V +12.0V : +5.875V -12.0V : -0.000V - 5.0V : -0.000V and the thermal info is there [verify1] /home/mdtancsa# sysctl -A hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 33.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 100.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 [verify1] /home/mdtancsa# >sysutils/xmbmon and sysutils/healthd can't seem to read anything from it >anyway. Is this because the SMBus has no temperature sensors tied to it? >It has them in the BIOS, so I assumed I could read them in FreeBSD. > >I get ichsmb0: irq 0x04 during -1 in dmesg when trying healthd and > >root@alexis:~/ > healthd -S >ioctl(SMB_WRITEB): Permission denied > >Cheers, >Phil From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 12:45:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E8716A4CE for ; Tue, 12 Apr 2005 12:45:13 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9840843D4C for ; Tue, 12 Apr 2005 12:45:12 +0000 (GMT) (envelope-from robbak@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so3394788wri for ; Tue, 12 Apr 2005 05:45:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=is9q9MAl5+Z6q60ZY42AsOCIO5cUiUz9uhN5nEopwkmWAoGoaQCwfmUoPh6pw4NLNnBR2TTAVttkCB7p8zcL21eOGC1teUri+FX/SDdufuVb2kqPiyVuJejP7Vdb9i9rf1TqYsk+4iPnGk+UVz89mjhIvob/6+BDcuKjgZpP4y0= Received: by 10.54.55.61 with SMTP id d61mr3327800wra; Tue, 12 Apr 2005 05:45:11 -0700 (PDT) Received: by 10.54.14.15 with HTTP; Tue, 12 Apr 2005 05:45:11 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 22:45:11 +1000 From: Robert Backhaus To: Jan Sebosik In-Reply-To: <425B86B4.9030203@demax.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <425B86B4.9030203@demax.sk> cc: freebsd-stable@freebsd.org Subject: Re: Package managment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Backhaus List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 12:45:13 -0000 On Apr 12, 2005 6:28 PM, Jan Sebosik wrote: > Hi > > I`ve got one simple question: if i`ve built packages on my freebsd > 5.3-RELEASE system, do I need to rebuilt them again for 5.4-RELEASE > (after downloading && compiling from sources) ? > > Best regards, > Jan Sebosik > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > With care, in many situations, you should be able to get away with it. Problems occur with ports that contain kernel modules (ltmdm, nvidia-driver). There have also been major changes within ports (new gtk versions, and a gnome upgrade) which will make partial rebuilding hazardous. Most of us would recommend a general rebuild, for safety's sake. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 13:07:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5739E16A4CE for ; Tue, 12 Apr 2005 13:07:53 +0000 (GMT) Received: from mail2out.barnet.com.au (mail2out.barnet.com.au [202.83.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 260E843D45 for ; Tue, 12 Apr 2005 13:07:48 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mail2out.barnet.com.au (Postfix, from userid 27) id 8847F7074B7; Tue, 12 Apr 2005 23:07:40 +1000 (EST) X-Viruscan-Id: <425BC81C00008C190B524B@BarNet> Received: from mail2-auth.barnet.com.au (mail2.barnet.com.au [202.83.176.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id D40787074B1 for ; Tue, 12 Apr 2005 23:07:39 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 16AED7074AE for ; Tue, 12 Apr 2005 23:07:39 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id DA067617E; Tue, 12 Apr 2005 23:07:27 +1000 (EST) Date: Tue, 12 Apr 2005 23:07:27 +1000 From: Edwin Groothuis To: freebsd-stable@freebsd.org Message-ID: <20050412130727.GE1209@k7.mavetju> Mail-Followup-To: Edwin Groothuis , freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Adaptec 1210 weird behaviour X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 13:07:53 -0000 The Adaptec 1210 is a serial ATA RAID0/1 controller. When the two disks are configured as RAID1, FreeBSD still sees two harddisks instead of one. This is with 5.3. Scary :-) Will try this weekend with 5.4 -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 13:53:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D787E16A4E6 for ; Tue, 12 Apr 2005 13:53:03 +0000 (GMT) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15BB343D3F for ; Tue, 12 Apr 2005 13:53:01 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 42BE8B850 for ; Tue, 12 Apr 2005 09:53:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <014301c53eb5$42638bf0$b3db87d4@multiplay.co.uk> References: <014301c53eb5$42638bf0$b3db87d4@multiplay.co.uk> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--284690505; protocol="application/pkcs7-signature" Message-Id: <0c9a92c2eb7461f25aa924322407f950@khera.org> From: Vivek Khera Date: Tue, 12 Apr 2005 09:52:59 -0400 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.619.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 13:53:04 -0000 --Apple-Mail-19--284690505 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 11, 2005, at 12:01 PM, Steven Hartland wrote: > of swap? Which leads to the question would it not be more sensible to > kill off the largest process first as its more than likely that it is > responsible > for the problem? > so when this largest process is your production database server for your e-commerce site, what will you change your recommendation to be? basically, there is no "right" choice of process to kill. a machine that is out of resources is just a bad situation, and the right thing is to try to avoid getting there with careful monitoring and planning. Vivek Khera, Ph.D. +1-301-869-4449 x806 --Apple-Mail-19--284690505-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 14:06:47 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E579916A4CE for ; Tue, 12 Apr 2005 14:06:47 +0000 (GMT) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D61A43D41 for ; Tue, 12 Apr 2005 14:06:45 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) j3CE6fU7060532; Tue, 12 Apr 2005 15:06:41 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) j3CE6fHs051435; Tue, 12 Apr 2005 15:06:41 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Vivek Khera In-Reply-To: <0c9a92c2eb7461f25aa924322407f950@khera.org> from Vivek Khera of "Tue, 12 Apr 2005 09:52:59 -0400" Date: Tue, 12 Apr 2005 15:06:41 +0100 Message-ID: <51434.1113314801@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:06:48 -0000 At 2005-04-12 13:52:59+0000, Vivek Khera writes: > > of swap? Which leads to the question would it not be more sensible to > > kill off the largest process first as its more than likely that it is > > responsible > > for the problem? > > > > so when this largest process is your production database server for > your e-commerce site, what will you change your recommendation to be? > > basically, there is no "right" choice of process to kill. a machine > that is out of resources is just a bad situation, and the right thing > is to try to avoid getting there with careful monitoring and planning. The right choice is for mmap() to return ENOMEM, and then for malloc() to return NULL, but almost no operating systems make this choice any more. Nick B From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 14:16:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE1F316A4CE for ; Tue, 12 Apr 2005 14:16:34 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2BB243D66 for ; Tue, 12 Apr 2005 14:16:33 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 50C771F081; Tue, 12 Apr 2005 16:16:04 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 36D1862F7; Tue, 12 Apr 2005 16:16:04 +0200 (CEST) Date: Tue, 12 Apr 2005 16:16:04 +0200 From: Marc Olzheim To: Aaron Summers Message-ID: <20050412141604.GA1570@stack.nl> References: <6cd6260405041119126b78c33@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <6cd6260405041119126b78c33@mail.gmail.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: stable@freebsd.org Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:16:35 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers wrote: > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server > running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD, > SCSI controller, etc. To no avail. We are running SMP GENERIC > Kernel. I cannot get the system to panic, leave a core dump, etc. It > just always freezes. The server functions as a web server in a > HSphere Cluster. I am about out of options besides loading 4.11 > (since our 4 series servers never die). Any help, feedback, clues, > similar experiences, etc would be greatly appreciated. >=20 > On SCSI: The onboard Adaptec 7902 gives a dump on bootup but appears > to work. I read the archived post about this issue. The system still > locked up with an Adaptec 7982B that did not give this message. We've got exactly the same, but then with the X5DPR-IG2+/X5DPR-8G2+. I've got about 25-30 running FreeBSD 4.6 - 4.11 running perfectly stable, but the 3 that I installed 5.x on, (currently all 5.4-STABLE), keep on hanging themselves up completely, even with no read load on them, within a week. CPUs range from 3.06 to 3.2 GHz, all of them have 4x1GB DIMMs, and 3 SEAGATE ST3146807LC 0007's... I tried updating the BIOSes as well, with both a standard BIOS and one given to us bh supermicro preconfigured fro com-console, so I could flashed them with a remotely booted DOS floppy over com-console. :-) Another thing I noticed: motherboard versions from before 2005 do not detect sio0 on the right place: port 0x2f8-0x2ff irq 3 on acpi0 (the normal place for sio1), resulting in loader/kernel comconsole going to the right port and the userland comconsole going to the wrong port... This problem does not occur on newer versions of the servers... Marc --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW9gkezjnobFOgrERArSAAJ0UNlPFnxVDfMBmweS40oXtkOSYrQCgn5k+ 1FNbNwaVlfK0B4LBnj9fCmM= =j43/ -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 14:26:41 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE42F16A4CE for ; Tue, 12 Apr 2005 14:26:41 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6921543D46 for ; Tue, 12 Apr 2005 14:26:41 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 9EB011F0A1; Tue, 12 Apr 2005 16:26:40 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 86F4F62F7; Tue, 12 Apr 2005 16:26:40 +0200 (CEST) Date: Tue, 12 Apr 2005 16:26:40 +0200 From: Marc Olzheim To: Nick Barnes Message-ID: <20050412142640.GB1570@stack.nl> References: <0c9a92c2eb7461f25aa924322407f950@khera.org> <51434.1113314801@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <51434.1113314801@thrush.ravenbrook.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Vivek Khera cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:26:41 -0000 --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: > The right choice is for mmap() to return ENOMEM, and then for malloc() > to return NULL, but almost no operating systems make this choice any > more. No, the problem occurs only when previously allocated / mmap()d blocks are actually used (written) and when the total of virtual memory has been overcommitted: Physical pages are not allocated to processes at malloc() time, but at time of first usage (Copy On Write). A possible solution would be for the kernel to only hand out memory allocation-time when it's possible to back it up with virtual memory, but normal memory usage allows for overcommits just fine and many programs have been programmed in a way that assumes this behaviour, for instance by sparsely using large allocations instead of adding the possible extra bookkeeping to allow for smaller allocations. It just makes a lot of memory allocation / duplication issues a lot easier... Marc --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW9qgezjnobFOgrERAgVCAKCL3eaLjKIg717mq1T8QSAesdO/HQCgv0FX w8OmE5m5ED2LowplQTOjmg8= =TJz3 -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 14:40:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24D0716A4CE for ; Tue, 12 Apr 2005 14:40:13 +0000 (GMT) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D0DA43D46 for ; Tue, 12 Apr 2005 14:40:12 +0000 (GMT) (envelope-from don@SANDVINE.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C53F6D.87A912AB" Date: Tue, 12 Apr 2005 10:40:10 -0400 Message-ID: <2BCEB9A37A4D354AA276774EE13FB8C23A6B41@mailserver.sandvine.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze Thread-Index: AcU/alYCsQU+eu1HQ8+EvmRynV7CPgAArdfA From: "Don Bowman" To: "Marc Olzheim" , "Aaron Summers" , cc: stable@freebsd.org Subject: RE: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:40:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C53F6D.87A912AB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable From: Marc Olzheim > On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers wrote: > > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB=20 > RAM server=20 > > running 5.4-STABLE that keeps freezing up. We have=20 > replaced RAM, HD,=20 > > SCSI controller, etc. To no avail. We are running SMP GENERIC=20 > > Kernel. I cannot get the system to panic, leave a core=20 > dump, etc. It=20 > > just always freezes. The server functions as a web server in a=20 > > HSphere Cluster. I am about out of options besides loading 4.11=20 > > (since our 4 series servers never die). Any help, feedback, clues,=20 > > similar experiences, etc would be greatly appreciated. > >=20 > > On SCSI: The onboard Adaptec 7902 gives a dump on bootup=20 > but appears=20 > > to work. I read the archived post about this issue. The=20 > system still=20 > > locked up with an Adaptec 7982B that did not give this message. >=20 The problem is with the periodic SMM interrupt and the bios. The attached program (ich-periodic-smm-disable.c) will fix the problem. For more information on what it does, see the Intel ICH3 datasheet. compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will be good. Run this on each boot. I think you only need to clear PERIODIC_EN. --don ------_=_NextPart_001_01C53F6D.87A912AB Content-Type: application/octet-stream; name="ich-periodic-smm-disable.c" Content-Transfer-Encoding: base64 Content-Description: ich-periodic-smm-disable.c Content-Disposition: attachment; filename="ich-periodic-smm-disable.c" LyoKICogQ29weXJpZ2h0IChDKSAyMDA1IFNhbmR2aW5lIEluY29ycG9yYXRlZC4gQWxsIHJpZ2h0 cyByZXNlcnZlZC4KICogCiAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBi aW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAogKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0 ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKICogYXJlIG1ldDoKICog MS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBj b3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyLgogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0g bXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAogKiAgICBub3RpY2UsIHRoaXMgbGlz dCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCiAqICAg IGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBk aXN0cmlidXRpb24uCiAqIAogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIEFVVEhPUiBB TkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCiAqIElNUExJRUQg V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgQVVUSE9SIE9S IENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJ REVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKICogREFNQUdFUyAo SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUg R09PRFMKICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBC VVNJTkVTUyBJTlRFUlJVUFRJT04pCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZ IE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCiAqIExJQUJJTElUWSwg T1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFO WSBXQVkKICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VE IE9GIFRIRSBQT1NTSUJJTElUWSBPRgogKiBTVUNIIERBTUFHRS4KKi8KCgoKI2luY2x1ZGUgPHN0 ZGlvLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxz eXMvaW9jdGwuaD4KI2luY2x1ZGUgPHN5cy9tZW1yYW5nZS5oPgojaW5jbHVkZSA8c3lzL3BjaWlv Lmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUgPHN5cy9tbWFuLmg+CiNpbmNsdWRl IDxtYWNoaW5lL2NwdWZ1bmMuaD4KCiNkZWZpbmUgSUNIX1BNQkFTRSAgICAgICAgICAgICAgMHg0 MCAvKiBBQ1BJIGJhc2UgYWRkcmVzcyByZWdpc3RlciAqLwojZGVmaW5lIElOVEVMX1ZFTkRPUklE ICAgICAgICAgIDB4ODA4NgojZGVmaW5lIElOVEVMX0RFVklDRUlEX0lDSDQgICAgIDB4MjRjMAov KiA4MjA4MUNBIChJQ0gzLVMpIExQQyBJbnRlcmZhY2UgYnJpZGdlICovCiNkZWZpbmUgSU5URUxf REVWSUNFSURfSUNIMyAgICAgMHgyNDgwCi8qIDgyODAxRUIvRVIgKElDSDUpIExQQyBJbnRlcmZh Y2UgQnJpZGdlICovCiNkZWZpbmUgSU5URUxfREVWSUNFSURfSUNINSAgICAgMHgyNGQwCgoKCmlu dApjbGVhclBlcmlvZGljQml0cyh1X2ludCBwbWJhc2UpCnsKICAgIHVfaW50IHNtaV9lbjsKCiAg ICBzbWlfZW4gPSBpbmwocG1iYXNlICsgMHgzMCk7CiAgICAvKiBUaGlzIGRpc2FibGVzIFNNSSBm b3IgdGhlIGVudGlyZSBzeXN0ZW0uCiAgICAgKiBUaGlzIG1heSBub3QgYmUgd2hhdCB5b3Ugd2Fu dCBmb3IgZS5nLiBBQ1BJIG9yIEFQTQogICAgICovCiAgICBzbWlfZW4gPSBzbWlfZW4gJiAofigo MTw8MTQpfAkvKiBQRVJJT0RJQ19FTiAgICovCgkJCSAoMTw8MTMpfAkvKiBUQ09fRU4gICAgICAg ICovCgkJCSAoMTw8MTEpfAkvKiBNQ1NNSV9FTiAgICAgICovCgkJCSAoMTw8NikgfCAJLyogU1dT TUlfVE1SX0VOICAqLwoJCQkgKDE8PDUpIHwgCS8qIEFQTUNfRU4gICAgICAgKi8KCQkJICgxPDw0 KSB8IAkvKiBTTFBfU01JX0VOICAgICovCgkJCSAoMTw8MykgfCAJLyogTEVHQUNZX1VTQl9FTiAq LwoJCQkgKDE8PDIpIHwgCS8qIEJJT1NfRU4gICAgICAgKi8KCQkJICgxPDwwKSkpOwkvKiBHTEJM X1NNSV9FTiAgICovCiAgICAvKiBEaXNhYmxlIHRoZSBUQ08gY291bnRlciB0byBnZW5lcmF0ZSBT TUkgKi8KICAgIG91dGwocG1iYXNlKzB4MzAsIHNtaV9lbik7Cgp9CgppbnQKY2xlYXJQZXJpb2Rp YyhpbnQgZmQsCiAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHZlbmRvcmlkLAoJICAgICAgdW5z aWduZWQgaW50IGRldmljZWlkKQp7CiAgICB1X2ludCBwbWJhc2U7CiAgICBzdHJ1Y3QgcGNpX2lv IGlvOwogICAgc3RydWN0IHBjaV9jb25mX2lvIHBjaWlvOwogICAgc3RydWN0IHBjaV9tYXRjaF9j b25mIG1jOwogICAgc3RydWN0IHBjaV9jb25mIG1hdGNoOwogICAgbWVtc2V0KCZwY2lpbywwLHNp emVvZihwY2lpbykpOwogICAgbWVtc2V0KCZtYywgMCwgc2l6ZW9mKG1jKSk7CiAgICBtZW1zZXQo Jm1hdGNoLCAwLCBzaXplb2YobWF0Y2gpKTsKICAgIG1jLnBjX3ZlbmRvciA9IHZlbmRvcmlkOyAv KiBJbnRlbCAqLwogICAgbWMucGNfZGV2aWNlID0gZGV2aWNlaWQ7IC8qIElDSDMgTFBDIDwtPiBQ Q0kgSVNBIGJyaWRnZSAqLwogICAgbWMuZmxhZ3MgPSBQQ0lfR0VUQ09ORl9NQVRDSF9WRU5ET1Ig fCBQQ0lfR0VUQ09ORl9NQVRDSF9ERVZJQ0U7CiAgICBwY2lpby5wYXR0ZXJucyA9ICZtYzsKICAg IHBjaWlvLnBhdF9idWZfbGVuID0gc2l6ZW9mKG1jKTsKICAgIHBjaWlvLm51bV9wYXR0ZXJucyA9 IDE7CiAgICBwY2lpby5tYXRjaGVzID0gJm1hdGNoOwogICAgcGNpaW8ubWF0Y2hfYnVmX2xlbiA9 IHNpemVvZihtYXRjaCk7CiAgICBpZiAoaW9jdGwoZmQsIFBDSU9DR0VUQ09ORiwgJnBjaWlvKSA8 IDApCiAgICB7CglwZXJyb3IoIlBDSU9DR0VUQ09ORiIpOwoJcmV0dXJuIDE7CiAgICB9CiAgICBp ZiAocGNpaW8ubnVtX21hdGNoZXMgPT0gMCkKICAgIHsKCXJldHVybiAxOwogICAgfQoKICAgIGlv LnBpX3NlbCA9IG1hdGNoLnBjX3NlbDsKICAgIGlvLnBpX3JlZyA9IElDSF9QTUJBU0U7CiAgICBp by5waV93aWR0aCA9IDQ7CiAgICBpZiAoaW9jdGwoZmQsIFBDSU9DUkVBRCwgJmlvKSA8IDApCiAg ICB7CglwZXJyb3IoIlBDSU9DUkVBRCIpOwoJcmV0dXJuIDE7CiAgICB9CiAgICBwbWJhc2UgPSAo KHVfaW50IClpby5waV9kYXRhKSAvIDIgKiAyOwogICAgcHJpbnRmKCJGb3VuZCBJQ0ggZGV2aWNl IEAgJXUuJXUuJXUuIHBtYmFzZSA9ICUwOHhcbiIsCgkgICAgbWF0Y2gucGNfc2VsLnBjX2J1cywg ICAgCgkgICAgbWF0Y2gucGNfc2VsLnBjX2RldiwKCSAgICBtYXRjaC5wY19zZWwucGNfZnVuYywg cG1iYXNlKTsKICAgIGNsZWFyUGVyaW9kaWNCaXRzKHBtYmFzZSk7Cn0KCmludAptYWluKGludCBh cmdjLCBjaGFyICoqYXJndikKewogICAgaW50IGZkMSwgZmQyOwoKCiAgICBmZDEgPSBvcGVuKCIv ZGV2L3BjaSIsIE9fUkRXUiwgMCk7CiAgICBpZiAoZmQxIDwgMCkKICAgIHsKCXBlcnJvcigib3Bl biAvZGV2L3BjaSIpOwogICAgfQoKICAgIGZkMiA9IG9wZW4oIi9kZXYvaW8iLCBPX1JEV1IsIDAp OwogICAgaWYgKGZkMiA8IDApCiAgICB7CglwZXJyb3IoIm9wZW4gL2Rldi9pbyIpOwogICAgfQog ICAgY2xlYXJQZXJpb2RpYyhmZDEsIElOVEVMX1ZFTkRPUklELElOVEVMX0RFVklDRUlEX0lDSDMp Owp9Cg== ------_=_NextPart_001_01C53F6D.87A912AB-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 15:01:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B21E16A4CE for ; Tue, 12 Apr 2005 15:01:45 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BABC043D1D for ; Tue, 12 Apr 2005 15:01:44 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id C8F5C1F0A7; Tue, 12 Apr 2005 17:01:43 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id B13CF62F7; Tue, 12 Apr 2005 17:01:43 +0200 (CEST) Date: Tue, 12 Apr 2005 17:01:43 +0200 From: Marc Olzheim To: Don Bowman Message-ID: <20050412150143.GC1570@stack.nl> References: <2BCEB9A37A4D354AA276774EE13FB8C23A6B41@mailserver.sandvine.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UFHRwCdBEJvubb2X" Content-Disposition: inline In-Reply-To: <2BCEB9A37A4D354AA276774EE13FB8C23A6B41@mailserver.sandvine.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: stable@freebsd.org cc: carlos@infodrive.com.ar cc: Aaron Summers Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 15:01:45 -0000 --UFHRwCdBEJvubb2X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman wrote: > The problem is with the periodic SMM interrupt and the bios. >=20 > The attached program (ich-periodic-smm-disable.c) will fix the problem. > For more information on what it does, see the Intel ICH3 datasheet. >=20 > compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will be > good. > Run this on each boot. >=20 > I think you only need to clear PERIODIC_EN. Ok, I'll try it right away, thanks a lot! Marc --UFHRwCdBEJvubb2X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW+LXezjnobFOgrERAlz4AJ0cToTWZMFP8Vh3rtSmNc2+IUkfSwCdG1AG WdfMkOEGZZGAcYcERKXoYd4= =Fwqo -----END PGP SIGNATURE----- --UFHRwCdBEJvubb2X-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 15:09:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D866E16A4CE for ; Tue, 12 Apr 2005 15:09:24 +0000 (GMT) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C1F43D45 for ; Tue, 12 Apr 2005 15:09:23 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) j3CF9LU7064458; Tue, 12 Apr 2005 16:09:21 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) j3CF9LHs051622; Tue, 12 Apr 2005 16:09:21 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Marc Olzheim In-Reply-To: <20050412142640.GB1570@stack.nl> from Marc Olzheim of "Tue, 12 Apr 2005 16:26:40 +0200" Date: Tue, 12 Apr 2005 16:09:21 +0100 Message-ID: <51621.1113318561@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Vivek Khera cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 15:09:25 -0000 At 2005-04-12 14:26:40+0000, Marc Olzheim writes: > On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: > > The right choice is for mmap() to return ENOMEM, and then for malloc() > > to return NULL, but almost no operating systems make this choice any > > more. > > No, the problem occurs only when previously allocated / mmap()d blocks > are actually used (written) and when the total of virtual memory has > been overcommitted: Physical pages are not allocated to processes at > malloc() time, but at time of first usage (Copy On Write). Yes, implicit in my statement is that the OS shouldn't overcommit. I remember when overcommit was new (maybe 1990), and some Unix (Irix, perhaps, or AIX?) made it switchable. There was a bit of flurry in the OS community, as some people (myself included) felt that the OS shouldn't make promises it couldn't fulfill, and that this "kill a random process" behaviour was more of a bug than a solution. Consider a parallel design which allows (say) file descriptors to be overcommitted. You can open a billion files, but if you touch one of them, that consumes a finite kernel resource, and if the kernel has run out then a randomly chosen process gets killed. Great. > many programs have been programmed in a way that assumes this > behaviour, for instance by sparsely using large allocations instead > of adding the possible extra bookkeeping to allow for smaller > allocations. This is the well-known problem with my fantasy world in which the OS doesn't overcommit any resources. All those programs are broken, but it's too costly to fix them. If overcommit had been resisted more effectively in the first place, those programs would have been written properly. My recollection, quite possibly faulty, is that FreeBSD came quite late to the overcommit binge party. Nick B From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:04:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8890D16A4CE for ; Tue, 12 Apr 2005 16:04:38 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B93243D54 for ; Tue, 12 Apr 2005 16:04:38 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5B07672DE4; Tue, 12 Apr 2005 09:04:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 561C972DDF; Tue, 12 Apr 2005 09:04:38 -0700 (PDT) Date: Tue, 12 Apr 2005 09:04:38 -0700 (PDT) From: Doug White To: Kirill Ponomarew In-Reply-To: <20050410070638.GB38785@voodoo.oberon.net> Message-ID: <20050412090310.Q2178@carver.gumbysoft.com> References: <20050406084615.GF15165@voodoo.oberon.net> <20050410070638.GB38785@voodoo.oberon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@FreeBSD.org Subject: Re: 4.11R panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:04:38 -0000 On Sun, 10 Apr 2005, Kirill Ponomarew wrote: > On Fri, Apr 08, 2005 at 10:14:17AM -0700, Doug White wrote: > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0x20202020 > > > > Hm, something ran into a bunch of ASCII spaces.. > > > > Can you jump to frame #6 and print *kbp? It appears the kernel malloc > > bucket list is corrupted, so I'm curious just how badly that struct is > > spammed. > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) up 6 > #6 0xc0193533 in malloc (size=324, type=0xc030d780, flags=9) > at /usr/src/sys/kern/kern_malloc.c:243 > 243 va = kbp->kb_next; > (kgdb) print *kbp > $1 = {kb_next = 0x20202020
, > kb_last = 0xcc8fa000 "", kb_calls = 5704, kb_total = 448, kb_elmpercl = 8, > kb_totalfree = 13, kb_highwat = 40, kb_couldfree = 0} Not very, apparently. Dunno what to say ... I'd guess something coughed up a bad address to a DMA op or something and it just happened to land there. If you can reproduce this with any sort of regularity there might be a bug, although that seems unlikely since that code hasn't changed in years and this is the first such report I've seen of this :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:07:07 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820FC16A4CE for ; Tue, 12 Apr 2005 16:07:07 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67AC443D39 for ; Tue, 12 Apr 2005 16:07:07 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5A29372DE7; Tue, 12 Apr 2005 09:07:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 580F872DE4; Tue, 12 Apr 2005 09:07:07 -0700 (PDT) Date: Tue, 12 Apr 2005 09:07:07 -0700 (PDT) From: Doug White To: Matthias Buelow In-Reply-To: <200504091700.j39H0csE000776@drjekyll.mkbuelow.net> Message-ID: <20050412090627.S2178@carver.gumbysoft.com> References: <200504091700.j39H0csE000776@drjekyll.mkbuelow.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: suboptimal handling of accidentally pulled usb devices (5.4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:07:07 -0000 On Sat, 9 Apr 2005, Matthias Buelow wrote: > every so often, I forget to unmount my ipod (usb2) before pulling it > from my PC. While this and the mess that ensues is clearly a user > error, it would be nice if this exceptional situation would get handled > a bit more gracefully by the OS. What happens now is that I cannot use > the device anymore ("Resource unavailable") until I reboot. Trying to > unmount the still mounted filesystem (no matter if the device is plugged > back in or not) simply gives: Please see the archives for a lenghty explanation of why this is not going to be fixed in the near-term future. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:16:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B625416A4CE for ; Tue, 12 Apr 2005 16:16:32 +0000 (GMT) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23FE643D49 for ; Tue, 12 Apr 2005 16:16:31 +0000 (GMT) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id j3CGGTk7015818; Tue, 12 Apr 2005 11:16:29 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id j3CGGTet015817; Tue, 12 Apr 2005 11:16:29 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Tue, 12 Apr 2005 11:16:29 -0500 From: Scott Lambert To: freebsd-stable@freebsd.org Message-ID: <20050412161629.GA12421@sysmon.tcworks.net> Mail-Followup-To: freebsd-stable@freebsd.org, Nick Barnes References: <49903.1113300300@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49903.1113300300@thrush.ravenbrook.com> User-Agent: Mutt/1.5.9i Subject: Re: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:16:32 -0000 On Tue, Apr 12, 2005 at 11:05:00AM +0100, Nick Barnes wrote: > I run FreeBSD as my main desktop, but occasionally have to develop, > build, or test software on a variety of other x86 operating systems > (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the > moment I have a row of mini-towers and a KVM switch. I'd much rather > run these other machines as virtual machines under FreeBSD. Can > anyone recommend virtualizing software for FreeBSD? I don't mind > having to pay, as long as it really works. I have not used it, but it claims to support FreeBSD as the host: http://www.serenityvirtual.com/ I have had a good relationship with the company that is behind the product. I just haven't used that particular product, especially now that my primary workstation is a PowerBook. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:24:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3778516A4CE for ; Tue, 12 Apr 2005 16:24:10 +0000 (GMT) Received: from 163.com (smtp.163.com [202.108.44.212]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D70943D58 for ; Tue, 12 Apr 2005 16:24:07 +0000 (GMT) (envelope-from ncisoft@163.com) Received: from [211.157.74.200] (unknown [211.157.74.200]) by smtp4 (Coremail) with SMTP id IABAegf2W0J9zTUD.2 for ; Wed, 13 Apr 2005 00:23:39 +0800 (CST) X-Originating-IP: [211.157.74.200] Date: Wed, 13 Apr 2005 00:23:39 +0800 From: Young Lee To: Uzi Klein In-Reply-To: <424C1F3C.4020208@bmby.com> References: <20050331232901.BC1B.NCISOFT@163.com> <424C1F3C.4020208@bmby.com> Message-Id: <20050413000852.9F7C.NCISOFT@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [en] cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.3 SMP freezes with MySQL 4.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:24:10 -0000 I had repeated the panic by reset debug.mpsafenet from 0 to 1, after that, the system automatically reboot after several hours, and if debug.mpsafenet was set to 0, the system is stable. so i guess this is a tcp stack or NIC driver SMP thread-safe issue, normally my server got over 1000 interrupts/s on bge, I have plan to replace the onboard bge NIC to fxp and set debug.mpsafenet to 1 to see what will happen this week. -- Young Lee On Thu, 31 Mar 2005 18:03:08 +0200 Uzi Klein wrote: > Young Lee wrote: > > Thank you very much. My server's uptime last two days by refer to > > Klein's configuration, it's impactful, thanks to Klein. > > > > My concern of stablility is focus on mysql's build options as > > BUILD_STATIC & BUILD_OPTIMIZED, but it looks like ridiculous > > without any logicality, build_static should have not any different > > between dynamatic lib. I will do some testing after the current > > configuration to be proven by uptime over one week, and try to > > find out how to repeat the panic. > > > > I think the real change was usin linuxthreads for SMP honestly. > The BUILD_STATIC & BUILD_OPTIMIZED only increase speed by not setting > shared libs and enables assembly AFAIK. > > -- > Uzi Klein > Software Development Manager > BMBY Software Systems Ltd > 2 Hataasia St., Yokneam, Israel > P: +972 4 959 79 89 > F: +972 3 617 93 36 > http://www.bmby.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:24:41 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16E3316A4D1 for ; Tue, 12 Apr 2005 16:24:41 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E0C43D1F for ; Tue, 12 Apr 2005 16:24:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3CGRtB7038581; Tue, 12 Apr 2005 10:27:59 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425BF587.5070904@samsco.org> Date: Tue, 12 Apr 2005 10:21:27 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edwin Groothuis References: <20050412130727.GE1209@k7.mavetju> In-Reply-To: <20050412130727.GE1209@k7.mavetju> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-stable@freebsd.org Subject: Re: Adaptec 1210 weird behaviour X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:24:41 -0000 Edwin Groothuis wrote: > The Adaptec 1210 is a serial ATA RAID0/1 controller. > > When the two disks are configured as RAID1, FreeBSD still sees two > harddisks instead of one. > > This is with 5.3. Scary :-) > Will try this weekend with 5.4 > The 1210 is not a real RAID controller, it's a SATA controller with an Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to do the RAID operations after that. The new ATA driver in 6-current might actually be able to handle this, so it's worth trying. 5.4 definitely will not. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:41:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F4E16A4CE for ; Tue, 12 Apr 2005 16:41:29 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A16343D3F for ; Tue, 12 Apr 2005 16:41:29 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3CGfRCu030462; Tue, 12 Apr 2005 09:41:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3CGfQDO030461; Tue, 12 Apr 2005 09:41:26 -0700 Date: Tue, 12 Apr 2005 09:41:26 -0700 From: Brooks Davis To: Tim Howe Message-ID: <20050412164126.GA18471@odin.ac.hmc.edu> References: <87oecl57nk.fsf@beaker.data-secure.net> <20050411230107.GA11717@odin.ac.hmc.edu> <87y8boeo7d.fsf@beaker.data-secure.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <87y8boeo7d.fsf@beaker.data-secure.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-stable@freebsd.org Subject: Re: Kodak USB flash reader causes freezes, panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:41:29 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 10:14:14PM -0400, Tim Howe wrote: > Brooks Davis writes: >=20 > > On Mon, Apr 11, 2005 at 05:24:15PM -0400, Tim Howe wrote: > > > > > Reproducibly, if I begin copying data to a [...] CF card [...] it > > > works for a while, then freezes the system. > > > > It is quite likely that 5.4 fixed your problem. >=20 > Unfortunately not. I was able, having mounted the filesystem with no > synchronization options, to copy 171MiB of data onto it and unmount. > However when I re-mounted it with the same options and tried to copy > 71MiB more, it again froze midway through. Sounds like you should file a PR about the issue. Are you sure the file system in question is OK? There were some msdosfs corruption bugs fixed recently. > Everything else (X11, sound, printing, input) seems to be working > perfectly with 5.4, but I did notice something new and strange with > regard to umass. I still have to run "true > /dev/da0" to get the slice > to show up, but now I get the following: >=20 > [1042] ~ # true > /dev/da0 =20 > [1043] ~ # camcontrol rescan 0 =20 > Re-scan of bus 0 was successful > [1044] ~ # ls -l /dev/da0* =20 > crw-r----- 1 root operator 4, 21 Apr 11 21:45 /dev/da0 > crw-r----- 1 root operator 4, 28 Apr 11 21:45 /dev/da0s1 > crw-r----- 1 root operator 4, 29 Apr 11 21:45 /dev/da0s1s1 > [1045] ~ # mount_msdosfs /dev/da0s1 /mnt/cf=20 > [1046] ~ # umount /mnt/cf=20 > [1047] ~ # mount_msdosfs /dev/da0s1s1 /mnt/cf > [1048] ~ # umount /mnt/cf I'd highly recommend running the command in the other direction so you try to read rather than write. It shouldn't matter, but that makes me nervous (not that I think it has anything to do with your problem.) It would appear that your da0s1 has data at the front that looks like an MBR and GEOM is attaching to it. I'm not sure what the best solution to that problem is. Probably a reformat. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCW/o2XY6L6fI4GtQRAuQUAJ4pMVWmeITjpIeVsUCze8XGbMVurwCgwxSb tHTjPqPiQod1vuz63plB5wQ= =lozc -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:44:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F231116A4CE for ; Tue, 12 Apr 2005 16:44:40 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9470043D54 for ; Tue, 12 Apr 2005 16:44:40 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j3CGidfQ007106; Tue, 12 Apr 2005 09:44:39 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j3CGid40013324; Tue, 12 Apr 2005 09:44:39 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j3CGid7i013259; Tue, 12 Apr 2005 09:44:39 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200504121644.j3CGid7i013259@realtime.exit.com> In-Reply-To: <20050412161629.GA12421@sysmon.tcworks.net> To: Scott Lambert Date: Tue, 12 Apr 2005 09:44:39 -0700 (PDT) X-Copyright0: Copyright 2005 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: virtual machines X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:44:41 -0000 Scott Lambert wrote: > On Tue, Apr 12, 2005 at 11:05:00AM +0100, Nick Barnes wrote: > > I run FreeBSD as my main desktop, but occasionally have to develop, > > build, or test software on a variety of other x86 operating systems > > (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the > > moment I have a row of mini-towers and a KVM switch. I'd much rather > > run these other machines as virtual machines under FreeBSD. Can > > anyone recommend virtualizing software for FreeBSD? I don't mind > > having to pay, as long as it really works. > > I have not used it, but it claims to support FreeBSD as the host: > > http://www.serenityvirtual.com/ > > I have had a good relationship with the company that is behind the > product. I just haven't used that particular product, especially now > that my primary workstation is a PowerBook. Note that SVISTA doesn't (currently) support 5-stable, or indeed anything past 4.x. There have been questions asked about that in the fora but they have gone unanswered, last I checked. I bought it for 4.x and it worked fine. Better in some ways than qemu, although in other ways it was not as good (qemu seems to have better display support, while SVISTA's networking is vastly better). Since I've gone to 5-stable, though, qemu is my only real alternative. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:45:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A34AE16A4CE for ; Tue, 12 Apr 2005 16:45:40 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3481D43D1F for ; Tue, 12 Apr 2005 16:45:39 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3CGja3Z095750; Tue, 12 Apr 2005 11:45:36 -0500 (CDT) (envelope-from dan) Date: Tue, 12 Apr 2005 11:45:36 -0500 From: Dan Nelson To: Nick Barnes Message-ID: <20050412164536.GB4842@dan.emsphone.com> References: <20050412142640.GB1570@stack.nl> <51621.1113318561@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51621.1113318561@thrush.ravenbrook.com> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: Marc Olzheim cc: Vivek Khera cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:45:40 -0000 In the last episode (Apr 12), Nick Barnes said: > This is the well-known problem with my fantasy world in which the OS > doesn't overcommit any resources. All those programs are broken, but > it's too costly to fix them. If overcommit had been resisted more > effectively in the first place, those programs would have been > written properly. Another issue is things like shared libraries; without overcommit you need to reserve the file size * the number of processes mapping it, since you can't guarantee they won't touch every COW page handed to them. I think you can design a shlib scheme where you can map the libs RO; not sure if you would take a performance hit or if there are other considerations. There's a similar problem when large processes want to fork+exec something; for a fraction of a second you need to reserve 2x the process's space until the exec frees it. vfork solves that problem, at the expense of blocking the parent until the child's process is loaded. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:52:12 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD7A516A4F0 for ; Tue, 12 Apr 2005 16:52:12 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7469043D46 for ; Tue, 12 Apr 2005 16:52:12 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3CGq1X7032454; Tue, 12 Apr 2005 09:52:01 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3CGq18R032452; Tue, 12 Apr 2005 09:52:01 -0700 Date: Tue, 12 Apr 2005 09:52:01 -0700 From: Brooks Davis To: Robert Backhaus Message-ID: <20050412165201.GB18471@odin.ac.hmc.edu> References: <425B86B4.9030203@demax.sk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Jan Sebosik cc: freebsd-stable@freebsd.org Subject: Re: Package managment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:52:12 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 10:45:11PM +1000, Robert Backhaus wrote: > On Apr 12, 2005 6:28 PM, Jan Sebosik wrote: > > Hi > >=20 > > I`ve got one simple question: if i`ve built packages on my freebsd > > 5.3-RELEASE system, do I need to rebuilt them again for 5.4-RELEASE > > (after downloading && compiling from sources) ? > >=20 > > Best regards, > > Jan Sebosik > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > >=20 > With care, in many situations, you should be able to get away with it. > Problems occur with ports that contain kernel modules (ltmdm, > nvidia-driver). There have also been major changes within ports (new > gtk versions, and a gnome upgrade) which will make partial rebuilding > hazardous. >=20 > Most of us would recommend a general rebuild, for safety's sake. I certaintly would not. Unless you actually need to upgrade, there is no reason to rebuild between minor OS upgrades. If your programs stop working in that case, it's usually a bug. For that matter, most application will work if compiled on an older major version. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCW/ywXY6L6fI4GtQRAjuQAJ9U8IdyGAaqUqz4U+eg1RiJ2K2YOACfbh7v DOBBV+ol3XzmSd3ynHuu9N8= =TxtC -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 18:16:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2FFA16A4CE for ; Tue, 12 Apr 2005 18:16:58 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C1143D5E for ; Tue, 12 Apr 2005 18:16:57 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (pD9542FFB.dip.t-dialin.net [217.84.47.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 88D3F33788; Tue, 12 Apr 2005 20:16:38 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j3CIHWRT017619; Tue, 12 Apr 2005 20:17:33 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200504121817.j3CIHWRT017619@drjekyll.mkbuelow.net> To: Dan Nelson In-Reply-To: Message from Dan Nelson <20050412164536.GB4842@dan.emsphone.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Apr 2005 20:17:32 +0200 From: Matthias Buelow cc: Marc Olzheim cc: freebsd-stable@freebsd.org cc: Vivek Khera Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 18:16:58 -0000 Dan Nelson writes: >Another issue is things like shared libraries; without overcommit you >need to reserve the file size * the number of processes mapping it, >since you can't guarantee they won't touch every COW page handed to >them. I think you can design a shlib scheme where you can map the libs >RO; not sure if you would take a performance hit or if there are other >considerations. There's a similar problem when large processes want to >fork+exec something; for a fraction of a second you need to reserve 2x >the process's space until the exec frees it. vfork solves that >problem, at the expense of blocking the parent until the child's >process is loaded. Is that really problematic these days, with huge disk sizes? I mean, a couple GB swap don't really hurt anyone these days when you've got disk sizes around 250GB. Especially when you gain a lot more reliable operation through this. And maybe one could make overcommitting configurable, so that all scenarios are provided for. I for one would happily add some more swap space if I could get the behaviour that the OS doesn't go politician and promise all and everything which it then cannot deliver. Overcommitting made sense in the early 90ies, when you had a large address space (4GB) and relatively small disks (~1GB). I'm not sure it makes much sense anymore, it's a typical kludge. This stuff has been discussed in the past. It'll probably continue to be an issue, until it has been resolved satisfactorily (i.e., both the overcommitters and reliable-VMers can have their way). mkb. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 18:30:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF1B16A4CE for ; Tue, 12 Apr 2005 18:30:06 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D3D243D68 for ; Tue, 12 Apr 2005 18:30:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3CIXBf1039248; Tue, 12 Apr 2005 12:33:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425C12E3.5050205@samsco.org> Date: Tue, 12 Apr 2005 12:26:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Sze References: <4257F20C.70004@samsco.org> <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> <425A0BB2.10704@samsco.org> <6.2.1.2.2.20050411234713.069afb28@mail.distrust.net> In-Reply-To: <6.2.1.2.2.20050411234713.069afb28@mail.distrust.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 18:30:06 -0000 David Sze wrote: > At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All: > >> Making a driver PAE-ified means either teaching it to do 64-bit >> scatter-gather (assuming that the peripheral hardware can do this >> and that it's documented), or teaching the driver to correctly handle >> EINPROGRESS from bus_dmamap_load() along with using the proper busdma >> tag limits. The strategy I took with 6.x/5.x was the second one since >> I didn't have good IPS docs in front of me and I wanted it follow the >> APIs correctly. I did test it with 8GB of memory and it performed >> correctly under load. I haven't taken a close enough look at your >> MFC patch to say for sure if it's correct or not. I'm not sure if >> I'll have time to take another look in the next few days, unfortunately. >> Is there any chance you could test 5.x/6.0 under load with PAE just to >> validate the assertion that it works correctly there? > > > I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE, and > SMP-PAE kernels (the last one is just PAE with "options SMP"). > > To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz > (non-E64MT), ServeRAID-7K. > > GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE paniced > reproducibly doing the same. The DDB stack trace doesn't appear to be > anywhere near the IPS driver though, so I'm way out of my league. > > Darnit, hard to say if this is an existing bug in 5.4 or if it's a bug/corruption in ips. Can you re-run with PAE disabled? Would you be willing to put the Giant lock back on top of the driver? This would mean modifying the call to bus_intr_config(), adding the D_GIANTNEEDED flag to the disk structure in disk_create(), and switching the mutex argument in bus_dma_tag_create() for the sg_dmatag tag. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 19:02:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B3D16A4CE for ; Tue, 12 Apr 2005 19:02:45 +0000 (GMT) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id D870F43D39 for ; Tue, 12 Apr 2005 19:02:44 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 397EFB850; Tue, 12 Apr 2005 15:02:44 -0400 (EDT) In-Reply-To: <20050413000852.9F7C.NCISOFT@163.com> References: <20050331232901.BC1B.NCISOFT@163.com> <424C1F3C.4020208@bmby.com> <20050413000852.9F7C.NCISOFT@163.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30--266107039; protocol="application/pkcs7-signature" Message-Id: From: Vivek Khera Date: Tue, 12 Apr 2005 15:02:42 -0400 To: Young Lee X-Mailer: Apple Mail (2.619.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.3 SMP freezes with MySQL 4.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:02:45 -0000 --Apple-Mail-30--266107039 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 12, 2005, at 12:23 PM, Young Lee wrote: > I had repeated the panic by reset debug.mpsafenet from 0 to 1, > after that, the system automatically reboot after several hours, > and if debug.mpsafenet was set to 0, the system is stable. > > so i guess this is a tcp stack or NIC driver SMP thread-safe issue, > normally my server got over 1000 interrupts/s on bge, I have plan > to replace the onboard bge NIC to fxp and set debug.mpsafenet > to 1 to see what will happen this week. > I just did the exact same thing: disable motherboard bge in preference to em (intel) on a PCI card, and have had 100% stable for the last 6 days. Normally every night during heavy network backup and database reporting the bge ports would either be reset after watchdog timeout, or the whole system would freeze with nothing logged to console, screen, or BIOS... so going 6 days without any events leads me to point a big hairy finger at bge driver. Even with mpsafenet=0, I was having these timeouts and lockups, and bad performance thrown in. :-( I run with mpsafenet default and the em ethernet driver. Be sure to disable the onboard bge in your BIOS. I'm on a dual opteron Tyan S2881 motherboard, for what that's worth. FreeBSD 5.4-STABLE from April 4 is my OS. My guess is with the intel NIC you will find yourself much more stable. On my lesser loaded machines the bge driver holds up ok. Vivek Khera, Ph.D. +1-301-869-4449 x806 --Apple-Mail-30--266107039-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 19:18:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A068416A4CE for ; Tue, 12 Apr 2005 19:18:35 +0000 (GMT) Received: from mail2out.barnet.com.au (mail2out.barnet.com.au [202.83.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA8AD43D46 for ; Tue, 12 Apr 2005 19:18:34 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mail2out.barnet.com.au (Postfix, from userid 27) id 2E29B7074B7; Wed, 13 Apr 2005 05:18:33 +1000 (EST) X-Viruscan-Id: <425C1F09000161FFD5F9FD@BarNet> Received: from mail2-auth.barnet.com.au (mail2.barnet.com.au [202.83.176.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id B3C217074B1; Wed, 13 Apr 2005 05:18:32 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 307A67074AE; Wed, 13 Apr 2005 05:18:32 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id CCBDC617E; Wed, 13 Apr 2005 05:18:30 +1000 (EST) Date: Wed, 13 Apr 2005 05:18:30 +1000 From: Edwin Groothuis To: Scott Long Message-ID: <20050412191830.GF1209@k7.mavetju> Mail-Followup-To: Edwin Groothuis , Scott Long , freebsd-stable@freebsd.org References: <20050412130727.GE1209@k7.mavetju> <425BF587.5070904@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425BF587.5070904@samsco.org> User-Agent: Mutt/1.5.6i cc: freebsd-stable@freebsd.org Subject: Re: Adaptec 1210 weird behaviour X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:18:35 -0000 On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote: > Edwin Groothuis wrote: > >The Adaptec 1210 is a serial ATA RAID0/1 controller. > > > >When the two disks are configured as RAID1, FreeBSD still sees two > >harddisks instead of one. > > > >This is with 5.3. Scary :-) > >Will try this weekend with 5.4 > > The 1210 is not a real RAID controller, it's a SATA controller with an > Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to > do the RAID operations after that. The new ATA driver in 6-current Euhm. Oh. Software RAID? A la WinModems? But then I don't understand that it gets away with advertising it as a RAID0/1 controller... Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 19:21:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0610A16A4CE for ; Tue, 12 Apr 2005 19:21:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D16F43D60 for ; Tue, 12 Apr 2005 19:21:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3CJOgtv039541; Tue, 12 Apr 2005 13:24:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425C1EF6.4000608@samsco.org> Date: Tue, 12 Apr 2005 13:18:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edwin Groothuis References: <20050412130727.GE1209@k7.mavetju> <425BF587.5070904@samsco.org> <20050412191830.GF1209@k7.mavetju> In-Reply-To: <20050412191830.GF1209@k7.mavetju> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-stable@freebsd.org Subject: Re: Adaptec 1210 weird behaviour X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:21:26 -0000 Edwin Groothuis wrote: > On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote: > >>Edwin Groothuis wrote: >> >>>The Adaptec 1210 is a serial ATA RAID0/1 controller. >>> >>>When the two disks are configured as RAID1, FreeBSD still sees two >>>harddisks instead of one. >>> >>>This is with 5.3. Scary :-) >>>Will try this weekend with 5.4 >> >>The 1210 is not a real RAID controller, it's a SATA controller with an >>Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to >>do the RAID operations after that. The new ATA driver in 6-current > > > Euhm. Oh. Software RAID? A la WinModems? More or less. It's quite common these days, with lots of motherboard makers getting into the game and licensing software raid stacks for their onboard SATA controllers. > > But then I don't understand that it gets away with advertising it > as a RAID0/1 controller... If you don't understand then you should be glad that you didn't choose Marketting as a profession ;-) Scott From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 19:23:25 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A91A016A4CE for ; Tue, 12 Apr 2005 19:23:25 +0000 (GMT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 382E943D2D for ; Tue, 12 Apr 2005 19:23:25 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 12 Apr 2005 19:23:24 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id E445B612B; Tue, 12 Apr 2005 14:23:22 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06775-08; Tue, 12 Apr 2005 14:23:21 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id 5DCF86109; Tue, 12 Apr 2005 14:23:21 -0500 (CDT) Message-ID: <425C2029.2010109@alumni.rice.edu> Date: Tue, 12 Apr 2005 14:23:21 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edwin Groothuis References: <20050412130727.GE1209@k7.mavetju> <425BF587.5070904@samsco.org> <20050412191830.GF1209@k7.mavetju> In-Reply-To: <20050412191830.GF1209@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: freebsd-stable@freebsd.org Subject: Re: Adaptec 1210 weird behaviour X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:23:25 -0000 On 4/12/2005 2:18 PM, Edwin Groothuis wrote: > On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote: >>Edwin Groothuis wrote: >>>The Adaptec 1210 is a serial ATA RAID0/1 controller. >>> >>>When the two disks are configured as RAID1, FreeBSD still sees two >>>harddisks instead of one. >>> >>>This is with 5.3. Scary :-) >>>Will try this weekend with 5.4 >> >>The 1210 is not a real RAID controller, it's a SATA controller with an >>Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to >>do the RAID operations after that. The new ATA driver in 6-current > > Euhm. Oh. Software RAID? A la WinModems? > > But then I don't understand that it gets away with advertising it > as a RAID0/1 controller... The RAID functionality is implemented in the driver, so the "product" as a whole is a RAID0/1 controller. This is very common; in fact, most products under $150-200 are like this... Jon From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 19:37:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FCD116A4CE for ; Tue, 12 Apr 2005 19:37:08 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E485243D5E for ; Tue, 12 Apr 2005 19:37:07 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3CJalHc036643; Tue, 12 Apr 2005 12:36:51 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504121936.j3CJalHc036643@gw.catspoiler.org> Date: Tue, 12 Apr 2005 12:36:47 -0700 (PDT) From: Don Lewis To: dnelson@allantgroup.com In-Reply-To: <20050412164536.GB4842@dan.emsphone.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: marcolz@stack.nl cc: freebsd-stable@FreeBSD.org cc: vivek@khera.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 19:37:08 -0000 On 12 Apr, Dan Nelson wrote: > In the last episode (Apr 12), Nick Barnes said: >> This is the well-known problem with my fantasy world in which the OS >> doesn't overcommit any resources. All those programs are broken, but >> it's too costly to fix them. If overcommit had been resisted more >> effectively in the first place, those programs would have been >> written properly. > > Another issue is things like shared libraries; without overcommit you > need to reserve the file size * the number of processes mapping it, > since you can't guarantee they won't touch every COW page handed to > them. I think you can design a shlib scheme where you can map the libs > RO; not sure if you would take a performance hit or if there are other > considerations. The data and bss sizes in most shared libraries are small, so I don't think that is much of an issue. The text pages are more of a problem because of the need to do relocation fixups. It would be nice to mark the text pages read only after relocation and/or prelink the binaries and shared libraries like recent versions of Linux do. Text page modifications to set debugger breakpoints would also have to be handled. A bigger problem is the default stack size of 64 MB per process. That quickly adds up to a lot of reserved swap space. One way of handling that might be an ELF header field that could limit the stack size to a smaller value for most binaries. I don't happen to remember the default SunOS 4.x stack size, but I suspect that SunOS 4.x overcommited stack space on the assumption that most processes wouldn't use anything close to the limit. > There's a similar problem when large processes want to > fork+exec something; for a fraction of a second you need to reserve 2x > the process's space until the exec frees it. vfork solves that > problem, at the expense of blocking the parent until the child's > process is loaded. The fork() case was a common failure mode that I ran into back when I was using SunOS 4. It was usually a fairly benign problem because the fork() was triggered by an interactive command, and when it failed I could usually recover from the problem by exiting some other process or by freeing up some swap space by removing files from the swap-backed /tmp directory. In an earlier life, I had the displeasure of trying to run large processes (~3x RAM) on a small-memory machine without either COW or vfork(). Actually, fork() was required in at least some of the cases because the process wanted to make a snapshot of itself to do processing on its in-memory data in the background. The machine would page like crazy and swap other processes in and out for about an hour each time the large process forked. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 21:33:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F334416A4CE for ; Tue, 12 Apr 2005 21:33:50 +0000 (GMT) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0808D43D46 for ; Tue, 12 Apr 2005 21:33:49 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) j3CLXdU7079461; Tue, 12 Apr 2005 22:33:39 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) j3CLXbHs052803; Tue, 12 Apr 2005 22:33:37 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Matthias Buelow In-Reply-To: <200504121817.j3CIHWRT017619@drjekyll.mkbuelow.net> from Matthias Buelow of "Tue, 12 Apr 2005 20:17:32 +0200" Date: Tue, 12 Apr 2005 22:33:37 +0100 Message-ID: <52802.1113341617@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Marc Olzheim cc: Vivek Khera cc: Dan Nelson cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 21:33:51 -0000 At 2005-04-12 18:17:32+0000, Matthias Buelow writes: > This stuff has been discussed in the past. Indeed. For a couple of examples from the days before BSD systems got overcommit, see these threads from 1990 and 1991: Nick B From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 21:34:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A58CC16A4CE for ; Tue, 12 Apr 2005 21:34:09 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2030143D62 for ; Tue, 12 Apr 2005 21:34:09 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so2006169wri for ; Tue, 12 Apr 2005 14:34:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=W4bhNK9w1rp6f/ER0l9oDLWZLBuv9DDFJzzVt3xCYC5p+Qos/aRY0YGIqwqIGIni62NpA8vqsBU+b4xaZ/Ajam07lfejE3oJCd/fmGWbvA/FJPsiAtXDRWtAqbMAcL1THwnsoTOhVz8WNcn/5Ot0uIQaJGHxdFqI9lsvoBbfOgg= Received: by 10.54.39.34 with SMTP id m34mr1483151wrm; Tue, 12 Apr 2005 14:34:07 -0700 (PDT) Received: by 10.54.56.4 with HTTP; Tue, 12 Apr 2005 14:34:07 -0700 (PDT) Message-ID: <59e2ee81050412143459b7c679@mail.gmail.com> Date: Tue, 12 Apr 2005 23:34:07 +0200 From: Rostislav Krasny To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: strange atacontrol output in 5.4-RC1 and 5.4-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rostislav Krasny List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 21:34:09 -0000 Hi, I have two i386 computers with close configuration of ATA disks: mercury# atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 4 Slave: no device present ATA channel 1: Master: ad2 ATA/ATAPI revision 3 Slave: acd0 ATA/ATAPI revision 0 vega# atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 4 Slave: no device present ATA channel 1: Master: ad2 ATA/ATAPI revision 0 Slave: ad3 ATA/ATAPI revision 2 Mercury is Intel SE440BX-2 motherboard based computer with FreeBSD 5.4-RC2. Vega is Intel 430TX chipset based computer with FreeBSD 5.4-RC1. When I run ' atacontrol cap 0 0' I get the same last part of the output: Feature Support Enable Value Vendor write cache yes yes read ahead yes yes dma queued no no 0/0x00 SMART yes yes microcode download no no security no yes power management yes yes advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 How could the security feature be not supported and enabled at the same time? From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 22:06:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F2C016A4CE for ; Tue, 12 Apr 2005 22:06:24 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CD843D4C for ; Tue, 12 Apr 2005 22:06:24 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (pD9542FFB.dip.t-dialin.net [217.84.47.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 8EDC533A01; Wed, 13 Apr 2005 00:06:18 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j3CM7BE7018595; Wed, 13 Apr 2005 00:07:11 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200504122207.j3CM7BE7018595@drjekyll.mkbuelow.net> To: Nick Barnes In-Reply-To: Message from Nick Barnes <52802.1113341617@thrush.ravenbrook.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Apr 2005 00:07:11 +0200 From: Matthias Buelow cc: Marc Olzheim cc: Vivek Khera cc: Dan Nelson cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 22:06:24 -0000 Nick Barnes writes: >> This stuff has been discussed in the past. >Indeed. For a couple of examples from the days before BSD systems got >overcommit, see these threads from 1990 and 1991: > >b658465/4c590978f1001507?q=overcommit&rnum=14#4c590978f1001507> > >6d30eb1/e8c30f78c44a3f62?q=overcommit&rnum=12#e8c30f78c44a3f62> Apparently, it can be turned off on AIX, quoting from http://tinyurl.com/4epc8: ``If the PSALLOC environment variable is set to early, then every program started in that environment from that point on, but not including currently running processes, runs in the early allocation environment. In the early allocation environment, interfaces such as the malloc subroutine and the brk subroutine will fail if sufficient paging space cannot be reserved when the request is made. Processes run in the early allocation environment mode are not sent the SIGKILL signal if a low paging space condition occur.'' Googling showed that on Linux 2.6, overcommit can be disabled globally through the vm.overcommit_memory sysctl. I hope that some day some mechanism to solve that problem will be available in FreeBSD aswell. mkb. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 02:59:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CB2F16A4D3 for ; Wed, 13 Apr 2005 02:59:08 +0000 (GMT) Received: from mx-itb.geoph.ITB.ac.id (mx7.ITB.ac.id [167.205.30.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A059F43D46 for ; Wed, 13 Apr 2005 02:59:05 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from antivirus.itb.ac.id (antivirus.ITB.ac.id [167.205.108.137]) by mx-itb.geoph.ITB.ac.id (Postfix) with SMTP id 4E9DC20A86 for ; Wed, 13 Apr 2005 10:15:00 +0700 (WIT) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx-itb.geoph.ITB.ac.id (Postfix) with ESMTP id 30E2A20A83 for ; Wed, 13 Apr 2005 10:15:00 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id 31F81114E4; Wed, 13 Apr 2005 09:58:55 +0700 (WIT) Date: Wed, 13 Apr 2005 09:58:55 +0700 From: Dikshie To: freebsd-stable@freebsd.org Message-ID: <20050413025855.GA25698@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 5.4-STABLE i386) X-Uptime: 9:56AM up 4 days, 20:45, 1 user, load averages: 0.12, 0.12, 0.09 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D Subject: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 02:59:08 -0000 dear all, I would like to buy SCSI card which must: - support Ultra 320 - support RAID 0,1,5, and 1/0 any recommendation for FreeBSD-5.x ? thanks ! -dikshie- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 03:14:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FEFE16A4CE for ; Wed, 13 Apr 2005 03:14:58 +0000 (GMT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 656EA43D2D for ; Wed, 13 Apr 2005 03:14:57 +0000 (GMT) (envelope-from mi@corbulon.video-collage.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j3D3Eq9v014550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Apr 2005 23:14:55 -0400 (EDT) (envelope-from mi@corbulon.video-collage.com) Received: from corbulon.video-collage.com (mi@localhost.video-collage.com [127.0.0.1])j3D3Ekpb043748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Apr 2005 23:14:46 -0400 (EDT) (envelope-from mi@corbulon.video-collage.com) Received: (from mi@localhost) by corbulon.video-collage.com (8.13.1/8.13.1/Submit) id j3D3EjrT043747 for stable@FreeBSD.org; Tue, 12 Apr 2005 23:14:45 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <200504130314.j3D3EjrT043747@corbulon.video-collage.com> To: stable@FreeBSD.org Date: Tue, 12 Apr 2005 23:14:45 -0400 (EDT) X-Mailer: ELM [version 2.5 PL7] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.43715.1113362085--%" X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Subject: reliable "panic: isa_dmastart: bad bounce buffer" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 03:14:58 -0000 --%--multipart-mixed-boundary-1.43715.1113362085--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello! Whenever I try to mount a floppy disk: mount -t msdosfs /dev/fd0 /mnt I get: panic: isa_dmastart: bad bounce buffer The OS is FreeBSD-5.4-STABLE from last night, amd64. dmesg attached. DR-DOS boots perfectly fine from this floppy... Any ideas? Thanks! -mi --%--multipart-mixed-boundary-1.43715.1113362085--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: ASCII English text Content-Disposition: attachment; filename="blue-dmesg.txt" Copyright (c) 1992-2005 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.4-STABLE #0: Tue Apr 12 22:42:27 EDT 2005 root@blue.virtual-estates.net:/var/obj/var/src/sys/SILVER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 246 (2004.56-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 2147418112 (2047 MB) avail memory = 2057740288 (1962 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xe0000000-0xe7ffffff,0xfd000000-0xfdffffff irq 16 at device 0.0 on pci1 pcib2: at device 6.0 on pci0 pci2: on pcib2 ohci0: mem 0xfe6fd000-0xfe6fdfff irq 19 at device 0.0 on pci2 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: 3 ports with 3 removable, self powered ohci1: mem 0xfe6fe000-0xfe6fefff irq 19 at device 0.1 on pci2 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ahc0: port 0x9800-0x98ff mem 0xfe6ff000-0xfe6fffff irq 16 at device 4.0 on pci2 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fwohci0: mem 0xfe6f8000-0xfe6fbfff,0xfe6fc800-0xfe6fcfff irq 18 at device 6.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:f0:12 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:00:f0:12 fwe0: Ethernet address: 02:00:00:00:f0:12 fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ohci2: mem 0xfe6f6000-0xfe6f6fff irq 19 at device 7.0 on pci2 usb2: OHCI version 1.0 usb2: on ohci2 usb2: USB revision 1.0 uhub2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 3 ports with 3 removable, self powered ohci3: mem 0xfe6f7000-0xfe6f7fff irq 16 at device 7.1 on pci2 usb3: OHCI version 1.0 usb3: on ohci3 usb3: USB revision 1.0 uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci2: at device 7.2 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcm0: port 0xcc00-0xcc3f,0xc800-0xc8ff irq 17 at device 7.5 on pci0 pcm0: pcib3: at device 10.0 on pci0 pci3: on pcib3 skc0: port 0xa800-0xa8ff mem 0xfe8fc000-0xfe8fffff irq 27 at device 3.0 on pci3 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:00:00:04:a8:97 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto atapci1: port 0xa000-0xa00f,0xa080-0xa083,0xa400-0xa407,0xa480-0xa483,0xac00-0xac07 mem 0xfe8fbc00-0xfe8fbfff irq 25 at device 5.0 on pci3 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 ata4: channel #2 on atapci1 ata5: channel #3 on atapci1 pci0: at device 10.1 (no driver attached) pcib4: at device 11.0 on pci0 pci4: on pcib4 ciss0: port 0xb800-0xb8ff mem 0xfea80000-0xfeabffff,0xfeafe000-0xfeafffff irq 29 at device 1.0 on pci4 pci0: at device 11.1 (no driver attached) acpi_button0: on acpi0 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 Generic PS/2 mouse, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 isa_dmainit(2, 40960) failed fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xdb000-0xdefff,0xd6800-0xdafff,0xce800-0xd67ff,0xc0000-0xce7ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2004556009 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDR at ata1-master PIO4 Waiting 8 seconds for SCSI devices to settle Interrupt storm detected on "irq17: pcm0"; throttling interrupt source da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69419MB (142171680 512 byte sectors: 255H 32S/T 17423C) cd0 at ahc0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 8.333MB/s transfers (8.333MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/da0s1a WARNING: /var was not properly dismounted --%--multipart-mixed-boundary-1.43715.1113362085--%-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 03:32:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF7B216A4CE for ; Wed, 13 Apr 2005 03:32:48 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A0B43D48 for ; Wed, 13 Apr 2005 03:32:48 +0000 (GMT) (envelope-from marchenko@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so27156wri for ; Tue, 12 Apr 2005 20:32:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c1SxULZPbWSoGePKvUCw0/L0QQl+RQo3eOwbGgzeqayG/nST0Vy9hZ/l39nNUms1ynMNOiUEKB1g/JHymUk5UD2zp/vwfxKQU8yDYvXvVpLt3Oa/w+Yd/eqoJ8FQSd6TRz/FecnNeGEyLxC0F+FFXB14EpmgNJoGp9HtMYhlydQ= Received: by 10.54.49.5 with SMTP id w5mr141718wrw; Tue, 12 Apr 2005 20:32:47 -0700 (PDT) Received: by 10.54.45.1 with HTTP; Tue, 12 Apr 2005 20:32:47 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 23:32:47 -0400 From: Vlad To: Dikshie In-Reply-To: <20050413025855.GA25698@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050413025855.GA25698@ppk.itb.ac.id> cc: freebsd-stable@freebsd.org Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 03:32:48 -0000 Dikshie, giving the list the idea of how powerful should it be OR how much money do you want to spend on it will help you get the answer :) lsi logic's megaraid 320-2 works pretty good for me=20 On 4/12/05, Dikshie wrote: > dear all, > I would like to buy SCSI card which must: > - support Ultra 320 > - support RAID 0,1,5, and 1/0 > any recommendation for FreeBSD-5.x ? >=20 > thanks ! > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 03:54:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD10716A4CE for ; Wed, 13 Apr 2005 03:54:03 +0000 (GMT) Received: from mx-itb.geoph.ITB.ac.id (mx7.ITB.ac.id [167.205.30.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE92043D1F for ; Wed, 13 Apr 2005 03:54:02 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from antivirus.itb.ac.id (antivirus.ITB.ac.id [167.205.108.137]) by mx-itb.geoph.ITB.ac.id (Postfix) with SMTP id 6B8F020CB6 for ; Wed, 13 Apr 2005 11:10:04 +0700 (WIT) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx-itb.geoph.ITB.ac.id (Postfix) with ESMTP id 571EC20C4B for ; Wed, 13 Apr 2005 11:10:04 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id 5E668114E5; Wed, 13 Apr 2005 10:53:59 +0700 (WIT) Date: Wed, 13 Apr 2005 10:53:59 +0700 From: Dikshie To: Vlad Message-ID: <20050413035359.GA22196@ppk.itb.ac.id> References: <20050413025855.GA25698@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 5.4-STABLE i386) X-Uptime: 10:44AM up 4 days, 21:33, 1 user, load averages: 1.88, 1.06, 0.50 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D cc: freebsd-stable@freebsd.org Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 03:54:03 -0000 Hi Vlad, thank you for your reply. Vlad (marchenko@gmail.com) wrote: > giving the list the idea of how powerful should it be OR how much > money do you want to spend on it will help you get the answer :) no money constraint, my campus will buy some :-) regards, -dikshie- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 03:57:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0716116A4CE for ; Wed, 13 Apr 2005 03:57:04 +0000 (GMT) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945E743D49 for ; Wed, 13 Apr 2005 03:57:03 +0000 (GMT) (envelope-from dsze@alumni.uwaterloo.ca) Received: from eeyore.distrust.net (CPE00a0c978120d-CM00122570472e.cpe.net.cable.rogers.com [70.24.0.197]) (authenticated bits=0) by mail.distrust.net (8.13.1/8.12.11) with ESMTP id j3D3uwL1050903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2005 22:57:01 -0500 (CDT) (envelope-from dsze@alumni.uwaterloo.ca) Message-Id: <6.2.1.2.2.20050412234622.05a6daf8@mail.distrust.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Apr 2005 23:57:17 -0400 To: Scott Long From: David Sze In-Reply-To: <425C12E3.5050205@samsco.org> References: <4257F20C.70004@samsco.org> <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> <425A0BB2.10704@samsco.org> <6.2.1.2.2.20050411234713.069afb28@mail.distrust.net> <425C12E3.5050205@samsco.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_695434812==_" X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 17:53:21 2005 on mail.distrust.net X-Virus-Status: Clean cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 03:57:04 -0000 --=====================_695434812==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:26 PM 12/04/2005 -0600, Scott Long wrote this to All: >David Sze wrote: >>At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All: >> >>>Making a driver PAE-ified means either teaching it to do 64-bit >>>scatter-gather (assuming that the peripheral hardware can do this >>>and that it's documented), or teaching the driver to correctly handle >>>EINPROGRESS from bus_dmamap_load() along with using the proper busdma >>>tag limits. The strategy I took with 6.x/5.x was the second one since >>>I didn't have good IPS docs in front of me and I wanted it follow the >>>APIs correctly. I did test it with 8GB of memory and it performed >>>correctly under load. I haven't taken a close enough look at your >>>MFC patch to say for sure if it's correct or not. I'm not sure if >>>I'll have time to take another look in the next few days, unfortunately. >>>Is there any chance you could test 5.x/6.0 under load with PAE just to >>>validate the assertion that it works correctly there? >> >>I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE, and >>SMP-PAE kernels (the last one is just PAE with "options SMP"). >>To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz (non-E64MT), >>ServeRAID-7K. >>GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE paniced >>reproducibly doing the same. The DDB stack trace doesn't appear to be >>anywhere near the IPS driver though, so I'm way out of my league. > >Darnit, hard to say if this is an existing bug in 5.4 or if it's a >bug/corruption in ips.Can you re-run with PAE disabled? Works fine with PAE disabled (or at least I couldn't get it to panic), both UP and SMP kernels. >Would you be >willing to put the Giant lock back on top of the driver? This would >mean modifying the call to bus_intr_config(), adding the D_GIANTNEEDED >flag to the disk structure in disk_create(), and switching the mutex >argument in bus_dma_tag_create() for the sg_dmatag tag. I put Giant back in as you described (patch attached), but it still panic'ed with PAE enabled, both UP and SMP kernels. The stack trace was very similar; the fault address (0x24) and the top three stack frames were the same as without Giant: propagate_priority turnstile_wait _mtx_lock_sleep At this point I no longer have access to the hardware, the customer wanted his servers back. They're going into the datacenter with RELENG_4 (w/IPS stability patch), without PAE (so the top ~900MB of his 4GB RAM is lost to PCI-X address space). --=====================_695434812==_ Content-Type: application/octet-stream; name="ips.RELENG_5_4.giant.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ips.RELENG_5_4.giant.patch" ZGlmZiAtdSBzeXMvZGV2L2lwcy5vcmlnL2lwcy5jIHN5cy9kZXYvaXBzL2lwcy5jCi0tLSBzeXMv ZGV2L2lwcy5vcmlnL2lwcy5jCVN1biBKYW4gMzAgMTQ6NDE6MTIgMjAwNQorKysgc3lzL2Rldi9p cHMvaXBzLmMJVHVlIEFwciAxMiAxMjo1OTozMSAyMDA1CkBAIC0zNDksOCArMzQ5LDggQEAKIAkJ CQkvKiBtYXhzZWdzaXplKi8JSVBTX0NPTU1BTkRfTEVOICsgCiAJCQkJCQkgICAgSVBTX01BWF9T R19MRU4sCiAJCQkJLyogZmxhZ3MgICAgICovCTAsCi0JCQkJLyogbG9ja2Z1bmMgICovIE5VTEws Ci0JCQkJLyogbG9ja2FyZyAgICovIE5VTEwsCisJCQkJLyogbG9ja2Z1bmMgICovIGJ1c2RtYV9s b2NrX211dGV4LAorCQkJCS8qIGxvY2thcmcgICAqLyAmR2lhbnQsCiAJCQkJJnNjLT5jb21tYW5k X2RtYXRhZykgIT0gMCkgewogICAgICAgICAgICAgICAgIGRldmljZV9wcmludGYoc2MtPmRldiwg ImNhbid0IGFsbG9jIGNvbW1hbmQgZG1hIHRhZ1xuIik7CiAJCWdvdG8gZXJyb3I7CkBAIC0zNjcs NyArMzY3LDcgQEAKIAkJCQkvKiBtYXhzZWdzaXplKi8JSVBTX01BWF9JT0JVRl9TSVpFLAogCQkJ CS8qIGZsYWdzICAgICAqLwkwLAogCQkJCS8qIGxvY2tmdW5jICAqLyBidXNkbWFfbG9ja19tdXRl eCwKLQkJCQkvKiBsb2NrYXJnICAgKi8gJnNjLT5xdWV1ZV9tdHgsCisJCQkJLyogbG9ja2FyZyAg ICovICZHaWFudCwKIAkJCQkmc2MtPnNnX2RtYXRhZykgIT0gMCkgewogCQlkZXZpY2VfcHJpbnRm KHNjLT5kZXYsICJjYW4ndCBhbGxvYyBTRyBkbWEgdGFnXG4iKTsKIAkJZ290byBlcnJvcjsKQEAg LTU4NCw4ICs1ODQsOCBAQAogCQkJCS8qIG51bXNlZ3MgICAqLwkxLAogCQkJCS8qIG1heHNlZ3Np emUqLwlzaXplb2YoaXBzX2NvcHBlcl9xdWV1ZV90KSwKIAkJCQkvKiBmbGFncyAgICAgKi8JMCwK LQkJCQkvKiBsb2NrZnVuYyAgKi8gTlVMTCwKLQkJCQkvKiBsb2NrYXJnICAgKi8gTlVMTCwKKwkJ CQkvKiBsb2NrZnVuYyAgKi8gYnVzZG1hX2xvY2tfbXV0ZXgsCisJCQkJLyogbG9ja2FyZyAgICov ICZHaWFudCwKIAkJCQkmZG1hdGFnKSAhPSAwKSB7CiAgICAgICAgICAgICAgICAgZGV2aWNlX3By aW50ZihzYy0+ZGV2LCAiY2FuJ3QgYWxsb2MgZG1hIHRhZyBmb3Igc3RhdHVlIHF1ZXVlXG4iKTsK IAkJZXJyb3IgPSBFTk9NRU07CmRpZmYgLXUgc3lzL2Rldi9pcHMub3JpZy9pcHNfY29tbWFuZHMu YyBzeXMvZGV2L2lwcy9pcHNfY29tbWFuZHMuYwotLS0gc3lzL2Rldi9pcHMub3JpZy9pcHNfY29t bWFuZHMuYwlTdW4gSmFuIDMwIDE0OjQxOjEyIDIwMDUKKysrIHN5cy9kZXYvaXBzL2lwc19jb21t YW5kcy5jCVR1ZSBBcHIgMTIgMTM6MDI6MTkgMjAwNQpAQCAtMjA5LDggKzIwOSw4IEBACiAJCQkJ LyogbnVtc2VncyAgICovCTEsCiAJCQkJLyogbWF4c2Vnc2l6ZSovCUlQU19BREFQVEVSX0lORk9f TEVOLAogCQkJCS8qIGZsYWdzICAgICAqLwkwLAotCQkJCS8qIGxvY2tmdW5jICAqLyBOVUxMLAot CQkJCS8qIGxvY2thcmcgICAqLyBOVUxMLAorCQkJCS8qIGxvY2tmdW5jICAqLyBidXNkbWFfbG9j a19tdXRleCwKKwkJCQkvKiBsb2NrYXJnICAgKi8gJkdpYW50LAogCQkJCSZjb21tYW5kLT5kYXRh X2RtYXRhZykgIT0gMCkgewogICAgICAgICAgICAgICAgIHByaW50ZigiaXBzOiBjYW4ndCBhbGxv YyBkbWEgdGFnIGZvciBhZGFwdGVyIHN0YXR1c1xuIik7CiAJCWVycm9yID0gRU5PTUVNOwpAQCAt MzA4LDggKzMwOCw4IEBACiAJCQkJLyogbnVtc2VncyAgICovCTEsCiAJCQkJLyogbWF4c2Vnc2l6 ZSovCUlQU19EUklWRV9JTkZPX0xFTiwKIAkJCQkvKiBmbGFncyAgICAgKi8JMCwKLQkJCQkvKiBs b2NrZnVuYyAgKi8gTlVMTCwKLQkJCQkvKiBsb2NrYXJnICAgKi8gTlVMTCwKKwkJCQkvKiBsb2Nr ZnVuYyAgKi8gYnVzZG1hX2xvY2tfbXV0ZXgsCisJCQkJLyogbG9ja2FyZyAgICovICZHaWFudCwK IAkJCQkmY29tbWFuZC0+ZGF0YV9kbWF0YWcpICE9IDApIHsKICAgICAgICAgICAgICAgICBwcmlu dGYoImlwczogY2FuJ3QgYWxsb2MgZG1hIHRhZyBmb3IgZHJpdmUgc3RhdHVzXG4iKTsKIAkJZXJy b3IgPSBFTk9NRU07CkBAIC01NDcsOCArNTQ3LDggQEAKIAkJCQkvKiBudW1zZWdzICAgKi8JMSwK IAkJCQkvKiBtYXhzZWdzaXplKi8JSVBTX05WUkFNX1BBR0VfU0laRSwKIAkJCQkvKiBmbGFncyAg ICAgKi8JMCwKLQkJCQkvKiBsb2NrZnVuYyAgKi8gTlVMTCwKLQkJCQkvKiBsb2NrYXJnICAgKi8g TlVMTCwKKwkJCQkvKiBsb2NrZnVuYyAgKi8gYnVzZG1hX2xvY2tfbXV0ZXgsCisJCQkJLyogbG9j a2FyZyAgICovICZHaWFudCwKIAkJCQkmY29tbWFuZC0+ZGF0YV9kbWF0YWcpICE9IDApIHsKICAg ICAgICAgICAgICAgICBwcmludGYoImlwczogY2FuJ3QgYWxsb2MgZG1hIHRhZyBmb3IgbnZyYW1c biIpOwogCQllcnJvciA9IEVOT01FTTsKZGlmZiAtdSBzeXMvZGV2L2lwcy5vcmlnL2lwc19kaXNr LmMgc3lzL2Rldi9pcHMvaXBzX2Rpc2suYwotLS0gc3lzL2Rldi9pcHMub3JpZy9pcHNfZGlzay5j CVN1biBKYW4gMzAgMTQ6NDE6MTIgMjAwNQorKysgc3lzL2Rldi9pcHMvaXBzX2Rpc2suYwlUdWUg QXByIDEyIDEzOjA0OjQ0IDIwMDUKQEAgLTE1NSw3ICsxNTUsNyBAQAogCWRzYy0+aXBzZF9kaXNr LT5kX3NlY3RvcnNpemUgPSBJUFNfQkxLU0laRTsKIAlkc2MtPmlwc2RfZGlzay0+ZF9tZWRpYXNp emUgPSAob2ZmX3QpdG90YWxzZWN0b3JzICogSVBTX0JMS1NJWkU7CiAJZHNjLT5pcHNkX2Rpc2st PmRfdW5pdCA9IGRzYy0+dW5pdDsKLQlkc2MtPmlwc2RfZGlzay0+ZF9mbGFncyA9IDA7CisJZHNj LT5pcHNkX2Rpc2stPmRfZmxhZ3MgPSBESVNLRkxBR19ORUVEU0dJQU5UOwogCWRpc2tfY3JlYXRl KGRzYy0+aXBzZF9kaXNrLCBESVNLX1ZFUlNJT04pOwogCiAJZGV2aWNlX3ByaW50ZihkZXYsICJM b2dpY2FsIERyaXZlICAoJWRNQilcbiIsCmRpZmYgLXUgc3lzL2Rldi9pcHMub3JpZy9pcHNfaW9j dGwuYyBzeXMvZGV2L2lwcy9pcHNfaW9jdGwuYwotLS0gc3lzL2Rldi9pcHMub3JpZy9pcHNfaW9j dGwuYwlTdW4gSmFuIDMwIDE0OjQxOjEyIDIwMDUKKysrIHN5cy9kZXYvaXBzL2lwc19pb2N0bC5j CVR1ZSBBcHIgMTIgMTM6MDI6MzYgMjAwNQpAQCAtOTksOCArOTksOCBAQAogCQkJLyogbnVtc2Vn cyAgICovCTEsCiAJCQkvKiBtYXhzZWdzaXplKi8JaW9jdGxfY21kLT5kYXRhc2l6ZSwKIAkJCS8q IGZsYWdzICAgICAqLwkwLAotCQkJLyogbG9ja2Z1bmMgICovIE5VTEwsCi0JCQkvKiBsb2NrYXJn ICAgKi8gTlVMTCwKKwkJCS8qIGxvY2tmdW5jICAqLyBidXNkbWFfbG9ja19tdXRleCwKKwkJCS8q IGxvY2thcmcgICAqLyAmR2lhbnQsCiAJCQkmaW9jdGxfY21kLT5kbWF0YWcpICE9IDApIHsKIAkJ cmV0dXJuIEVOT01FTTsKICAgICAgICAgfQpkaWZmIC11IHN5cy9kZXYvaXBzLm9yaWcvaXBzX3Bj aS5jIHN5cy9kZXYvaXBzL2lwc19wY2kuYwotLS0gc3lzL2Rldi9pcHMub3JpZy9pcHNfcGNpLmMJ U3VuIEphbiAzMCAxNDo0MToxMiAyMDA1CisrKyBzeXMvZGV2L2lwcy9pcHNfcGNpLmMJVHVlIEFw ciAxMiAxMzowMzozMSAyMDA1CkBAIC0xMjYsNyArMTI2LDcgQEAKICAgICAgICAgICAgICAgICBk ZXZpY2VfcHJpbnRmKGRldiwgImlycSBhbGxvY2F0aW9uIGZhaWxlZFxuIik7CiAgICAgICAgICAg ICAgICAgZ290byBlcnJvcjsKICAgICAgICAgfQotCWlmKGJ1c19zZXR1cF9pbnRyKGRldiwgc2Mt PmlycXJlcywgSU5UUl9UWVBFX0JJT3xJTlRSX01QU0FGRSwgc2MtPmlwc19hZGFwdGVyX2ludHIs IHNjLCAmc2MtPmlycWNvb2tpZSkpeworCWlmKGJ1c19zZXR1cF9pbnRyKGRldiwgc2MtPmlycXJl cywgSU5UUl9UWVBFX0JJTywgc2MtPmlwc19hZGFwdGVyX2ludHIsIHNjLCAmc2MtPmlycWNvb2tp ZSkpewogICAgICAgICAgICAgICAgIGRldmljZV9wcmludGYoZGV2LCAiaXJxIHNldHVwIGZhaWxl ZFxuIik7CiAgICAgICAgICAgICAgICAgZ290byBlcnJvcjsKICAgICAgICAgfQpAQCAtMTQxLDgg KzE0MSw4IEBACiAJCQkJLyogbnVtc2VncyAgICovCUlQU19NQVhfU0dfRUxFTUVOVFMsCiAJCQkJ LyogbWF4c2Vnc2l6ZSovCUJVU19TUEFDRV9NQVhTSVpFXzMyQklULAogCQkJCS8qIGZsYWdzICAg ICAqLwkwLAotCQkJCS8qIGxvY2tmdW5jICAqLyBOVUxMLAotCQkJCS8qIGxvY2thcmcgICAqLyBO VUxMLAorCQkJCS8qIGxvY2tmdW5jICAqLyBidXNkbWFfbG9ja19tdXRleCwKKwkJCQkvKiBsb2Nr YXJnICAgKi8gJkdpYW50LAogCQkJCSZzYy0+YWRhcHRlcl9kbWF0YWcpICE9IDApIHsKICAgICAg ICAgICAgICAgICBwcmludGYoIklQUyBjYW4ndCBhbGxvYyBkbWEgdGFnXG4iKTsKICAgICAgICAg ICAgICAgICBnb3RvIGVycm9yOwo= --=====================_695434812==_-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 04:24:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E092D16A4CE for ; Wed, 13 Apr 2005 04:24:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3065743D49 for ; Wed, 13 Apr 2005 04:24:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3D4RZgn042046; Tue, 12 Apr 2005 22:27:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425C9E37.2010105@samsco.org> Date: Tue, 12 Apr 2005 22:21:11 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Sze References: <4257F20C.70004@samsco.org> <6.2.1.2.2.20050411005214.065dc018@mail.distrust.net> <425A0BB2.10704@samsco.org> <6.2.1.2.2.20050411234713.069afb28@mail.distrust.net> <425C12E3.5050205@samsco.org> <6.2.1.2.2.20050412234622.05a6daf8@mail.distrust.net> In-Reply-To: <6.2.1.2.2.20050412234622.05a6daf8@mail.distrust.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Anthony Downer cc: stable@freebsd.org cc: mb@imp.ch Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 04:24:29 -0000 David Sze wrote: > At 12:26 PM 12/04/2005 -0600, Scott Long wrote this to All: > >> David Sze wrote: >> >>> At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All: >>> >>>> Making a driver PAE-ified means either teaching it to do 64-bit >>>> scatter-gather (assuming that the peripheral hardware can do this >>>> and that it's documented), or teaching the driver to correctly handle >>>> EINPROGRESS from bus_dmamap_load() along with using the proper busdma >>>> tag limits. The strategy I took with 6.x/5.x was the second one since >>>> I didn't have good IPS docs in front of me and I wanted it follow the >>>> APIs correctly. I did test it with 8GB of memory and it performed >>>> correctly under load. I haven't taken a close enough look at your >>>> MFC patch to say for sure if it's correct or not. I'm not sure if >>>> I'll have time to take another look in the next few days, >>>> unfortunately. >>>> Is there any chance you could test 5.x/6.0 under load with PAE just to >>>> validate the assertion that it works correctly there? >>> >>> >>> I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE, >>> and SMP-PAE kernels (the last one is just PAE with "options SMP"). >>> To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz >>> (non-E64MT), ServeRAID-7K. >>> GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE >>> paniced reproducibly doing the same. The DDB stack trace doesn't >>> appear to be anywhere near the IPS driver though, so I'm way out of >>> my league. >> >> >> Darnit, hard to say if this is an existing bug in 5.4 or if it's a >> bug/corruption in ips.Can you re-run with PAE disabled? > > > Works fine with PAE disabled (or at least I couldn't get it to panic), > both UP and SMP kernels. > > >> Would you be >> willing to put the Giant lock back on top of the driver? This would >> mean modifying the call to bus_intr_config(), adding the D_GIANTNEEDED >> flag to the disk structure in disk_create(), and switching the mutex >> argument in bus_dma_tag_create() for the sg_dmatag tag. > > > I put Giant back in as you described (patch attached), but it still > panic'ed with PAE enabled, both UP and SMP kernels. The stack trace was > very similar; the fault address (0x24) and the top three stack frames > were the same as without Giant: > > propagate_priority > turnstile_wait > _mtx_lock_sleep > > At this point I no longer have access to the hardware, the customer > wanted his servers back. They're going into the datacenter with > RELENG_4 (w/IPS stability patch), without PAE (so the top ~900MB of his > 4GB RAM is lost to PCI-X address space). > > Crumbs, I see a potential problem. I won't have time until this weekend to sort it out, though. Sorry this has become such a drawn-out affair, I hope that your customer isn't too upset. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 06:40:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 330DF16A4CE for ; Wed, 13 Apr 2005 06:40:53 +0000 (GMT) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 303D243D39 for ; Wed, 13 Apr 2005 06:40:52 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net id j3D6eoCH024409 (8.13.2/1.4); Wed, 13 Apr 2005 08:40:50 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id j3D6eo96016547 (8.13.2/2.02); Wed, 13 Apr 2005 08:40:50 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Wed, 13 Apr 2005 08:40:50 +0200 (MEST) From: Michiel Boland To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: fxp lockups on 5.4-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 06:40:53 -0000 Hi. I was using a small test program to generate artificial network load on 5.4-RC1. The program sets up 1000 sockets that all connect, send a number of pipelined request, and then read the response from a nearby web server. After a short while the machine locked up, even the console was dead. Luckily DDB worked, so I was able to gather some backtraces (see below). Looks like something is stuck in the fxp process. Being a bit impatient, I did not check to see if the lockup would go away after some time. The problem went away after I increased nmbclusters to 32768. If more info is needed I can provide this of course. Cheers Michiel > tr Tracing pid 23 tid 100017 td 0xc157da80 kdb_enter(c05d55bb) at kdb_enter+0x2b siointr1(c167f000) at siointr1+0xce siointr(c167f000) at siointr+0x38 intr_execute_handlers(c05ffac0,d4000bd8,0,c0c46460,c0c45240) at intr_execute_handlers+0x7d atpic_handle_intr(4) at atpic_handle_intr+0x96 Xatpic_intr4() at Xatpic_intr4+0x20 --- interrupt, eip = 0xc057ff87, esp = 0xd4000c1c, ebp = 0xd4000c28 --- uma_zfree_internal(c0c45240,c4173418,0,0,80) at uma_zfree_internal+0x153 bucket_free(c4173418,1,80,f3c8,c0c45bd8) at bucket_free+0x22 uma_zalloc_bucket(c0c45ba0,1) at uma_zalloc_bucket+0x263 uma_zalloc_arg(c0c45ba0,d4000c9c,1) at uma_zalloc_arg+0x274 fxp_add_rfabuf(c1616000,c16165d0) at fxp_add_rfabuf+0x2a fxp_intr_body(c1616000,c1616000,50,ffffffff) at fxp_intr_body+0xd4 fxp_intr(c1616000) at fxp_intr+0xf4 ithread_loop(c1576800,d4000d48) at ithread_loop+0x151 fork_exit(c04838a0,c1576800,d4000d48) at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4000d7c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 375 c1731388 1001 370 375 0004002 [SLPQ zonelimit 0xc0c1f460][SLP] kqmaps 370 c1731c5c 1001 369 370 0004002 [SLPQ wait 0xc1731c5c][SLP] bash 369 c1731e20 0 1 369 0004102 [SLPQ wait 0xc1731e20][SLP] login 368 c18b5000 0 1 368 0004002 [SLPQ ttyin 0xc1574e10][SLP] getty 367 c18b51c4 0 1 367 0004002 [SLPQ ttyin 0xc1683010][SLP] getty 366 c18b5388 0 1 366 0004002 [SLPQ ttyin 0xc1683210][SLP] getty 365 c18b554c 0 1 365 0004002 [SLPQ ttyin 0xc1683410][SLP] getty 364 c18b5710 0 1 364 0004002 [SLPQ ttyin 0xc1573010][SLP] getty 363 c18b58d4 0 1 363 0004002 [SLPQ ttyin 0xc1573210][SLP] getty 362 c172d54c 0 1 362 0004002 [SLPQ ttyin 0xc1573410][SLP] getty 361 c172d710 0 1 361 0004002 [SLPQ ttyin 0xc1573610][SLP] getty 321 c15c7e20 0 1 321 0000100 [SLPQ select 0xc060f364][SLP] sshd 199 c172d1c4 0 1 199 0000000 [SLPQ select 0xc060f364][SLP] devd 38 c172d8d4 0 0 0 0000204 [SLPQ - 0xd5445d18][SLP] schedcpu 37 c172da98 0 0 0 0000204 [SLPQ syncer 0xc060baec][SLP] syncer 36 c172dc5c 0 0 0 0000204 [SLPQ vlruwt 0xc172dc5c][SLP] vnlru 35 c172de20 0 0 0 0000204 [SLPQ psleep 0xc060f84c][SLP] bufdaemon 9 c1731000 0 0 0 000020c [SLPQ pgzero 0xc0616ed4][SLP] pagezero 8 c15b654c 0 0 0 0000204 [SLPQ psleep 0xc0616f28][SLP] vmdaemon 7 c15b6710 0 0 0 0000204 [SLPQ psleep 0xc0616ee4][SLP] pagedaemon 34 c15b68d4 0 0 0 0000204 [IWAIT] swi0: sio 33 c15b6a98 0 0 0 0000204 [IWAIT] swi6: task queue 6 c15b6c5c 0 0 0 0000204 [SLPQ - 0xc15e7e00][SLP] kqueue taskq 32 c15b6e20 0 0 0 0000204 [IWAIT] swi6:+ 5 c15c7000 0 0 0 0000204 [SLPQ - 0xc15f5000][SLP] thread taskq 31 c15c71c4 0 0 0 0000204 [IWAIT] swi6:+ 30 c15c7388 0 0 0 0000204 [SLPQ - 0xc0603a40][SLP] yarrow 4 c15c754c 0 0 0 0000204 [SLPQ - 0xc0606428][SLP] g_down 3 c15c7710 0 0 0 0000204 [SLPQ - 0xc0606424][SLP] g_up 2 c15c78d4 0 0 0 0000204 [SLPQ - 0xc060641c][SLP] g_event 29 c15801c4 0 0 0 0000204 [IWAIT] swi1: net 28 c1580388 0 0 0 0000204 [IWAIT] swi4: vm 27 c158054c 0 0 0 000020c [RUNQ] swi5: clock sio 26 c1580710 0 0 0 0000204 [IWAIT] irq15: ata1 25 c15808d4 0 0 0 0000204 [IWAIT] irq14: ata0 24 c1580a98 0 0 0 0000204 [IWAIT] irq13: 23 c1580c5c 0 0 0 0000204 [CPU 0] irq12: fxp0 22 c1580e20 0 0 0 0000204 [IWAIT] irq11: 21 c15b6000 0 0 0 0000204 [IWAIT] irq10: 20 c15b61c4 0 0 0 0000204 [IWAIT] irq9: 19 c15b6388 0 0 0 0000204 [IWAIT] irq8: rtc 18 c1578000 0 0 0 0000204 [IWAIT] irq7: 17 c15781c4 0 0 0 0000204 [IWAIT] irq6: 16 c1578388 0 0 0 0000204 [IWAIT] irq5: 15 c157854c 0 0 0 0000204 [IWAIT] irq4: sio0 14 c1578710 0 0 0 0000204 [IWAIT] irq3: sio1 13 c15788d4 0 0 0 0000204 [IWAIT] irq1: atkbd0 12 c1578a98 0 0 0 0000204 [IWAIT] irq0: clk 11 c1578c5c 0 0 0 000020c [Can run] idle 1 c1578e20 0 0 1 0004200 [SLPQ wait 0xc1578e20][SLP] init 10 c1580000 0 0 0 0000204 [SLPQ ktrace 0xc0609d18][SLP] ktrace 0 c06064c0 0 0 0 0000200 [SLPQ sched 0xc06064c0][SLP] swapper db> tr 375 Tracing pid 375 tid 100038 td 0xc15b8c00 sched_switch(c15b8c00,0,1) at sched_switch+0x143 mi_switch(1,0,c15b8c00,0,c15b8c00) at mi_switch+0x1ba sleepq_switch(c0c1f460) at sleepq_switch+0xda sleepq_wait(c0c1f460,0,c0c45240,0,0) at sleepq_wait+0xb msleep(c0c1f460,c0c1f468,44,c05d48df,0) at msleep+0x2ce uma_zone_slab(c0c45b40,2,2,80,314c) at uma_zone_slab+0xd2 uma_zalloc_bucket(c0c45b40,2) at uma_zalloc_bucket+0x14c uma_zalloc_arg(c0c45b40,c41c1c00,2) at uma_zalloc_arg+0x274 mb_init_pack(c41c1c00,100,2) at mb_init_pack+0x1d uma_zalloc_bucket(c0c45ba0,3) at uma_zalloc_bucket+0x1b4 uma_zalloc_arg(c0c45ba0,d5229c0c,2) at uma_zalloc_arg+0x274 sosend(c1a05000,0,d5229c54,0,0) at sosend+0x33d kern_sendit(c15b8c00,3fd,d5229ccc,0,0) at kern_sendit+0x11c sendit(c15b8c00,3fd,d5229ccc,0,805a000) at sendit+0x145 sendto(c15b8c00,d5229d14,6,60,202) at sendto+0x4d syscall(2f,805002f,bfbf002f,1a4,80521b0) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c2b9b, esp = 0xbfbfeb4c, ebp = 0xbfbfeb78 --- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 08:09:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15B8F16A4CE for ; Wed, 13 Apr 2005 08:09:05 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C38943D3F for ; Wed, 13 Apr 2005 08:09:04 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3D891q9059738 for ; Wed, 13 Apr 2005 10:09:01 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <425CD339.3000705@DeepCore.dk> Date: Wed, 13 Apr 2005 10:07:21 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Subject: UPDATE: ATA mkIII official patches for releng_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 08:09:05 -0000 I've just uploaded the latest ATA mkIII patches for releng_5 (and=20 releng_5_4 for that matter). Since this work is now in -current there will only be releng_5 patches=20 now and then if there is sufficient interest. Anyhow, they are on http:/people.freebsd.org/~sos/ATA Enjoy! --=20 -S=F8ren From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 08:59:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 096AE16A4CE for ; Wed, 13 Apr 2005 08:59:13 +0000 (GMT) Received: from f26.mail.ru (f26.mail.ru [194.67.57.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A724843D41 for ; Wed, 13 Apr 2005 08:59:12 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f26.mail.ru with local id 1DLdiD-0008s1-00; Wed, 13 Apr 2005 12:59:05 +0400 Received: from [81.200.13.122] by win.mail.ru with HTTP; Wed, 13 Apr 2005 12:59:05 +0400 From: dima <_pppp@mail.ru> To: Dikshie Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Wed, 13 Apr 2005 12:59:05 +0400 In-Reply-To: <20050413025855.GA25698@ppk.itb.ac.id> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-stable@freebsd.org Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 08:59:13 -0000 > dear all, > I would like to buy SCSI card which must: > - support Ultra 320 > - support RAID 0,1,5, and 1/0 > any recommendation for FreeBSD-5.x ? Adaptec 7902 (I have an onboard one) works quite fine with asr(4) zero-channel raid card. It's a quite cheap solution but it performs stable and fast. Unfortunately asrutils aren't functional at least in 5.x (the specification/sources are available though, see archives). From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 09:41:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C7F16A4CE; Wed, 13 Apr 2005 09:41:08 +0000 (GMT) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDD7643D54; Wed, 13 Apr 2005 09:41:07 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 6E5534AEDB; Wed, 13 Apr 2005 11:41:06 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05080-03-6; Wed, 13 Apr 2005 11:41:06 +0200 (CEST) Received: from [192.168.1.187] (rambutan.pingpong.net [192.168.1.187]) by melon.pingpong.net (Postfix) with ESMTP id 30DA74AEDA; Wed, 13 Apr 2005 11:41:06 +0200 (CEST) Date: Wed, 13 Apr 2005 11:41:06 +0200 From: Palle Girgensohn To: amd64@freebsd.org Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at pingpong.net cc: stable@freebsd.org Subject: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 09:41:09 -0000 Hi! We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64). It reboots sporadically, a few times per day! It has a rather high load, running php, apache & postfix. Is anyone else experiencing any problems with this kind of setup? diff against GENERIC kernel is minor: +# SMP +options SMP + +# SysV stuff +# This provides support for System V shared memory. +# +options SYSVSHM +options SYSVSEM +options SYSVMSG +options SHMMAXPGS=65536 +options SEMMNI=40 +options SEMMNS=240 +options SEMUME=40 +options SEMMNU=120 Also CPUTYPE?=nocona is set in /etc/make.conf Any ideas about this would ber *very* appreciated. Thanks! See also my previous post from yesterday. Regards, Palle $ dmesg Copyright (c) 1992-2005 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.4-RC2 #1: Wed Apr 13 01:24:15 CEST 2005 girgen@melon.pingpong.net:/usr/obj/usr/src/sys/MELON Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d,MON,DS_CPL,CNTX-ID,CX16,> AMD Features=0x20000800 Hyperthreading: 2 logical CPUs real memory = 2147221504 (2047 MB) avail memory = 2061373440 (1965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 10 ioapic2: WARNING: intbase 64 != expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xdfdc0000-0xdfdfffff,0xd80f0000-0xd80fffff irq 46 at device 14.0 on pci2 amr0: Firmware 513O, BIOS H418, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:37:a4:9e em0: Speed:N/A Duplex:N/A pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:37:a4:9f em1: Speed:N/A Duplex:N/A pcib8: at device 6.0 on pci0 pci8: on pcib8 uhci0: port 0xbce0-0xbcff 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 0xbcc0-0xbcdf 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 0xbca0-0xbcbf 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 pci0: at device 29.7 (no driver attached) pcib9: at device 30.0 on pci0 pci9: on pcib9 pci9: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xec000-0xeffff,0xce800-0xcf7ff,0xcb000-0xcbfff,0xc0000-0xcafff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub3: Dell product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub3: 2 ports with 2 removable, self powered Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 amrd0: on amr0 amrd0: 139760MB (286228480 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Mounting root from ufs:/dev/amrd0s2a WARNING: / was not properly dismounted WARNING: /misc was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /usr/local was not properly dismounted /usr/local: mount pending error: blocks 32 files 3 WARNING: /var was not properly dismounted WARNING: /var/spool/imap was not properly dismounted /var/spool/imap: mount pending error: blocks 20 files 4 em1: Link is up 100 Mbps Half Duplex em0: Link is up 1000 Mbps Full Duplex From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 09:58:37 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26F4F16A4CE for ; Wed, 13 Apr 2005 09:58:37 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id A76C943D45 for ; Wed, 13 Apr 2005 09:58:36 +0000 (GMT) (envelope-from cristiano.deana@gmail.com) Received: by wproxy.gmail.com with SMTP id 49so310996wri for ; Wed, 13 Apr 2005 02:58:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mk15jQ0Ptbdoz1jpEtVXtqAXeGFZj2GfY5DqPt+VKnbfunvZzpI0U6XKFO1+GM0dfxMAbOZnw5YWKRkrrv8jzy9qg3xLmNb7MQGGNeRMjEFR9f8+MConGn0zP/JBVkXtXRVzOn1OWGMYF+xd6jYEQtYkny4Fls1BAaHNEvhBxFk= Received: by 10.54.20.71 with SMTP id 71mr47906wrt; Wed, 13 Apr 2005 02:58:34 -0700 (PDT) Received: by 10.54.59.13 with HTTP; Wed, 13 Apr 2005 02:58:04 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 11:57:04 +0159 From: Cristiano Deana To: amd64@freebsd.org, stable@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cristiano Deana List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 09:58:37 -0000 2005/4/13, Palle Girgensohn : > We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64) > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 I am a little bit confused. amd64 with a dual xeon? --=20 Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:06:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15E1C16A4D0 for ; Wed, 13 Apr 2005 10:06:23 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4373543D41 for ; Wed, 13 Apr 2005 10:06:22 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so107145rng for ; Wed, 13 Apr 2005 03:06:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rWSI7QF0lklyuFt0Xp03mk+3xTmwKNVmx38scLpJcidsbss/uFAJHWa9MVK+yZFGr992tg2dip2KGlDlDBl3ZR+woVHdbbWGoKBhzUvVwvBdyqzVqBOLVc82Pvl1V5wX+xtkY12Rt2J8QzUBEsYgNKv0b12F0cGDYUuis0g0Mxs= Received: by 10.38.74.72 with SMTP id w72mr440639rna; Wed, 13 Apr 2005 03:06:21 -0700 (PDT) Received: by 10.38.149.53 with HTTP; Wed, 13 Apr 2005 03:06:21 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 12:06:21 +0200 From: Claus Guttesen To: Palle Girgensohn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: cc: amd64@freebsd.org cc: stable@freebsd.org Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Claus Guttesen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:06:23 -0000 > We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64). It reboots > sporadically, a few times per day! It has a rather high load, running php= , > apache & postfix. Is anyone else experiencing any problems with this kind > of setup? I have a similar server which is not in production yet. So it hasn't been tested in a real world environment, but it does not reboot. > CPUTYPE?=3Dnocona > is set in /etc/make.conf Have the same, looks fine. > $ dmesg > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 You may want to disable HTT since the logical cpu may actually decrease the overall performance. See 'show stoppers' for the upcoming 5.4 release, there is an issue with 4 cpus and heavy on http://www.freebsd.org/releases/5.4R/todo.html. regards Claus From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:09:07 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0505A16A4CE for ; Wed, 13 Apr 2005 10:09:07 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98FB743D5C for ; Wed, 13 Apr 2005 10:09:06 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so107626rng for ; Wed, 13 Apr 2005 03:09:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HfYk2Xxy+gqWA7OGYahefVMvdf0C4pwViI5WvnijOn8VXx/xH0qyXFe0E7vxuZDdeSW5VAB0z+W5KLj58FgUQNfh6fyt4aRNp9jBgpDg3aFiRvbBcsqhQkorMQ3c8QtMlie3+ulqFYwEUO+baQ9I8VGnepFqkEBZazOkXUImoEE= Received: by 10.39.1.41 with SMTP id d41mr441048rni; Wed, 13 Apr 2005 03:09:05 -0700 (PDT) Received: by 10.38.149.53 with HTTP; Wed, 13 Apr 2005 03:09:05 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 12:09:05 +0200 From: Claus Guttesen To: amd64@freebsd.org, stable@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Claus Guttesen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:09:07 -0000 > I am a little bit confused. > amd64 with a dual xeon? Works fine. Pls. search the list before posting such replies. regards Claus From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:09:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00DA316A4CF; Wed, 13 Apr 2005 10:09:54 +0000 (GMT) Received: from dev.bmby.co.il (l192-114-46-204.broadband.actcom.net.il [192.114.46.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F44B43D46; Wed, 13 Apr 2005 10:09:52 +0000 (GMT) (envelope-from uzi@bmby.com) Received: from [10.0.0.3] ([10.0.0.3]) by dev.bmby.co.il (8.12.9/8.12.9) with ESMTP id j3DA9nqx013471; Wed, 13 Apr 2005 13:09:50 +0300 Message-ID: <425CFDFF.3040902@bmby.com> Date: Wed, 13 Apr 2005 13:09:51 +0200 From: Uzi Klein User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cristiano Deana References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: amd64@freebsd.org cc: stable@freebsd.org Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:09:54 -0000 Cristiano Deana wrote: > 2005/4/13, Palle Girgensohn : > > >>We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64) > > >>CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > > I am a little bit confused. > amd64 with a dual xeon? > The FreeBSD amd64 supports Intel EM64T. See http://www.freebsd.org/platforms/amd64.html -- Uzi Klein B.M.B.Y Software Systems LTD. http://www.bmby.com From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:14:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A50716A4CE for ; Wed, 13 Apr 2005 10:14:20 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE9543D45 for ; Wed, 13 Apr 2005 10:14:19 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.50 (FreeBSD)) id 1DLet0-0005Vj-Jw for stable@freebsd.org; Wed, 13 Apr 2005 12:14:18 +0200 Date: Wed, 13 Apr 2005 12:14:18 +0200 From: Oliver Brandmueller To: stable@freebsd.org Message-ID: <20050413101418.GB87365@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: Oliver Brandmueller Subject: strangeness about netstat -m and mbuf clusters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:14:20 -0000 Hi everybody, I have something real strange about netst -m in RELENG_5: caipi# uname -a FreeBSD caipi 5.4-STABLE FreeBSD 5.4-STABLE #11: Tue Apr 5 13:18:21 CEST 2005 root@hudson:/usr/obj/usr/src/sys/APP i386 caipi# netstat -m 463324 mbufs in use 4294964312/25600 mbuf clusters in use (current/max) 0/4/6656 sfbufs in use (current/peak/max) 109863 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 323 calls to protocol drain routines On all the machines where this happens I also see, that I cannot use vi to edit a file on an NFS filesystem. vi simply does nothing, it hangs and cannot be killed or only after a long time. Using truss is not possible: "truss: PIOCBIS: Inappropriate ioctl for device" (procfs is mounted). Using another editor (vim for example) works as expected. Any ideas, what I could test/do? Greetings, 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-stable@FreeBSD.ORG Wed Apr 13 10:19:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87ABC16A4CE; Wed, 13 Apr 2005 10:19:57 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D20743D5F; Wed, 13 Apr 2005 10:19:57 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DLeyR-000Lhq-Kk; Wed, 13 Apr 2005 11:19:55 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.43 (FreeBSD)) id 1DLeyR-000C6z-Ge; Wed, 13 Apr 2005 11:19:55 +0100 To: amd64@freebsd.org, cristiano.deana@gmail.com, stable@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Wed, 13 Apr 2005 11:19:55 +0100 Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:19:57 -0000 > I am a little bit confused. > amd64 with a dual xeon? Preseumably one of the newer 64 bit Xeons. I would home amd64 supports them doesnt it ? -pcf. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:22:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02CD316A4CE for ; Wed, 13 Apr 2005 10:22:00 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6FC043D31 for ; Wed, 13 Apr 2005 10:21:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E4DB051268; Wed, 13 Apr 2005 03:21:58 -0700 (PDT) Date: Wed, 13 Apr 2005 03:21:58 -0700 From: Kris Kennaway To: Oliver Brandmueller Message-ID: <20050413102158.GA57881@xor.obsecurity.org> References: <20050413101418.GB87365@e-Gitt.NET> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20050413101418.GB87365@e-Gitt.NET> User-Agent: Mutt/1.4.2.1i cc: stable@freebsd.org Subject: Re: strangeness about netstat -m and mbuf clusters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:22:00 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 13, 2005 at 12:14:18PM +0200, Oliver Brandmueller wrote: >=20 > Hi everybody, >=20 > I have something real strange about netst -m in RELENG_5: >=20 > caipi# uname -a > FreeBSD caipi 5.4-STABLE FreeBSD 5.4-STABLE #11: Tue Apr 5 13:18:21 CEST= 2005 root@hudson:/usr/obj/usr/src/sys/APP i386 >=20 > caipi# netstat -m > 463324 mbufs in use > 4294964312/25600 mbuf clusters in use (current/max) > 0/4/6656 sfbufs in use (current/peak/max) > 109863 KBytes allocated to network > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 323 calls to protocol drain routines See the errata for 5.3, this is still true for later versions. > On all the machines where this happens I also see, that I cannot use vi= =20 > to edit a file on an NFS filesystem. vi simply does nothing, it hangs=20 > and cannot be killed or only after a long time. Using truss is not=20 > possible: "truss: PIOCBIS: Inappropriate ioctl for device" (procfs is=20 > mounted). Using another editor (vim for example) works as expected. Sounds like rpc.lockd is not set up on client and/or server. Kris --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXPLFWry0BWjoQKURArJ2AKDlHsnnV7pgTbDlwbWbG9Vzh5PyQQCfeT/V Sx9aOv0/TC6CLtaduKQM/Vo= =a0OD -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:37:22 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B09016A4CE for ; Wed, 13 Apr 2005 10:37:22 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECE5343D49 for ; Wed, 13 Apr 2005 10:37:21 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DLfFE-000Lue-Lp; Wed, 13 Apr 2005 11:37:16 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.43 (FreeBSD)) id 1DLfFE-000CEc-Eo; Wed, 13 Apr 2005 11:37:16 +0100 To: dikshie@ppk.itb.ac.id, freebsd-stable@freebsd.org In-Reply-To: <20050413025855.GA25698@ppk.itb.ac.id> Message-Id: From: Pete French Date: Wed, 13 Apr 2005 11:37:16 +0100 Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:37:22 -0000 > dear all, > I would like to buy SCSI card which must: > - support Ultra 320 > - support RAID 0,1,5, and 1/0 > any recommendation for FreeBSD-5.x ? The Compaq SMART series have always worked well for me. Have a 3200 here on FreeBSD 5, and have tried almost all of them on FreeBSD 4 (from the old SMART 2 up to my current 5402). Nice cards in my opinion. -pcf. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:41:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C309616A4CE; Wed, 13 Apr 2005 10:41:33 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8673A43D1F; Wed, 13 Apr 2005 10:41:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3DAfKHJ019491; Wed, 13 Apr 2005 20:11:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org, Cristiano Deana Date: Wed, 13 Apr 2005 20:11:10 +0930 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11720866.i6L7C3YFjf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504132011.18758.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: amd64@freebsd.org cc: stable@freebsd.org Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:41:34 -0000 --nextPart11720866.i6L7C3YFjf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 13 Apr 2005 19:28, Cristiano Deana wrote: > 2005/4/13, Palle Girgensohn : > > We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64) > > > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) > > Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 > > I am a little bit confused. > amd64 with a dual xeon? EMT64... =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart11720866.i6L7C3YFjf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCXPdO5ZPcIHs/zowRAixfAJ9yPEM4SHrJDI2HfEPKllmmqEEw/gCcCLM0 RL0C4V9eSncMn+Wb5PvQlcQ= =cN+m -----END PGP SIGNATURE----- --nextPart11720866.i6L7C3YFjf-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:41:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C309616A4CE; Wed, 13 Apr 2005 10:41:33 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8673A43D1F; Wed, 13 Apr 2005 10:41:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3DAfKHJ019491; Wed, 13 Apr 2005 20:11:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org, Cristiano Deana Date: Wed, 13 Apr 2005 20:11:10 +0930 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11720866.i6L7C3YFjf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504132011.18758.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: amd64@freebsd.org cc: stable@freebsd.org Subject: Re: Dell 2850 sporadically reboots (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:41:34 -0000 --nextPart11720866.i6L7C3YFjf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 13 Apr 2005 19:28, Cristiano Deana wrote: > 2005/4/13, Palle Girgensohn : > > We have a dual CPU Dell 2850 running fresh RELENG_5_4 (amd64) > > > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) > > Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 > > I am a little bit confused. > amd64 with a dual xeon? EMT64... =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart11720866.i6L7C3YFjf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCXPdO5ZPcIHs/zowRAixfAJ9yPEM4SHrJDI2HfEPKllmmqEEw/gCcCLM0 RL0C4V9eSncMn+Wb5PvQlcQ= =cN+m -----END PGP SIGNATURE----- --nextPart11720866.i6L7C3YFjf-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 10:51:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3C9616A4CE for ; Wed, 13 Apr 2005 10:51:31 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75CE343D41 for ; Wed, 13 Apr 2005 10:51:31 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.50 (FreeBSD)) id 1DLfT0-0006Gl-JS for freebsd-stable@freebsd.org; Wed, 13 Apr 2005 12:51:30 +0200 Date: Wed, 13 Apr 2005 12:51:30 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20050413105130.GD87365@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050413101418.GB87365@e-Gitt.NET> <20050413102158.GA57881@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20050413102158.GA57881@xor.obsecurity.org> User-Agent: Mutt/1.5.9i Sender: Oliver Brandmueller Subject: Re: strangeness about netstat -m and mbuf clusters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 10:51:32 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kris. On Wed, Apr 13, 2005 at 03:21:58AM -0700, Kris Kennaway wrote: > See the errata for 5.3, this is still true for later versions. Err, OK, sorry. > > On all the machines where this happens I also see, that I cannot use vi= =20 > > to edit a file on an NFS filesystem. vi simply does nothing, it hangs= =20 > > and cannot be killed or only after a long time. Using truss is not=20 > > possible: "truss: PIOCBIS: Inappropriate ioctl for device" (procfs is= =20 > > mounted). Using another editor (vim for example) works as expected. >=20 > Sounds like rpc.lockd is not set up on client and/or server. rpc.lockd / rpc.statd were set up and were running on both client and=20 server. And it had been working before. Well the actual problem was, that on the server the processes were still=20 there, but the lockd didn't work anymore. After restarting the lockd=20 there everything worked again. Thanx for the pointer! Now we start going for the rest of all the strange things :-) - Oliver --=20 | 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! | --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXPmyiqtMdzjafykRAlNlAJ4i3109DRG/g25v0LQRKFWY3BEYLwCgm44O aLxLNL08kBojrj406opKcxg= =4Gfv -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 11:32:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E8F916A4CE for ; Wed, 13 Apr 2005 11:32:50 +0000 (GMT) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2ED543D2F for ; Wed, 13 Apr 2005 11:32:49 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id B217B1DD80E for ; Wed, 13 Apr 2005 12:32:51 +0100 (BST) Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00666-16 for ; Wed, 13 Apr 2005 12:32:47 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 6C1E21DD80C; Wed, 13 Apr 2005 12:32:47 +0100 (BST) Date: Wed, 13 Apr 2005 12:25:28 +0100 From: David Taylor To: freebsd-stable@freebsd.org Message-ID: <20050413112527.GA12511@outcold.yadt.co.uk> References: <20050407144539.GB55594@outcold.yadt.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20050407144539.GB55594@outcold.yadt.co.uk> User-Agent: Mutt/1.4.2.1i Resent-From: davidt@yadt.co.uk Resent-Date: Wed, 13 Apr 2005 12:32:47 +0100 Resent-To: freebsd-stable@freebsd.org Resent-Message-Id: <20050413113247.6C1E21DD80C@outcold.yadt.co.uk> X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at yadt.co.uk Subject: Re: [PATCH] puc/ppc and amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 11:32:50 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline On Thu, 07 Apr 2005, David Taylor wrote: > Hi, > > I've got an amd64 box with 1 built-in parallel port, which works fine. > > I also bought an add-on parallel port adapter card (a MosChip > SemiConductors Nm9805 chip). After discovering puc, I enabled > device puc and the card is now detected by puc, but doesn't > appear to be picked up by the ppc driver. I have now, finally, figured out what was going on. After much wasted time trying to debug ppc_puc.c, I realised it wasn't even being compiled in the kernel. After adding dev/ppc/ppc_puc.c to files.amd64, everything worked a lot better. A patch (against 5-STABLE) is attached, which adds ppc_puc.c to all architectures with ppc.c listed (alpha, amd64, ia64 -- I can only test amd64, however). If this gets lost for ages, I'll add a PR... -- David Taylor --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename="puc_ppc.patch" --- sys/conf/files.alpha.old Wed Apr 13 12:20:57 2005 +++ sys/conf/files.alpha Wed Apr 13 12:21:43 2005 @@ -183,6 +183,7 @@ dev/kbd/kbd.c optional sc dev/kbd/kbd.c optional ukbd dev/ppc/ppc.c optional ppc +dev/ppc/ppc_puc.c optional ppc puc pci dev/sio/sio.c optional sio dev/sio/sio_isa.c optional sio isa dev/syscons/schistory.c optional sc --- sys/conf/files.amd64.old Wed Apr 13 12:21:15 2005 +++ sys/conf/files.amd64 Wed Apr 13 12:21:53 2005 @@ -133,6 +133,7 @@ dev/kbd/kbd.c optional ukbd dev/mem/memutil.c optional mem dev/ppc/ppc.c optional ppc +dev/ppc/ppc_puc.c optional ppc puc pci dev/sio/sio.c optional sio dev/sio/sio_isa.c optional sio isa dev/syscons/apm/apm_saver.c optional apm_saver apm --- sys/conf/files.ia64.old Wed Apr 13 12:21:05 2005 +++ sys/conf/files.ia64 Wed Apr 13 12:22:11 2005 @@ -59,6 +59,7 @@ dev/kbd/kbd.c optional sc dev/kbd/kbd.c optional ukbd dev/ppc/ppc.c optional ppc isa +dev/ppc/ppc_puc.c optional ppc puc pci dev/syscons/schistory.c optional sc dev/syscons/scmouse.c optional sc dev/syscons/scterm-dumb.c optional sc --tThc/1wpZn/ma/RB-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 12:33:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 372C916A4CE for ; Wed, 13 Apr 2005 12:33:13 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98A0D43D41 for ; Wed, 13 Apr 2005 12:33:12 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 8ED79651F4; Wed, 13 Apr 2005 13:32:51 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47124-04-8; Wed, 13 Apr 2005 13:32:51 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 8A9FD651EB; Wed, 13 Apr 2005 13:32:47 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 835F16471; Wed, 13 Apr 2005 05:33:05 -0700 (PDT) Date: Wed, 13 Apr 2005 05:33:05 -0700 From: Bruce M Simpson To: David Taylor Message-ID: <20050413123305.GC755@empiric.icir.org> References: <20050407144539.GB55594@outcold.yadt.co.uk> <20050413112527.GA12511@outcold.yadt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413112527.GA12511@outcold.yadt.co.uk> cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] puc/ppc and amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 12:33:13 -0000 On Wed, Apr 13, 2005 at 12:25:28PM +0100, David Taylor wrote: > I have now, finally, figured out what was going on. After much > wasted time trying to debug ppc_puc.c, I realised it wasn't > even being compiled in the kernel. After adding dev/ppc/ppc_puc.c > to files.amd64, everything worked a lot better. Yay. Does it work? I just added ID's to pucdata.c in my own branch to deal with the EasiDock 5000's onboard parallal port, but I thought parallel port puc wasn't known to work just now? BMS From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 12:46:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E26F916A4CE for ; Wed, 13 Apr 2005 12:46:58 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B76443D1F for ; Wed, 13 Apr 2005 12:46:58 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j3DCkvkI023812 for ; Wed, 13 Apr 2005 07:46:57 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Wed Apr 13 07:46:57 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j3DCku12023810; Wed, 13 Apr 2005 07:46:56 -0500 (CDT) (envelope-from karl) Message-ID: <20050413074656.B23777@denninger.net> Date: Wed, 13 Apr 2005 07:46:56 -0500 From: Karl Denninger To: =?iso-8859-1?Q?S=F8ren_Schmidt?= , stable@freebsd.org References: <425CD339.3000705@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2i In-Reply-To: =?iso-8859-1?Q?=3C425CD339=2E3000705=40DeepCore=2Edk=3E=3B_from_S=F8ren_?= =?iso-8859-1?Q?Schmidt_on_Wed=2C_Apr_13=2C_2005_at_10:07:21AM_+0200?= Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: UPDATE: ATA mkIII official patches for releng_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 12:46:59 -0000 Is there any plan to MFC this? -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind On Wed, Apr 13, 2005 at 10:07:21AM +0200, Søren Schmidt wrote: > > I've just uploaded the latest ATA mkIII patches for releng_5 (and > releng_5_4 for that matter). > > Since this work is now in -current there will only be releng_5 patches > now and then if there is sufficient interest. > > Anyhow, they are on http:/people.freebsd.org/~sos/ATA > > Enjoy! > > -- > > -Søren > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [freebsd], message ok > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 12:49:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F0716A4CE for ; Wed, 13 Apr 2005 12:49:34 +0000 (GMT) Received: from ns1.onsitepcs.net (ns1.onsitepcs.net [71.32.223.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C5143D39 for ; Wed, 13 Apr 2005 12:49:31 +0000 (GMT) (envelope-from jaimie@onsitepcs.net) Received: from ns1.onsitepcs.net (localhost.localdomain [127.0.0.1]) by ns1.onsitepcs.net (8.13.1/8.13.1) with ESMTP id j3D5oScc012554 for ; Wed, 13 Apr 2005 05:50:28 GMT Received: from localhost (localhost [[UNIX: localhost]]) by ns1.onsitepcs.net (8.13.1/8.13.1/Submit) id j3D5oRgj012553 for freebsd-stable@freebsd.org; Wed, 13 Apr 2005 05:50:27 GMT X-Authentication-Warning: ns1.onsitepcs.net: jaimie set sender to jaimie@onsitepcs.net using -f From: Jaimie Garner Organization: Onsite PCS inc. To: freebsd-stable@freebsd.org Date: Wed, 13 Apr 2005 05:50:27 +0000 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504130550.27484.jaimie@onsitepcs.net> Subject: Problems with NIC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 12:49:34 -0000 This just started happing this evening not sure what is up. The nic is a Linksys LNE 100 V 4.something I forget now. I had some weird errors a while back when I first installed 5.3-RELEASE but i disabled ACPI and they seemed to work fine. Here is some info dc0: port 0x1000-0x10ff mem 0xfc001000-0xfc0013ff irq 9 at device 12.0 on pci0on pci0 miibus0: on dc0i0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:03:6d:16:09:1e dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] This looks odd especaly this: Interrupt storm detected on "irq9: dc0 ohci0"; throttling interrupt source IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled dc0: TX underrun -- increasing TX thresholdn isa0 dc0: TX underrun -- increasing TX thresholdort 0x64,0x60 on isa0 dc0: failed to force tx and rx to idle stateed irqs 0 Interrupt storm detected on "irq9: dc0 ohci0"; throttling interrupt source : dc0: watchdog timeoutn't assign resources (port) dc0: failed to force tx and rx to idle stateort) dc0: watchdog timeoutn't assign resources (port) dc0: failed to force tx and rx to idle stateort) dc0: watchdog timeoutquency 379986358 Hz quality 800 dc0: failed to force tx and rx to idle state dc0: watchdog timeout4K020H1/A08.1500> [39560/16/63] at ata0-master UDMA66 dc0: failed to force tx and rx to idle state dc0: watchdog timeout Apr 13 05:21:16 www kernel: dc0: watchdog timeout Apr 13 05:21:16 www kernel: dc0: failed to force tx and rx to idle state Basicly I think I will replace this NIC cause I have had nothing but problems with it. It's an old one I have had in several boxs as a spare/backup. Might be going south on me. One other ? how do I start and stop networking on FreeBSD. I am just moving to FreeBSD from SV Linux and am used to a /etc/rc.d/init.d/network restart. Thanks for any input. -- Jaimie Garner Onsite PCS inc. 323 SE RIverside AV Grants Pass, OR 97526 541.471.1343 866.471.1343 jaimie@onsitepcs.net www.onistepcs.net From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 13:34:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CC1216A4CE for ; Wed, 13 Apr 2005 13:34:10 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B50943D5D for ; Wed, 13 Apr 2005 13:34:09 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) j3DDtbEo025457; Wed, 13 Apr 2005 09:55:41 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Dikshie In-Reply-To: <20050413025855.GA25698@ppk.itb.ac.id> References: <20050413025855.GA25698@ppk.itb.ac.id> Content-Type: text/plain Date: Wed, 13 Apr 2005 09:34:25 -0400 Message-Id: <1113399266.16777.19.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 cc: freebsd-stable@freebsd.org Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 13:34:10 -0000 On Wed, 2005-04-13 at 09:58 +0700, Dikshie wrote: > dear all, > I would like to buy SCSI card which must: > - support Ultra 320 > - support RAID 0,1,5, and 1/0 > any recommendation for FreeBSD-5.x ? > > > > > thanks ! > > > -dikshie- > _______________________________________________ We find the LSI MegaRaid 320-2x series works great (using it on a dual opteron system), especially with the battery-backed cache ... can be picked up for just under $1k Sven From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 13:43:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C6116A4CE for ; Wed, 13 Apr 2005 13:43:56 +0000 (GMT) Received: from copland.jeol.com (copland.jeol.com [65.215.44.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF0043D3F for ; Wed, 13 Apr 2005 13:43:55 +0000 (GMT) (envelope-from lambert@jeol.com) Received: from jeol.com (mail.jeol.com [208.196.228.78]) by copland.jeol.com (8.12.9p2/8.12.9) with ESMTP id j3DDhNf1039875 for ; Wed, 13 Apr 2005 09:43:23 -0400 (EDT) (envelope-from lambert@jeol.com) Received: from [208.196.228.59] (account lambert HELO [208.196.228.59]) by jeol.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 847977 for freebsd-stable@freebsd.org; Wed, 13 Apr 2005 09:43:50 -0400 Message-ID: <425D2216.6060604@jeol.com> Date: Wed, 13 Apr 2005 09:43:50 -0400 From: Mike Lambert User-Agent: Mozilla Thunderbird 1.0 (X11/20050203) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20050413025855.GA25698@ppk.itb.ac.id> In-Reply-To: <20050413025855.GA25698@ppk.itb.ac.id> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: (-2.82) ALL_TRUSTED Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 13:43:56 -0000 Dikshie wrote: > dear all, > I would like to buy SCSI card which must: > - support Ultra 320 > - support RAID 0,1,5, and 1/0 > any recommendation for FreeBSD-5.x ? I think the bigger question is "Are there any SCSI RAID cards that can be fully monitored and managed from FreeBSD-5.x"? Mike Lambert From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 16:16:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2420A16A4CE for ; Wed, 13 Apr 2005 16:16:03 +0000 (GMT) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB3143D62 for ; Wed, 13 Apr 2005 16:16:01 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3DGFuTq058288; Wed, 13 Apr 2005 18:15:56 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 589BE625D; Wed, 13 Apr 2005 18:15:56 +0200 (CEST) Date: Wed, 13 Apr 2005 18:15:56 +0200 From: Roland Smith To: freebsd-stable@freebsd.org Message-ID: <20050413161556.GA82955@slackbox.xs4all.nl> Mail-Followup-To: freebsd-stable@freebsd.org, Jaimie Garner References: <200504130550.27484.jaimie@onsitepcs.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <200504130550.27484.jaimie@onsitepcs.net> User-Agent: Mutt/1.4.2.1i X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! Organization: Me, organized? X-Virus-Scanned: by XS4ALL Virus Scanner cc: Jaimie Garner Subject: Re: Problems with NIC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 16:16:03 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 13, 2005 at 05:50:27AM +0000, Jaimie Garner wrote: >=20 > This just started happing this evening not sure what is up. The nic > is a Linksys LNE 100 V 4.something I forget now. I had some weird > errors a while back when I first installed 5.3-RELEASE but i disabled > ACPI and they seemed to work fine. >=20 > Here is some info > dc0: port 0x1000-0x10ff mem 0xfc001000-0xfc00= 13ff=20 > irq 9 at device 12.0 on pci0on pci0 > miibus0: on dc0i0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:03:6d:16:09:1e > dc0: if_start running deferred for Giant > dc0: [GIANT-LOCKED] >=20 > This looks odd especaly this: > Interrupt storm detected on "irq9: dc0 ohci0"; throttling interrupt sour= ce Looks like the USB bus (ohci0) and your network card are sharing an interrupt line. My guess would be that a USB device generates too much interrupts causing the kernel to throttle them. This then screws up the network. According to polling(4), the dc driver supports polling instead of using an interrupt line. You could try rebuilding the kernel with polling support and see if the problem goes away. Or you could disable ohci0 in the bios, or plug the offending USB device into another port. Or you could try to force the dc triver to use another interrupt line. See the acpi manual page and google for 'irq routing freebsd'. I _think_ you should do the following: 'ps -xa|grep irq' will show which irq's are free. Let's say that irq 10 is still free. Now you'd have to find the pci address of the network card with 'pciconf -l -v|grep dc0'.=20 Let's say you get something like 'dc0@pci0:11:0' You can now tune the interrupt by setting the following in /boot/device.hints: hw.acpi.pci.link.0.11.0.irq=3D10 HTH, Roland --=20 R.F. Smith /"\ ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ / No HTML/RTF in e-mail http://www.xs4all.nl/~rsmith/ X No Word docs in e-mail public key: http://www.keyserver.net / \ Respect for open standards --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXUW8EnfvsMMhpyURAmzUAJkBB0/ccGJghKnncYfMnkfLtVvl0QCfW9eU bfHodfnD3xXgR+ZZIcYGeAE= =Eysg -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 17:07:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDC5716A4CF for ; Wed, 13 Apr 2005 17:07:01 +0000 (GMT) Received: from fmmailgate05.web.de (fmmailgate05.web.de [217.72.192.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21D9143D2F for ; Wed, 13 Apr 2005 17:07:01 +0000 (GMT) (envelope-from Helmut.Allwang@web.de) Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id j3DH6akB031276 for freebsd-stable@freebsd.org; Wed, 13 Apr 2005 19:06:59 +0200 Received: from [83.129.183.36] by freemailng0504.web.de with HTTP; Wed, 13 Apr 2005 19:06:32 +0200 Date: Wed, 13 Apr 2005 19:06:32 +0200 Message-Id: <1908714315@web.de> MIME-Version: 1.0 From: "Helmut Allwang" To: freebsd-stable@freebsd.org Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: pxeboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 17:07:02 -0000 Hello, it was possible for me, to boot a bootable floppy-image over pxeboot. Is it possible to boot a CD-image over pxeboot? Please cc me your answers. Thank you all, Helmut ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 17:44:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60FA516A52A for ; Wed, 13 Apr 2005 17:44:12 +0000 (GMT) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE81143D53 for ; Wed, 13 Apr 2005 17:44:11 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 4566AB850 for ; Wed, 13 Apr 2005 13:44:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <20050413025855.GA25698@ppk.itb.ac.id> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20--184420131; protocol="application/pkcs7-signature" Message-Id: <48900db0e058b7774fc755b265af8cce@khera.org> From: Vivek Khera Date: Wed, 13 Apr 2005 13:44:09 -0400 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.619.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 17:44:13 -0000 --Apple-Mail-20--184420131 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 12, 2005, at 11:32 PM, Vlad wrote: > lsi logic's megaraid 320-2 works pretty good for me > I'll second this recommendation. Vivek Khera, Ph.D. +1-301-869-4449 x806 --Apple-Mail-20--184420131-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 18:25:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B05416A4D3 for ; Wed, 13 Apr 2005 18:25:58 +0000 (GMT) Received: from ns1.onsitepcs.net (ns1.onsitepcs.net [71.32.223.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E6B343D31 for ; Wed, 13 Apr 2005 18:25:57 +0000 (GMT) (envelope-from jaimie@onsitepcs.net) Received: from ns1.onsitepcs.net (localhost.localdomain [127.0.0.1]) by ns1.onsitepcs.net (8.13.1/8.13.1) with ESMTP id j3DBQsJw014139 for ; Wed, 13 Apr 2005 11:26:54 GMT Received: from localhost (localhost [[UNIX: localhost]]) by ns1.onsitepcs.net (8.13.1/8.13.1/Submit) id j3DBQrOY014138 for freebsd-stable@freebsd.org; Wed, 13 Apr 2005 11:26:53 GMT X-Authentication-Warning: ns1.onsitepcs.net: jaimie set sender to jaimie@onsitepcs.net using -f From: Jaimie Garner Organization: Onsite PCS inc. To: freebsd-stable@freebsd.org Date: Wed, 13 Apr 2005 11:26:53 +0000 User-Agent: KMail/1.7.1 References: <200504130550.27484.jaimie@onsitepcs.net> <20050413161556.GA82955@slackbox.xs4all.nl> In-Reply-To: <20050413161556.GA82955@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504131126.53450.jaimie@onsitepcs.net> Subject: Re: Problems with NIC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 18:25:58 -0000 How about disable USB altogether since it is not used on this machine. Thanks for the info On Wednesday 13 April 2005 16:15, Roland Smith wrote: > On Wed, Apr 13, 2005 at 05:50:27AM +0000, Jaimie Garner wrote: > > This just started happing this evening not sure what is up. The nic > > is a Linksys LNE 100 V 4.something I forget now. I had some weird > > errors a while back when I first installed 5.3-RELEASE but i disabled > > ACPI and they seemed to work fine. > > > > Here is some info > > dc0: port 0x1000-0x10ff mem > > 0xfc001000-0xfc0013ff irq 9 at device 12.0 on pci0on pci0 > > miibus0: on dc0i0 > > ukphy0: on miibus0 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > dc0: Ethernet address: 00:03:6d:16:09:1e > > dc0: if_start running deferred for Giant > > dc0: [GIANT-LOCKED] > > > > This looks odd especaly this: > > Interrupt storm detected on "irq9: dc0 ohci0"; throttling interrupt > > source > > Looks like the USB bus (ohci0) and your network card are sharing an > interrupt line. My guess would be that a USB device generates too much > interrupts causing the kernel to throttle them. This then screws up the > network. > > According to polling(4), the dc driver supports polling instead of using > an interrupt line. You could try rebuilding the kernel with polling > support and see if the problem goes away. > > Or you could disable ohci0 in the bios, or plug the offending USB device > into another port. > > Or you could try to force the dc triver to use another interrupt > line. See the acpi manual page and google for 'irq routing freebsd'. I > _think_ you should do the following: 'ps -xa|grep irq' will show which > irq's are free. Let's say that irq 10 is still free. Now you'd have to > find the pci address of the network card with 'pciconf -l -v|grep dc0'. > Let's say you get something like 'dc0@pci0:11:0' You can now tune the > interrupt by setting the following in /boot/device.hints: > > hw.acpi.pci.link.0.11.0.irq=10 > > HTH, > > Roland -- Jaimie Garner Onsite PCS inc. 323 SE RIverside AV Grants Pass, OR 97526 541.471.1343 866.471.1343 jaimie@onsitepcs.net www.onistepcs.net From owner-freebsd-stable@FreeBSD.ORG Wed Apr 13 22:00:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E117B16A4CE for ; Wed, 13 Apr 2005 22:00:50 +0000 (GMT) Received: from ferengi.borderworlds.dk (ferengi.borderworlds.dk [80.166.152.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F9343D53 for ; Wed, 13 Apr 2005 22:00:50 +0000 (GMT) (envelope-from xi@borderworlds.dk) Received: from borg.borderworlds.dk (localhost [127.0.0.1]) by ferengi.borderworlds.dk (Postfix) with ESMTP id BAAA8B909; Thu, 14 Apr 2005 00:00:48 +0200 (CEST) Received: by borg.borderworlds.dk (Postfix, from userid 1001) id 9A08011460; Thu, 14 Apr 2005 00:00:48 +0200 (CEST) Sender: xi@borderworlds.dk To: =?iso-8859-1?q?S=F8ren_Schmidt?= References: <425CD339.3000705@DeepCore.dk> From: Christian Laursen Date: 14 Apr 2005 00:00:48 +0200 In-Reply-To: <425CD339.3000705@DeepCore.dk> Message-ID: <86sm1uz69b.fsf@borg.borderworlds.dk> Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: stable@freebsd.org Subject: Re: UPDATE: ATA mkIII official patches for releng_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 22:00:51 -0000 S=F8ren Schmidt writes: > I've just uploaded the latest ATA mkIII patches for releng_5 (and > releng_5_4 for that matter). Seems to work fine on my laptop running 5.4-RC2.=20 Suspend/resume doesn't work, but it didn't do that either with the code in RELENG_5_4. It seems to fail in a slightly different way now though. --=20 Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 00:54:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7AF616A4CE for ; Thu, 14 Apr 2005 00:54:43 +0000 (GMT) Received: from priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CEC143D48 for ; Thu, 14 Apr 2005 00:54:43 +0000 (GMT) (envelope-from nemesisdivina@gennux.ca) Received: from athena ([66.222.214.181]) by priv-edtnes40.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050414005442.KXTG28631.priv-edtnes40.telusplanet.net@athena> for ; Wed, 13 Apr 2005 18:54:42 -0600 From: "Didier Caamano" To: "FreeBSD Mailing List" Date: Wed, 13 Apr 2005 19:04:08 -0600 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVAjb7d/5XoSDU9QxS/tEB4uxhaIw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Mouse (moused) problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 00:54:43 -0000 Greetings to all: As the subject says, I am having a bit of problem with the mouse. I have been running FBSD 5.3 for about 2 weeks, X was working wonderfully, I even manage to get my ports upgraded using CTM, happiness was everywhere. Then came the moment to enable the sound system, I have an nforce chip. I went to /boot/kernel to see anything related to nforce but there was noting. Then, following the Handbook, I tried kldload snd_pcm but no sound still, tried kldload sbd_driver but still nothing. Tired of trying and reaching no positive results I went to bed, the next time I booted FBSD the mouse was gone. My /etc/rc.conf and /etc/X11/xorg.conf looks as follow: /etc/rc.conf # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="athena" ifconfig_dc0="DHCP" sshd_enable="YES" usbd_enable="YES" linux_enable="YES" /etc/X11/xorg.conf Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" Option "Protocol" "Auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5" I ran /etc/rc.d/moused start and it gave no error message, not even an echo saying it was starting moused. Then I looked for sysmouse with: find / -name sysmouse -print but the only result I got was /dev/sysmouse (because it is supposed to be there); however, when I did an ls /dev sysmouse wasn't there, I tried ls -a but nothing. Any help regarding this will be appreciated. I was really having fun with FBSD until this little mouse incident and I don't want to redo the installation and upgrading of the ports. Have a nice day From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 02:33:12 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54F7316A4CE for ; Thu, 14 Apr 2005 02:33:12 +0000 (GMT) Received: from web54004.mail.yahoo.com (web54004.mail.yahoo.com [206.190.36.228]) by mx1.FreeBSD.org (Postfix) with SMTP id B8FC943D41 for ; Thu, 14 Apr 2005 02:33:11 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 62188 invoked by uid 60001); 14 Apr 2005 02:33:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=SVyFRGbNG1g4y990PMzvHIL9Df2YUr+XahA7w4x369nhrq+9Tlyo+iV1/QizQImsxtPhzUAgKajmcqq7vFso5uBqouJ2g3qwWbZET+aKhCKv0Mgd5yWvASP5ptmH6q60pTF1EFaWl9dN5CW1DFTe3INFSkl8tWtbwARlBFqnGhs= ; Message-ID: <20050414023311.62186.qmail@web54004.mail.yahoo.com> Received: from [147.46.44.181] by web54004.mail.yahoo.com via HTTP; Wed, 13 Apr 2005 19:33:10 PDT Date: Wed, 13 Apr 2005 19:33:10 -0700 (PDT) From: Rob To: nemesisdivina@gennux.ca MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD Stable Subject: Re: Mouse (moused) problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 02:33:12 -0000 Didier Caamano wrote: > the next time I booted FBSD the mouse was gone. In your rc.conf, there's no line like: moused_enable="YES" You can run sysinstall, and go to mouse configuration and do there whatever is needed for your mouse. This procedure will add the appropriate lines into your rc.conf. Have a look at those lines and try to understand what was missing in your rc.conf. For sound support, see /usr/src/sys/conf/NOTES. It has a section on sound and what you need for specific sound cards. This may help. Good luck. Rob. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 03:18:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60FA216A4CF for ; Thu, 14 Apr 2005 03:18:48 +0000 (GMT) Received: from flake.decibel.org (flake.decibel.org [67.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D583F43D31 for ; Thu, 14 Apr 2005 03:18:47 +0000 (GMT) (envelope-from decibel@decibel.org) Received: by flake.decibel.org (Postfix, from userid 1001) id 31BC315447; Wed, 13 Apr 2005 22:18:46 -0500 (CDT) Date: Wed, 13 Apr 2005 22:18:45 -0500 From: "Jim C. Nasby" To: Matthias Buelow Message-ID: <20050414031845.GF58835@decibel.org> Mail-Followup-To: "Jim C. Nasby" , Matthias Buelow , Nick Barnes , Marc Olzheim , Vivek Khera , Dan Nelson , freebsd-stable@freebsd.org References: <52802.1113341617@thrush.ravenbrook.com> <200504122207.j3CM7BE7018595@drjekyll.mkbuelow.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504122207.j3CM7BE7018595@drjekyll.mkbuelow.net> X-Operating-System: FreeBSD 4.11-RELEASE i386 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.8i cc: Marc Olzheim cc: Dan Nelson cc: freebsd-stable@freebsd.org cc: Vivek Khera Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 03:18:48 -0000 On Wed, Apr 13, 2005 at 12:07:11AM +0200, Matthias Buelow wrote: > Nick Barnes writes: > > >> This stuff has been discussed in the past. > >Indeed. For a couple of examples from the days before BSD systems got > >overcommit, see these threads from 1990 and 1991: > > > > >b658465/4c590978f1001507?q=overcommit&rnum=14#4c590978f1001507> > > > > >6d30eb1/e8c30f78c44a3f62?q=overcommit&rnum=12#e8c30f78c44a3f62> > > Apparently, it can be turned off on AIX, quoting from > http://tinyurl.com/4epc8: > > ``If the PSALLOC environment variable is set to early, then every > program started in that environment from that point on, but not > including currently running processes, runs in the early allocation > environment. In the early allocation environment, interfaces such as the > malloc subroutine and the brk subroutine will fail if sufficient paging > space cannot be reserved when the request is made. > Processes run in the early allocation environment mode are not sent the > SIGKILL signal if a low paging space condition occur.'' > > Googling showed that on Linux 2.6, overcommit can be disabled globally > through the vm.overcommit_memory sysctl. > > I hope that some day some mechanism to solve that problem will be > available in FreeBSD aswell. It's extremely disappointing that you can't turn this off. I've been bashing linux for months now about how they think it's OK to kill random processes. But at least they'll let you turn it off. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 04:28:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BDC16A4CE for ; Thu, 14 Apr 2005 04:28:44 +0000 (GMT) Received: from mx-itb.geoph.ITB.ac.id (mx7.ITB.ac.id [167.205.30.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8550C43D1D for ; Thu, 14 Apr 2005 04:28:40 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from antivirus.itb.ac.id (antivirus.ITB.ac.id [167.205.108.137]) by mx-itb.geoph.ITB.ac.id (Postfix) with SMTP id 8492020AEC for ; Thu, 14 Apr 2005 11:44:39 +0700 (WIT) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx-itb.geoph.ITB.ac.id (Postfix) with ESMTP id 6569020ACE for ; Thu, 14 Apr 2005 11:44:39 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id 72705114E5; Thu, 14 Apr 2005 11:28:34 +0700 (WIT) Date: Thu, 14 Apr 2005 11:28:34 +0700 From: Dikshie To: freebsd-stable@freebsd.org Message-ID: <20050414042834.GA90693@ppk.itb.ac.id> References: <20050413025855.GA25698@ppk.itb.ac.id> <48900db0e058b7774fc755b265af8cce@khera.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48900db0e058b7774fc755b265af8cce@khera.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 5.4-STABLE i386) X-Uptime: 11:25AM up 5 days, 22:14, 1 user, load averages: 0.55, 1.20, 1.54 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 04:28:45 -0000 Thank you all very much for your information. Vivek Khera (vivek@khera.org) wrote: > >lsi logic's megaraid 320-2 works pretty good for me > I'll second this recommendation. with best regards, -dikshie- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 10:02:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33CC616A4CE for ; Thu, 14 Apr 2005 10:02:57 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42FAA43D62 for ; Thu, 14 Apr 2005 10:02:56 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 504E91F0D3; Thu, 14 Apr 2005 12:02:55 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 36F586132; Thu, 14 Apr 2005 12:02:55 +0200 (CEST) Date: Thu, 14 Apr 2005 12:02:55 +0200 From: Marc Olzheim To: Helmut Allwang Message-ID: <20050414100255.GA85697@stack.nl> References: <1908714315@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <1908714315@web.de> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: pxeboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 10:02:57 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 13, 2005 at 07:06:32PM +0200, Helmut Allwang wrote: > Hello, >=20 > it was possible for me, to boot a bootable floppy-image over pxeboot. >=20 > Is it possible to boot a CD-image over pxeboot? You mount the image (mdconfig + mount_cd9660) on your tftp server and off you go... ;-) load load -t mfs_root set vfs.root.mountfrom=3D"ufs:/dev/md0c" boot away... Marc --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXj/PezjnobFOgrERAh8VAKCQqi/dFeko0eYvTbXST2GYWwzZvwCdGHdE 5d/dWPdNNR6R+so6MK75cGI= =ZKzB -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 10:08:41 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85F016A4CE; Thu, 14 Apr 2005 10:08:41 +0000 (GMT) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02FAE43D4C; Thu, 14 Apr 2005 10:08:41 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from [192.168.168.138] (unknown [192.168.168.138]) by gddsn.org.cn (Postfix) with ESMTP id F385538CB49; Thu, 14 Apr 2005 18:08:36 +0800 (CST) Message-ID: <425E40DB.6030204@gddsn.org.cn> Date: Thu, 14 Apr 2005 18:07:23 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.7.6) Gecko/20050326 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Subject: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 10:08:41 -0000 folks: Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? DELL released a newest Server PE6850 with this card.thx From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 11:23:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AA8316A4CE; Thu, 14 Apr 2005 11:23:01 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B0F943D45; Thu, 14 Apr 2005 11:23:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EBMxsj096990; Thu, 14 Apr 2005 07:22:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EBMxT1045978; Thu, 14 Apr 2005 07:22:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 480C07306E; Thu, 14 Apr 2005 07:22:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414112259.480C07306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 07:22:59 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner2 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on alpha/alpha X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 11:23:01 -0000 TB --- 2005-04-14 10:18:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 10:18:22 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2005-04-14 10:18:22 - checking out the source tree TB --- 2005-04-14 10:18:22 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2005-04-14 10:18:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 10:27:39 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 10:27:39 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2005-04-14 10:27:39 - /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 --- 2005-04-14 11:19:27 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 11:19:27 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2005-04-14 11:19:27 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 11:19:28 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/kern_xxx.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/link_elf.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/md5c.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/sched_4bsd.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/subr_autoconf.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/subr_blist.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2005-04-14 11:22:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 11:22:59 - ERROR: failed to build generic kernel TB --- 2005-04-14 11:22:59 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 11:26:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5416016A4CE; Thu, 14 Apr 2005 11:26:26 +0000 (GMT) Received: from 62-15-209-148.inversas.jazztel.es (62-15-209-148.inversas.jazztel.es [62.15.209.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4CE643D3F; Thu, 14 Apr 2005 11:26:24 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3EBQPwi020561; Thu, 14 Apr 2005 13:26:25 +0200 (CEST) (envelope-from freebsd@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3EBQLuV085463; Thu, 14 Apr 2005 13:26:21 +0200 (CEST) (envelope-from freebsd@redesjm.local) From: Jose M Rodriguez To: stable@FreeBSD.org Date: Thu, 14 Apr 2005 13:26:17 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504141326.20284.freebsd@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.45; host: antares.redesjm.local) cc: njl@FreeBSD.org Subject: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 11:26:26 -0000 Anyone seen this? -- josemi cc -c -Os -fno-strict-aliasing -fomit-frame-pointer -march=pentium -mtune=c3 -pi pe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto types -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostd inc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/con trib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/s ys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib /ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param i nline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-string s -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreesta nding -Werror /usr/src/sys/kern/subr_bus.c /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_ get_drivers' *** Error code 1 Stop in /usr/obj/usr/src/sys/ANTARES. *** Error code 1 --- #include __FBSDID("$FreeBSD: src/sys/kern/subr_bus.c,v 1.156.2.6 2005/04/14 04:54:15 njl Exp $"); From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 12:34:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF97316A4CE; Thu, 14 Apr 2005 12:34:21 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A809243D46; Thu, 14 Apr 2005 12:34:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3ECYKqO011969; Thu, 14 Apr 2005 08:34:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3ECYKmW061345; Thu, 14 Apr 2005 08:34:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DF1BB7306E; Thu, 14 Apr 2005 08:34:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414123419.DF1BB7306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 08:34:19 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner2 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 12:34:21 -0000 TB --- 2005-04-14 11:22:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 11:22:59 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2005-04-14 11:22:59 - checking out the source tree TB --- 2005-04-14 11:22:59 - cd /home/tinderbox/RELENG_5/amd64/amd64 TB --- 2005-04-14 11:22:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 11:32:19 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 11:32:19 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-04-14 11:32:19 - /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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-04-14 12:29:44 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 12:29:44 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-04-14 12:29:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 12:29:44 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/link_elf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/md5c.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/sched_4bsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/subr_autoconf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/subr_blist.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/obj/amd64/tinderbox/RELENG_5/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. TB --- 2005-04-14 12:34:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 12:34:19 - ERROR: failed to build generic kernel TB --- 2005-04-14 12:34:19 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 13:21:15 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BED7716A4CF for ; Thu, 14 Apr 2005 13:21:15 +0000 (GMT) Received: from darwin.illian.net (darwin.illian.net [80.69.74.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFB9243D5C for ; Thu, 14 Apr 2005 13:21:14 +0000 (GMT) (envelope-from rutger.bevaart@illian.net) Received: from localhost (localhost.illian.net [127.0.0.1]) by darwin.illian.net (Postfix) with ESMTP id D25AB450F4 for ; Thu, 14 Apr 2005 15:21:24 +0200 (CEST) Received: from darwin.illian.net ([127.0.0.1]) by localhost (darwin.illian.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06102-05 for ; Thu, 14 Apr 2005 15:21:21 +0200 (CEST) Received: from www.illian.net (localhost.illian.net [127.0.0.1]) by darwin.illian.net (Postfix) with ESMTP id 19986450E7 for ; Thu, 14 Apr 2005 15:21:21 +0200 (CEST) Received: from 213.236.112.75 (SquirrelMail authenticated user rutger); by www.illian.net with HTTP; Thu, 14 Apr 2005 15:21:21 +0200 (CEST) Message-ID: <17089.213.236.112.75.1113484881.squirrel@213.236.112.75> In-Reply-To: <20050414120130.71FA716A4CE@hub.freebsd.org> References: <20050414120130.71FA716A4CE@hub.freebsd.org> Date: Thu, 14 Apr 2005 15:21:21 +0200 (CEST) From: "Rutger Bevaart" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at illian.net Subject: Re: scsi card recommendation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 13:21:15 -0000 Message: 14 Date: Thu, 14 Apr 2005 11:28:34 +0700 From: Dikshie Subject: Re: scsi card recommendation To: freebsd-stable@freebsd.org Message-ID: <20050414042834.GA90693@ppk.itb.ac.id> Content-Type: text/plain; charset=us-ascii -dikshie- i've got about 15 Dell 1750, 1850 and 2850 boxes that use AMR-based SCSI RAID controllers. i can manage these perfectly using emoore's port of the amrcontrol and MEGAMGR tools, under 5.x only after adding the 4x-compat ports package. but i can rebuild, check status etc. somehow i haven't been able to get it to work on a PE750 server using an AMR-based PCI card. funny. rgds Rutger From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 13:29:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 151E316A4CE; Thu, 14 Apr 2005 13:29:04 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9EAD43D53; Thu, 14 Apr 2005 13:29:01 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id j3EDSxgk031808; Thu, 14 Apr 2005 06:28:59 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id j3EDSx1q031807; Thu, 14 Apr 2005 06:28:59 -0700 (PDT) (envelope-from david) Date: Thu, 14 Apr 2005 06:28:59 -0700 From: David Wolfskill To: Jose M Rodriguez Message-ID: <20050414132859.GA60995@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Jose M Rodriguez , stable@freebsd.org, njl@freebsd.org References: <200504141326.20284.freebsd@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504141326.20284.freebsd@redesjm.local> User-Agent: Mutt/1.4.2.1i cc: stable@freebsd.org cc: njl@freebsd.org Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 13:29:04 -0000 On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: > Anyone seen this? [... /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 ... ] Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. 1.156.2.6. Perhaps something was overlooked in the MFC from 2005-04-14 04:54:15 UTC? Peace, david -- David H. Wolfskill david@catwhisker.org There is a place in software engineering for an appreciation of history. See http://www.catwhisker.org/~david/publickey.gpg for public key. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 13:41:19 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0A0516A4CE; Thu, 14 Apr 2005 13:41:18 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0117A43D31; Thu, 14 Apr 2005 13:41:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EDfHg7017340; Thu, 14 Apr 2005 09:41:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EDfH5H073863; Thu, 14 Apr 2005 09:41:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 55CEF7306E; Thu, 14 Apr 2005 09:41:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414134117.55CEF7306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 09:41:17 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner2 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 13:41:19 -0000 TB --- 2005-04-14 12:34:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 12:34:20 - starting RELENG_5 tinderbox run for i386/i386 TB --- 2005-04-14 12:34:20 - checking out the source tree TB --- 2005-04-14 12:34:20 - cd /home/tinderbox/RELENG_5/i386/i386 TB --- 2005-04-14 12:34:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 12:44:00 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 12:44:00 - cd /home/tinderbox/RELENG_5/i386/i386/src TB --- 2005-04-14 12:44:00 - /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 --- 2005-04-14 13:36:17 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 13:36:17 - cd /home/tinderbox/RELENG_5/i386/i386/src TB --- 2005-04-14 13:36:17 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 13:36:17 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/kern_xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/link_elf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/md5c.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/sched_4bsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/subr_autoconf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/subr_blist.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/i386/src/sys -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/i386/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/i386/i386/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/i386/i386/obj/tinderbox/RELENG_5/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/i386/i386/src. *** Error code 1 Stop in /tinderbox/RELENG_5/i386/i386/src. TB --- 2005-04-14 13:41:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 13:41:17 - ERROR: failed to build generic kernel TB --- 2005-04-14 13:41:17 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 14:27:15 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 716DD16A4CE for ; Thu, 14 Apr 2005 14:27:15 +0000 (GMT) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by mx1.FreeBSD.org (Postfix) with SMTP id 1349D43D1F for ; Thu, 14 Apr 2005 14:27:15 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 14 Apr 2005 14:27:14 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 0144E6109; Thu, 14 Apr 2005 09:27:12 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05439-06; Thu, 14 Apr 2005 09:27:11 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id 8ACD360D5; Thu, 14 Apr 2005 09:27:10 -0500 (CDT) Message-ID: <425E7DBD.8060107@alumni.rice.edu> Date: Thu, 14 Apr 2005 09:27:09 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Wolfskill References: <200504141326.20284.freebsd@redesjm.local> <20050414132859.GA60995@bunrab.catwhisker.org> In-Reply-To: <20050414132859.GA60995@bunrab.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: stable@freebsd.org cc: Jose M Rodriguez cc: njl@freebsd.org Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 14:27:15 -0000 On 4/14/2005 8:28 AM, David Wolfskill wrote: > On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: >>Anyone seen this? > > [... > /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' > *** Error code 1 > ... > ] > > Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. 1.156.2.6. > > Perhaps something was overlooked in the MFC from 2005-04-14 04:54:15 UTC? Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. Jon From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 14:48:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67B6216A4CE; Thu, 14 Apr 2005 14:48:50 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4898043D5F; Thu, 14 Apr 2005 14:48:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EEmmkF012670; Thu, 14 Apr 2005 10:48:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EEmmlo076837; Thu, 14 Apr 2005 10:48:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 67F0A7306E; Thu, 14 Apr 2005 10:48:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414144848.67F0A7306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 10:48:48 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 14:48:50 -0000 TB --- 2005-04-14 13:41:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 13:41:17 - starting RELENG_5 tinderbox run for i386/pc98 TB --- 2005-04-14 13:41:17 - checking out the source tree TB --- 2005-04-14 13:41:17 - cd /home/tinderbox/RELENG_5/i386/pc98 TB --- 2005-04-14 13:41:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 13:51:23 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 13:51:23 - cd /home/tinderbox/RELENG_5/i386/pc98/src TB --- 2005-04-14 13:51:23 - /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 --- 2005-04-14 14:44:37 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 14:44:37 - cd /home/tinderbox/RELENG_5/i386/pc98/src TB --- 2005-04-14 14:44:37 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 14:44:37 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/kern_xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/link_elf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/md5c.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/sched_4bsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/subr_autoconf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/subr_blist.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/i386/pc98/src/sys -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/altq -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/pf -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/RELENG_5/i386/pc98/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/i386/pc98/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/i386/pc98/obj/pc98/tinderbox/RELENG_5/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/i386/pc98/src. *** Error code 1 Stop in /tinderbox/RELENG_5/i386/pc98/src. TB --- 2005-04-14 14:48:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 14:48:48 - ERROR: failed to build generic kernel TB --- 2005-04-14 14:48:48 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 14:52:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC01E16A4CE for ; Thu, 14 Apr 2005 14:52:42 +0000 (GMT) Received: from conversation.bsdunix.ch (fun-dimension.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55FC543D3F for ; Thu, 14 Apr 2005 14:52:39 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost.localdomain (bert.mlan.solnet.ch [212.101.1.83]) (authenticated bits=0)j3EEv1ah089066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Apr 2005 16:57:02 +0200 (CEST) (envelope-from freebsdlists@bsdunix.ch) From: Thomas Vogt To: stable@freebsd.org Content-Type: text/plain Date: Thu, 14 Apr 2005 16:51:37 +0200 Message-Id: <1113490297.41050.2.camel@bert.mlan.solnet.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66, SARE_FROM_SPAM_WORD3 autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on conversation.bsdunix.ch Subject: 5.4 rc2 problems with tftpd service X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 14:52:43 -0000 Hello I can't download files via tftp. The tftp client gets a timeout and the written file is 0 bytes. I've done all my test on a local machine. No network was involved. System information: FreeBSD lizard 5.4-RC2 Wed Apr 13 15:04:30 UTC 2005 root@lizard:/usr/obj/usr/src/sys/UP i386 inetd.conf contains tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /var/tftpboot /var/tftpboot permission is set to 755 (root:wheel). I tried the -u root option for tftpd too but it didn't work either. Also changed ownership to nobody:nobody for /var/tftpboot but no luck. There is no error message in xferlog. I always get tftpd[47744]: 127.0.0.1: read request for //test: success. But the file was not transferred. Everything works fine if I remove the -l option or the -s option in inetd.conf for tftpd. Is this "strange" behavior with -l as option intended? Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 16:07:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C23016A4CE; Thu, 14 Apr 2005 16:07:57 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DCC243D31; Thu, 14 Apr 2005 16:07:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EG7t8c019716; Thu, 14 Apr 2005 12:07:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EG7tTO041275; Thu, 14 Apr 2005 12:07:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 909967306E; Thu, 14 Apr 2005 12:07:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414160755.909967306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 12:07:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner2 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 16:07:57 -0000 TB --- 2005-04-14 14:48:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 14:48:48 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2005-04-14 14:48:48 - checking out the source tree TB --- 2005-04-14 14:48:48 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2005-04-14 14:48:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 14:58:20 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 14:58:20 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2005-04-14 14:58:20 - /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 --- 2005-04-14 16:02:32 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 16:02:32 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2005-04-14 16:02:32 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 16:02:32 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/kern_xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/link_elf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/md5c.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/sched_4bsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/subr_autoconf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/subr_blist.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/ia64/ia64/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2005-04-14 16:07:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 16:07:55 - ERROR: failed to build generic kernel TB --- 2005-04-14 16:07:55 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 16:25:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EBB616A4CE for ; Thu, 14 Apr 2005 16:25:23 +0000 (GMT) Received: from mail.vericept.com (eternal.vericept.com [65.100.174.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6539743D41 for ; Thu, 14 Apr 2005 16:25:22 +0000 (GMT) (envelope-from matt.meola@vericept.com) Received: from matt.den-esniff.com ([10.3.1.71]) by mail.vericept.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Apr 2005 10:25:21 -0600 From: Matt Meola To: FreeBSD Stable List Content-Type: text/plain Organization: Vericept Corp. Date: Thu, 14 Apr 2005 10:25:21 -0600 Message-Id: <1113495921.966.21.camel@matt.den-esniff.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2005 16:25:22.0010 (UTC) FILETIME=[8E258BA0:01C5410E] Subject: FreeBSD 5.4 RC2 on a Compaq Laptop? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 16:25:23 -0000 Has anyone had any success getting 5.4RC2 installed on a Compaq Presario laptop? According to my BIOS, I have a Presario R3200 (Athlon XP processor). I get the splash screen, it begins the boot process and then it just shuts off the computer. I've tried to disable ACPI, but there appears to be no provision for that in the BIOS... Any help would be most appreciated. And thanks for all the hard work; it runs like a champ on my desktop box. -- Matt Meola Contractor Vericept Corporation 750 West Hampden Avenue, Suite 550 Englewood, Colorado 80110-2163 "Protecting Your Information and Reputationtm" tel: (303) 798-1568 ext. 5008 fax: (303) 268-0520 www.vericept.com From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 16:25:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C041916A4CE for ; Thu, 14 Apr 2005 16:25:46 +0000 (GMT) Received: from alogis.com (firewall2.alogis.com [62.8.223.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D4C843D55 for ; Thu, 14 Apr 2005 16:25:45 +0000 (GMT) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.1/8.13.1) with ESMTP id j3EGPhoB073502; Thu, 14 Apr 2005 18:25:43 +0200 (CEST) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.1/8.13.1/Submit) id j3EGPhmY073501; Thu, 14 Apr 2005 18:25:43 +0200 (CEST) (envelope-from hk) Date: Thu, 14 Apr 2005 18:25:43 +0200 From: Holger Kipp To: stable@freebsd.org Message-ID: <20050414162543.GA73129@intserv.int1.b.intern> References: <20050414100301.GA64468@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050414100301.GA64468@intserv.int1.b.intern> User-Agent: Mutt/1.4.2.1i Subject: Strange Shared Memory values: Apache::SizeLimit on 5.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 16:25:46 -0000 Hello, I am using Apache::SizeLimit and have the folowing problem: Process exits with the correct SIZE-Limit, but the SHARE-Size I get look a bit strange. As a result of this, checking for MAX_UNSHARED seem not to work. here a few results: exiting at SIZE=60004 KB SHARE=11733744 KB REQUESTS=2058 LIFETIME=55408 exiting at SIZE=60036 KB SHARE=11688304 KB REQUESTS=2043 LIFETIME=55154 exiting at SIZE=76088 KB SHARE=1009904 KB REQUESTS=166 LIFETIME=1988 exiting at SIZE=60084 KB SHARE=9565628 KB REQUESTS=1686 LIFETIME=54152 Anyone has an idea why SHARE goes up to 11GB or more? Is this a badly written application, or could this also be BSD::Resource returning wrong values here? Unfortunately I cannot check the application itself... top gives eg the following values for memory useage: 61828 57556 (Size, Res) This is on a 2GB HP ProLiant Dual Xeon System with FreeBSD 5.3-STABLE. Any help and/or explanation welcome! Especially: how can a single process have that much shared memory with a total of 350-400MB physical memory in use. Regards, Holger Kipp From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 16:51:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2B5416A4CE for ; Thu, 14 Apr 2005 16:51:56 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB02143D54 for ; Thu, 14 Apr 2005 16:51:56 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BD66C72DDD; Thu, 14 Apr 2005 09:51:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B854172DD9; Thu, 14 Apr 2005 09:51:56 -0700 (PDT) Date: Thu, 14 Apr 2005 09:51:56 -0700 (PDT) From: Doug White To: Jose M Rodriguez In-Reply-To: <200504111007.03460.freebsd@redesjm.local> Message-ID: <20050414094959.C24742@carver.gumbysoft.com> References: <200504111007.03460.freebsd@redesjm.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: stable@FreeBSD.org Subject: Re: Problems with world build in RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 16:51:57 -0000 On Mon, 11 Apr 2005, Jose M Rodriguez wrote: > Hi, > > I found a little problem with RELENG_5_4 buildworld in my env. > > I have a little patched RELENG_5_4 src in a local cvs server, mounted > ro,-L in the build machine (/usr/src) > > No rpc.lockd or rpc.statd daemon running in both machines. build > machine timesync with cvs server by ntpdate before build. > > Every time I do a rm -rf /usr/obj/* && cd /usr/src && make buildworld I > get: > > ===> share/info > ===> include > rm -f osreldate.h version vers.c > rm: version: Read-only file system > *** Error code 1 > > The only thing I change form previous week builds are the -L mount and > disabling the rpc.lockd and rpc.statd daemons in both machines. > > I can solve the problem doing a make obj before make buildworld. Sounds like these files may be leftovers from a local build on the NFS server. You might try doing 'make cleandir; make cleandir' on the server to remove any remnants. Areyou setting MAKEOBJDIRPREFIX in /etc/make.conf? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:11:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924BD16A4CE; Thu, 14 Apr 2005 17:11:28 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B41543D6D; Thu, 14 Apr 2005 17:11:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EHBQAm033651; Thu, 14 Apr 2005 13:11:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3EHBb4W077720; Thu, 14 Apr 2005 13:11:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7EE567306E; Thu, 14 Apr 2005 13:11:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414171126.7EE567306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 13:11:26 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:11:28 -0000 TB --- 2005-04-14 16:07:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 16:07:55 - starting RELENG_5 tinderbox run for sparc64/sparc64 TB --- 2005-04-14 16:07:55 - checking out the source tree TB --- 2005-04-14 16:07:55 - cd /home/tinderbox/RELENG_5/sparc64/sparc64 TB --- 2005-04-14 16:07:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-04-14 16:17:46 - building world (CFLAGS=-O -pipe) TB --- 2005-04-14 16:17:46 - cd /home/tinderbox/RELENG_5/sparc64/sparc64/src TB --- 2005-04-14 16:17:46 - /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 --- 2005-04-14 17:08:14 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-04-14 17:08:14 - cd /home/tinderbox/RELENG_5/sparc64/sparc64/src TB --- 2005-04-14 17:08:14 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 17:08:14 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/kern_xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/link_elf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/md5c.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/sched_4bsd.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/subr_autoconf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/subr_blist.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/subr_bus.c /tinderbox/RELENG_5/sparc64/sparc64/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/obj/sparc64/tinderbox/RELENG_5/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/src. TB --- 2005-04-14 17:11:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 17:11:26 - ERROR: failed to build generic kernel TB --- 2005-04-14 17:11:26 - tinderbox aborted From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:13:52 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE3D416A4CE for ; Thu, 14 Apr 2005 17:13:52 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AEC843D39 for ; Thu, 14 Apr 2005 17:13:52 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8B73D72DDB; Thu, 14 Apr 2005 10:13:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 8999A72DCB for ; Thu, 14 Apr 2005 10:13:52 -0700 (PDT) Date: Thu, 14 Apr 2005 10:13:52 -0700 (PDT) From: Doug White To: freebsd-stable@freebsd.org In-Reply-To: <20050411110240.GA2118@gicco.homeip.net> Message-ID: <20050414095534.U24742@carver.gumbysoft.com> References: <20050411110240.GA2118@gicco.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Alternate menu logos X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:13:53 -0000 (Changing the subject since its not reflective of the tone of the message. Apologies to the poster, but since this is a touchy subject I'm going to make this a more technical discussion.) On Mon, 11 Apr 2005, Hanspeter Roth wrote: > - or have an convenient flag in loaders.conf that allows to > run Beastie menu but display some other decoration? I I have an idea and the patch in PR 74577 is about halfway there. I suggest providing a script that forth-ifies a provided ASCII logo, and a loader option to load a banner file from disk. This way, if, say, an OEM wanted to put contact information in there, they could put in loader.conf: banner_enable="YES" banner_file="/boot/oem.banner" and have that displayed instead of the beastie. The forthifier script would turn the file into a forth function definition and then it can be included with standard routines in the loader. Then your banner function would just call it. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:21:36 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC78F16A4CE for ; Thu, 14 Apr 2005 17:21:36 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E1A943D39 for ; Thu, 14 Apr 2005 17:21:36 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7BC0D72DDD; Thu, 14 Apr 2005 10:21:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 792CF72DDB; Thu, 14 Apr 2005 10:21:36 -0700 (PDT) Date: Thu, 14 Apr 2005 10:21:36 -0700 (PDT) From: Doug White To: "Jim C. Nasby" In-Reply-To: <20050414031845.GF58835@decibel.org> Message-ID: <20050414102022.F24742@carver.gumbysoft.com> References: <52802.1113341617@thrush.ravenbrook.com> <20050414031845.GF58835@decibel.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marc Olzheim cc: freebsd-stable@freebsd.org cc: Vivek Khera cc: Dan Nelson cc: Matthias Buelow Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:21:36 -0000 On Wed, 13 Apr 2005, Jim C. Nasby wrote: > It's extremely disappointing that you can't turn this off. I've been > bashing linux for months now about how they think it's OK to kill random > processes. But at least they'll let you turn it off. It's extremely disappointing that you haven't submitted patches yet, particularly when you have so many testers lined up. :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:26:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA12C16A4CE for ; Thu, 14 Apr 2005 17:26:26 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B582943D5A for ; Thu, 14 Apr 2005 17:26:26 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id A734772DDF; Thu, 14 Apr 2005 10:26:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A212472DDB; Thu, 14 Apr 2005 10:26:26 -0700 (PDT) Date: Thu, 14 Apr 2005 10:26:26 -0700 (PDT) From: Doug White To: John Hawkes-Reed In-Reply-To: <200504111746.42804.hirez@libeljournal.com> Message-ID: <20050414102210.K24742@carver.gumbysoft.com> References: <200504111746.42804.hirez@libeljournal.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: Hp dc7100 installs 5.4-rc1 from CD but won't boot from HD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:26:27 -0000 On Mon, 11 Apr 2005, John Hawkes-Reed wrote: > (Which I think covers the problem) > > Boots from CD ok, USB keyboard seems less than reliable, so I'm using a PS2 > item. Running through 'standard' install appears to write data to the (SATA > ICH6 controller) disk, but on reboot it sits at the F1: FreeBSD prompt > beeping every ten seconds. > > Is there likely to be anything obvious I've missed? (Or indeed more useful > data I can provide.) Your system appears to require packet mode, but sysinstall didn't enable it. Two possible fixes: 1. If you have disc 2: Boot the install CD, go to Fixit, start up fixit off CD, then run boot0cfg -o packet adX where adX is the appropriate disk device. 2. Reinstall, but use the standard MBR rather than the boot manager. Once you get the system booted you can install the boot manager with: boot0cfg -B -o packet adX where adX is the appropriate disk device. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:38:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBC5C16A4CE for ; Thu, 14 Apr 2005 17:38:54 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D0143D45 for ; Thu, 14 Apr 2005 17:38:54 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8711872DDF; Thu, 14 Apr 2005 10:38:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 84A6272DDB; Thu, 14 Apr 2005 10:38:54 -0700 (PDT) Date: Thu, 14 Apr 2005 10:38:54 -0700 (PDT) From: Doug White To: Philip Murray In-Reply-To: Message-ID: <20050414103735.A24742@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: Intel 6300ESB (ICH) SMBus controller not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:38:54 -0000 On Tue, 12 Apr 2005, Philip Murray wrote: > Hi, > > I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver > doesn't want to work with it, I get the following on boot: > > ichsmb0: port 0x8c0-0x8df irq 17 > at device 31.3 on pci0 > device_attach: ichsmb0 attach returned 6 > > It then doesn't load smb or smbus. I had a look in the source and it is > supposed to work with this controller. > > Is this something wrong with the driver? or have I left out some bit of > configuration? > > Attached is the output from boot -v and my kernel configuration. Is > there any other debugging output that would be useful? According to the boot -v messages the I/O range map is getting attached to the wrong function on that chip: found-> vendor=0x8086, dev=0x25a3, revid=0x02 bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02a8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 000008c0, size 5, enabled but it should be on this: ichsmb0: port 0x8c0-0x8df irq 17 at device 31.3 on pci0 I'll poke at this a bit, but you should check for a BIOS update. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:44:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98F8816A4D0 for ; Thu, 14 Apr 2005 17:44:44 +0000 (GMT) Received: from 62-15-209-148.inversas.jazztel.es (62-15-209-148.inversas.jazztel.es [62.15.209.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 379CA43D49 for ; Thu, 14 Apr 2005 17:44:43 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3EHihTO000759; Thu, 14 Apr 2005 19:44:43 +0200 (CEST) (envelope-from freebsd@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3EHiaCC000788; Thu, 14 Apr 2005 19:44:36 +0200 (CEST) (envelope-from freebsd@redesjm.local) From: Jose M Rodriguez To: Doug White Date: Thu, 14 Apr 2005 19:44:35 +0200 User-Agent: KMail/1.8 References: <200504111007.03460.freebsd@redesjm.local> <20050414094959.C24742@carver.gumbysoft.com> In-Reply-To: <20050414094959.C24742@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504141944.35956.freebsd@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.45; host: antares.redesjm.local) cc: stable@FreeBSD.org cc: Jose M Rodriguez Subject: Re: Problems with world build in RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:44:44 -0000 El Thursday 14 April 2005 18:51, Doug White escribi=F3: > On Mon, 11 Apr 2005, Jose M Rodriguez wrote: > > Hi, > > > > I found a little problem with RELENG_5_4 buildworld in my env. > > > > I have a little patched RELENG_5_4 src in a local cvs server, > > mounted ro,-L in the build machine (/usr/src) > > > > No rpc.lockd or rpc.statd daemon running in both machines. build > > machine timesync with cvs server by ntpdate before build. > > > > Every time I do a rm -rf /usr/obj/* && cd /usr/src && make > > buildworld I get: > > > > =3D=3D=3D> share/info > > =3D=3D=3D> include > > rm -f osreldate.h version vers.c > > rm: version: Read-only file system > > *** Error code 1 > > > > The only thing I change form previous week builds are the -L mount > > and disabling the rpc.lockd and rpc.statd daemons in both machines. > > > > I can solve the problem doing a make obj before make buildworld. > > Sounds like these files may be leftovers from a local build on the > NFS server. You might try doing 'make cleandir; make cleandir' on > the server to remove any remnants. > No builds made in the nfs server ever. make cleandir gets to the same=20 result. > Areyou setting MAKEOBJDIRPREFIX in /etc/make.conf? No. /usr/obj is in a local fs. Only /usr/src is in the nfs server and=20 mounted ro. Seems I can't reproduce it with nfs locking enabled and well configured. =20 Nor with /usr/obj populated before the build. Maybe a make issue? =2D- josemi From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:56:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2657D16A4CE for ; Thu, 14 Apr 2005 17:56:46 +0000 (GMT) Received: from akac.axelero.hu (akac.axelero.hu [195.228.240.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F5D443D45 for ; Thu, 14 Apr 2005 17:56:43 +0000 (GMT) (envelope-from kutizs@axelero.hu) Received: from tinca (ktv32-241-76.catv-pool.axelero.hu [62.201.76.241]) by akac.axelero.hu (8.12.11/8.12.11) with SMTP id j3EHufcn075697 for ; Thu, 14 Apr 2005 19:56:41 +0200 (CEST) Date: Thu, 14 Apr 2005 20:00:07 +0200 From: Zsolt =?ISO-8859-2?Q?K=FAti?= To: freebsd-stable@freebsd.org Message-Id: <20050414200007.3d2dfd87.kutizs@axelero.hu> In-Reply-To: <20050414102210.K24742@carver.gumbysoft.com> References: <200504111746.42804.hirez@libeljournal.com> <20050414102210.K24742@carver.gumbysoft.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-VBMilter: scanned Subject: Hp dc7100 installs 5.4-rc1 from CD but won't boot from HD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:56:46 -0000 > On Mon, 11 Apr 2005, John Hawkes-Reed wrote: >=20 > (Which I think covers the problem) > > Boots from CD ok, USB keyboard seems less than reliable, so I'm > using a PS2 item. Running through 'standard' install appears to > write data to the (SATA ICH6 controller) disk, but on reboot it sits > at the F1: FreeBSD prompt beeping every ten seconds. > Is there likely to be anything obvious I've missed? (Or indeed more > useful data I can provide.) Hello, I had the same problem recently. What I figured out is that in the BIOS you can change automatic geometry detection to another one. Don't remember which. Mail me if you can't find it. Bye=20 Zsolt --------------- Zsolt K=FAti From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 17:59:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DCB216A4CE for ; Thu, 14 Apr 2005 17:59:45 +0000 (GMT) Received: from geraint.oxfam.org.uk (geraint.oxfam.org.uk [193.133.69.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDA1943D49 for ; Thu, 14 Apr 2005 17:59:43 +0000 (GMT) (envelope-from saprillya@oxfam.or.id) X-SEF-Processed: 5_0_0_713__2005_04_14_18_59_00 X-SEF-6E8B4D2D-7A1F-4551-AB60-FEBFFD151913: 1 Received: from Unknown [10.10.1.111] by geraint.oxfam.org.uk - SurfControl E-mail Filter (5.0); Thu, 14 Apr 2005 18:59:00 +0100 From: saprillya@oxfam.or.id To: stable@freebsd.org Message-ID: Date: Fri, 15 Apr 2005 01:00:58 +0700 X-MIMETrack: Serialize by Router on OXGBMGAT02/Oxfam(Release 5.0.13a |April 8, 2004) at 14/04/2005 18:59:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Sukma Tin Aprillya/Yogyakarta/International/Oxfam is out of the office. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 17:59:45 -0000 I will be out of the office starting 11/04/2005 and will not return until 18/04/2005. I will respond to your message when I return. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 18:23:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09A9116A4CE; Thu, 14 Apr 2005 18:23:45 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2E3043D31; Thu, 14 Apr 2005 18:23:44 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j3EIJSba031980; Thu, 14 Apr 2005 14:19:28 -0400 Message-ID: <425EB486.5090001@root.org> Date: Thu, 14 Apr 2005 11:20:54 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: noackjr@alumni.rice.edu References: <200504141326.20284.freebsd@redesjm.local> <20050414132859.GA60995@bunrab.catwhisker.org> <425E7DBD.8060107@alumni.rice.edu> In-Reply-To: <425E7DBD.8060107@alumni.rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: stable@freebsd.org cc: Jose M Rodriguez Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 18:23:45 -0000 Jon Noack wrote: > On 4/14/2005 8:28 AM, David Wolfskill wrote: > >> On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: >> >>> Anyone seen this? >> >> >> [... >> /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for >> 'devclass_get_drivers' >> *** Error code 1 >> ... >> ] >> >> Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. 1.156.2.6. >> >> Perhaps something was overlooked in the MFC from 2005-04-14 04:54:15 UTC? > > Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. I've committed the prototype, much apologies for the breakage. I compiled the patch in my RELENG_5 tree just fine, but it appears the kernel build may be referencing /sys for includes instead of ../../../sys or whatever. Thus build-testing MFC patches on a -current box is not a good test. -- Nate From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 18:31:39 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D287916A4CF for ; Thu, 14 Apr 2005 18:31:39 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4917043D3F for ; Thu, 14 Apr 2005 18:31:39 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so434969rnf for ; Thu, 14 Apr 2005 11:31:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MNbLkG+EOja/HrJin5eTfLvTnIXLNEQwpXGkfu0e88T5QSLuVQMKvknJOb0Y6pcrXIu7tkr8LsDFmyfrepCVKLKykSom6vrQ9dai51ltRO1TGY0jnHKeokj7D0+wqeWgW0OnDBifRKmpbEGYdAxbkxy3HYos4ITQcmym/y0Absw= Received: by 10.38.65.55 with SMTP id n55mr2085529rna; Thu, 14 Apr 2005 11:31:38 -0700 (PDT) Received: by 10.38.104.23 with HTTP; Thu, 14 Apr 2005 11:31:37 -0700 (PDT) Message-ID: <7579f7fb050414113147698bbf@mail.gmail.com> Date: Thu, 14 Apr 2005 11:31:37 -0700 From: Matthew Jacob To: wsk In-Reply-To: <425E40DB.6030204@gddsn.org.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425E40DB.6030204@gddsn.org.cn> cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 18:31:40 -0000 Yes, the 234X cards have been supported for quite a while. DELL has a clone card which up until recently wasn't supported. The 236X/63XX cards are not yet supported. On 4/14/05, wsk wrote: > folks: > Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? > DELL released a newest Server PE6850 with this card.thx > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 20:04:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00E0016A4CE for ; Thu, 14 Apr 2005 20:04:55 +0000 (GMT) Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9FBF43D2F for ; Thu, 14 Apr 2005 20:04:53 +0000 (GMT) (envelope-from hirez@libeljournal.com) Received: from 82-40-167-142.cable.ubr01.chap.blueyonder.co.uk ([82.40.167.142] helo=propellor.libeljournal.com ident=hirez) 1.181) id 425ecce1.8817.15e7; Thu, 14 Apr 2005 21:04:49 +0100 (envelope-sender ) Received: from twister.libeljournal.com (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTP id C48AA20C0; Thu, 14 Apr 2005 21:04:45 +0100 (BST) Message-Id: <6.0.1.1.2.20050414204935.034c9a60@127.0.0.1> X-Sender: pop3.gradwell.net:postmaster%pop3.libeljournal.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 14 Apr 2005 21:05:33 +0100 To: freebsd-stable@freebsd.org From: John Hawkes-Reed In-Reply-To: <20050414200007.3d2dfd87.kutizs@axelero.hu> References: <200504111746.42804.hirez@libeljournal.com> <20050414102210.K24742@carver.gumbysoft.com> <20050414200007.3d2dfd87.kutizs@axelero.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: kutizs@axelero.hu Subject: Re: Hp dc7100 installs 5.4-rc1 from CD but won't boot from HD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 20:04:55 -0000 At 19:00 14/04/2005, Zsolt =?ISO-8859-2?Q?K=FAti?= wrote: > > On Mon, 11 Apr 2005, John Hawkes-Reed wrote: > > > > (Which I think covers the problem) > > > > Boots from CD ok, USB keyboard seems less than reliable, so I'm > > using a PS2 item. Running through 'standard' install appears to > > write data to the (SATA ICH6 controller) disk, but on reboot it sits > > at the F1: FreeBSD prompt beeping every ten seconds. > > Is there likely to be anything obvious I've missed? (Or indeed more > > useful data I can provide.) > >Hello, > >I had the same problem recently. What I figured out is that in the BIOS > you can change automatic geometry detection to another one. Don't >remember which. Mail me if you can't find it. I thought I'd been through all the combinations available in the BIOS, but I won't be surprised if I missed one. What worked for you? One thing, probably critical, that I forgot to mention in the excitement, is that fdisk complains that the reported geometry is 'wrong' and substitutes another C/H/S combination that doesn't use all the disk. Neither that, nor the different again combination reported by atacontrol, appeared to make much difference. My notes on the relevant values are at work, but I'll happily reproduce them if needed. [ ... ] Doug White wrote: >Your system appears to require packet mode, but sysinstall didn't enable >it. Two possible fixes: > >1. If you have disc 2: Boot the install CD, go to Fixit, start up fixit >off CD, then run > >boot0cfg -o packet adX > >where adX is the appropriate disk device. > >2. Reinstall, but use the standard MBR rather than the boot manager. Once >you get the system booted you can install the boot manager with: > >boot0cfg -B -o packet adX > >where adX is the appropriate disk device. Aha! Thanks. I think I've got some reading up to do... In the end I ran out of time, so created a small partition and installed a minimal Debian thereon. Grub boots into 5.4 and all's well with the world. However, for the sake of completeness and to provide an answer for the next poor sod who meets this problem, I'll overwrite Debian and try the above. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 20:39:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59E8816A4CE for ; Thu, 14 Apr 2005 20:39:48 +0000 (GMT) Received: from obelix.sunrise.ch (mailrelay3.sunrise.ch [194.158.229.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E18E43D49 for ; Thu, 14 Apr 2005 20:39:45 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (pop-ls-18-1-dialup-139.freesurf.ch [194.230.186.139]) by obelix.sunrise.ch (8.12.10/8.12.10) with ESMTP id j3EKdewv003216 for ; Thu, 14 Apr 2005 22:39:42 +0200 Received: from goofy.here (localhost.here [127.0.0.1]) by gicco.homeip.net (8.13.3/8.13.1) with ESMTP id j3EIxJUX033004 for ; Thu, 14 Apr 2005 20:59:19 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by goofy.here (8.13.3/8.13.1/Submit) id j3EIxJva033003 for freebsd-stable@freebsd.org; Thu, 14 Apr 2005 20:59:19 +0200 (CEST) (envelope-from hampi@rootshell.be) X-Authentication-Warning: goofy.here: idefix set sender to hampi@rootshell.be using -f Date: Thu, 14 Apr 2005 20:59:19 +0200 From: Hanspeter Roth To: freebsd-stable@freebsd.org Message-ID: <20050414185919.GA15326@gicco.homeip.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050411110240.GA2118@gicco.homeip.net> <20050414095534.U24742@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050414095534.U24742@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i Subject: Re: Alternate menu logos X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 20:39:48 -0000 On Apr 14 at 10:13, Doug White spoke: > (Changing the subject since its not reflective of the tone of the > message. Apologies to the poster, but since this is a touchy subject I'm > going to make this a more technical discussion.) The original subject was not technical but it was precise. > On Mon, 11 Apr 2005, Hanspeter Roth wrote: > > > - or have an convenient flag in loaders.conf that allows to > > run Beastie menu but display some other decoration? > > I I have an idea and the patch in PR 74577 is about halfway there. I > suggest providing a script that forth-ifies a provided ASCII logo, and a If somebody provides the script, nice. But if it's just another suggestion that only delays the matter like the talks of the "new FreeBSD Logo" did then it's better to have a quick and dirty solution. > loader option to load a banner file from disk. This way, if, say, an OEM > wanted to put contact information in there, they could put in loader.conf: > > banner_enable="YES" > banner_file="/boot/oem.banner" > > and have that displayed instead of the beastie. > > The forthifier script would turn the file into a forth function definition > and then it can be included with standard routines in the loader. Then > your banner function would just call it. Of course this solution is more flexible and thus to favor. Just somebody do it... -Hanspeter From owner-freebsd-stable@FreeBSD.ORG Thu Apr 14 22:19:52 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C03CD16A4CE for ; Thu, 14 Apr 2005 22:19:52 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF37443D48 for ; Thu, 14 Apr 2005 22:19:51 +0000 (GMT) (envelope-from bsdfreak@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so645827nzf for ; Thu, 14 Apr 2005 15:19:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rXtsooXs1KMgN8XTWYjJKrtRWBdt6tdbcGuQnav92oYDqWNS3y0vo8o4vWhOyRnNPP1X3CS1og8YuGKy/LW2NvrhcWqzipr6bas8eN/3DKLIvpmfx8aIQ4tgMyeQIUzBpNUsuzz8Lz1vRsyqqt3n4/j7yVMCL9V584SIaV6fcHk= Received: by 10.36.59.9 with SMTP id h9mr150815nza; Thu, 14 Apr 2005 15:19:50 -0700 (PDT) Received: by 10.36.7.11 with HTTP; Thu, 14 Apr 2005 15:19:50 -0700 (PDT) Message-ID: Date: Thu, 14 Apr 2005 18:19:50 -0400 From: Alexander Chamandy To: freebsd-questions@freebsd.org, freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Problem with SoundBlaster Audigy on FreeBSD 5.4-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Chamandy List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 22:19:52 -0000 I'm having problems after a recent upgrade to FreeBSD 5.4-STABLE.=20 RC-1 seemed to work fine, but now my media files (audio and video alike) are not properly playing. And I get this error: pcm0:play:0: play interrupt timeout, channel dead Has anyone experienced this and if so, know of a reasonable workaround? dmesg: FreeBSD 5.4-STABLE #14: Thu Apr 14 16:29:53 EDT 2005 alex@vetra.envescent.net:/usr/src/sys/amd64/compile/vetra Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.15-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0xf48 Stepping =3D 8 Features=3D0x78bfbff AMD Features=3D0xe0500800 real memory =3D 2147418112 (2047 MB) avail memory =3D 2064994304 (1969 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf0-0xcf3,0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfc003000-0xfc003fff irq 22 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfc004000-0xfc004fff irq 21 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pcib1: at device 10.0 on pci0 pci1: on pcib1 pcm0: port 0xa000-0xa01f irq 19 at device 7.0 on pci1 pcm0: pci1: at device 7.2 (no driver attached) ahc0: port 0xa800-0xa8ff mem 0xfb004000-0xfb004fff irq 16 at device 8.0 on pci1 aic7890/91: Ultra2 Wide Channel A, SCSI Id=3D7, 32/253 SCBs atapci1: port 0xbc00-0xbc0f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 mem 0xfb006000-0xfb0061ff irq 17 at device 13.0 on pci1 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pcib2: at device 11.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pci2: at device 0.1 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xd8000-0xdd7ff,0xd0000-0xd7fff,0xc0000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: vendor 0x0543 product 0x1167, class 9/0, rev 2.00/ff.ff, addr 2 uhub2: 4 ports with 4 removable, self powered ugen0: Saitek Saitek X45, rev 1.00/0.02, addr 3 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 4, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2009148084 Hz quality 800 Timecounters tick every 1.000 msec ad2: 58644MB [119150/16/63] at ata1-master UDMA= 100 acd0: DVDR at ata1-slave PIO4 da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) da0: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) Mounting root from ufs:/dev/ad2s1a nv0: port 0xd000-0xd007 mem 0xfc000000-0xfc000fff irq 22 at device 5.0 on pci0 nv0: Ethernet address 00:0d:61:14:6f:39 nv0: Ethernet address: 00:0d:61:14:6f:39 miibus0: on nv0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto --=20 Best wishes, Alexander G. Chamandy Webmaster www.bsdfreak.org Your Source For BSD News! From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 04:23:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BF3016A4CE for ; Fri, 15 Apr 2005 04:23:53 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id 375A643D1F for ; Fri, 15 Apr 2005 04:23:52 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 26111 invoked by alias); 15 Apr 2005 04:36:06 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 15 Apr 2005 04:36:06 -0000 Date: Fri, 15 Apr 2005 13:23:51 +0900 From: Joel To: stable@freebsd.org In-Reply-To: <425EB486.5090001@root.org> References: <425E7DBD.8060107@alumni.rice.edu> <425EB486.5090001@root.org> Message-Id: <20050415131817.E89F.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 04:23:53 -0000 On Thu, 14 Apr 2005 11:20:54 -0700 Nate Lawson wrote > Jon Noack wrote: > > On 4/14/2005 8:28 AM, David Wolfskill wrote: > > > >> On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: > >> > >>> Anyone seen this? > >> > >> > >> [... > >> /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for > >> 'devclass_get_drivers' > >> *** Error code 1 > >> ... > >> ] > >> > >> Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. 1.156.2.6. > >> > >> Perhaps something was overlooked in the MFC from 2005-04-14 04:54:15 UTC? > > > > Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. > > I've committed the prototype, much apologies for the breakage. I > compiled the patch in my RELENG_5 tree just fine, but it appears the > kernel build may be referencing /sys for includes instead of > ../../../sys or whatever. Thus build-testing MFC patches on a -current > box is not a good test. Okay, I started a build makeworld in /usr/src last night, and then build make kernel hits this. What do we do next? Is it okay to go back to cvsup, and will that pick up the changes? -- Joel Rees digitcom, inc. $B3t<02q ** From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 05:32:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B88A16A4CE for ; Fri, 15 Apr 2005 05:32:44 +0000 (GMT) Received: from smtp.owt.com (smtp.owt.com [204.118.6.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD79F43D1D for ; Fri, 15 Apr 2005 05:32:43 +0000 (GMT) (envelope-from kstewart@owt.com) Received: from [207.41.94.233] (owt-207-41-94-233.owt.com [207.41.94.233]) by smtp.owt.com (8.12.8/8.12.8) with ESMTP id j3F5VxUF028927 for ; Thu, 14 Apr 2005 22:31:59 -0700 From: Kent Stewart To: freebsd-stable@freebsd.org Date: Thu, 14 Apr 2005 22:32:42 -0700 User-Agent: KMail/1.8 References: <425E7DBD.8060107@alumni.rice.edu> <425EB486.5090001@root.org> <20050415131817.E89F.REES@ddcom.co.jp> In-Reply-To: <20050415131817.E89F.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504142232.42274.kstewart@owt.com> Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 05:32:44 -0000 On Thursday 14 April 2005 09:23 pm, Joel wrote: > On Thu, 14 Apr 2005 11:20:54 -0700 > Nate Lawson wrote > > > Jon Noack wrote: > > > On 4/14/2005 8:28 AM, David Wolfskill wrote: > > >> On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: > > >>> Anyone seen this? > > >> > > >> [... > > >> /usr/src/sys/kern/subr_bus.c:1082: warning: no previous > > >> prototype for 'devclass_get_drivers' > > >> *** Error code 1 > > >> ... > > >> ] > > >> > > >> Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. > > >> 1.156.2.6. > > >> > > >> Perhaps something was overlooked in the MFC from 2005-04-14 > > >> 04:54:15 UTC? > > > > > > Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. > > > > I've committed the prototype, much apologies for the breakage. I > > compiled the patch in my RELENG_5 tree just fine, but it appears > > the kernel build may be referencing /sys for includes instead of > > ../../../sys or whatever. Thus build-testing MFC patches on a > > -current box is not a good test. > > Okay, I started a build makeworld in /usr/src last night, and then > build make kernel hits this. > > What do we do next? Is it okay to go back to cvsup, and will that > pick up the changes? > Joel, Can I give you a bad time. We were always told that if you follow x-stable, you were to follow cvs-all. Then, you would have seen his fix committed around 1811 UTC. FWIW, you are just in time anyway because they added a security notice and if you cvsup now, you will also get that fix. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 05:49:22 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CCB516A4CE for ; Fri, 15 Apr 2005 05:49:22 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id 5EA1343D46 for ; Fri, 15 Apr 2005 05:49:21 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 27926 invoked by alias); 15 Apr 2005 06:01:37 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 15 Apr 2005 06:01:37 -0000 Date: Fri, 15 Apr 2005 14:49:22 +0900 From: Joel To: freebsd-stable@freebsd.org In-Reply-To: <200504142232.42274.kstewart@owt.com> References: <20050415131817.E89F.REES@ddcom.co.jp> <200504142232.42274.kstewart@owt.com> Message-Id: <20050415144031.E8A2.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 05:49:22 -0000 On Thu, 14 Apr 2005 22:32:42 -0700 Kent Stewart wrote > On Thursday 14 April 2005 09:23 pm, Joel wrote: > > On Thu, 14 Apr 2005 11:20:54 -0700 > > Nate Lawson wrote > > > > > Jon Noack wrote: > > > > On 4/14/2005 8:28 AM, David Wolfskill wrote: > > > >> On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: > > > >>> Anyone seen this? > > > >> > > > >> [... > > > >> /usr/src/sys/kern/subr_bus.c:1082: warning: no previous > > > >> prototype for 'devclass_get_drivers' > > > >> *** Error code 1 > > > >> ... > > > >> ] > > > >> > > > >> Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. > > > >> 1.156.2.6. > > > >> > > > >> Perhaps something was overlooked in the MFC from 2005-04-14 > > > >> 04:54:15 UTC? > > > > > > > > Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. > > > > > > I've committed the prototype, much apologies for the breakage. I > > > compiled the patch in my RELENG_5 tree just fine, but it appears > > > the kernel build may be referencing /sys for includes instead of > > > ../../../sys or whatever. Thus build-testing MFC patches on a > > > -current box is not a good test. > > > > Okay, I started a build makeworld in /usr/src last night, and then > > build make kernel hits this. > > > > What do we do next? Is it okay to go back to cvsup, and will that > > pick up the changes? > > > > Joel, > > Can I give you a bad time. Of course. My kids would say I deserve it, too, since I'm such a tease around the house. > We were always told that if you follow > x-stable, you were to follow cvs-all. (B... as in editing the example to set the default host to cvsup3.jp.freebsd.org, and doing sudo cvsup -g -L 2 stable-supfile right before the make buildworld? > Then, you would have seen his fix > committed around 1811 UTC. I think I was in bed by then. (UTC+9 here.) > FWIW, you are just in time anyway because they added a security notice > and if you cvsup now, you will also get that fix. So the system is not in an unstable situation such that repeating the cvsup would have me trying to build from inconsistent libraries or anything like that? What the heck, I'll take a backup and give it a spin. Thanks. -- Joel Rees digitcom, inc. $B3t<02q ** From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 06:19:07 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 183F216A4CE for ; Fri, 15 Apr 2005 06:19:07 +0000 (GMT) Received: from smtp.owt.com (smtp.owt.com [204.118.6.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEBB743D53 for ; Fri, 15 Apr 2005 06:19:06 +0000 (GMT) (envelope-from kstewart@owt.com) Received: from [207.41.94.233] (owt-207-41-94-233.owt.com [207.41.94.233]) by smtp.owt.com (8.12.8/8.12.8) with ESMTP id j3F6IGUF029917; Thu, 14 Apr 2005 23:18:17 -0700 From: Kent Stewart To: freebsd-stable@freebsd.org Date: Thu, 14 Apr 2005 23:18:59 -0700 User-Agent: KMail/1.8 References: <20050415131817.E89F.REES@ddcom.co.jp> <200504142232.42274.kstewart@owt.com> <20050415144031.E8A2.REES@ddcom.co.jp> In-Reply-To: <20050415144031.E8A2.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504142319.00148.kstewart@owt.com> cc: Joel Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 06:19:07 -0000 On Thursday 14 April 2005 10:49 pm, Joel wrote: > On Thu, 14 Apr 2005 22:32:42 -0700 > Kent Stewart wrote > > > On Thursday 14 April 2005 09:23 pm, Joel wrote: > > > On Thu, 14 Apr 2005 11:20:54 -0700 > > > Nate Lawson wrote > > > > > > > Jon Noack wrote: > > > > > On 4/14/2005 8:28 AM, David Wolfskill wrote: > > > > >> On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: > > > > >>> Anyone seen this? > > > > >> > > > > >> [... > > > > >> /usr/src/sys/kern/subr_bus.c:1082: warning: no previous > > > > >> prototype for 'devclass_get_drivers' > > > > >> *** Error code 1 > > > > >> ... > > > > >> ] > > > > >> > > > > >> Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. > > > > >> 1.156.2.6. > > > > >> > > > > >> Perhaps something was overlooked in the MFC from 2005-04-14 > > > > >> 04:54:15 UTC? > > > > > > > > > > Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. > > > > > > > > I've committed the prototype, much apologies for the breakage. > > > > I compiled the patch in my RELENG_5 tree just fine, but it > > > > appears the kernel build may be referencing /sys for includes > > > > instead of ../../../sys or whatever. Thus build-testing MFC > > > > patches on a -current box is not a good test. > > > > > > Okay, I started a build makeworld in /usr/src last night, and > > > then build make kernel hits this. > > > > > > What do we do next? Is it okay to go back to cvsup, and will that > > > pick up the changes? > > > > Joel, > > > > Can I give you a bad time. > > Of course. My kids would say I deserve it, too, since I'm such a > tease around the house. > > > We were always told that if you follow > > x-stable, you were to follow cvs-all. > > ... as in editing the example to set the default host to > cvsup3.jp.freebsd.org, and doing > > sudo cvsup -g -L 2 stable-supfile > > right before the make buildworld? > > > Then, you would have seen his fix > > committed around 1811 UTC. > > I think I was in bed by then. (UTC+9 here.) > > > FWIW, you are just in time anyway because they added a security > > notice and if you cvsup now, you will also get that fix. > > So the system is not in an unstable situation such that repeating the > cvsup would have me trying to build from inconsistent libraries or > anything like that? When you do the buildworld, you get a new world and then the kernel will build. This is one of the reasons to buildworld, buildkernel, and install kernel. Since the buildkernel died, your libraries haven't been updated. You wouldn't do that until after you have booted the new kernel in single user mode. The sequence may be awkward at times but it saves you from the little disasters :). > > What the heck, I'll take a backup and give it a spin. Just remember you build and install the world and the kernel. I just got through upgrading to get the ifconf fix. No, problem. Kent > > Thanks. > > -- > Joel Rees > digitcom, inc. $B3t<02q Kobe, Japan +81-78-672-8800 > ** ** > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 07:27:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA8F116A4CE for ; Fri, 15 Apr 2005 07:27:21 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E1F43D1D for ; Fri, 15 Apr 2005 07:27:21 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so633187wra for ; Fri, 15 Apr 2005 00:27:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BpSuH0MA7xn1celfvGl0DOjzl1tRBC2K2ez/1SlMhPu4tzNZU4yCmCx101vh1SmFoh++1jzO41anSrlzfLbIQFDc9gOKgM4jYq0apjECUNemlGeczPnSr+Y21Sc40a7FnRwOB34eF/nk8+DgbFVi0SJPKdUO5TJce84RLKDY8yg= Received: by 10.54.16.68 with SMTP id 68mr403429wrp; Fri, 15 Apr 2005 00:27:11 -0700 (PDT) Received: by 10.54.7.56 with HTTP; Fri, 15 Apr 2005 00:27:11 -0700 (PDT) Message-ID: <6eb82e05041500274172afd3@mail.gmail.com> Date: Fri, 15 Apr 2005 15:27:11 +0800 From: Rong-En Fan To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: 5.4/amd64 console hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rong-En Fan List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 07:27:21 -0000 Hi, I'm using a Pentium Xeon 3.2G * 2 running 5.3/5.4 amd54 RELEASE. Recently, I have frequently hang, say 4 in 3 days. Originally, I'm using 5.3-RELEASE-p5 or so, and it happens, so I decided upgrade to 5.4-RC1/RC2 and disable HTT in BIOS= . Somehow, I noticed that this situation happens more frequently after upgrad= e to 5.4-RC1/RC2. This is a Mail server running Postifx with clamd/amavisd and apache2 with some webmail applications. All users home directory (toatl 10) is mounted from another NFS server running 5.4-PRELEASE/i386. I have few ddb output and kernel config here: http://rafan.infor.org/tmp/5.4-hang/ I executes ps, show threads, show lockedvn.=20 when console hangs, serial console does not response, front console, I can use alt+f? to switch vty, caps/numlock led is fine, but keyboard does not response. can break to ddb. any suggestions? Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 07:35:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C386B16A4CE for ; Fri, 15 Apr 2005 07:35:00 +0000 (GMT) Received: from conversation.bsdunix.ch (fiescherwand.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1066343D2F for ; Fri, 15 Apr 2005 07:35:00 +0000 (GMT) (envelope-from thomas@bsdunix.ch) Received: from [192.168.0.14] ([192.168.0.14])j3F7dKGJ095161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 09:39:21 +0200 (CEST) (envelope-from thomas@bsdunix.ch) Message-ID: <425F6EA0.7000406@bsdunix.ch> Date: Fri, 15 Apr 2005 09:34:56 +0200 From: Thomas Vogt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Vogt References: <1113490297.41050.2.camel@bert.mlan.solnet.ch> In-Reply-To: <1113490297.41050.2.camel@bert.mlan.solnet.ch> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_66,NO_RDNS2 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on conversation.bsdunix.ch cc: stable@freebsd.org Subject: Re: 5.4 rc2 problems with tftpd service X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 07:35:00 -0000 Hi Problem was caused by net.inet.udp.blackhole=1. It looks like -l or -s does not work with this option. Regards, Thomas Thomas wrote: > Hello > > I can't download files via tftp. The tftp client gets a timeout and the > written file is 0 bytes. I've done all my test on a local machine. No > network was involved. > > System information: > FreeBSD lizard 5.4-RC2 Wed Apr 13 15:04:30 UTC 2005 > root@lizard:/usr/obj/usr/src/sys/UP i386 > > inetd.conf contains > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /var/tftpboot > > /var/tftpboot permission is set to 755 (root:wheel). > > I tried the -u root option for tftpd too but it didn't work either. Also > changed ownership to nobody:nobody for /var/tftpboot but no luck. > There is no error message in xferlog. I always get tftpd[47744]: > 127.0.0.1: read request for //test: success. But the file was not > transferred. > > Everything works fine if I remove the -l option or the -s option in > inetd.conf for tftpd. Is this "strange" behavior with -l as option > intended? > > Regards, > Thomas > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- My blog: http://www.bsdunix.ch From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 09:12:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D4D316A4CE for ; Fri, 15 Apr 2005 09:12:48 +0000 (GMT) Received: from post.00t.org (feynman.00t.org [217.160.135.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4AF343D53 for ; Fri, 15 Apr 2005 09:12:47 +0000 (GMT) (envelope-from kpanic@00t.org) Received: from [172.24.0.14] (p548C962B.dip.t-dialin.net [84.140.150.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by post.00t.org (Postfix) with ESMTP id E0A65192DE for ; Fri, 15 Apr 2005 11:12:45 +0200 (CEST) Message-ID: <425F859D.1040101@00t.org> Date: Fri, 15 Apr 2005 11:13:01 +0200 From: Ulrik Guenther User-Agent: Mozilla Thunderbird 1.0 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: xl0: transmission error: 90 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kpanic@00t.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 09:12:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following messages while transferring a big file (31GByte) over 100MBit ethernet: Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 180 bytes Apr 15 08:46:19 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:19 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 240 bytes Apr 15 08:46:19 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:19 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 300 bytes Apr 15 08:46:21 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:21 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 360 bytes Apr 15 08:47:29 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:47:29 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 420 bytes So, okay the threshold was increaed in 60byte steps from 120 to 420 bytes, then it stopped. This procedure took place only during the first gigabytes of the transmission. I noticed no negative side effects (say: the file arrived completely on the other computer, checksum was okay as well). Transmission was done via SSH/SCP. Now my question: What do these messages from the xl(4) mean? Thanks in advance, Ulrik Guenther -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX4Wdy06DkvPH780RAqnLAKCHdbJGj8obBnHpyj7BHvWGeNbf6QCgm/lK FEnMYakL4j4YcH/vUaPGGbA= =ghm3 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 10:22:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B9C916A4CE for ; Fri, 15 Apr 2005 10:22:49 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C2D943D58 for ; Fri, 15 Apr 2005 10:22:48 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 1734 invoked by alias); 15 Apr 2005 10:35:04 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 15 Apr 2005 10:35:04 -0000 Date: Fri, 15 Apr 2005 19:22:52 +0900 From: Joel To: freebsd-stable@freebsd.org In-Reply-To: <200504142319.00148.kstewart@owt.com> References: <20050415144031.E8A2.REES@ddcom.co.jp> <200504142319.00148.kstewart@owt.com> Message-Id: <20050415185009.E8A5.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: Re: RELENG_5 broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 10:22:49 -0000 > > > FWIW, you are just in time anyway because they added a security > > > notice and if you cvsup now, you will also get that fix. And it's nice to have that out of the way. > > So the system is not in an unstable situation such that repeating the > > cvsup would have me trying to build from inconsistent libraries or > > anything like that? > > When you do the buildworld, you get a new world and then the kernel will > build. This is one of the reasons to buildworld, buildkernel, and > install kernel. I'm just a following the instructions in the on-line manual. Well, I used sudo from the main admin account while in multi-user mode, except I forgot that a couple of times and had to break out. And I forgot to grab it at the beastie menu on the reboot just now, but it seems to be installing world okay after a second reboot to single-user. > Since the buildkernel died, your libraries haven't been > updated. You wouldn't do that until after you have booted the new > kernel in single user mode. The sequence may be awkward at times but it > saves you from the little disasters :). No problem with that. Just wanted to make sure the libraries would not be in a half-way state from not having completed the previous build. > > What the heck, I'll take a backup and give it a spin. > > Just remember you build and install the world and the kernel. I just got > through upgrading to get the ifconf fix. No, problem. > > Kent Thanks again. It just finished the install, so I'll see what happens in the second pass of mergemaster (That looks like it could be a very useful tool.) and then build ports. I guess it's obvious I haven't done this very much on freeBSD. -- Joel Rees digitcom, inc. $B3t<02q ** From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 11:46:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 168D416A4CE for ; Fri, 15 Apr 2005 11:46:49 +0000 (GMT) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 716D943D2D for ; Fri, 15 Apr 2005 11:46:48 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (213.3.248.147) by mail2.bluewin.ch (Bluewin 7.0.043) id 423AEC47002F7998 for freebsd-stable@freebsd.org; Fri, 15 Apr 2005 11:46:47 +0000 Received: from snoopy.here (localhost [127.0.0.1]) by gicco.homeip.net (8.12.9p2/8.12.9) with ESMTP id j3FBkgi4018564 for ; Fri, 15 Apr 2005 13:46:42 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from hampi@localhost) by snoopy.here (8.12.9p2/8.12.9/Submit) id j3FBkgSh018563 for freebsd-stable@freebsd.org; Fri, 15 Apr 2005 13:46:42 +0200 (CEST) (envelope-from hampi@rootshell.be) X-Authentication-Warning: snoopy.here: hampi set sender to hampi@rootshell.be using -f Date: Fri, 15 Apr 2005 13:46:42 +0200 From: Hanspeter Roth To: freebsd-stable@freebsd.org Message-ID: <20050415114642.GA18430@gicco.homeip.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050411110240.GA2118@gicco.homeip.net> <20050414095534.U24742@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050414095534.U24742@carver.gumbysoft.com> User-Agent: Mutt/1.4.1i Subject: Re: Alternate menu logos X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 11:46:49 -0000 On Apr 14 at 10:13, Doug White spoke: > I I have an idea and the patch in PR 74577 is about halfway there. I > suggest providing a script that forth-ifies a provided ASCII logo, and a > loader option to load a banner file from disk. This way, if, say, an OEM > wanted to put contact information in there, they could put in loader.conf: > > banner_enable="YES" > banner_file="/boot/oem.banner" > > and have that displayed instead of the beastie. Is it acceptable that the banner_file is just an include file or should the program open the banner_file itself? -Hanspeter From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 12:27:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B861216A4CE for ; Fri, 15 Apr 2005 12:27:24 +0000 (GMT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id F19A843D2F for ; Fri, 15 Apr 2005 12:27:23 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 15 Apr 2005 12:27:23 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Fri, 15 Apr 2005 08:27:13 -0400 (EDT) Message-ID: <1193.172.16.0.199.1113568033.squirrel@172.16.0.1> In-Reply-To: <425F859D.1040101@00t.org> References: <425F859D.1040101@00t.org> Date: Fri, 15 Apr 2005 08:27:13 -0400 (EDT) From: "Mike Jakubik" To: kpanic@00t.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-stable@freebsd.org Subject: Re: xl0: transmission error: 90 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 12:27:24 -0000 On Fri, April 15, 2005 5:13 am, Ulrik Guenther said: > on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following > messages while transferring a big file (31GByte) over 100MBit ethernet: > > Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 > Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start > > So, okay the threshold was increaed in 60byte steps from 120 to 420 > bytes, then it stopped. This procedure took place only during the first > gigabytes of the transmission. I noticed no negative side effects (say: > the file arrived completely on the other computer, checksum was okay as > well). Transmission was done via SSH/SCP. > > Now my question: What do these messages from the xl(4) mean? Im assuming the xl cards default tx buffer is too low, or something of that nature. I get the same messages, but everything works fine. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 12:46:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48D4C16A4D9 for ; Fri, 15 Apr 2005 12:46:32 +0000 (GMT) Received: from pastinakel.tue.nl (pastinakel.tue.nl [131.155.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C133643D4C for ; Fri, 15 Apr 2005 12:46:31 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: by pastinakel.tue.nl (Postfix, from userid 40) id B236614BD1E; Fri, 15 Apr 2005 14:46:30 +0200 (CEST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by pastinakel.tue.nl (Postfix) with ESMTP id BBF6614BCB6; Fri, 15 Apr 2005 14:46:29 +0200 (CEST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.13.3/8.13.1/Submit) id j3FCkT58089102; Fri, 15 Apr 2005 14:46:29 +0200 (CEST) (envelope-from stijn) Date: Fri, 15 Apr 2005 14:46:29 +0200 From: Stijn Hoop To: Mike Jakubik Message-ID: <20050415124629.GC79421@pcwin002.win.tue.nl> References: <425F859D.1040101@00t.org> <1193.172.16.0.199.1113568033.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <1193.172.16.0.199.1113568033.squirrel@172.16.0.1> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! X-Spam-DCC: CollegeOfNewCaledonia: pastinakel.tue.nl 1189; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pastinakel.tue.nl X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=6.3 tests=BAYES_00 autolearn=ham version=2.64 cc: kpanic@00t.org cc: freebsd-stable@freebsd.org Subject: Re: xl0: transmission error: 90 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 12:46:32 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2005 at 08:27:13AM -0400, Mike Jakubik wrote: > On Fri, April 15, 2005 5:13 am, Ulrik Guenther said: > > on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following > > messages while transferring a big file (31GByte) over 100MBit ethernet: > > > > Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 > > Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start > > > > So, okay the threshold was increaed in 60byte steps from 120 to 420 > > bytes, then it stopped. This procedure took place only during the first > > gigabytes of the transmission. I noticed no negative side effects (say: > > the file arrived completely on the other computer, checksum was okay as > > well). Transmission was done via SSH/SCP. > > > > Now my question: What do these messages from the xl(4) mean? >=20 > Im assuming the xl cards default tx buffer is too low, or something of > that nature. I get the same messages, but everything works fine. I've been getting them for a few years now, always after a reboot: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes (not exactly all at the same time of course). Machine functions just fine as far as I can tell. --Stijn --=20 Coughlin's law: never tell tales about a woman no matter how far away she is, she'll always hear you. -- Cocktail --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCX7elY3r/tLQmfWcRAgU+AJ43n3NDpQycb8xkO/Vtyc5jF5Jm+wCgsJ+2 DyvZgp/kRr/M1qUa8XWCO0w= =pLQ1 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 13:01:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5128E16A4CE for ; Fri, 15 Apr 2005 13:01:01 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D4CC43D31 for ; Fri, 15 Apr 2005 13:01:00 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 5145 invoked by alias); 15 Apr 2005 13:13:15 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 15 Apr 2005 13:13:15 -0000 Date: Fri, 15 Apr 2005 22:01:05 +0900 From: Joel To: freebsd-stable@freebsd.org Message-Id: <20050415214645.E8AC.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: merging locale stuff in mtree? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 13:01:01 -0000 Just finished rebuilding and installing the world and the kernel by the "canonical" method. In using mergemaster, I find myself puzzled by the locale stuff in mtree. I have not installed a lot of locales, haven't even started X11 at all yet, but the updates seem to want to put a lot of stuff about locales in BSD.X11-4.dist and BSD.local.dist. Is all that locale stuff necessary there if you haven't installed all those locales? (I tried to merge BSD.local.dist, and I think I botched it.) I'm not really clear on what mtree does, in case that isn't obvious. Search the web only turned up stuff about an alternative to tripwire, but I suppose it might be mergemaster's db configuration? (Scanned man on mtree and /usr/src/etc/mtree/README, but it hasn't sunk it yet.) Appreciate a cluestick if anyone cares to hit me with one. -- Joel Rees digitcom, inc. $B3t<02q ** From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 14:28:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A83616A4CE for ; Fri, 15 Apr 2005 14:28:43 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6EC43D46 for ; Fri, 15 Apr 2005 14:28:42 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so726040wri for ; Fri, 15 Apr 2005 07:28:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pT0ex3T7oKujEAUnfldWC5SZ0dzCOSK9aSxsSucxNUxmteJMrDFIjY8A3nPeeZEySu0c+W3mT6wgnHHL/udHomydwwECgHCLbXC8Pvax4MKj/dWDLdhuhtDCvwmPU8cem3pAE75OYVWC5j0P+pkKPc9uuWPqKwrv3tcxfQweT44= Received: by 10.54.27.4 with SMTP id a4mr1110932wra; Fri, 15 Apr 2005 07:28:41 -0700 (PDT) Received: by 10.54.29.77 with HTTP; Fri, 15 Apr 2005 07:28:41 -0700 (PDT) Message-ID: <790a9fff05041507287212fbbb@mail.gmail.com> Date: Fri, 15 Apr 2005 09:28:41 -0500 From: Scot Hetzel To: Joel In-Reply-To: <20050415214645.E8AC.REES@ddcom.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050415214645.E8AC.REES@ddcom.co.jp> cc: freebsd-stable@freebsd.org Subject: Re: merging locale stuff in mtree? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 14:28:43 -0000 On 4/15/05, Joel wrote: > Just finished rebuilding and installing the world and the kernel by the > "canonical" method. >=20 > In using mergemaster, I find myself puzzled by the locale stuff in mtree. > I have not installed a lot of locales, haven't even started X11 at all > yet, but the updates seem to want to put a lot of stuff about locales in > BSD.X11-4.dist and BSD.local.dist. Is all that locale stuff necessary > there if you haven't installed all those locales? >=20 The locale stuff in the BSD.*.dist files is used to create standard directories and permissions. This way when you install a port/package it doesn't need to create the missing locale directories, instead mtree will create them. > (I tried to merge BSD.local.dist, and I think I botched it.) >=20 Just copy the src/etc/mtree/BSD.local.dist to /etc/mtree to fix it. > I'm not really clear on what mtree does, in case that isn't obvious. > Search the web only turned up stuff about an alternative to tripwire, > but I suppose it might be mergemaster's db configuration? (Scanned man > on mtree and /usr/src/etc/mtree/README, but it hasn't sunk it yet.) >=20 mtree is used to create standard permissions (directories and files) and default directories that should exist. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 16:20:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A983A16A4D0 for ; Fri, 15 Apr 2005 16:20:01 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BA9443D3F for ; Fri, 15 Apr 2005 16:20:00 +0000 (GMT) (envelope-from bsdfreak@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so869434nzf for ; Fri, 15 Apr 2005 09:19:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qq5wHyhLQCKLYiqE0Wm8/q9QQf5J8bwTX/4hIVjgd0SpFhISVyDvZMxvn/W1uDBs8K8YUsGMlQwX/hCuJ9zogWj/KaQi2dZeMkb76Q9FK6IWeVdXUZUYVz1O7Im0dQvGC/gnokLZHUf06EwQIs+l4q99U5Crwh6qy3Hh+We7SfM= Received: by 10.36.12.7 with SMTP id 7mr203248nzl; Fri, 15 Apr 2005 09:19:59 -0700 (PDT) Received: by 10.36.7.11 with HTTP; Fri, 15 Apr 2005 09:19:59 -0700 (PDT) Message-ID: Date: Fri, 15 Apr 2005 12:19:59 -0400 From: Alexander Chamandy To: freebsd-questions@freebsd.org, freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Re: Problem with SoundBlaster Audigy on FreeBSD 5.4-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Chamandy List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 16:20:01 -0000 On 4/14/05, Alexander Chamandy wrote: > I'm having problems after a recent upgrade to FreeBSD 5.4-STABLE. > RC-1 seemed to work fine, but now my media files (audio and video > alike) are not properly playing. And I get this error: >=20 > pcm0:play:0: play interrupt timeout, channel dead This problem seems to be directly related to ACPI being enabled. Once I disable it sound works fine. >=20 > Has anyone experienced this and if so, know of a reasonable workaround? >=20 > dmesg: >=20 > FreeBSD 5.4-STABLE #14: Thu Apr 14 16:29:53 EDT 2005 > alex@vetra.envescent.net:/usr/src/sys/amd64/compile/vetra > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.15-MHz K8-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0xf48 Stepping =3D 8 > Features=3D0x78bfbff > AMD Features=3D0xe0500800 > real memory =3D 2147418112 (2047 MB) > avail memory =3D 2064994304 (1969 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf0-0xcf3,0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xfc003000-0xfc003fff irq > 22 at device 2.0 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfc004000-0xfc004fff irq > 21 at device 2.1 on pci0 > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 3 ports with 3 removable, self powered > pci0: at device 2.2 (no driver attached) > pci0: at device 5.0 (no driver attached) > pci0: at device 6.0 (no driver attached) > atapci0: port > 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on > pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pcib1: at device 10.0 on pci0 > pci1: on pcib1 > pcm0: port 0xa000-0xa01f irq 19 at device > 7.0 on pci1 > pcm0: > pci1: at device 7.2 (no driver attached) > ahc0: port 0xa800-0xa8ff mem > 0xfb004000-0xfb004fff irq 16 at device 8.0 on pci1 > aic7890/91: Ultra2 Wide Channel A, SCSI Id=3D7, 32/253 SCBs > atapci1: port > 0xbc00-0xbc0f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 > mem 0xfb006000-0xfb0061ff irq 17 at device 13.0 on pci1 > ata2: channel #0 on atapci1 > ata3: channel #1 on atapci1 > pcib2: at device 11.0 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pci2: at device 0.1 (no driver attached) > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > orm0: at iomem > 0xd8000-0xdd7ff,0xd0000-0xd7fff,0xc0000-0xccfff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > uhub2: vendor 0x0543 product 0x1167, class 9/0, rev 2.00/ff.ff, addr 2 > uhub2: 4 ports with 4 removable, self powered > ugen0: Saitek Saitek X45, rev 1.00/0.02, addr 3 > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 4, iclass 3/1 > ums0: 3 buttons and Z dir. > Timecounter "TSC" frequency 2009148084 Hz quality 800 > Timecounters tick every 1.000 msec > ad2: 58644MB [119150/16/63] at ata1-master UD= MA100 > acd0: DVDR at ata1-slave PIO4 > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) > da0: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) > Mounting root from ufs:/dev/ad2s1a > nv0: port 0xd000-0xd007 mem > 0xfc000000-0xfc000fff irq 22 at device 5.0 on pci0 > nv0: Ethernet address 00:0d:61:14:6f:39 > nv0: Ethernet address: 00:0d:61:14:6f:39 > miibus0: on nv0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >=20 > -- > Best wishes, >=20 > Alexander G. Chamandy > Webmaster > www.bsdfreak.org > Your Source For BSD News! >=20 --=20 Best wishes, Alexander G. Chamandy Webmaster www.bsdfreak.org Your Source For BSD News! From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 19:45:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37BEF16A4CE for ; Fri, 15 Apr 2005 19:45:55 +0000 (GMT) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E7CC43D3F for ; Fri, 15 Apr 2005 19:45:55 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id A07F5B80D for ; Fri, 15 Apr 2005 15:45:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <86b62f18a2b0f9feca7009a6e6e1b9d7@kcilink.com> References: <86b62f18a2b0f9feca7009a6e6e1b9d7@kcilink.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4a4fe842c405691304df8b6cb8847151@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 15 Apr 2005 15:45:53 -0400 To: stable@freebsd.org X-Mailer: Apple Mail (2.619.2) Subject: Re: bge0 watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 19:45:55 -0000 On Mar 22, 2005, at 1:24 PM, Vivek Khera wrote: > Twice today during very heavy network I/O (dumping a large postgres > database over the ethernet to another machine on the same switch) I > got this error: > > Mar 22 03:42:22 d01 kernel: bge0: watchdog timeout -- resetting > Mar 22 10:28:24 d01 kernel: bge0: watchdog timeout -- resetting > For the archives: I punted and installed an em based NIC and disabled the bge on board via BIOS. Stable ever since. See thread in freebsd-amd64 list "tyan k8sr lockups" for full gory details. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 20:50:36 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 607AE16A4CE for ; Fri, 15 Apr 2005 20:50:36 +0000 (GMT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DA3D43D41 for ; Fri, 15 Apr 2005 20:50:35 +0000 (GMT) (envelope-from tilman@arved.at) Received: from jim.arved.de (localhost [127.0.0.1])j3FKoXV0063320 for ; Fri, 15 Apr 2005 22:50:33 +0200 (CEST) (envelope-from tilman@arved.at) Received: (from arved@localhost) by jim.arved.de (8.13.1/8.13.1/Submit) id j3FKoX19063319 for freebsd-stable@freebsd.org; Fri, 15 Apr 2005 22:50:33 +0200 (CEST) (envelope-from tilman@arved.at) X-Authentication-Warning: jim.arved.de: arved set sender to tilman@arved.at using -f Date: Fri, 15 Apr 2005 22:50:33 +0200 From: Tilman Linneweh To: freebsd-stable@freebsd.org Message-ID: <20050415205033.GD17852@arved.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic in uma_dbg_free (pfil hooks related?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 20:50:36 -0000 Hi, Same situation like the panic i reported last month (http://lists.freebsd.org/pipermail/freebsd-stable/2005-March/013066.html ) but this time without ipl(4) in the kernel. I closed my laptop lid without closing the ssh session and boom the NAT gateway (running 5.4-PRERELEASE) crashed. db> where Tracing pid 27 tid 100021 td 0xc107f190 kdb_enter(c06ca9e8) at kdb_enter+0x2b panic(c06e1733,c1346a00,c0c6aae0,c06c929b,c06e1717) at panic+0xbb uma_dbg_free(c0c6aae0,0,c1346a00) at uma_dbg_free+0x110 uma_zfree_arg(c0c6aae0,c1346a00,0) at uma_zfree_arg+0xf3 m_freem(c1346a00,c1346a00,c1598a00,4,41) at m_freem+0x36 fr_check(c1346a50,14,c1120000,0,ca8a8c88) at fr_check+0xce8 fr_check_wrapper(0,ca8a8c88,c1120000,1,0) at fr_check_wrapper+0x2a pfil_run_hooks(c075f8a0,ca8a8cd4,c1120000,1,0) at pfil_run_hooks+0xbd ip_input(c1346a00) at ip_input+0x231 netisr_processqueue(c075eb38) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c1074500,ca8a8d48,c1074500,c0520610,0) at ithread_loop+0x124 fork_exit(c0520610,c1074500,ca8a8d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 Unfortunately still no gdb dump... regards tilman From owner-freebsd-stable@FreeBSD.ORG Fri Apr 15 21:21:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97AD516A4CE for ; Fri, 15 Apr 2005 21:21:32 +0000 (GMT) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA95143D2D for ; Fri, 15 Apr 2005 21:21:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3FLLT9K020614 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 16 Apr 2005 07:21:30 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3FLLT7l007801 for ; Sat, 16 Apr 2005 07:21:29 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j3FLLT77007800 for stable@freebsd.org; Sat, 16 Apr 2005 07:21:29 +1000 (EST) (envelope-from pjeremy) Date: Sat, 16 Apr 2005 07:21:29 +1000 From: Peter Jeremy To: stable@freebsd.org Message-ID: <20050415212129.GB90280@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: Deadlock in 5.3p5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 21:21:32 -0000 My son's computer deadlocked last night. "show lockedvnods" in DDB showed: Locked vnodes 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid 9666) with 7 pending ino 2, on dev ad0s1g (4, 25) 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with 1 pending ino 23552, on dev ad0s1g (4, 25) 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with 1 pending ino 122986, on dev ad0s1g (4, 25) 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with 1 pending ino 142022, on dev ad0s1g (4, 25) 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending ino 142169, on dev ad0s1g (4, 25) After poking around in the crashdump for a while, I've worked out that the process holding each of the above exclusive locks is waiting on the next lock in the list. Unfortunately, there doesn't appear to be any way to work out which process is holding the shared lock unless DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly downgraded by a process calling lockmgr(LK_SHARED) when it holds an exclusive lock). FWIW, the affected inodes are: 2 /usr 23552 /usr/local 122986 /usr/local/OpenOffice.org1.1.4 142022 /usr/local/OpenOffice.org1.1.4/program 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so Does anyone have any ideas on how to track this further (or so I just write it off as a glitch). -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 03:13:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D419916A4CE for ; Sat, 16 Apr 2005 03:13:10 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B888343D5D for ; Sat, 16 Apr 2005 03:13:10 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id AA7E472DDD; Fri, 15 Apr 2005 20:13:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A5D5072DDB; Fri, 15 Apr 2005 20:13:10 -0700 (PDT) Date: Fri, 15 Apr 2005 20:13:10 -0700 (PDT) From: Doug White To: Mikhail Teterin In-Reply-To: <200504130314.j3D3EjrT043747@corbulon.video-collage.com> Message-ID: <20050415200656.N38788@carver.gumbysoft.com> References: <200504130314.j3D3EjrT043747@corbulon.video-collage.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: stable@FreeBSD.org Subject: Re: reliable "panic: isa_dmastart: bad bounce buffer" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 03:13:10 -0000 On Tue, 12 Apr 2005, Mikhail Teterin wrote: > Hello! > > Whenever I try to mount a floppy disk: > > mount -t msdosfs /dev/fd0 /mnt > > I get: > > panic: isa_dmastart: bad bounce buffer > > The OS is FreeBSD-5.4-STABLE from last night, amd64. dmesg attached. Probably related to: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 isa_dmainit(2, 40960) failed fd0: <1440-KB 3.5" drive> on fdc0 drive 0 That message is printed by isa_dmainit() in src/sys/amd64/isa/isa_dma.c. You might instrument that function and see where its blowing up. I suspect its getting the buffer from malloc() but the range check below it fails. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 03:18:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D27A816A4CE for ; Sat, 16 Apr 2005 03:18:09 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA0E43D58 for ; Sat, 16 Apr 2005 03:18:09 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 836A972DDD; Fri, 15 Apr 2005 20:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 7E21272DDB; Fri, 15 Apr 2005 20:18:09 -0700 (PDT) Date: Fri, 15 Apr 2005 20:18:09 -0700 (PDT) From: Doug White To: Michiel Boland In-Reply-To: Message-ID: <20050415201719.R38788@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org Subject: Re: fxp lockups on 5.4-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 03:18:09 -0000 On Wed, 13 Apr 2005, Michiel Boland wrote: > Hi. I was using a small test program to generate artificial network load > on 5.4-RC1. The program sets up 1000 sockets that all connect, send a > number of pipelined request, and then read the response from a nearby web > server. > > After a short while the machine locked up, even the console was dead. > Luckily DDB worked, so I was able to gather some backtraces (see below). > Looks like something is stuck in the fxp process. you appear to be running low on kenrel memory. the only msleep in uma_zone_slab is for zonelimit and that gets triggered when kernel memroy runs low. > > Being a bit impatient, I did not check to see if the lockup would go away > after some time. > > The problem went away after I increased nmbclusters to 32768. Probably the right thing to do. > > If more info is needed I can provide this of course. > > Cheers > Michiel > > > tr > Tracing pid 23 tid 100017 td 0xc157da80 > kdb_enter(c05d55bb) at kdb_enter+0x2b > siointr1(c167f000) at siointr1+0xce > siointr(c167f000) at siointr+0x38 > intr_execute_handlers(c05ffac0,d4000bd8,0,c0c46460,c0c45240) at intr_execute_handlers+0x7d > atpic_handle_intr(4) at atpic_handle_intr+0x96 > Xatpic_intr4() at Xatpic_intr4+0x20 > --- interrupt, eip = 0xc057ff87, esp = 0xd4000c1c, ebp = 0xd4000c28 --- > uma_zfree_internal(c0c45240,c4173418,0,0,80) at uma_zfree_internal+0x153 > bucket_free(c4173418,1,80,f3c8,c0c45bd8) at bucket_free+0x22 > uma_zalloc_bucket(c0c45ba0,1) at uma_zalloc_bucket+0x263 > uma_zalloc_arg(c0c45ba0,d4000c9c,1) at uma_zalloc_arg+0x274 > fxp_add_rfabuf(c1616000,c16165d0) at fxp_add_rfabuf+0x2a > fxp_intr_body(c1616000,c1616000,50,ffffffff) at fxp_intr_body+0xd4 > fxp_intr(c1616000) at fxp_intr+0xf4 > ithread_loop(c1576800,d4000d48) at ithread_loop+0x151 > fork_exit(c04838a0,c1576800,d4000d48) at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd4000d7c, ebp = 0 --- > db> ps > pid proc uid ppid pgrp flag stat wmesg wchan cmd > 375 c1731388 1001 370 375 0004002 [SLPQ zonelimit 0xc0c1f460][SLP] kqmaps > 370 c1731c5c 1001 369 370 0004002 [SLPQ wait 0xc1731c5c][SLP] bash > 369 c1731e20 0 1 369 0004102 [SLPQ wait 0xc1731e20][SLP] login > 368 c18b5000 0 1 368 0004002 [SLPQ ttyin 0xc1574e10][SLP] getty > 367 c18b51c4 0 1 367 0004002 [SLPQ ttyin 0xc1683010][SLP] getty > 366 c18b5388 0 1 366 0004002 [SLPQ ttyin 0xc1683210][SLP] getty > 365 c18b554c 0 1 365 0004002 [SLPQ ttyin 0xc1683410][SLP] getty > 364 c18b5710 0 1 364 0004002 [SLPQ ttyin 0xc1573010][SLP] getty > 363 c18b58d4 0 1 363 0004002 [SLPQ ttyin 0xc1573210][SLP] getty > 362 c172d54c 0 1 362 0004002 [SLPQ ttyin 0xc1573410][SLP] getty > 361 c172d710 0 1 361 0004002 [SLPQ ttyin 0xc1573610][SLP] getty > 321 c15c7e20 0 1 321 0000100 [SLPQ select 0xc060f364][SLP] sshd > 199 c172d1c4 0 1 199 0000000 [SLPQ select 0xc060f364][SLP] devd > 38 c172d8d4 0 0 0 0000204 [SLPQ - 0xd5445d18][SLP] schedcpu > 37 c172da98 0 0 0 0000204 [SLPQ syncer 0xc060baec][SLP] syncer > 36 c172dc5c 0 0 0 0000204 [SLPQ vlruwt 0xc172dc5c][SLP] vnlru > 35 c172de20 0 0 0 0000204 [SLPQ psleep 0xc060f84c][SLP] bufdaemon > 9 c1731000 0 0 0 000020c [SLPQ pgzero 0xc0616ed4][SLP] pagezero > 8 c15b654c 0 0 0 0000204 [SLPQ psleep 0xc0616f28][SLP] vmdaemon > 7 c15b6710 0 0 0 0000204 [SLPQ psleep 0xc0616ee4][SLP] pagedaemon > 34 c15b68d4 0 0 0 0000204 [IWAIT] swi0: sio > 33 c15b6a98 0 0 0 0000204 [IWAIT] swi6: task queue > 6 c15b6c5c 0 0 0 0000204 [SLPQ - 0xc15e7e00][SLP] kqueue taskq > 32 c15b6e20 0 0 0 0000204 [IWAIT] swi6:+ > 5 c15c7000 0 0 0 0000204 [SLPQ - 0xc15f5000][SLP] thread taskq > 31 c15c71c4 0 0 0 0000204 [IWAIT] swi6:+ > 30 c15c7388 0 0 0 0000204 [SLPQ - 0xc0603a40][SLP] yarrow > 4 c15c754c 0 0 0 0000204 [SLPQ - 0xc0606428][SLP] g_down > 3 c15c7710 0 0 0 0000204 [SLPQ - 0xc0606424][SLP] g_up > 2 c15c78d4 0 0 0 0000204 [SLPQ - 0xc060641c][SLP] g_event > 29 c15801c4 0 0 0 0000204 [IWAIT] swi1: net > 28 c1580388 0 0 0 0000204 [IWAIT] swi4: vm > 27 c158054c 0 0 0 000020c [RUNQ] swi5: clock sio > 26 c1580710 0 0 0 0000204 [IWAIT] irq15: ata1 > 25 c15808d4 0 0 0 0000204 [IWAIT] irq14: ata0 > 24 c1580a98 0 0 0 0000204 [IWAIT] irq13: > 23 c1580c5c 0 0 0 0000204 [CPU 0] irq12: fxp0 > 22 c1580e20 0 0 0 0000204 [IWAIT] irq11: > 21 c15b6000 0 0 0 0000204 [IWAIT] irq10: > 20 c15b61c4 0 0 0 0000204 [IWAIT] irq9: > 19 c15b6388 0 0 0 0000204 [IWAIT] irq8: rtc > 18 c1578000 0 0 0 0000204 [IWAIT] irq7: > 17 c15781c4 0 0 0 0000204 [IWAIT] irq6: > 16 c1578388 0 0 0 0000204 [IWAIT] irq5: > 15 c157854c 0 0 0 0000204 [IWAIT] irq4: sio0 > 14 c1578710 0 0 0 0000204 [IWAIT] irq3: sio1 > 13 c15788d4 0 0 0 0000204 [IWAIT] irq1: atkbd0 > 12 c1578a98 0 0 0 0000204 [IWAIT] irq0: clk > 11 c1578c5c 0 0 0 000020c [Can run] idle > 1 c1578e20 0 0 1 0004200 [SLPQ wait 0xc1578e20][SLP] init > 10 c1580000 0 0 0 0000204 [SLPQ ktrace 0xc0609d18][SLP] ktrace > 0 c06064c0 0 0 0 0000200 [SLPQ sched 0xc06064c0][SLP] swapper > db> tr 375 > Tracing pid 375 tid 100038 td 0xc15b8c00 > sched_switch(c15b8c00,0,1) at sched_switch+0x143 > mi_switch(1,0,c15b8c00,0,c15b8c00) at mi_switch+0x1ba > sleepq_switch(c0c1f460) at sleepq_switch+0xda > sleepq_wait(c0c1f460,0,c0c45240,0,0) at sleepq_wait+0xb > msleep(c0c1f460,c0c1f468,44,c05d48df,0) at msleep+0x2ce > uma_zone_slab(c0c45b40,2,2,80,314c) at uma_zone_slab+0xd2 > uma_zalloc_bucket(c0c45b40,2) at uma_zalloc_bucket+0x14c > uma_zalloc_arg(c0c45b40,c41c1c00,2) at uma_zalloc_arg+0x274 > mb_init_pack(c41c1c00,100,2) at mb_init_pack+0x1d > uma_zalloc_bucket(c0c45ba0,3) at uma_zalloc_bucket+0x1b4 > uma_zalloc_arg(c0c45ba0,d5229c0c,2) at uma_zalloc_arg+0x274 > sosend(c1a05000,0,d5229c54,0,0) at sosend+0x33d > kern_sendit(c15b8c00,3fd,d5229ccc,0,0) at kern_sendit+0x11c > sendit(c15b8c00,3fd,d5229ccc,0,805a000) at sendit+0x145 > sendto(c15b8c00,d5229d14,6,60,202) at sendto+0x4d > syscall(2f,805002f,bfbf002f,1a4,80521b0) at syscall+0x27b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c2b9b, esp = 0xbfbfeb4c, ebp = 0xbfbfeb78 --- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 09:11:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 816FF16A4CE for ; Sat, 16 Apr 2005 09:11:50 +0000 (GMT) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA2BC43D45 for ; Sat, 16 Apr 2005 09:11:49 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [213.6.72.176] (A48b0.a.pppool.de [213.6.72.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 6DDDA3000296 for ; Sat, 16 Apr 2005 11:11:47 +0200 (CEST) Message-ID: <4260D6D0.9010101@mail.uni-mainz.de> Date: Sat, 16 Apr 2005 11:11:44 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-15?Q?f=FCr_Geophysik?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-AT; rv:1.7.6) Gecko/20050328 X-Accept-Language: de-de, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Subject: Support for NForce4 nve NIC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 09:11:50 -0000 Can anyone tell me when if_nve will be merged into the -STABLE tree? Are there plans changing systems compiler from gcc 3.4.2 to 4.0 or 3.4.3 for better AMD64 optimization support? From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 12:22:25 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D4E416A4CE for ; Sat, 16 Apr 2005 12:22:25 +0000 (GMT) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED14043D1F for ; Sat, 16 Apr 2005 12:22:24 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from localhost (totem.fix.no [80.91.36.20]) by totem.fix.no (Postfix) with ESMTP id 0D00B5F382C; Sat, 16 Apr 2005 14:22:23 +0200 (CEST) Received: from totem.fix.no ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id 53937-02-4; Sat, 16 Apr 2005 14:22:22 +0200 (CEST) Received: by totem.fix.no (Postfix, from userid 1000) id B55F75F382B; Sat, 16 Apr 2005 14:22:22 +0200 (CEST) Date: Sat, 16 Apr 2005 14:22:22 +0200 From: Anders Nordby To: Rong-En Fan Message-ID: <20050416122222.GA12385@totem.fix.no> References: <6eb82e05041500274172afd3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6eb82e05041500274172afd3@mail.gmail.com> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.6i cc: stable@freebsd.org Subject: Re: 5.4/amd64 console hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 12:22:25 -0000 Hi, On Fri, Apr 15, 2005 at 03:27:11PM +0800, Rong-En Fan wrote: > I'm using a Pentium Xeon 3.2G * 2 running 5.3/5.4 amd54 RELEASE. That's a strange combination. Don't use FreeBSD/amd64 with Intel Pentium Xeon processors. Maybe you made a typing error or two? :-) I'll be testing 5.4 on amd64 myself shortly, looking forward to that. Cheers, -- Anders. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 12:36:15 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E732F16A4CE for ; Sat, 16 Apr 2005 12:36:15 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D2D243D2D for ; Sat, 16 Apr 2005 12:36:15 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so1022463wri for ; Sat, 16 Apr 2005 05:36:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U+e6NCMuIT6/0ZFoK1u4PWeOdb5uwkIhcOprkjtCt6pKuEfV91oZ9I2/YhdL/VG8dbsOxTrI/RyfQUN2eU+fMHi2cohHRnrw85tzvqe6e9/OyjuXjI5aauaYxJ9jC1bEaexIkUWLdGpov6aAvF0QNbibbBOb2mtf+vR2AhA/rnM= Received: by 10.54.33.68 with SMTP id g68mr3048874wrg; Sat, 16 Apr 2005 05:36:14 -0700 (PDT) Received: by 10.54.7.56 with HTTP; Sat, 16 Apr 2005 05:36:14 -0700 (PDT) Message-ID: <6eb82e0504160536572e068c@mail.gmail.com> Date: Sat, 16 Apr 2005 20:36:14 +0800 From: Rong-En Fan To: Anders Nordby In-Reply-To: <20050416122222.GA12385@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6eb82e05041500274172afd3@mail.gmail.com> <20050416122222.GA12385@totem.fix.no> cc: stable@freebsd.org Subject: Re: 5.4/amd64 console hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rong-En Fan List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 12:36:16 -0000 On 4/16/05, Anders Nordby wrote: > Hi, >=20 > On Fri, Apr 15, 2005 at 03:27:11PM +0800, Rong-En Fan wrote: > > I'm using a Pentium Xeon 3.2G * 2 running 5.3/5.4 amd54 RELEASE. >=20 > That's a strange combination. Don't use FreeBSD/amd64 with Intel Pentium > Xeon processors. Maybe you made a typing error or two? :-) Those Xeon are EM64T, compatible with x86-64 :-) By the way, I'm thinking that more frequently hang might related with large read/write block in mount_nfs -r/-w (I use 8192, original is 1024). Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 12:56:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD76816A4CE for ; Sat, 16 Apr 2005 12:56:57 +0000 (GMT) Received: from mail.iinet.net.au (mail-02.iinet.net.au [203.59.3.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 94B6243D39 for ; Sat, 16 Apr 2005 12:56:56 +0000 (GMT) (envelope-from shinjii@virusinfo.rdksupportinc.com) Received: (qmail 6466 invoked from network); 16 Apr 2005 12:56:55 -0000 Received: from unknown (HELO warren.shinji.nq.nu) (203.217.86.5) by mail.iinet.net.au with SMTP; 16 Apr 2005 12:56:55 -0000 From: Warren To: freebsd-questions@freebsd.org User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Disposition: inline Date: Sat, 16 Apr 2005 22:56:03 +1000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> cc: freebsd-stable@freebsd.org Subject: /var/spool/clientmque 185meg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 12:56:57 -0000 /var/spool/clientmqueue <-- 185meg How do i get the messages from the above to the root mail folder of my machine ? im willing to provide any neccessary information to help. -- Yours Sincerely Shinjii http://www.shinji.nq.nu From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 13:45:15 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9471516A4CE for ; Sat, 16 Apr 2005 13:45:15 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 016E043D41 for ; Sat, 16 Apr 2005 13:45:15 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 2521 invoked from network); 16 Apr 2005 13:45:14 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 16 Apr 2005 13:45:14 -0000 Received: (qmail 54923 invoked by uid 1001); 16 Apr 2005 13:45:13 -0000 Date: Sat, 16 Apr 2005 09:45:13 -0400 From: Brian Reichert To: Warren Message-ID: <20050416134513.GN19606@numachi.com> References: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> User-Agent: Mutt/1.5.8i cc: freebsd-stable@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: /var/spool/clientmque 185meg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 13:45:15 -0000 On Sat, Apr 16, 2005 at 10:56:03PM +1000, Warren wrote: > /var/spool/clientmqueue <-- 185meg > > How do i get the messages from the above to the root mail folder of my > machine ? > > im willing to provide any neccessary information to help. Is the undelivered mail destined to local users, or are there any remote users involved? > -- > Yours Sincerely > Shinjii > http://www.shinji.nq.nu -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 18:36:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BF6216A4CE for ; Sat, 16 Apr 2005 18:36:50 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31F8A43D45 for ; Sat, 16 Apr 2005 18:36:50 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7ACBE519EF; Sat, 16 Apr 2005 11:36:49 -0700 (PDT) Date: Sat, 16 Apr 2005 11:36:49 -0700 From: Kris Kennaway To: Peter Jeremy , Jeff Roberson Message-ID: <20050416183649.GA61170@xor.obsecurity.org> References: <20050415212129.GB90280@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20050415212129.GB90280@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i cc: stable@freebsd.org Subject: Re: Deadlock in 5.3p5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 18:36:50 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable CC'ing to jeffr On Sat, Apr 16, 2005 at 07:21:29AM +1000, Peter Jeremy wrote: > My son's computer deadlocked last night. "show lockedvnods" in DDB showe= d: >=20 > Locked vnodes > 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, fla= gs (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 = (pid 9666) with 7 pending > ino 2, on dev ad0s1g (4, 25) > 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, fla= gs (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 156= 86) with 1 pending > ino 23552, on dev ad0s1g (4, 25) > 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, fla= gs (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid = 9075) with 1 pending > ino 122986, on dev ad0s1g (4, 25) > 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, fla= gs (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid = 9067) with 1 pending > ino 142022, on dev ad0s1g (4, 25) > 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, fla= gs (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending > ino 142169, on dev ad0s1g (4, 25) >=20 > After poking around in the crashdump for a while, I've worked out that > the process holding each of the above exclusive locks is waiting on > the next lock in the list. Unfortunately, there doesn't appear to be > any way to work out which process is holding the shared lock unless > DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly > downgraded by a process calling lockmgr(LK_SHARED) when it holds an > exclusive lock). >=20 > FWIW, the affected inodes are: > 2 /usr > 23552 /usr/local > 122986 /usr/local/OpenOffice.org1.1.4 > 142022 /usr/local/OpenOffice.org1.1.4/program > 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so >=20 > Does anyone have any ideas on how to track this further (or so I just > write it off as a glitch). >=20 > --=20 > Peter Jeremy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCYVtBWry0BWjoQKURAiLIAKCB57mp433S4RgP3ItyNubHLamPGQCePWPl 7KDivBq2GXDRS1m96vIVHPc= =5Wfq -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 18:37:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2146416A4CE; Sat, 16 Apr 2005 18:37:58 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB3FE43D2D; Sat, 16 Apr 2005 18:37:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BFA64530F3; Sat, 16 Apr 2005 11:37:55 -0700 (PDT) Date: Sat, 16 Apr 2005 11:37:55 -0700 From: Kris Kennaway To: Rong-En Fan Message-ID: <20050416183755.GB61170@xor.obsecurity.org> References: <6eb82e05041500274172afd3@mail.gmail.com> <20050416122222.GA12385@totem.fix.no> <6eb82e0504160536572e068c@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <6eb82e0504160536572e068c@mail.gmail.com> User-Agent: Mutt/1.4.2.1i cc: Anders Nordby cc: stable@freebsd.org Subject: Re: 5.4/amd64 console hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 18:37:58 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 16, 2005 at 08:36:14PM +0800, Rong-En Fan wrote: > On 4/16/05, Anders Nordby wrote: > > Hi, > >=20 > > On Fri, Apr 15, 2005 at 03:27:11PM +0800, Rong-En Fan wrote: > > > I'm using a Pentium Xeon 3.2G * 2 running 5.3/5.4 amd54 RELEASE. > >=20 > > That's a strange combination. Don't use FreeBSD/amd64 with Intel Pentium > > Xeon processors. Maybe you made a typing error or two? :-) >=20 > Those Xeon are EM64T, compatible with x86-64 :-) >=20 > By the way, I'm thinking that more frequently hang might related with > large read/write block in mount_nfs -r/-w (I use 8192, original is 1024). That's certainly possible since non-default settings don't get as much testing. It would be good to get a traceback. Kris --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCYVuBWry0BWjoQKURAgsdAJ0YqeNEPlRjbsmlhfbvfTQMnhLPvgCdF2Ml 6utE1mRA23YqJLqaIWmUp3E= =JF2Y -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 23:23:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9168D16A4CE for ; Sat, 16 Apr 2005 23:23:23 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED1FA43D4C for ; Sat, 16 Apr 2005 23:23:22 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IF2002CPBDIRT40@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 17 Apr 2005 01:17:42 +0200 (CEST) Received: from kg-work.kg4.no ([80.203.21.150]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0IF200A9ZBOWPJP0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 17 Apr 2005 01:24:33 +0200 (CEST) Date: Sun, 17 Apr 2005 01:23:17 +0200 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq;m"_0v;~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH To: freebsd-stable@freebsd.org Message-id: <20050417012317.3efbc6c7.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Content-type: multipart/mixed; boundary="Boundary_(ID_ervVu1WmPRqn0x17ux+prA)" Subject: amd64 - RS480M2-IL mainboard still needs disabled apic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 23:23:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ervVu1WmPRqn0x17ux+prA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Just for information, in case anyone is interested. I upgraded my amd64 machine to FreeBSD 5.4-stable today: root@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 5.4-STABLE FreeBSD 5.4-STABLE #1: Sat Apr 16 21:04:54 CEST 2005 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 and (not surprisingly, really) it still needs hint.apic.0.disabled="1" in /boot/loader.conf (see earlier thread "amd64 and FreeBSD 5.4-BETA1" on this mailinglist) Other than that, I have not noticed any changes. dmesg.boot attached. -- Regards, Torfinn Ingolfsen, Norway --Boundary_(ID_ervVu1WmPRqn0x17ux+prA) Content-type: application/octet-stream; name=dmesg.boot_amd64_5.4-stable Content-transfer-encoding: base64 Content-disposition: attachment; filename=dmesg.boot_amd64_5.4-stable Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuNC1TVEFCTEUgIzE6IFNhdCBBcHIgMTYgMjE6MDQ6NTQg Q0VTVCAyMDA1CiAgICByb290QGtnLXF1aWV0LmtnNC5ubzovdXNyL29iai91c3Ivc3JjL3N5cy9R VUlFVApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApD UFU6IEFNRCBBdGhsb24odG0pIDY0IFByb2Nlc3NvciAzMDAwKyAoMTc5MC44NC1NSHogSzgtY2xh c3MgQ1BVKQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4MTBmZjAgIFN0ZXBwaW5n ID0gMAogIEZlYXR1cmVzPTB4NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNS LFNTRSxTU0UyPgogIEFNRCBGZWF0dXJlcz0weGUyNTAwODAwPFNZU0NBTEwsTlgsTU1YKyw8YjI1 PixMTSwzRE5vdyssM0ROb3c+CnJlYWwgbWVtb3J5ICA9IDQ2ODY0NzkzNiAoNDQ2IE1CKQphdmFp bCBtZW1vcnkgPSA0NDA4ODExNTIgKDQyMCBNQikKYWNwaTA6IDxSUzQ4MCBBV1JEQUNQST4gb24g bW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJ LXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDMy LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgtMHg0MDBiIG9uIGFjcGkwCmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRs aW5nPiBvbiBjcHUwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6 IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiA8ZGlz cGxheSwgVkdBPiBhdCBkZXZpY2UgNS4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTA6IDxH RU5FUklDIEFUQSBjb250cm9sbGVyPiBwb3J0IDB4ZmEwMC0weGZhMGYsMHhmYjAwLTB4ZmIwMyww eGZjMDAtMHhmYzA3LDB4ZmQwMC0weGZkMDMsMHhmZTAwLTB4ZmUwNyBpcnEgMTEgYXQgZGV2aWNl IDE3LjAgb24gcGNpMAphdGEyOiBjaGFubmVsICMwIG9uIGF0YXBjaTAKYXRhMzogY2hhbm5lbCAj MSBvbiBhdGFwY2kwCmF0YXBjaTE6IDxHRU5FUklDIEFUQSBjb250cm9sbGVyPiBwb3J0IDB4ZjUw MC0weGY1MGYsMHhmNjAwLTB4ZjYwMywweGY3MDAtMHhmNzA3LDB4ZjgwMC0weGY4MDMsMHhmOTAw LTB4ZjkwNyBpcnEgMTAgYXQgZGV2aWNlIDE4LjAgb24gcGNpMAphdGE0OiBjaGFubmVsICMwIG9u IGF0YXBjaTEKYXRhNTogY2hhbm5lbCAjMSBvbiBhdGFwY2kxCm9oY2kwOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlMDJkMDAwLTB4ZmUwMmRmZmYgaXJxIDEwIGF0IGRl dmljZSAxOS4wIG9uIHBjaTAKdXNiMDogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQK dXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGluZwp1c2IwOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6 ICgweDEwMDIpIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CnVodWIwOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApvaGNpMTogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTAyYzAwMC0weGZlMDJjZmZmIGly cSAxMCBhdCBkZXZpY2UgMTkuMSBvbiBwY2kwCnVzYjE6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2Fj eSBzdXBwb3J0CnVzYjE6IFNNTSBkb2VzIG5vdCByZXNwb25kLCByZXNldHRpbmcKdXNiMTogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQp1c2IxOiBVU0IgcmV2aXNpb24g MS4wCnVodWIxOiAoMHgxMDAyKSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMQp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK cGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDE5LjIgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMjAuMCAobm8gZHJpdmVyIGF0 dGFjaGVkKQphdGFwY2kyOiA8R0VORVJJQyBBVEEgY29udHJvbGxlcj4gcG9ydCAweGYzMDAtMHhm MzBmLDB4Mzc2LDB4MTcwLTB4MTc3LDB4M2Y2LDB4MWYwLTB4MWY3IGF0IGRldmljZSAyMC4xIG9u IHBjaTAKYXRhMDogY2hhbm5lbCAjMCBvbiBhdGFwY2kyCmF0YTE6IGNoYW5uZWwgIzEgb24gYXRh cGNpMgppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMjAuMyBvbiBwY2kwCmlzYTA6 IDxJU0EgYnVzPiBvbiBpc2FiMApwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyMC40IG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcmwwOiA8UmVhbFRl ayA4MTM5IDEwLzEwMEJhc2VUWD4gcG9ydCAweGRmMDAtMHhkZmZmIG1lbSAweGZkY2ZmMDAwLTB4 ZmRjZmYwZmYgaXJxIDUgYXQgZGV2aWNlIDMuMCBvbiBwY2kyCm1paWJ1czA6IDxNSUkgYnVzPiBv biBybDAKcmxwaHkwOiA8UmVhbFRlayBpbnRlcm5hbCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1 czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZE WCwgYXV0bwpybDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjExOjA5OmY2OmRjOjAyCmZ3b2hjaTA6 IDxWSUEgRmlyZSBJSSAoVlQ2MzA2KT4gcG9ydCAweGRlMDAtMHhkZTdmIG1lbSAweGZkY2ZlMDAw LTB4ZmRjZmU3ZmYgaXJxIDExIGF0IGRldmljZSA0LjAgb24gcGNpMgpmd29oY2kwOiBPSENJIHZl cnNpb24gMS4xMCAoUk9NPTEpCmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBp cyA0Lgpmd29oY2kwOiBFVUk2NCAwMDoxMDpkYzowMDowMDo5MzpkZDoxNApmd29oY2kwOiBQaHkg MTM5NGEgYXZhaWxhYmxlIFM0MDAsIDIgcG9ydHMuCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3Jl YyAyMDQ4IGJ5dGVzLgpmaXJld2lyZTA6IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29o Y2kwCmZ3ZTA6IDxFdGhlcm5ldCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDog RmFrZSBFdGhlcm5ldCBhZGRyZXNzOiAwMjoxMDpkYzo5MzpkZDoxNApmd2UwOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMjoxMDpkYzo5MzpkZDoxNApmd2UwOiBpZl9zdGFydCBydW5uaW5nIGRlZmVycmVk IGZvciBHaWFudApzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAK ZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IG5vZGVfaWQ9MHhjODAwZmZjMCwg Z2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwg Y2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCnBjaTA6IDxt dWx0aW1lZGlhLCBhdWRpbz4gYXQgZGV2aWNlIDIwLjUgKG5vIGRyaXZlciBhdHRhY2hlZCkKZmRj MDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2Y3LDB4M2YwLTB4M2Y1IGlycSA2 IGRycSAyIG9uIGFjcGkwCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAw CnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEg NCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCnBwYzA6IDxFQ1AgcGFyYWxs ZWwgcHJpbnRlciBwb3J0PiBwb3J0IDB4Nzc4LTB4NzdiLDB4Mzc4LTB4MzdmIGlycSA3IGRycSAz IG9uIGFjcGkwCnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoRVBQL05JQkJMRSkgaW4gQ09NUEFUSUJM RSBtb2RlCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBsaXAwOiA8UExJUCBu ZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0 MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAph dGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQsMHg2MCBpcnEg MSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gZmxhZ3MgMHgxIGlycSAxIG9uIGF0a2Jk YzAKa2JkMCBhdCBhdGtiZDAKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBz bTA6IG1vZGVsIEludGVsbGlNb3VzZSBFeHBsb3JlciwgZGV2aWNlIElEIDQKb3JtMDogPElTQSBP cHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhkMDAwMC0weGQzZmZmLDB4YzAwMDAtMHhjY2ZmZiBvbiBp c2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdB IDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMTogY29uZmlndXJlZCBpcnEg MyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJlIGVu YWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMAp1bXMwOiBXaXJlbGVzcyBNb3VzZSBXaXJlbGVzcyBNb3Vz ZSwgcmV2IDEuMTAvMS4wMSwgYWRkciAyLCBpY2xhc3MgMy8xCnVtczA6IDUgYnV0dG9ucyBhbmQg WiBkaXIuClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAxNzkwODM5OTEyIEh6IHF1YWxpdHkg ODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKYWQwOiAxMTQ0NzNNQiA8U1Qz MTIwMDI2QS84LjAxPiBbMjMyNTgxLzE2LzYzXSBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWNkMDog Q0RST00gPFNBTVNVTkcgQ0QtUk9NIFNDLTE0OEYvUFMwNT4gYXQgYXRhMS1tYXN0ZXIgUElPNApN b3VudGluZyByb290IGZyb20gdWZzOi9kZXYvYWQwczFhCg== --Boundary_(ID_ervVu1WmPRqn0x17ux+prA)-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 23:32:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3ADE16A4CE; Sat, 16 Apr 2005 23:32:54 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C92B43D2D; Sat, 16 Apr 2005 23:32:54 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3GNWrNf023663; Sat, 16 Apr 2005 19:32:53 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23091-05; Sat, 16 Apr 2005 19:32:52 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3GNWqIW023656; Sat, 16 Apr 2005 19:32:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.12.11) with ESMTP id j3GNWkxw036888; Sat, 16 Apr 2005 19:32:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050416192711.03519df8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Apr 2005 19:31:34 -0400 To: Warren , freebsd-questions@freebsd.org From: Mike Tancsa In-Reply-To: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> References: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-stable@freebsd.org Subject: Re: /var/spool/clientmque 185meg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 23:32:54 -0000 At 08:56 AM 16/04/2005, Warren wrote: >/var/spool/clientmqueue <-- 185meg > >How do i get the messages from the above to the root mail folder of my >machine ? > >im willing to provide any neccessary information to help. Take a look at /var/log/maillog to see why its not being processed. If necessary, bump up the loglevel in sendmail In /etc/mail/sendmail.cf change O LogLevel=9 to O LogLevel=14 cd /etc/mail make stop make start You can see the local queue via mailq -Ac and process it manually via sendmail -q -Ac -v ---Mike From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 23:37:30 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D452616A4CF for ; Sat, 16 Apr 2005 23:37:30 +0000 (GMT) Received: from mail.iinet.net.au (mail-03.iinet.net.au [203.59.3.35]) by mx1.FreeBSD.org (Postfix) with SMTP id A1E0743D4C for ; Sat, 16 Apr 2005 23:37:29 +0000 (GMT) (envelope-from shinjii@virusinfo.rdksupportinc.com) Received: (qmail 12461 invoked from network); 16 Apr 2005 23:37:28 -0000 Received: from unknown (HELO warren.shinji.nq.nu) (203.217.86.5) by mail.iinet.net.au with SMTP; 16 Apr 2005 23:37:28 -0000 From: Warren To: Mike Tancsa Date: Sun, 17 Apr 2005 09:36:40 +1000 User-Agent: KMail/1.8 References: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> <6.2.1.2.0.20050416192711.03519df8@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050416192711.03519df8@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504170936.40626.shinjii@virusinfo.rdksupportinc.com> cc: freebsd-stable@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: /var/spool/clientmque 185meg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 23:37:31 -0000 On Sun, 17 Apr 2005 9:31 am, Mike Tancsa wrote: > At 08:56 AM 16/04/2005, Warren wrote: > >/var/spool/clientmqueue <-- 185meg > > > >How do i get the messages from the above to the root mail folder of my > >machine ? > > > >im willing to provide any neccessary information to help. > > Take a look at /var/log/maillog to see why its not being processed. If > necessary, bump up the loglevel in sendmail > > In /etc/mail/sendmail.cf change > O LogLevel=9 > to > O LogLevel=14 > cd /etc/mail > make stop > make start > > You can see the local queue via > > mailq -Ac j3DH6EkG069310 2071 Thu Apr 14 03:06 MAILER-DAEMON (Deferred: Invalid argument) shinjii j3DH6EkH069310 2071 Thu Apr 14 03:06 MAILER-DAEMON (Deferred: Invalid argument) shinjii j3DH6EkI069310 2071 Thu Apr 14 03:06 MAILER-DAEMON (Deferred: Invalid argument) shinjii j3DH6EkJ069310 2071 Thu Apr 14 03:06 MAILER-DAEMON (Deferred: Invalid argument) shinjii (And the list scrolls on) > and process it manually via > > sendmail -q -Ac -v > > > ---Mike -- Yours Sincerely Shinjii http://www.shinji.nq.nu From owner-freebsd-stable@FreeBSD.ORG Sat Apr 16 23:58:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB21216A4CE; Sat, 16 Apr 2005 23:58:54 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C2A643D46; Sat, 16 Apr 2005 23:58:54 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-a.dmv.com (mail-gw-cl-a.dmv.com [216.240.97.38]) j3GNwrEo068188; Sat, 16 Apr 2005 19:58:53 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [64.45.134.154] (dogpound.dyndns.org [64.45.134.154]) by mail-gw-cl-a.dmv.com (8.12.9/8.12.9) with ESMTP id j3GNwqw5037186; Sat, 16 Apr 2005 19:58:53 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <4261A6DA.1030104@dmv.com> Date: Sat, 16 Apr 2005 19:59:22 -0400 From: Sven Willenberger User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <200504162256.04288.shinjii@virusinfo.rdksupportinc.com> <6.2.1.2.0.20050416192711.03519df8@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050416192711.03519df8@64.7.153.2> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.38 cc: freebsd-stable@freebsd.org cc: Warren cc: freebsd-questions@freebsd.org Subject: Re: /var/spool/clientmque 185meg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 23:58:55 -0000 Mike Tancsa presumably uttered the following on 04/16/05 19:31: > At 08:56 AM 16/04/2005, Warren wrote: > >> /var/spool/clientmqueue <-- 185meg >> >> How do i get the messages from the above to the root mail folder of my >> machine ? >> >> im willing to provide any neccessary information to help. > > > > Take a look at /var/log/maillog to see why its not being processed. If > necessary, bump up the loglevel in sendmail > > In /etc/mail/sendmail.cf change > O LogLevel=9 > to > O LogLevel=14 > cd /etc/mail > make stop > make start > The general recommendation is to *never* edit the sendmail.cf directly. Rather cd to /etc/mail and edit your freebsd.mc file adding: define(`confLOG_LEVEL',`14')dnl (those are backtick, value, singlequote) Then: rm `hostname`.?? make && make install-cf make restart if you want to revert back you can simply delete the line from your freebsd.mc file and then remake and install the newly generated cf file. Sven