From owner-freebsd-current@FreeBSD.ORG Sun May 9 00:49:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CC0D16A4CE for ; Sun, 9 May 2004 00:49:03 -0700 (PDT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA3B743D45 for ; Sun, 9 May 2004 00:49:02 -0700 (PDT) (envelope-from j.e.drews@worldnet.att.net) Received: from [12.74.141.14] (14.st.louis-104-105rs.mo.dial-access.att.net[12.74.141.14]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004050907490111200bh5u3e>; Sun, 9 May 2004 07:49:01 +0000 From: Jonathan To: FreeBSD Current In-Reply-To: <1083129282.20619.18.camel@mobile.silbsd.org> References: <1083129282.20619.18.camel@mobile.silbsd.org> Content-Type: text/plain Message-Id: <1084089040.227.29.camel@mobile.silbsd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 09 May 2004 02:50:41 -0500 Content-Transfer-Encoding: 7bit Subject: Re: vinvalbuf panic while shutting down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 07:49:03 -0000 FreeBSD 5.2-CURRENT #0: Sat May 8 17:45:59 CDT 2004 Hi: I get a kernel panic when I deliberately remove a umass storage device that is still mounted. The machine panics after the halt command. I recopied these messages. umass0: at uhb1 port 2 (addr 2) disconnected (pass0:umass-sim0:0:0:0): lost device (pass0:umass-sim0:0:0:0): removing device entry (pass0:umass-sim0:0:0:0): lost device umass0: detached Fatal trap 12: page fault while in kernel mode fault virtual address =0xb9a558c0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc04437cb stack pointer = 0x10:0xd6bebaa8 frame pointer = 0x10:0xd6bebaac code segement = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1 (init) trap number = 12 panic: page fault at line 815 in file /usr/src/sys/i386/i386/trap.c On Wed, 2004-04-28 at 00:14, Jonathan wrote: > uname: 5.2-CURRENT #0: Sun Apr 25 22:37 CDT > i386 > compiled using std make.conf ( only -O for optimization) > > > While shutting down my FreeBSD laptop, I got this panic: > > panic: vinvalbuf: dirty bufs > at line 921 in file /usr/src/sys/kern/vfs_subr.c > > I had just detached a USB mass storage device (umass) and then given the > command "halt", when the panic happened. I may have forgotten to do > umount /mnt, which may have caused the panic ? FreeBSD CURRENT has > worked fine beside this first panic. From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:06:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EEA16A4CE for ; Sun, 9 May 2004 01:06:11 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E974C43D4C for ; Sun, 9 May 2004 01:06:10 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (19253adde396753f32c5e2c0088e7640@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i4986AkF002390 for ; Sun, 9 May 2004 03:06:10 -0500 (CDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8EB6B523EC; Sun, 9 May 2004 01:06:09 -0700 (PDT) Date: Sun, 9 May 2004 01:06:09 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20040509080609.GA910@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: "Fatal trap 12: page fault while in kernel mode" in mmap() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 08:06:11 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A package build machine just died with the following: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6c fault code = supervisor read, page not present instruction pointer = 0x8:0xc06cf6e0 stack pointer = 0x10:0xe32c9c70 frame pointer = 0x10:0xe32c9ce4 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 = 76798 (javadoc) kernel: type 12 trap, code=0 mmap(c7c65bd0,e32c9d14,20,434,8) at mmap+0x2a0 syscall(805002f,280f002f,bfbf002f,8059330,825a415) at syscall+0x2a0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (198, FreeBSD ELF32, nosys), eip = 0x281785a4, esp = 0xbfbfd80c, ebp = 0xbfbfd858 --- --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAneZxWry0BWjoQKURAhIdAJwJUVaMFfiUd3kQqQDQ/acrCnmNsgCgy6sH poy+v98DRNko2UXD+N6DOG8= =jpyK -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:24:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4973B16A4CE for ; Sun, 9 May 2004 01:24:25 -0700 (PDT) Received: from andromeda.oftc.net (andromeda.oftc.net [80.190.233.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2DCD43D1F for ; Sun, 9 May 2004 01:24:24 -0700 (PDT) (envelope-from stu@ipng.org.uk) Received: from [213.106.20.241] (helo=ipng.org.uk) by andromeda.oftc.net with asmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.33) id 1BMjbe-0002D8-AQ; Sun, 09 May 2004 08:24:18 +0000 Received: from stu by ipng.org.uk with local (Exim 4.22) id 1BMjcw-0007su-VP; Sun, 09 May 2004 09:25:38 +0100 Date: Sun, 9 May 2004 09:25:38 +0100 From: Stuart Walsh To: Dylan Wylie Message-ID: <20040509082538.GA30198@deepfreeze.stu> References: <409CC9B8.11985.69A113@localhost> <409D614D.7983.2B9BBDF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409D614D.7983.2B9BBDF@localhost> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org cc: "M. Warner Losh" Subject: Re: cardbus trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 08:24:25 -0000 On Sat May 08, 10:38P +0200, Dylan Wylie wrote: > hm.. > I'm afraid I only have the one 3com cardbus card. > well...more than one,but identical ones. > Other pccard cards work though. > I could get my hands on some other ones in the coming days. > Is any-one else seeing this? > If not, I'll shut-up for now until I get a chance to try other cards. > > Dylan > oh...no more need for CC, I've re-activated the list. > > On 8 May 2004 at 14:04, M. Warner Losh wrote: > > > Do any cardbus cards work? This looks like the problem I reported a week or two ago(see "current cardbus weirdness"). In my case neither or the two cardbus cards I have available worked, both gave the same message. 5.1 and 5.2.1 work fine but not -current. The two cards I tried were a 3com wireless card(unsupported but I wanted to try ndis) and a realtek 8180 wireless card(same thing, unsupported natively). Regards, Stuart From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:24:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D45E16A4CE; Sun, 9 May 2004 01:24:55 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2119843D45; Sun, 9 May 2004 01:24:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i498Oo5v031065; Sun, 9 May 2004 18:24:50 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i498OlI2029469; Sun, 9 May 2004 18:24:48 +1000 Date: Sun, 9 May 2004 18:24:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Akinori MUSHA In-Reply-To: <86oeoyhavv.knu@iDaemons.org> Message-ID: <20040509172353.S7849@gamplex.bde.org> References: <86smebgjsb.knu@iDaemons.org> <20040509000147.U4217@gamplex.bde.org> <86oeoyhavv.knu@iDaemons.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: audit@freebsd.org Subject: Re: making test(1)'s -nt/-ot ignore nanosecond fractions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 08:24:55 -0000 On Sun, 9 May 2004, Akinori MUSHA wrote: > At Sun, 9 May 2004 00:48:27 +1000 (EST), > Bruce Evans wrote: > > ffs uses vfs_timestamp() which gives a timestamp with the precision > > specified by vfs.timestamp_precision. The default is 0 (TSP_SEC), > > which means that timestamps on files are normally in seconds with > > nanoseconds part 0. This can be changed easily using sysctl, but > > changing the precision to the highest (nanoseconds) gives the bugs > > being discussed. Changing it to microseconds precision is safer, > > since utimes(2) (but not utime(2) supports this precision. > > > > The only other way to get ffs timestamps with a nonzero nanseconds > > part is to use utimes(), but this gives microseconds precision which > > utimes() can copy later. > > Hm, I never changed vfs.timestamp_precision to anything other than the > default (nor even knew of it), but I acutually observed some files > having ...032 and ...256 nanoseconds on an NFS exported FFS on > 4-STABLE. I'm not sure if the files were created directly on FFS or > via NFS. > > Does that mean there could be a bug somewhere around nanotime() calls? The most obvious bug is that nfsclient has no reference to VA_UTIMES_NULL. I think this cause it to use stack garbage for tv_nsec. This seems to be fixed in NetBSD. Demonstration of the bug: %%% Script started on Sun May 9 17:29:21 2004 ttyv2:bde@gamplex:/c/z> cat foo.c main(int argc, char **argv) { utimes(argv[1], 0); } ttyv2:bde@gamplex:/c/z> cc -o foo foo.c ttyv2:bde@gamplex:/c/z> /usr/bin/stat -f "%N %Fm" foo foo 1084087769.000000000 ttyv2:bde@gamplex:/c/z> ./foo foo ttyv2:bde@gamplex:/c/z> /usr/bin/stat -f "%N %Fm" foo foo 1084087802.503363000 ttyv2:bde@gamplex:/c/z> ./foo foo ttyv2:bde@gamplex:/c/z> /usr/bin/stat -f "%N %Fm" foo foo 1084087824.912722647 ttyv2:bde@gamplex:/c/z> exit Script done on Sun May 9 17:30:36 2004 %%% After cc -o foo, foo has a normal mtime set by writing on the server (-current nfsv3 server with vfs.timestamp_precision=0). Then running utimes("foo", 0) on the client messes up foo's st_mtime.tv_nsec. Somehow it avoids messing up foo's st_mtime.tv_sec, and on the first run it rounds to the nearest usec (this behaviour seems to be consistent). I think utimes("foo", 0) should run on the client and set the times to the current time on the client just like utimes("foo", non_null) would set to times obtained from somewhere on the client. However, I think the times should always be rounded (by the server) according to the server's vfs.timestamp_precision. Clients can't be expected to do this since they might not support a timestamp precision. More precision than the server would set for writes would be less than useful. Here is part of the NetBSD code for supporting VA_UTIMES_NULL (atimes are handled similarly for TOSERVER, but not for TOCLIENT -- VA_UTIMES_NULL Is not used then): nfsm_subs.h 1.36: % #define nfsm_srvsattr(a) \ % ... \ % switch (fxdr_unsigned(int, *tl)) { \ % case NFSV3SATTRTIME_TOCLIENT: \ % nfsm_dissect(tl, u_int32_t *, 2 * NFSX_UNSIGNED); \ % fxdr_nfsv3time(tl, &(a)->va_mtime); \ % (a)->va_vaflags &= ~VA_UTIMES_NULL; \ % break; \ % case NFSV3SATTRTIME_TOSERVER: \ % (a)->va_mtime.tv_sec = time.tv_sec; \ % (a)->va_mtime.tv_nsec = time.tv_usec * 1000; \ % (a)->va_vaflags |= VA_UTIMES_NULL; \ % break; \ % }; } The corresponding code in -current is: nfs_srvsubs.c: % int % nfsm_srvsattr_xx(struct vattr *a, struct mbuf **md, caddr_t *dpos) % ... % switch (fxdr_unsigned(int, *tl)) { % case NFSV3SATTRTIME_TOCLIENT: % tl = nfsm_dissect_xx(2 * NFSX_UNSIGNED, md, dpos); % if (tl == NULL) % return EBADRPC; % fxdr_nfsv3time(tl, &(a)->va_mtime); % break; % case NFSV3SATTRTIME_TOSERVER: % getnanotime(&(a)->va_mtime); % break; % } Looks like I was wrong about the client handling VA_UTIMES_NULL -- the above seems to run on the server. I don't understand what it is doing with VA_UTIMES_NULL. Other aspects of the bug are clearer: using getnanotime() instead of vfs_timestamp() breaks the policy set in vfs.timestamp_precision. It wrong anyway since it gives excessive precision -- getnanotime() has at most 1/HZ accuracy. `time' used to have the same accuracy and perhaps still does in NetBSD, but using it gives 3 fewer digits of excessive precision and is friendlier with utimes(). THe quick fix is to replace the above getnanotime() with vfs_timestamp(). Unfortunately, nfs has 16 other calls to getnanotime(), 2 calls to microtime() and 3 calls to getmicrotime() that need to be checked. Bruce From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:50:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2801A16A4CE for ; Sun, 9 May 2004 01:50:59 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7926443D31 for ; Sun, 9 May 2004 01:50:58 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (203.134.131.56) by smtp01.syd.iprimus.net.au (7.0.024) id 409956B400137785; Sun, 9 May 2004 18:50:54 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id E211541E5; Sun, 9 May 2004 18:50:27 +1000 (EST) Date: Sun, 9 May 2004 18:50:27 +1000 From: Tim Robbins To: Kris Kennaway Message-ID: <20040509085027.GA25317@cat.robbins.dropbear.id.au> References: <20040509080609.GA910@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040509080609.GA910@xor.obsecurity.org> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: "Fatal trap 12: page fault while in kernel mode" in mmap() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 08:50:59 -0000 On Sun, May 09, 2004 at 01:06:09AM -0700, Kris Kennaway wrote: > A package build machine just died with the following: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x6c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc06cf6e0 > stack pointer = 0x10:0xe32c9c70 > frame pointer = 0x10:0xe32c9ce4 > 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 = 76798 (javadoc) > kernel: type 12 trap, code=0 > > mmap(c7c65bd0,e32c9d14,20,434,8) at mmap+0x2a0 > syscall(805002f,280f002f,bfbf002f,8059330,825a415) at syscall+0x2a0 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (198, FreeBSD ELF32, nosys), eip = 0x281785a4, esp = 0xbfbfd80c, ebp = 0xbfbfd858 --- After a conversation on IRC, it was established that mmap+0x2a0 was: #9 0xc06cf6e0 in mmap (td=0xc7c65bd0, uap=0xe32c9d14) at ../../../vm/vm_mmap.c:323 323 if (vp->v_mount->mnt_flag & MNT_NOEXEC) And: (kgdb) print fp->f_vnode $1 = (struct vnode *) 0xc9c0fe38 (kgdb) print fp->f_vnode->v_mount $2 = (struct mount *) 0x0 (kgdb) print fp->f_vnode->v_op $3 = (vop_t **) 0xc61ff700 (kgdb) print fp->f_vnode->v_type $4 = VCHR (kgdb) print spec_vnodeop_p $5 = (vop_t **) 0xc61ff700 (kgdb) print fp->f_vnode->v_tag $6 = 0xc0772c0e "orphanchr" This is a character device vnode that has been orphaned from the filesystem containing its special file by a forced unmount. mmap() should check that v_mount != NULL before dereferencing it to handle this case properly. I'll commit a fix for this soon if nobody beats me to it. Tim From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:55:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C1016A4CE for ; Sun, 9 May 2004 01:55:36 -0700 (PDT) Received: from smtp30.hccnet.nl (smtp30.hccnet.nl [62.251.0.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id E281A43D2D for ; Sun, 9 May 2004 01:55:34 -0700 (PDT) (envelope-from d.wylie@hccnet.nl) Received: from smp by smtp30.hccnet.nl via fia142-13-100.dsl.hccnet.nl [80.100.13.142] with ESMTP id i498tPZR009415 (8.12.10/2.04); Sun, 9 May 2004 10:55:26 +0200 (MEST) From: "Dylan Wylie" To: "M. Warner Losh" , freebsd-current@freebsd.org Date: Sun, 09 May 2004 10:52:10 +0200 MIME-Version: 1.0 Message-ID: <409E0D5A.19164.559D04D@localhost> Priority: normal In-reply-to: <20040508.172554.110767931.imp@bsdimp.com> References: <409D614D.7983.2B9BBDF@localhost> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-current@freebsd.org Subject: Re: cardbus trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 08:55:36 -0000 Yes, it used to work perfectly. The dmesg with both cardbus and cbb debuging enabled is included below. Again, it shows insertion of the cardbus card which fails, followed by the pccard card, which succeedes. I also don't remember any 'lazy allocation' with the working builds. Dylan On 8 May 2004 at 17:25, M. Warner Losh wrote: > [[ this may be a duplicate ]] > > In message: <409D614D.7983.2B9BBDF@localhost> > "Dylan Wylie" writes: > : hm.. > : I'm afraid I only have the one 3com cardbus card. > : well...more than one,but identical ones. > : Other pccard cards work though. > : I could get my hands on some other ones in the coming days. > : Is any-one else seeing this? > : If not, I'll shut-up for now until I get a chance to try other cards. > > It used to work for you, right? if you set hw.cbb.debug=1 and > hw.cardbus.debug=1 what output do you get? > > Warner > #dmesg starts here Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #3: Sat May 8 23:21:31 CEST 2004 root@blankerdieblank:/usr/obj/usr/src/sys/PRESARIO Preloaded elf kernel "/boot/kernel/kernel" at 0xc086c000. Preloaded elf module "/boot/kernel/snd_via82c686.ko" at 0xc086c1f4. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc086c2a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc086c354. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (466.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 192872448 (183 MB) avail memory = 179036160 (170 MB) Pentium Pro MTRR support enabled random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pcibios: BIOS version 2.10 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 7 INTD is routed to irq 11 pcib0: slot 7 INTC is routed to irq 9 pcib0: slot 7 INTC is routed to irq 9 pcib0: slot 9 INTA is routed to irq 11 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 pcib1: at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1820-0x182f,0x376,0x170- 0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1820 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: at 0x1f0 irq 14 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: at 0x170 irq 15 on atapci0 uhci0: port 0x1800-0x181f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered isab1: at device 7.4 on pci0 device_probe_and_attach: isab1 attach returned 6 pcm0: port 0x1830-0x1833,0x1834-0x1837,0x1000-0x10ff irq 9 at device 7.5 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1000 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 7.6 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: at device 10.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf0000000 cbb0: Found memory at f0000000 cbb0: Secondary bus is 0 cbb0: Secondary bus set to 1 subbus 2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: slot 10 INTA is routed to irq 9 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 fdc0: port 0x3f7,0x3f0- 0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port acpi_ec0: port 0x66,0x62 on acpi0 orm0: )/:>0OZ@@R]MP%?9LZ7%/"KHO8-3D)#] MJ)'XG/=P1J#!0QYS:74@]#-!D?E%=-*_6%A/?-"X_9."\M@(= MTE"7QB'GZ[^"1NK2:"J^HZ`OLZ\'',(=G&-SGZV(ZC&/$FK-A?A>NY.!4OT& M9$@U])[7273R$TA>A.+KJH/3D0+/;@=[/&UR>^V\^147P(_?`UQ MCS!)7#MOA_\>BV?^W$I`#K2&DQ^S?FY54LQ:#%&^@CGPM2X,;/O,\NA/L/#3 MYM\-'S@2+R7LSA5DV35HSAQI0DZAJ4*][P/A/\)ZKYI=UX%&()S$#0_8RAF\ M8];[7Y0GQU"HRA'(CCWG,FCYU.TD)[[6SO/E$-$7OF4'F3NQ!P_YDT7??Q^+ MWW=P:F3`NY;0^\2>4H+5Y\R]_X=E[]M0[SL1,,4K8$^N(??%BU'Y>^GD=&GF M"3F-Y)`E,6II,>?`^>?(W.^76L)!3^=(9)_Y'JF/B8A/;W@Q\!0:&(>!O$6= MS/W/"HJYCVYXM9XY6"!?%727[R,?<]X*CX9<&E(>?1R8"Q?;86;2ZN MQ6JC]M$-+\X"#XI!+HU#_#;UI1=@,=\+U8R7NT+GZNOS?@^>Z1^KJ]SWCQ4N\?+<7OA_R? M@4JQ.=/KO7"RJO>%WC<2J6D34,VLP>?GUQ+?AGK?]$@UFK>B(K+9F\3/]??[ M\+S6(*=+`KP@N5V\"Y7*GOOY'$L?JZ_-[X*I"OY:VV=JZ)&>R\'_\7`KJ'A MGL.7<_QA2ZV/P'(G7 MC=LA$DW4$+'8G@J(>WPU`5:G((9\9B2^]KZ\@7$HQ`>YEL5L7/T]`<\#N4U$ MX7L8^%OMLJ;Q[8$=+K[9E,=LO+=I2G7(1TOQ'7>9(LP**,@D^#M8&FHZ7`UX MF"SZ`DHY(O%S_3T5$!M`EEA"KD5G&-:_/Y6H-IFYMQ&"Z_UL512LGGTQWB)# M+@U+=9%8/$WLO?2WB>!458'E[Y+\_=EPE.<31I%XUK@3'9_W-E#UIR&CGGR9 M?JPF_=.4_3Z>4NN(>$&1>D(*=2CIJ4R/6`[:80#V(`>]U MCNGZ8=5^L'ISHU4="\2 M/]??$YY*UKX^&SQ!)G*[U1^1?$[;#/E["O4'WGLE$)4KJ!&1L&K-E+]_&$3E MGR:KMFW]K1X#V10).!`$[`&Z:I^MS7U4?\^0ZH0&\IA[J.8S%.Z=D*)XR-U0 MJ),1=9"]U!#3$?@*P=S?FV[JW0OF/Q)/M+..&N)5!19.P:U&#J<>/IJ8=ZO? M+ZY@?A>+G^OO]^%^I&!%"3C1KDMZSX/C[$@\YVY.YUQ:$]1J:,@&U'#B.5G1 MCD=W?K[)S[U(>F5M<<'/(?4AIVY=5'_?>G]#!1Z9@>C$5_.%9RZVX9 MUYZ6Q#?:5:)Z.YYXPWM?P]=E;BP5Q+<%/Z>#VF0%><*.YZ)R;*_M>NX\50X] M]6>S"LZQ:U@!&J+W90[Y">1T0O'^G`0RN`*I+NK]#:-ZZ2E\49@<*S4\!P/- M[A12?0)UH+T_;?[7)$D=B2_5WUN/AR&Q%;)JSW*]YXU;C0;.9J<^$]BW*JC) MJN,*DE'\UT7-Z>?Z>PWSTL,$3_7W]=MNJ(4W.F2,")989'A?TTW@_^\%%_CA\`MG+W7N5O)6U9M M/]??RWVI8I7X\^X^K,?\!,N4@]_A%5E"^FFBU`#+1'6UI[FW:]D\-[I\0RRC2``R5A\D)*,/2L9ETA'-IM&R$%N0;,06I-*SN4)G%%-FZLP@ M'7]02;(-)$IJ1C>`1"E&Q%)ME:X.1J.DRF6MXB$I0221XY"L$Y<9DI+*I&B4 MXP-C9S(OM#\;T"CMLA'HTAA7DU>;W-K0%)A/5E16VSE8SJ7@[>'0GE1[4.&# M)I,Q3^*`3:;KS1'^H!!;9I-QPO2FV<0-`...=VO+;#+!Y3R;ER>/Z^;JY/S, M$T7TAAN/'*;P>;2#8L`1,F*HE/(8"?:9$= MVG#K:>N;M#NP\OAJIR=G7TX;A!3-?AZ5-GL[ M2>ZS:&WJ'-R=_8Y\=@B&]OC(N(,`3\7N\V(%L+"5Q!*J\WRWO6X:G9D@:P99 ME:&\P5I+8.&SK;_"O[1MI8B7:5N-C>R4]U1U^".&D71>FNR\$`,LVZ5YH1IH MTB>X1ALQ5K7:%]&&.36*14OJHKL\/WV>7U+<^E]T%:J1VS5`,E"->M]FAFI5 M4:]#-3I^1&0&N^P,6KEZPPQR5XF9($`&U%[9%PA"%8(PO"32O.P8L2>N6);.TG*,W,X]R&O80_X#*H=9N\;2YXD!$5?"TN::J M6B@QF96XSPU3,R#[+"FQ5AYR_'R$6R?W'GWRV7L???#H77@)S[W$>R_#TYF7 M&"E6R*/QG98;+6G*'L66/%J_N0S(EY>J^G99ZXR&Z&ZD8&*.6HOT6&-!B%#E M@1SASS'*$!:L81A!]PK]M"(XB2FOT&;,`*5)AAD0_Y2"$XRPG-$RT76!X!I] MQX+$G`UA*ZHTP@8RI,RS:_"1:`?)D=+LJD/9K==9K=&7FY@*53A&+V:PQM:= M7Z%5ZX[PYZ@V+T%IC4EDE4$9K9&V-ER7ZX36V(,46P4WPV>MC3#E(7+*&4YG MC316PM!U-FOL0:5?'9DU]GZ7/$>YK-/&JC(0*&=&B6]IJ[%'/_!$P5Z<-=>4*(%9Y)+$'E=8OQUN-"=55AK8::[_'6VTADT24!OKQ)/#*&03(:2BE5@PR!*T'1/`5WO1-<_[B_.G M7FW:26U/+.R#W"!DZW9M9)S!W=<7 MN[K>7=285T@BKY`+KS$:N'/,*EQY(=F3'NQU[WXYE]^YNFU_H7BD7?J'S3RBZ$"DS M@I<'A@:3A'*BD,"?+S:39:1_?'<#+*/B@Q2YLDHRZ<@;)J6^W>>OAL8#8ZNF?M;G/^ M[.SJG?(7MZ]@9F,RBC`B5P(M+M^O/3T_,7+L09=X[= MR>5`=&ZCG9/^I&MW]>6N?G;UI#N[.FGL\SO[ZQ0-E3<9VPD3*[=TFPQ'_2AF ME;N<=\-9EUS.3"*[#-=;5^U=*HQS*CYY'UU\KR;/N2EW3N[;N4;22GHQGP=889I<:UO M9%RN9?T;Y;\,:H/*([-KF6[]1IQ2[2F\3VS`XX M2O!2NQ=/NN[T_][WWRG.1!4S0P^AYVA!IC^WQ@-I-R";'\I$C#8Z"!.;4R4I.HF1F*C*9D=R8)E'GF.58D#*2JW-];SKI;>K2#1`+.KUTL@,4F^*N:PZ=7^;"^H[,0:2F#XCBH[D:;& MUS\&_,E,=550D8<]%ZY;5Y%GU=D.9J[(PYY0)")//F3QQBS5%<1;89]K9RV< M?638T[O3IXL_OO_TF\NO3Y=_ M./;A_E=?/E[^S5=75OB3/U1O9D8NXT^H7>9M+_'&QF`IS+!W7Q+#GU&R]#U?O8E?$=F;XP`N<:P6:PMUKN M-P,N,IUBE-)#.L48U(@5M@`F(=.Y+"HWG.6ZHD125(XTX^Z2-+I6I.%SM0#^ M!NZ"CN5J<9=/T1U&]5SL>.,H3P;TORR8)X-_30?K'WSZX<8=AE8M&1]CW&/< M=,8!=B^8B088IM&([B+0&??[+MUAV$A],Z!:#>`>5;!3%FWT6\<_B/`]LCM, M(_9JK#_POU7"RR-56-1PV`[35),\Y#?)^8S@UR@SB9>)^/;C&>HCL\,0SUP- M&):]&-^!_1:*_SCX)Q*ON4,I\GA%'GO*\X]4Q\PS#XA$<_:X>,`?!!0T`=P"`C!S:I%' MD?N/`?XXT_L(?U`!@E`#WY^X\C.L-(_(P_ M*("QO6Y2/6T;G-7W-RO+BN@F1N>O`=E0(ASE'J^W7B#X>>,6B9_Q!UE?PLBH M0&-EQ(:Q1,K=+WOO\`>!2T8"MHE!,-)8C[";/@F$_RR=G!E_L$$8_PQHIX)] M2Z@<==*'>DQYE%92`49]G/\)1Y,B,/RC[`(5>P]I/+5+$@WX>(-*C M3.(DPGP!/#0#=I*+=$0U2=@P/L#%S_B#/2WB&<*(&,_Q9O'IGT@\"_5^7Y<8 MN6I`E]\W$19887)F_,$]8!P:$]@<@ZPMOMW/L?&`0Y/1"-:,`98!`Y(-\/OR MC/A_CL7/^(,&P;2MZV`?-*#W!=S-I=Y3&]]6':+M?H<%-/.^SJ!ID?SDS/B# M'.:Y]P@],"(5LMT%>O_^"L8U;0;L:@.H@PHXE#BP'Q$$*]G9^^\=8Z3'D?@9 M?U#"KM$#ZT@KU]BL'Z]I3H0_V,&\<(T@+H-=4R::^Y"W[)N8ZANX0,$/XPA' M.0>^*=(L+>;'"Z[$2#S1#K]6(*A'$%<`OJ2*$)-\[W\8J.5"/.V0.3#`U^K1 M=PG@V"$V1T^T8N\LQ?/0WFM@V&R[X,]JP'M2L#=B_OVCM/?",\*E7CV@>#4* M]Q3>7-$$_KW#P,DO_-8O"[QL(*U,!WNWZ]93&:: M&+N0`7(^AVB"0P88WVM_F1>?X@^JMLAVG/!!?U?J?1/AZD/\1I"U56.]_[0\ M.3/^8.TY+[L`55(`]XL"%L_%JOUI`"SYJZ7XGCLT1@$HAA+FF<*>(A"\7L?` M#A<@ZB)+L&Z4=LXE"UI;92!@_()*@F\!DR6+_?3MY"))Y:O0=_4@%?B%T+'+SZY*NJ&K)12QCJ MO\;B60>90`.[N$<,UN5E]9,`1!ME<1=6[^&KVJB<`U)Q:4=4@W@Y1>4O\N)E M8HL;\'BX"7RI(D?E)SGQ>J&)`M:1!I19+%*?O;2+:4']`L+/2+R1X$\RP&05 M@)@N0*]JB#D#)A*]8A1$[6X\3_$V*(#,\1X;^)Q3<4?#T#LT&!\XC# M"D!MSCL(,5=&;[`M[PGJ0>&Q4!N!T'=P\;T$AD@*#%`%FV-W M,)KO_2=+JN^J<3G&F7U+IN,0D%5K(3ZB,LDI?`XD19%X.N`9U3Q3!]=(0/N?OZ4\J#S#DY0/=.Y`JR4K6$C)S/),PH[WOBU5PNTANZ6!$TSE&!F>3"1%D?A.NS,'#=_2\R!I MB*@TG*S@.84'V1RRZK=5PNV#57$`$XDFW,56!++L"HD'/<>$A-AECJW>+V;` M-4V^6^]Y:E^4YX/VI[F^3N$?)Z$N0GD[ M%:]3O?<[MF?Z4.78ZCPW.4:[DP$-]EX#-VL-'I0$KUG!WPJ$F_5OP^^1^+H# M?Z-DUSS;&`O]^P_7/FW#G6[,^6)>;:J6E28Y\?0$O)'XMN#G".!J42M^SA'$)>%4&LK\$YLIG9Y;510W0S43B&07^R!KB-\]>ZQFT*'@/ M@>;\?`K>9KJ3WR[%<^U\+@*,:P;X99*O(.,*IMVW/UA0S'1I[T6'<`/78(K^PF$NX8P@\7-X'S#/$\AE.'M?!T(_P\7K@MXK7T,`>7XF ML+WV64""&8FOAQQ%RE\%6?L*LF`$UL>^'V*K7ZS:>[-/+3#H4%<'E1<$3N87 MU47S:FTQ\4WC\D,&SFLKT"$-=6D<\SJ)3GX"R8N(2;SJX'2DP+/6P1Y/F]Q> M.Z_<2#P-%^<>.=67P`]:0]PC3!+7SMOAO\?BF3^W$I`#K>'DQZR?6Q4I[L40 MY2N8`U_KPL"VSRP__@0+/VW^W?"!(_%2PN[L&9HU:,X<:4).H:E"O0\)UG^$ M]5XUCK=70*]2EE8>L%4R>,>L][\H3XZA4)4CD!U[SF70\JG;24Y\K9WGRR&B M+WS+#C)W8@\>\B>+OO\^%K_OX-3(@'=")A" M%;#GU9#[XL6H_+UT'%P%-H8!P&\A9U,O<_*Q&51S>\6L\<)Y"O"KK+]Y&/^2P@//YE+#Z] MX:5#!E7/V.G9Z#-Q+58;M8]N>'$6>%`,I+[T`B_E>D$O[7BI^KK]O M/(\W:&<')VR]OMY9^5YS-Z<:3E63N6IA-GK0SG:LY#U:%S_7WQOP?/=(?=W> M9[QXJ?>/EN+W0_[/0*78G.GU7CA9U?M"[QN)U+0)J&;6X//S:XEO0[UO>J0: MS5M1$=GL3>+G^OM]>%Z+,7\+\(+D`3SHE;M0FO99@IX:B%BZ:F$Q9[_^SWGQ M4'^/W&YHD?Q+M<\Q*J/BH_K['KZ@A@Q57:<^OU39>R>/8_%S_;WQ52!=R5]K MZUP5-=I[.?@O!G8-#?<0/C4(@/ MP*>!W*;B,+W,/"WVF5-X]L#.UQ\LRF/V7AOTY3JD(^6XCON,D68 M%5"02?!WL#34=+@:\#!9]`64&OD@\9272063R7"AFO@[$Z!ML\^?Y*_/YOHX3%.XI8U[D3' MY[T-5/UIR*@G7Z8?JTG_-&6_CZ?4.B)>4*2>D$(=2GHJTV,6\T5N[J5V>2Y_ MO\>`+290#V+`>_6\T6[5?K!Z7$T5+V8JHAC[0G(NUWIOA7KF!*##9H[IPE97=VD]EYWR[CVM"2^T:X2U=OQQ!O>^QJ^+G-CJ2"^+?@Y'=0F*\@3=CP7 ME6-[;==SYZERZ*D_FU5PCEW#"M`0O2]SR$\@IQ-1?<.:@0RN0*J+>G_#J%YZ M"E^4>-!I=`X&FMTII/H$ZD![?]K\KTF2.A)?JK^7':*3>VS5GN5ZSQNW&@V< MS5+@;J]!'HZ)(Q(5EAD^%_3S>`_+\77^"%P"V?O M=>Y6\I95V\_U]W)?JE@E_KR[#^LQOUP3WPY9"`:YH&1%$02O@'HTB$<+X3^, MQ<_U]P(Y*Q?^9"`3G?PVJ(WZ(];[WE&3P$HYZ.?;DSS\$F=&AM@]#H+E_@C< M@K:W*IMP[UKK.7)A3U260%6?@]\1%,!$9\PY390:8)EFCFW\024I1LM-7((U MH`%6F?=J@`@/6;F1EM)SX11?)(XRCVNS\47:@Q0"C[GJ)ND!HA],ZDP]CK_9 MNBS5@M%8"L8(O>\EXP]*GG;$\?L,HV4AMB#9B"U(E0).".B,8LI,G1FDHP_: MS5]M`XG2!'#P2B!16I@$+U'IZF`T2JH=G-(J8S3VH*>OPRCK50Z)SU0(8SW6 MC@%N69FQ/K,VC*!JD\JZ*E6^G$O!V\.A/6U@5EUK,AF70A8FT_4&?R/7FF^8 M32:(WC:;N`%@@IF-LRDU&%3@NO-$>9AP7!R>NQQIJ6!Z:R>J&T5!O'HP7P_R3CF4;#JV`NCS)2A-P\ M,.U9I.)7`OB9%MFA::TV3Z$-X"@+\-5.3\Z^G#8(*9K]/"IKG-W2ZX\R,G0, MC?JT/CT];_+0J(Z$G@4N@7OKM>%1K3L!AK>($LL="=DVE%CNN#Z6!HA9+\T495ZF;34V&V]AJ MP\1P34F,U^AX-FNU+\(-\Z$`)5Q3%]WE^>GSPIH2%1B8/%8C%YK)#%:CWK>9 MH0H#TUG`:N22:42UNNP,2B[-AAE4A(H-U/;8DU12!&)X23Y\V3FHT]V",&?W MU<7)\_JJ2XAT[I[53[LEJWKTIY2P8UHQ1^UU;-?_XN_H,:N.C72L>P$I#]I] M36+<6J?!2J.-M>'5]6;)..Z_Y2PMY^C-S*.P!L:G\%92;W"UA9V: MI1*368G[S##M\@"0]X(2V^!3S?-X"OG M+>8\BZUN33`7ZYQKR(/4+?)USK7?7`:D]$M5?;NH=?852N*<:TACY@!RB@/! MQS&<'Z4LG<,P@NZ5^LD$T%-,K)QH,R56R"IIYE,JIHT2BJ6-K:.@R_QVS!SA#U*%T&X*A"S:;C)?G#W]\FO'X_W61"E:X*;\ MY,&]W;M'Q2%*%S;&;)2.M)$9M#%SU,6E(7;X"&TPA2P+PO$1.O;EMU:Z;<.K M>!40;KN->@Y2*L/7.5^Q!XVY-"Z/$0_H5.6R M?RFY8I7C?,6H7JN(ZK7*4[UB[_=<[!.OHMM$68,VYH*8=:I7[$%7@77+5*_H M:QD<;*AG1E2]CB@U,&VW0X0JG\N3,\Y;W]N1HUW=MA?=,!Z, M,1)]X6(+XHX+DZ*^OO6FP6:,)/=O3;0HF8!#$T^8-3Z`N\J:"8`UMU[WV9B? MF9PJ92.F(0[$7\&4FE\Q/8H[`IJOT5T2?`.U8Z8(221!;/I9]V+W_D?34(OS M;H7R>#LBSE83=&/5PET\G(GC'9V]#R6ZB9UJ+*AM1MYHV^8F5$%>M M1]1ZV`;F[W@Z:OF406LU&UDOYO^E"DEZBN/*,*/\T$YQ?7?MAEL#)7W?X_*M MNXBP39/4ONZ&X3XK*/HHSL1;'W%VU%@R6U0'+=WP2CF-6EJ]K+1VEQ\LM M7T)<]BM>O@1M1QS?P9QD:)[W%^=/O=JTD]JX/&GP4E;Y]_<CX167'5ST*;X:+?S%1!#J&"\O(< M6KCM,]LU;EAKY_=32?26,[D8KG=UQ>[NMY=U%A01Z*@CFP.ZL:.R'BXTCA-%&AC M8\W>P4'=\*!+,[[:H&Y\+1SLEH,ZVY@*(LN#H_@ZH\/Q<>J=+`.([,B.=SOV MOAW+[MW=-O_$OI*3>!UR%UY0="%24[%RMHMV^,`,)8B2\L5FLDS4'=\=1_/@ MX5UK!)=_61Z7H8S&XQH.]SJL,2,$M+&0#!]:,A]$9I+AKIG=I>3!N>3A04K- MAESRA3-05FVKW5L/GPW,9$?WK-UMSI^=7;U3_N+V%=QLRB6[QERS[,[B/6ZS[I3[IV5U_NZF=73[JS MJY/&/K^SOTY>>7F3L?_/XE2,=)L,1_THZY:MK%J&^X;,NG!(4IKKK:OV+A7& M.16?/+C[[MUMR]:^T\19`3[L+:@V\M'MGUY6_D7V'-)O2[:XQIY)JV1[O+\Z_[,[NW/2/S$XY0 M?#=\_RF--/PD(232CFHXN\4*1?IZC(NQ)PW)I;60ULSP?/S=J[[/OH<9J+_< M\!Y.(?TL6`5_31J\%YS)('M$JZEV&D^OZ%:3_U7I M%73`04W8%&!"@@5I+P@1A0\L.YW[P-9GIML_L'!$KHM$V?+S\@8^KAHT>#P9 M0*3)Z`#??M9Q=\CD.H;O^CK7<:NY#N0CJ0J.Y:=,'V0ZL-;&D-NP`+I2R8*` M(DGG;':7Y\\NFFYWU3W]ZORBOC@Y_6;W[*Q^7I^W<([5OP_ MJE3H_TGG_UEE>NW__4_W_TBER?4,$"%4'>#_N9W@>OZ?U;L#WN,`S_&4W[Z_E_]__G^'\^A;W)_^.:J)OSRZQ/>(!?-LSWM?RR^Z_]LNO[94(* M=8A?)NCM^&7I2=C+^F6D?\W1-Y* M9M907MW\_D^(O.;^3^#*T8;]GQ!=O=3^OQ1*CX=*U57;/[13U[']PY-ZJ^UW MK14AY'#;/SXIR`'O8>;&;?\@-[K.,MM^QE%;-)+8DYSM5\J:$B')3KDC0NM` M4V=>NN5J?M'55T^ZB^.SI2VR=HPX2$%KS)2S8R-T/&G&MQ56\WE='S\^?YXS M^>,XN5JN).;NV5"*MK=&FN+?55==JTF3^ZR:$KW]LVJAD\B2#\NA%G/)[[UQ M?3C>\2:SK0RB3'CUBF=J@*LO6M'*:&'#W)\4FS,P`VM!;^&M1^?U-4![_&@'(&&O92" M#6*CVU5\M/6&Y2V$)GIA(<@KL1"-NRA232#ZL\&H66HA)N;Y*K40CIV%\FXG M6#-@S>H=[WAOW7Q>3;_9&-Z]R.R4NT(E75VZM1#_>/S`0<`^^.R]GS_X[-UW M[1`N6Y/XG="AB3*,3(CQK)XG3!!=+2V=VPC_>4+3>WN"(5W"3ET:+MF4YO;C>V?Q_J>ZE>KO01TI3?9Q[;Q5DT,$W)QUKM! M'W??6F7^)Z?,L0XN=6_0V^OLK9_G%&^`MXHV5^/NQ8H:;ZV-O`73QXW4-[JW M.J&"5_)ZVX[@7&[?#EP&\D;W5G5L*DJ(6MM;AW:"7B-=/#XI-YZB#:VUH(?O MK>.3AFQ_CROGNVGO;9!+N3DDDA*O/)*:-^_K1U+C.-7F2,JUYY3SM>19Q[8D MSP9I#L<]W4@H5?EYCG:2X5]B^M?MSG-35P6+9#_[MU\E.T@DV"EV3;-MQ(:8G=M\^>+CH^,,/ M?OW@X7(G694L(@]M=-.0W-_TMDB\HWJ";&%5]=)!G@^,9V+'6QOT"D3R\$0H M_E>NV]C<:YZ1+-12,NNB#*<7_ZM_&X7_-!4_4#VY@NTA.\IKLF/*X5@[H8+& M&=.@7>/%J]WQ\:]SFK-W)`=JO^M%,Q/PH?)TLQ.U(#M"FPDHWBKF?\7T9O_Q MN8.%C\0[JJ=<_X2S>=J]5^_3]X9S_Z=<[]LFZ%\]4#+6!_F_6N%U>%]N]_GG]\_KG]<_K GG]<_KW]>_[S^>?WS^N?US^N?US^O?U[_O/ZYH9__!MGDSW,`X`$` ` end Cyrille Lefevre -- mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Tue May 11 06:12:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0693E16A4DD for ; Tue, 11 May 2004 06:12:30 -0700 (PDT) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6124643D5C for ; Tue, 11 May 2004 06:12:29 -0700 (PDT) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id i4BDEHK0007209 for ; Tue, 11 May 2004 09:14:17 -0400 (EDT) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id i4BDEH1q007208 for freebsd-current@freebsd.org; Tue, 11 May 2004 09:14:17 -0400 (EDT) Date: Tue, 11 May 2004 09:14:17 -0400 From: Mathew Kanner To: freebsd-current@freebsd.org Message-ID: <20040511131417.GA7115@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.62 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on hak.cnd.mcgill.ca Subject: USB sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 13:12:32 -0000 Hi All, I've recently purchased an el-chepo external USB soundblaster device ($60.00 can) I notice that our usb sound driver is in bad shape. So far I've merged most of NetBSDs changes to date but I'm dying on the locking... Does it work for anybody on 5+? Is anybody working on it? Thanks, --Mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov From owner-freebsd-current@FreeBSD.ORG Tue May 11 07:01:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA4716A4CE for ; Tue, 11 May 2004 07:01:51 -0700 (PDT) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A770043D46 for ; Tue, 11 May 2004 07:01:50 -0700 (PDT) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id F3D9D6C804 for ; Tue, 11 May 2004 16:01:48 +0200 (CEST) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id BF8AC5B4CD; Tue, 11 May 2004 16:01:19 +0200 (CEST) To: Mailing List FreeBSD Current From: Eric Masson Date: Tue, 11 May 2004 15:55:56 +0200 Message-ID: <86oeov2hlf.fsf@t39bsdems.interne.kisoft-services.com> X-Operating-System: FreeBSD 4.9-STABLE i386 User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Panic after disc syncing on shutdown -p (FreeBSD 5.2.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 14:01:52 -0000 Hello, I'm getting the following panic on a P5MVP3/A3 based machine (Bios 2.0SL) The panic happened with 4.9-RELEASE and an older bios release (1.3SL) too. Any idea ? Script started on Tue May 11 15:52:36 2004 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... panic: general protection fault panic messages: --- Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x58:0x8b7f stack pointer = 0x10:0xcdb0fc24 frame pointer = 0x10:0x67890000 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = resume, IOPL = 0 current process = 1 (init) trap number = 9 panic: general protection fault cpuid = 0; Uptime: 2m37s Dumping 256 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- warning: cannot find file for module if_xl.ko warning: cannot find file for module miibus.ko warning: cannot find file for module agp.ko warning: cannot find file for module r128.ko warning: cannot find file for module nfsserver.ko Error while mapping shared library sections: if_xl.ko: No such file or directory. Error while mapping shared library sections: miibus.ko: Unknown error: 0. Error while mapping shared library sections: agp.ko: Unknown error: 0. Error while mapping shared library sections: r128.ko: Unknown error: 0. Error while mapping shared library sections: nfsserver.ko: Unknown error: 0. Error while reading shared library symbols: if_xl.ko: No such file or directory. Error while reading shared library symbols: miibus.ko: No such file or directory. Error while reading shared library symbols: agp.ko: No such file or directory. Error while reading shared library symbols: r128.ko: No such file or directory. Error while reading shared library symbols: nfsserver.ko: No such file or directory. #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) list *0x8b7f No source file for address 0x8b7f. (kgdb) backtrace #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0491883 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0491c27 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc05abd06 in trap_fatal (frame=0xcdb0fbe4, eva=0) at /usr/src/sys/i386/i386/trap.c:821 #4 0xc05ab7bf in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 96, tf_edi = 0, tf_esi = 34182, tf_ebp = 1737031680, tf_isp = -844039152, tf_ebx = 1, tf_edx = 0, tf_ecx = 3, tf_eax = 21249, tf_trapno = 9, tf_err = 61440, tf_eip = 35711, tf_cs = 88, tf_eflags = 65607, tf_esp = 34607, tf_ss = -2054815744}) at /usr/src/sys/i386/i386/trap.c:618 #5 0xc0599ee8 in calltrap () at {standard input}:94 ---Can't read userspace from dump, or kernel process--- (kgdb) quit Script done on Tue May 11 15:53:08 2004 Regards Eric Masson -- Mettre d'un coté ceux qui nous pompent l'air, de l'autre ceux qui brassent du vent. Nous obtiendrons un Usenet climatisé, c'est ça le génie français. Ca risque même d'être un peu trop ventilé. -+- MP in : Clim et châtiment -+- From owner-freebsd-current@FreeBSD.ORG Tue May 11 07:41:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEA9016A4CE for ; Tue, 11 May 2004 07:41:16 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EFF343D1F for ; Tue, 11 May 2004 07:41:16 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) by pooker.samsco.org (8.12.10/8.12.10) with ESMTP id i4BEjru6061169; Tue, 11 May 2004 08:45:53 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40A0E5FB.1060906@freebsd.org> Date: Tue, 11 May 2004 08:40:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <200405102141.53124.michaelnottebrock@gmx.net> <6.1.0.6.1.20040511120109.03f42eb8@popserver.sfu.ca> In-Reply-To: <6.1.0.6.1.20040511120109.03f42eb8@popserver.sfu.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: Panic on 5.2.1-R, netisr related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 14:41:16 -0000 Colin Percival wrote: > Is this problem reproducible? I ask because... > > At 20:41 10/05/2004, Michael Nottebrock wrote: > >>#4 0xc0675715 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:629 > > ^^^^^^ > >>#5 0xc06791c4 in getblk (vp=0xc312ab2c, blkno=1, size=16384, slpflag=0, >>slptimeo=0, flags=0) >> at ../../../kern/vfs_bio.c:2468 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ... this should never happen. getblk dereferences bp during the four > lines immediately before it calls bremfree(bp), so if bp is null, you > should have seen a panic before getting this far. > > Colin Percival > This is actually from the secondary panic in the trace from the system trying to sync after the first one. All bets are off after the first panic. Scott From owner-freebsd-current@FreeBSD.ORG Tue May 11 08:30:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2542D16A4CE; Tue, 11 May 2004 08:30:39 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B71343D48; Tue, 11 May 2004 08:30:33 -0700 (PDT) (envelope-from gnagelhout@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 11:30:22 -0400 Message-ID: From: Gerrit Nagelhout To: 'Robert Watson' Date: Tue, 11 May 2004 11:30:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-current@freebsd.org Subject: RE: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 15:30:39 -0000 Robert Watson wrote: > On Fri, 7 May 2004, Gerrit Nagelhout wrote: > >> The biggest problem I still see with all of this, is that even if I >> could compile the kernel for the P4, under SMP there is >> still no fast >> locking mechanism in place (that I am aware of, although I am >> researching that). > > Are you doing a uni-directional packet stream of a > bi-directional packet > stream? > I am doing a bi-directional packet stream. I am still using device polling though, so it doesn't really matter because only one cpu will be used at a time. I will try out your patches in a couple of days without device polling. The polling vs non-polling performance on 5.2.1 is similar, except that without polling, the system will livelock if I send too much data through. > Speaking of unsafe but fun to try: at one point I did experiment with > ifdef'ing out all of the locking macros and just using Giant, > and I found > that the lack of ability to properly preempt resulted in substantial > latency problems that in turn substantially slowed down performance > measurements for stream protocols like TCP. I can believe this. The fine grained locking can provide a lot of benefits, as long as the cost of the locks themselves can be mitigated. > Actually, I think the memory allocation code is one of the > areas we need > to think very seriously about the current level of locking -- > perhaps more > so than the other locking that's around. I've noticed a pretty high > number of locking operations to perform memory allocations, and we're > doing a lot of them. With mbuf allocation moving to using > UMA, we'll be > able to run statistics and optimize just one allocator, not two. I just had a quick look through some UMA documentation, and it sounds like it could work quite well for mbufs. Is any of that work scheduled for 5.3? Having per CPU memory pools should work well if the interfaces are bound to CPUs also. One approach that I found works well with bridging-type applications is to allocate the clusters separately from the mbufs. Ideally you would allocate a cluster in such a way that it did not have to be pulled into the cache, and then add it to the dma receive ring. Once the dma engine has filled it with data, an mbuf would be allocated, and the cluster attached to it then. The benefit of this is that the cluster only needs to get pulled into the cache once instead of twice, and the number of active mbufs is reduced. With this setup, the number of mbufs is small enough that they will likely stay in the cache all the time, so that the only cache misses will be reading the cluster data. If the cost of allocating one cluster is significant, it may also be worth while to be able to allocate a "slab" of these at once for each interface. If these were returned in some kind of array-type structure, it would be very efficient to add them to the dma ring. > BTW, on a related note, I've also been exploring passing packet chains > into a number of routines that currently accept only single > packets. This > raises more of the "retain ordering" spectre, but might also have some > benefits. If we do explore this model seriously, I think we need to > introduce an 'mbuf queue' structure/object that can be passed > around in > order to improve our ability to use type safety to avoid > nasties. I've > seen too many bugs where code assumes m_nextpkt is NULL when > it's not, or > doesn't carefully maintain synchronization and coherrency of > fields across > sleeping in 4.x, etc. > > Before committing to an approach based on short work queues > over single > packets, I'd definitely want to see observable performance > improvements in > some example cases, though. I think it's also worth > continuing to follow > down our current locking path to make sure we have a decent first cut > MPSAFE system where we have well documented synchronization semantics. I like the idea of using short work queues, and it should work very well for bridge/netgraph/etc. I ran a test where I changed the em driver to generate a chain of mbufs, and pass this to ether_input, thus avoiding one lock/unlock (much like you described). This changed the throughput from ~500kpps to ~540kpps, which is slightly better than just removing the semaphore. I think there are several advantages to this approach: 1) Fewer locks 2) Fewer function calls 3) Better instruction cache usage. Especially on a platform like the Xeon where the decoded instructions are stored in a cache, this is likely to have large benefits. In the case of bridging, I am pretty sure that the entire code path is too big to fit in this, but the individual loops that would be created by this would likely fit. Using work queues may also allow for using software prefetches to ensure the next packet is in cache while working on the current one. After (unsafely :) ) removing the obvious semaphores in the bridge path, the throughput went to around 700kpps, and after profiling this, most of the cycles seemed to be going to mbuf handling (allocating, freeing) and busdma. This is unfortunately still nowhere close to where 4.7 was, but with the UMA allocater, it should be become a lot better. > Something I'd like to explore in detail is a careful comparison of > performing delivery to completion in the interrupt thread vs > using a set > of netisr threads pinned to CPUs. Avoiding lots of context > switches is a > good thing, but I don't have any measurements that suggest at > what layer > in the inbound packet path we get the most coallescing: we > know interrupt > mitigation and coallescing works well at a high level, but are we > currently seeing substantial coallescing due to long-running interrupt > threads, handoffs to netisrs, etc? Some decent measurements > with counters > at each of the hand-off points might go a long way. If there are any other tests you'd like me to try out, let me know. I have a pretty good setup for stress & throughput testing bridging. > I would think that multi-directional bridging would be a win > due to real > latency improvements from parallelism in the kernel. > Likewise, I would > expect SMP application/kernel scenarios such as web servers > on SMP boxes > to benefit through substantially reduced contention. Giant and a > non-parallel kernel hurts us in a lot of these scenarios. > As long as we can reduce the locking costs, I definitely agree with this. Thanks for all the excellent feedback so far, Gerrit From owner-freebsd-current@FreeBSD.ORG Tue May 11 09:18:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76BF816A4CE for ; Tue, 11 May 2004 09:18:44 -0700 (PDT) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B3BE43D3F for ; Tue, 11 May 2004 09:18:43 -0700 (PDT) (envelope-from Holger.Kipp@alogis.com) Received: from intserv.int1.b.intern (localhost [127.0.0.1]) by alogis.com (8.11.1/8.9.3) with SMTP id i4BGIgb90276 for ; Tue, 11 May 2004 18:18:42 +0200 (CEST) (envelope-from hk@alogis.com) Message-Id: <200405111618.i4BGIgb90276@alogis.com> Date: Tue, 11 May 2004 16:18:36 +0000 From: Holger Kipp To: current@freebsd.org X-Mailer: phpGroupWare (http://www.phpgroupware.org) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-description: Mail message body Subject: [SOLVED] ports/66247: snmpd exits with signal 10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Holger.Kipp@alogis.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 16:18:44 -0000 Problem ports/66247 went magically away after going to the latest -CURRENT: (5.2-CURRENT FreeBSD 5.2-CURRENT #1: Tue May 11 17:07:55 CEST 2004) I don't know who made the relevant changes, but thanx anyway to everyone working on -CURRENT! Regards, Holger From owner-freebsd-current@FreeBSD.ORG Tue May 11 10:18:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B82F316A4CE for ; Tue, 11 May 2004 10:18:30 -0700 (PDT) Received: from willow.veidit.net (willow.veidit.net [81.93.138.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C1343D5C for ; Tue, 11 May 2004 10:18:29 -0700 (PDT) (envelope-from john@veidit.net) Received: from veidit.net (c-9cc071d5.15-1-64736c10.cust.bredbandsbolaget.se [213.113.192.156]) (authenticated bits=0) by willow.veidit.net (8.12.10/8.12.10) with ESMTP id i4BHIOpM013995 for ; Tue, 11 May 2004 19:18:28 +0200 (CEST) Message-ID: <40A10AC8.6080406@veidit.net> Date: Tue, 11 May 2004 19:18:00 +0200 From: John Angelmo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040430 X-Accept-Language: sv, en-gb, en, en-us MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: re driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 17:18:30 -0000 It seems that the re driver has some problems on my laptop at "high" network and some cpu it simply just dies, you can't ping out, not get a new dhcp lease or anything, a reboot seems to be the only thing that helps... This problem does not occur when using a WiFi card or other NICs.. from dmesg: re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x9000 re0: port 0x9000-0x90ff mem 0xf0018800-0xf00188ff irq 11 at device 11.0 on pci0 /John From owner-freebsd-current@FreeBSD.ORG Tue May 11 11:44:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED9D616A4CE for ; Tue, 11 May 2004 11:44:47 -0700 (PDT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4250443D5D for ; Tue, 11 May 2004 11:44:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18009 invoked from network); 11 May 2004 18:44:46 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 May 2004 18:44:46 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i4BIihEm005893; Tue, 11 May 2004 14:44:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Gerrit Nagelhout Date: Tue, 11 May 2004 14:45:10 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405111445.10295.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: 'Scott Long' cc: freebsd-current@FreeBSD.org cc: 'Robert Watson' cc: bmilekic@FreeBSD.org Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 18:44:48 -0000 On Tuesday 11 May 2004 11:30 am, Gerrit Nagelhout wrote: > I just had a quick look through some UMA documentation, and it sounds > like it could work quite well for mbufs. Is any of that work > scheduled for 5.3? Having per CPU memory pools should work well if > the interfaces are bound to CPUs also. Yes. Bosko Milekic is working on that. There is a mbuma2 branch in p4 that he is working on that has the current WIP. He might be able to rustle up a diff if you want. I'm not sure how ready it is for testing though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue May 11 13:12:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5109D16A4CE for ; Tue, 11 May 2004 13:12:31 -0700 (PDT) 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 D3EDD43D48 for ; Tue, 11 May 2004 13:12:29 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i4BKCMXw025632; Tue, 11 May 2004 22:12:27 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <40A133A7.60906@DeepCore.dk> Date: Tue, 11 May 2004 22:12:23 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Angelmo References: <40A10AC8.6080406@veidit.net> In-Reply-To: <40A10AC8.6080406@veidit.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@freebsd.org Subject: Re: re driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 20:12:31 -0000 John Angelmo wrote: > It seems that the re driver has some problems on my laptop > at "high" network and some cpu it simply just dies, you can't ping out, > not get a new dhcp lease or anything, a reboot seems to be the only > thing that helps... > This problem does not occur when using a WiFi card or other NICs.. > > from dmesg: > re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x9000 > re0: port 0x9000-0x90ff mem > 0xf0018800-0xf00188ff > irq 11 at device 11.0 on pci0 Thats a known problem, its been like this for ages... I hacked rl to take the card instead, works like a charm... -- -Søren From owner-freebsd-current@FreeBSD.ORG Tue May 11 14:26:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 591ED16A4CE for ; Tue, 11 May 2004 14:26:15 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA5A43D2D for ; Tue, 11 May 2004 14:26:14 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (sccrmhc11) with ESMTP id <2004051121261301100k4icde>; Tue, 11 May 2004 21:26:13 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i4BLQC8B085164; Tue, 11 May 2004 14:26:12 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i4BLQBWE085163; Tue, 11 May 2004 14:26:11 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 11 May 2004 14:26:11 -0700 From: "Crist J. Clark" To: cyrille.lefevre@laposte.net, david@catwhisker.org, freebsd-current@FreeBSD.org Message-ID: <20040511212611.GA84917@blossom.cjclark.org> References: <0cc701c43704$fe189fc0$7890a8c0@dyndns.org> <200405110321.i4B3LFGI073037@bunrab.catwhisker.org> <20040511093634.GA41727@gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040511093634.GA41727@gits.dyndns.org> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: bind timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 21:26:15 -0000 On Tue, May 11, 2004 at 11:36:35AM +0200, Cyrille Lefevre wrote: [snip] The only obvious problem I see is, [snip] > * /etc/namedb/named.soa > > @ IN SOA ns.gits.fr.invalid. root.gits.dyndns.org. ( > 2004051022 ; Serial > 3H ; Refresh > 1H ; Retry > 1W ; Expire > 1D ) ; Minimum > IN NS ns.gits.fr.invalid. [snip] > gits IN A 192.168.144.96 [snip] > ns IN CNAME gits A CNAME in an NS record is not a good idea, and I believe it is technically incorrect. Having one can cause weirdness. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-current@FreeBSD.ORG Tue May 11 16:28:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A95416A4CE; Tue, 11 May 2004 16:28:54 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3256D43D1F; Tue, 11 May 2004 16:28:53 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [81.185.165.68]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id D337017B537; Wed, 12 May 2004 01:29:36 +0200 (CEST) Message-ID: <140701c437af$b7e6d7a0$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "Crist J. Clark" , , References: <0cc701c43704$fe189fc0$7890a8c0@dyndns.org><200405110321.i4B3LFGI073037@bunrab.catwhisker.org><20040511093634.GA41727@gits.dyndns.org> <20040511212611.GA84917@blossom.cjclark.org> Date: Wed, 12 May 2004 01:28:49 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: bind timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 23:28:54 -0000 "Crist J. Clark" wrote: > On Tue, May 11, 2004 at 11:36:35AM +0200, Cyrille Lefevre wrote: > [snip] > > The only obvious problem I see is, > > [snip] > > > * /etc/namedb/named.soa > > > > @ IN SOA ns.gits.fr.invalid. root.gits.dyndns.org. ( changed to gits.gits.fr.invalid > > 2004051022 ; Serial > > 3H ; Refresh > > 1H ; Retry > > 1W ; Expire > > 1D ) ; Minimum > > IN NS ns.gits.fr.invalid. changed to gits.gits.fr.invalid > [snip] > > gits IN A 192.168.144.96 > [snip] > > ns IN CNAME gits > > A CNAME in an NS record is not a good idea, and I believe it is > technically incorrect. Having one can cause weirdness. nice try, but this doesn't fix anything :( # time host -r localhost 127.0.0.1 Using domain server 127.0.0.1: Host not found, try again. 60.23s real 0.00s user 0.05s system # time host -r localhost 127.0.0.1 Using domain server 127.0.0.1: localhost.gits.fr.invalid has address 127.0.0.1 10.07s real 0.01s user 0.02s system # time host -r localhost 127.0.0.1 Using domain server 127.0.0.1: localhost.gits.fr.invalid has address 127.0.0.1 5.10s real 0.00s user 0.06s system # time host -r localhost 127.0.0.1 Using domain server 127.0.0.1: localhost.gits.fr.invalid has address 127.0.0.1 0.06s real 0.00s user 0.04s system # time host -r localhost 127.0.0.1 Using domain server 127.0.0.1: (nothing!) 20.11s real 0.01s user 0.04s system the above times are the most common observed. thanks anyway. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Tue May 11 18:18:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 422D616A4CE for ; Tue, 11 May 2004 18:18:36 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11DA043D39 for ; Tue, 11 May 2004 18:18:35 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [81.185.165.68]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id BC60817B42F for ; Wed, 12 May 2004 03:19:18 +0200 (CEST) Message-ID: <147301c437bf$0aee09f0$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "freebsd current" References: <0cc701c43704$fe189fc0$7890a8c0@dyndns.org><200405110321.i4B3LFGI073037@bunrab.catwhisker.org> <20040511093634.GA41727@gits.dyndns.org> Date: Wed, 12 May 2004 03:18:32 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: bind timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 01:18:36 -0000 forgot to tack about some configuration files, who knowns ? in fact, the more I think, the more I'm sure this is a long standing bug I've for a long time now which broke many services such as : fetchmail, imap, sendmail, snmp, well, all related network services :( * nothing special in /etc/rc.conf except : named_enable=YES * /etc/sysctl.conf kern.corefile=core kern.randompid=10000 kern.maxprocperuid=512 kern.maxfilesperproc=1024 kern.ipc.shmseg=128 kern.ipc.shmmin=2 kern.ipc.shmall=2048 kern.ipc.shmmax=8388608 kern.ipc.somaxconn=1024 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight_enable=1 net.inet.tcp.isn_reseed_interval=1800 net.inet.udp.blackhole=1 net.inet.udp.recvspace=65536 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.ip.stealth=1 net.inet.ip.check_interface=1 net.inet.ip.redirect=0 net.inet.ip.rtexpire=60 net.inet.ip.ttl=128 net.inet.ip.fw.dyn_fin_lifetime=10 net.inet.ip.fw.dyn_rst_lifetime=5 net.inet.ip.fw.dyn_udp_lifetime=15 net.inet.ip.fw.dyn_short_lifetime=30 security.bsd.see_other_uids=0 security.bsd.unprivileged_proc_debug=0 security.bsd.unprivileged_read_msgbuf=0 lrexec.logall=-1 lrexec.max_bin_uid=2002 * /boot/loader.conf.local kern.ipc.shmmni=256 * /sys/i386/conf/CUSTOM machine i386 cpu I586_CPU # aka Pentium ident CUSTOM # PROC_* are local hack, see PR#65803 for details. options PROC_CHILDTIMES options PROC_CURSIG options PROC_MAXRSS options PROC_UMASK options PROC_SESSION options PROC_TTY options PROC_GID options PROC_RGID options PROC_NOSYSTEM options CPU_SUSP_HLT options INCLUDE_CONFIG_FILE options SCHED_ULE options COMPAT_43 options COMPAT_FREEBSD4 options SYSVSHM options SYSVSEM options SYSVMSG options COMPAT_AOUT # mod: aout req: gzip options P1003_1B_SEMAPHORES options _KPOSIX_PRIORITY_SCHEDULING options DDB options KTRACE options SW_WATCHDOG options INET options INET6 options IPSEC options IPSEC_ESP options IPDIVERT options PFIL_HOOKS # req: pf options IPSTEALTH options RANDOM_IP_ID # req: pf options TCP_DROP_SYNFIN options FFS options SOFTUPDATES options UFS_DIRHASH options MSGBUF_SIZE=65536 options SHOW_BUSYBUFS device isa device pmtimer device atkbdc device atkbd # flags 0x1 options KBD_INSTALL_CDEV device vga device sc # flags 0x100 options MAXCONS=8 options SC_CUT_SPACES2TABS options SC_HISTORY_SIZE=250 device sio device fdc # mod: fdc device ppc # req: ppbus device ppbus # mod: ppbus dep: ppc req: lpt device lpt # mod: lpt dep: ppc ppbus device psm device npx # flags 0x0 iosiz 0x0 device pci device ahc # mod: ahc options AHC_ALLOW_MEMIO options AHC_REG_PRETTY_PRINT device sym # mod: sym device ata device scbus options CAMDEBUG options SCSI_DELAY=5000 options SES_ENABLE_PASSTHROUGH device cd device da device pass device pt device sa options ATA_STATIC_ID device atadisk device ataraid device atapicd device atapicam device bpf device ether device loop device gzip # dep: aout device pty device random # mod: random device speaker # mod: speaker device splash # req: splash_* *_saver Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Tue May 11 20:33:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE51A16A4CE for ; Tue, 11 May 2004 20:33:33 -0700 (PDT) Received: from hotmail.com (bay18-f55.bay18.hotmail.com [65.54.187.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EDFA43D31 for ; Tue, 11 May 2004 20:33:33 -0700 (PDT) (envelope-from weaseal@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 May 2004 20:33:33 -0700 Received: from 130.85.245.34 by by18fd.bay18.hotmail.msn.com with HTTP; Wed, 12 May 2004 03:33:33 GMT X-Originating-IP: [130.85.245.34] X-Originating-Email: [weaseal@hotmail.com] X-Sender: weaseal@hotmail.com From: "Walter Venable" To: freebsd-current@freebsd.org Date: Tue, 11 May 2004 23:33:33 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2004 03:33:33.0474 (UTC) FILETIME=[E6E5F820:01C437D1] Subject: Fatal Trap 12 in -CURRENT cvsup'd 2004-May-11th X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 03:33:33 -0000 So today I tried to jump from 5.2.1-RELEASE-p6 to current. I used this procedure: cvsup cd /usr/obj rm -rf * cd /usr/src make clean make cleandir && make cleandir make -j4 buildworld make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC reboot Then, during the boot process, I got a fatal trap 12. I'd be happy to post the contents of the fatal trap 12 but I can't find where it may have dumped the output to on the system (if at all?). Any suggestions as to how to clear this issue up? _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp From owner-freebsd-current@FreeBSD.ORG Tue May 11 23:31:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4644E16A4CE for ; Tue, 11 May 2004 23:31:32 -0700 (PDT) Received: from hobbiton.shire.net (hobbiton.shire.net [206.71.64.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC87C43D31 for ; Tue, 11 May 2004 23:31:31 -0700 (PDT) (envelope-from chad@shire.net) Received: from [67.161.247.57] (helo=[192.168.99.66]) by hobbiton.shire.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.10) id 1BNnH9-000F7C-00 for freebsd-current@freebsd.org; Wed, 12 May 2004 00:31:31 -0600 Mime-Version: 1.0 (Apple Message framework v613) Message-Id: To: freebsd-current@freebsd.org From: "Chad Leigh -- Shire.Net LLC" Date: Wed, 12 May 2004 00:31:27 -0600 X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on hobbiton.shire.net X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=no version=2.63 X-Spam-Level: Subject: SiI 3114 SATA support (plain disk mode) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 06:31:32 -0000 Hi I realize that the ATA/SATA support is evolving and ongoing. I just wanted to know what the current level of support is for the SiI 3114 SATA controller in -CURRENT. I want to use it with plain old disks, not in any raid mode. I have a Tyan S2882 dual Opteron board running FreeBSD 5.2-CURRENT (updated May 11) running i386 version. This machine has an Adaptec 2200S controller with two arrays. Additionally I have several SATA drives I want to use using the built-in SiI 3114 controller. These are for backup and scratch disks, etc. The machine boots off the 2200S controller. Every time I enable the SiI 3114 controller (in ultra plain disk mode if it matters), the controller is detected, but when it goes to detect the disks, it hangs up the machine. ata5-master and then some detect stuff and hang. I will have to go to the data room and reset the BIOS to enable the controller and reboot to get the exact message. I temporarily am using a Maxtor (Promise) PCI SATA controller card to get two of the disks running but this is not a long term solution since the card is not a low profile card and this is a 2U rack and I cannot close the lid completely with the Maxtor. Any info on the status of SiI 3114 support in i386 FreeBSD (Tyan S2882) would be appreciated. Thanks Chad From owner-freebsd-current@FreeBSD.ORG Tue May 11 23:33:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59A0C16A4CE for ; Tue, 11 May 2004 23:33:39 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3348943D31 for ; Tue, 11 May 2004 23:33:38 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i4C6XZf9030828; Wed, 12 May 2004 08:33:36 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Chad Leigh -- Shire.Net LLC" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 12 May 2004 00:31:27 MDT." Date: Wed, 12 May 2004 08:33:35 +0200 Message-ID: <30827.1084343615@critter.freebsd.dk> cc: freebsd-current@freebsd.org Subject: Re: SiI 3114 SATA support (plain disk mode) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 06:33:39 -0000 In message , "Chad Leigh -- Shi re.Net LLC" writes: >Hi > >I realize that the ATA/SATA support is evolving and ongoing. I just >wanted to know what the current level of support is for the SiI 3114 >SATA controller in -CURRENT. I want to use it with plain old disks, >not in any raid mode. > >I have a Tyan S2882 dual Opteron board running FreeBSD 5.2-CURRENT >(updated May 11) running i386 version. With the last commit from sos@ (yesterday I think) the Sil3114 works on my S2882. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed May 12 00:12:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C8016A4CE for ; Wed, 12 May 2004 00:12:19 -0700 (PDT) Received: from hotmail.com (bay18-f108.bay18.hotmail.com [65.54.187.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A9343D3F for ; Wed, 12 May 2004 00:12:18 -0700 (PDT) (envelope-from weaseal@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 May 2004 00:12:18 -0700 Received: from 130.85.245.34 by by18fd.bay18.hotmail.msn.com with HTTP; Wed, 12 May 2004 07:12:18 GMT X-Originating-IP: [130.85.245.34] X-Originating-Email: [weaseal@hotmail.com] X-Sender: weaseal@hotmail.com From: "Walter Venable" To: freebsd-current@freebsd.org Date: Wed, 12 May 2004 03:12:18 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2004 07:12:18.0905 (UTC) FILETIME=[7643CC90:01C437F0] Subject: RE: Fatal Trap 12 in -CURRENT cvsup'd 2004-May-11th X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 07:12:19 -0000 Solved my own problem... Turns out I had to disable 'nvidia_load="YES"' in my /boot/loader.conf -- after I pulled that everything loaded okay. -Walt >From: "Walter Venable" >To: freebsd-current@freebsd.org >Subject: Fatal Trap 12 in -CURRENT cvsup'd 2004-May-11th >Date: Tue, 11 May 2004 23:33:33 -0400 > >So today I tried to jump from 5.2.1-RELEASE-p6 to current. I used this >procedure: > >cvsup >cd /usr/obj >rm -rf * >cd /usr/src >make clean >make cleandir && make cleandir >make -j4 buildworld >make buildkernel KERNCONF=GENERIC >make installkernel KERNCONF=GENERIC >reboot > >Then, during the boot process, I got a fatal trap 12. I'd be happy to post >the contents of the fatal trap 12 but I can't find where it may have dumped >the output to on the system (if at all?). > >Any suggestions as to how to clear this issue up? _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Wed May 12 00:54:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEF1C16A4CE for ; Wed, 12 May 2004 00:54:25 -0700 (PDT) Received: from md.gfk.ru (md.gfk.ru [62.205.179.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C61043D41 for ; Wed, 12 May 2004 00:54:24 -0700 (PDT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru ([10.0.0.30]) by md.gfk.ru (md.gfk.ru [62.205.179.201]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 55-md50000000049.tmp for ; Wed, 12 May 2004 11:53:51 +0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C437F6.42EDF3B0" X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 12 May 2004 11:53:49 +0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: LOR web page Thread-Index: AcQu28y/QJZgllcSQuyI/e0IltV9rAJFje3A From: "Yuriy Tsibizov" To: X-Spam-Processed: md.gfk.ru, Wed, 12 May 2004 11:53:51 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org Subject: panic: vm_fault: fault on nofault entry in ATA code(?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 07:54:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C437F6.42EDF3B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable I have an old (Pentium-166) machine with two 212Mb IDE disks (more info = attached) in CCD set. It was not in use for about a year (it was running = FreeBSD 5-CURRENT around mid-june 2003) and now I decide to upgrade it = to latest -CURRENT (from 1st May, to be precise). Now I'm getting panic = after attempt to fsck /dev/ccd0 after several ata FAILUREs: atapci0: port = 0xe800-0xe80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe800 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: at 0x1f0 irq 14 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: at 0x170 irq 15 on atapci0 [...] ad0: 535MB [1087/16/63] at ata0-master = WDMA0 ata1-master: FAILURE - SETFEATURES SET TRANSFER MODE = status=3D51 error=3D4 ad2: FAILURE - SETFEATURES DISABLE WCACHE status=3D51 = error=3D4 ad2: 202MB [989/12/35] at ata1-master BIOSPIO ad3: 202MB [989/12/35] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a Enter full pathname of shell or RETURN for /bin/sh: # ccdconfig -C # fsck -t ufs /dev/ccd0 ** /dev/ccd0 ad2: TIMEOUT - READ retrying (2 retries left) LBA=3D33554443 ad2: FAILURE - SETFEATURES SET TRANSFER MODE = status=3D51 error=3D4 ad2: FAILURE - SETFEATURES DISABLE WCACHE status=3D51 = error=3D4 ad2: FAILURE - SETFEATURES SET TRANSFER MODE = status=3D51 error=3D4 panic: vm_fault: fault on nofault entry, addr: c2e2d000 at line 277 in file /usr/src/sys/vm/vm_fault.c Debugger("panic") Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db> t Debugger(c05a7229) at Debugger+0x45 __panic(c05b706f,115,c05b708a,c2e2d000,5) at __panic+0xc7 vm_fault(c0c3b000,c2e2d000,2,0,c0cd0160) at vm_fault+0xe38 trap_pfault(c330ac68,0,c2e2d000) at trap_pfault+0x124 trap(18,10,10,c2e2d000,c14bfe00) at trap+0x2f9 calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0xc042ec82, esp =3D 0xc330aca8, ebp =3D 0xc330acc8 = --- ata_pio_read(c151f000,200) at ata_pio_read+0xba ata_generic_interrupt(c14bfe00) at ata_generic_interrupt+0x2c2 ithread_loop(c0cc4600,c330ad48,c0cc4600,c047a118,0) at = ithread_loop+0x1a4 fork_exit(c047a118,c0cc4600,c330ad48) at fork_exit+0xa8 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xc330ad7c, ebp =3D 0 --- db> ------_=_NextPart_001_01C437F6.42EDF3B0 Content-Type: application/octet-stream; name="cap-1-0" Content-Transfer-Encoding: base64 Content-Description: cap-1-0 Content-Disposition: attachment; filename="cap-1-0" QVRBIGNoYW5uZWwgMSwgTWFzdGVyLCBkZXZpY2UgYWQyOg0KDQpQcm90b2NvbCAgICAgICAgICAg ICAgQVRBL0FUQVBJIHJldmlzaW9uIDANCmRldmljZSBtb2RlbCAgICAgICAgICBXREMgQUMyMjAw Rg0Kc2VyaWFsIG51bWJlciAgICAgICAgIFdENDkzOTk4Mw0KZmlybXdhcmUgcmV2aXNpb24gICAg IDU0DQpjeWxpbmRlcnMgICAgICAgICAgICAgOTg5DQpoZWFkcyAgICAgICAgICAgICAgICAgMTIN CnNlY3RvcnMvdHJhY2sgICAgICAgICAzNQ0KbGJhIG5vdCBzdXBwb3J0ZWQgICAgICAgICANCmxi YTQ4IG5vdCBzdXBwb3J0ZWQgICAgICAgDQpkbWEgc3VwcG9ydGVkDQpvdmVybGFwIG5vdCBzdXBw b3J0ZWQNCg0KRmVhdHVyZSAgICAgICAgICAgICAgICAgICAgICBTdXBwb3J0ICBFbmFibGUgICAg VmFsdWUgICBWZW5kb3INCndyaXRlIGNhY2hlICAgICAgICAgICAgICAgICAgICBubwlubw0KcmVh ZCBhaGVhZCAgICAgICAgICAgICAgICAgICAgIG5vCW5vDQpkbWEgcXVldWVkICAgICAgICAgICAg ICAgICAgICAgbm8Jbm8JMC8weDAwDQpTTUFSVCAgICAgICAgICAgICAgICAgICAgICAgICAgbm8J bm8NCm1pY3JvY29kZSBkb3dubG9hZCAgICAgICAgICAgICBubwlubw0Kc2VjdXJpdHkgICAgICAg ICAgICAgICAgICAgICAgIG5vCW5vDQpwb3dlciBtYW5hZ2VtZW50ICAgICAgICAgICAgICAgbm8J bm8NCmFkdmFuY2VkIHBvd2VyIG1hbmFnZW1lbnQgICAgICBubwlubwkwLzB4MDANCmF1dG9tYXRp YyBhY291c3RpYyBtYW5hZ2VtZW50ICBubwlubwkwLzB4MDAJMC8weDAwDQo= ------_=_NextPart_001_01C437F6.42EDF3B0 Content-Type: application/octet-stream; name="cap-1-1" Content-Transfer-Encoding: base64 Content-Description: cap-1-1 Content-Disposition: attachment; filename="cap-1-1" QVRBIGNoYW5uZWwgMSwgU2xhdmUsIGRldmljZSBhZDM6DQoNClByb3RvY29sICAgICAgICAgICAg ICBBVEEvQVRBUEkgcmV2aXNpb24gMA0KZGV2aWNlIG1vZGVsICAgICAgICAgIFdEQyBBQzEyMTBG DQpzZXJpYWwgbnVtYmVyICAgICAgICAgV0QtV1QyNjkyMTQ3NDc4DQpmaXJtd2FyZSByZXZpc2lv biAgICAgMDYuMTZLMjUNCmN5bGluZGVycyAgICAgICAgICAgICA5ODkNCmhlYWRzICAgICAgICAg ICAgICAgICAxMg0Kc2VjdG9ycy90cmFjayAgICAgICAgIDM1DQpsYmEgbm90IHN1cHBvcnRlZCAg ICAgICAgIA0KbGJhNDggbm90IHN1cHBvcnRlZCAgICAgICANCmRtYSBzdXBwb3J0ZWQNCm92ZXJs YXAgbm90IHN1cHBvcnRlZA0KDQpGZWF0dXJlICAgICAgICAgICAgICAgICAgICAgIFN1cHBvcnQg IEVuYWJsZSAgICBWYWx1ZSAgIFZlbmRvcg0Kd3JpdGUgY2FjaGUgICAgICAgICAgICAgICAgICAg IG5vCW5vDQpyZWFkIGFoZWFkICAgICAgICAgICAgICAgICAgICAgbm8Jbm8NCmRtYSBxdWV1ZWQg ICAgICAgICAgICAgICAgICAgICBubwlubwkwLzB4MDANClNNQVJUICAgICAgICAgICAgICAgICAg ICAgICAgICBubwlubw0KbWljcm9jb2RlIGRvd25sb2FkICAgICAgICAgICAgIG5vCW5vDQpzZWN1 cml0eSAgICAgICAgICAgICAgICAgICAgICAgbm8Jbm8NCnBvd2VyIG1hbmFnZW1lbnQgICAgICAg ICAgICAgICBubwlubw0KYWR2YW5jZWQgcG93ZXIgbWFuYWdlbWVudCAgICAgIG5vCW5vCTAvMHgw MA0KYXV0b21hdGljIGFjb3VzdGljIG1hbmFnZW1lbnQgIG5vCW5vCTAvMHgwMAkwLzB4MDANCg== ------_=_NextPart_001_01C437F6.42EDF3B0-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 01:29:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76A4D16A4CE for ; Wed, 12 May 2004 01:29:38 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F29743D5E for ; Wed, 12 May 2004 01:29:38 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (a03e82cb5d406349f4fb14b28e1b0b5c@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i4C8Tab8006262; Wed, 12 May 2004 03:29:37 -0500 (CDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CD7095183F; Wed, 12 May 2004 01:29:35 -0700 (PDT) Date: Wed, 12 May 2004 01:29:35 -0700 From: Kris Kennaway To: Walter Venable Message-ID: <20040512082935.GA83166@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12 in -CURRENT cvsup'd 2004-May-11th X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 08:29:38 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2004 at 03:12:18AM -0400, Walter Venable wrote: > Solved my own problem... Turns out I had to disable 'nvidia_load=3D"YES"'= in=20 > my /boot/loader.conf -- after I pulled that everything loaded okay. You need to rebuild your modules whenever you update your kernel. This is mostly important for third party modules like nvidia. Kris --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAoeBvWry0BWjoQKURAnZuAJ9WecqXVEzO2JGs63X2EOiOrgTgnwCg3bKL ycFnE6D0rMFBmQHWpDTtMqY= =7LF4 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 03:09:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFD1B16A4CE for ; Wed, 12 May 2004 03:09:50 -0700 (PDT) Received: from willow.veidit.net (willow.veidit.net [81.93.138.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB5E43D5D for ; Wed, 12 May 2004 03:09:49 -0700 (PDT) (envelope-from john@veidit.net) Received: from veidit.net (c-f38e71d5.22-1-64736c10.cust.bredbandsbolaget.se [213.113.142.243]) (authenticated bits=0) by willow.veidit.net (8.12.10/8.12.10) with ESMTP id i4CA9XpM018609; Wed, 12 May 2004 12:09:37 +0200 (CEST) Message-ID: <40A1F7C9.1010801@veidit.net> Date: Wed, 12 May 2004 12:09:13 +0200 From: John Angelmo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040430 X-Accept-Language: sv, en-gb, en, en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <40A10AC8.6080406@veidit.net> <40A133A7.60906@DeepCore.dk> In-Reply-To: <40A133A7.60906@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: re driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 10:09:50 -0000 Søren Schmidt wrote: > > > Thats a known problem, its been like this for ages... > > I hacked rl to take the card instead, works like a charm... > How did you do that? do you have a patch for it? perhaps we can replace re with a hacked rl? /John From owner-freebsd-current@FreeBSD.ORG Wed May 12 04:48:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8C0F16A4CE for ; Wed, 12 May 2004 04:48:25 -0700 (PDT) Received: from smtp.rdsnet.ro (smtp.rdsnet.ro [62.231.74.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8947B43D66 for ; Wed, 12 May 2004 04:48:21 -0700 (PDT) (envelope-from itetcu@apropo.ro) Received: (qmail 17578 invoked by uid 89); 12 May 2004 11:42:07 -0000 Received: from unknown (HELO rdsnet.ro) (62.231.74.131) by 0 with SMTP; 12 May 2004 11:42:07 -0000 Received: (qmail 15724 invoked from network); 12 May 2004 11:48:20 -0000 Received: from unknown (HELO buh.cameradicommercio.ro) (81.196.25.19) by mail.rdsnet.ro with SMTP; 12 May 2004 11:48:20 -0000 Received: from it.buh.cameradicommercio.ro (it.buh.cameradicommercio.ro [192.168.0.10]) by buh.cameradicommercio.ro (Postfix) with ESMTP id 38EF3612C for ; Wed, 12 May 2004 14:48:11 +0300 (EEST) Received: from localhost (localhost.buh.cameradicommercio.ro [127.0.0.1]) by it.buh.cameradicommercio.ro (Postfix) with ESMTP id 307EF2F3 for ; Wed, 12 May 2004 14:52:13 +0300 (EEST) Received: from it.buh.cameradicommercio.ro ([127.0.0.1])port 10024) with ESMTP id 47673-09 for ; Wed, 12 May 2004 14:52:12 +0300 (EEST) Received: from it.buh.cameradicommercio.ro (localhost.buh.cameradicommercio.ro [127.0.0.1]) by it.buh.cameradicommercio.ro (Postfix) with SMTP id B2A132C9 for ; Wed, 12 May 2004 14:52:12 +0300 (EEST) Date: Wed, 12 May 2004 14:52:12 +0300 From: Ion-Mihai Tetcu To: freebsd-current@freebsd.org Message-Id: <20040512145212.62e7db1e@it.buh.cameradicommercio.ro> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at it.buh.cameradicommercio.ro Subject: ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=21267353 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 11:48:26 -0000 Hi, Could someone tell me what this means (-CURRENT)? Thanks, -- IOnut Unregistered ;) FreeBSD "user" From owner-freebsd-current@FreeBSD.ORG Tue May 11 07:18:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5780116A4CE for ; Tue, 11 May 2004 07:18:09 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3708743D45 for ; Tue, 11 May 2004 07:18:08 -0700 (PDT) (envelope-from cyrille.lefevre@laposte.net) Received: from pc2k (unknown [81.185.52.50]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id C1E9E17B876; Tue, 11 May 2004 16:18:51 +0200 (CEST) Message-ID: <0fa501c43762$c79749c0$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "Dave Hart" References: <255A839665EA24408EB27A6AAE15518E27AB59@europa.ad.hartbrothers.com> Date: Tue, 11 May 2004 16:18:06 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailman-Approved-At: Wed, 12 May 2004 04:56:28 -0700 cc: "current @FreeBSD.org" Subject: Re: bind timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 14:18:09 -0000 "Dave Hart" wrote: > > > * The contents of /etc/resolv.conf. > > > > search gits.fr.invalid private.gits.fr.invalid > > nameserver 127.0.0.1 > > nameserver 213.203.124.146 > > nameserver 212.30.96.108 > > This seems questionable. Do the non-localhost nameservers have records for no, this isn't questionnable since they are also declared in /etc/namedb/named.conf, so, in one case, the client asks the local bind to resolv some host, which may be local or not, if not, bind asks one of the forwarders to resolve the query. in another case, the local bind doesn't respond for any reason (down, etc.), so, the query is directly sent to the first available forwarders, then if the query isn't satisfied, take a look at /etc/hosts. since usually, the local bind respond (except for now...), the remote binds aren't reached using /etc/resolv.conf, but through the local bind. am I enough clear ? are you right w/ me or am I wrong ? > gits.fr.invalid? If not, you should only have 127.0.0.1 listed. however, no change w/o them in /etc/resolv.conf # host smarthost Host not found, try again. # host -r smarthost Host not found. CC -current Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Wed May 12 03:57:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D11116A4CE for ; Wed, 12 May 2004 03:57:45 -0700 (PDT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D00D43D60 for ; Wed, 12 May 2004 03:57:36 -0700 (PDT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id E89454EFCDE; Wed, 12 May 2004 18:57:33 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id DDD954EFCDC for ; Wed, 12 May 2004 18:57:33 +0800 (CST) Date: Wed, 12 May 2004 18:57:33 +0800 (CST) From: Tai-hwa Liang To: freebsd-current@freebsd.org Message-ID: <04051218534118.311@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 12 May 2004 04:56:28 -0700 Subject: if_em hung under high network load in -CURRENT cvsup'd on May-12-2004 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 10:57:45 -0000 Greetings, It seems that recent kernel(cvsup'ed on May-12-2004) changes breaks the em driver when the network load is high enough(rsync a directory contains +150MB files). The onboard Intel PRO/1000 just doesn't respond to network request such like ping or dhcp lease renewal -- all interrupt related to em0 was stopped since the "hang" took place. However, the system is still workable(can compile/edit code, only em0 hangs) at this moment. Manually unload/reload the if_em kernel module doesn't solve this problem. Last known good kernel was cvsup'ed on Apr-28-2004, the problem occurred since May-09-2004(cvsup/kernel build on a weekly basis, not sure about whether it worked between Apr-28 and May-09 or not). I'm wondering about whether recent PCI/ACPI changes correlated to this hang since there's no change in /sys/dev/em during last four weeks. The module was built without polling support. ---------------------- vmstat -i ---------------------------- interrupt total rate irq0: clk 93968 99 irq1: atkbd0 4227 4 irq4: cbb0 em0++ 166447 176 irq7: ppc0 1 0 irq8: rtc 120281 127 irq9: acpi0 301 0 irq10: uhci1 200 0 irq11: ath0 uhci2+ 2 0 irq12: psm0 21 0 irq13: npx0 1 0 irq14: ata0 7425 7 irq15: ata1 55 0 Total 392929 417 ------------------------ dmesg ------------------------------ ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 atpic: Programming IRQ4 as edge/high acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 ACPI PCI link before setting link priority: ACPI PCI link before fixup for boot-disabled links: ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base d0000000, size 28, enabled found-> vendor=0x8086, dev=0x3340, revid=0x03 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=0x3341, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKA) pcib0: slot 29 INTA is routed to irq 4 found-> vendor=0x8086, dev=0x24c2, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKD) pcib0: slot 29 INTB is routed to irq 10 found-> vendor=0x8086, dev=0x24c4, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC) pcib0: slot 29 INTC is routed to irq 11 found-> vendor=0x8086, dev=0x24c7, revid=0x01 bus=0, slot=29, func=2 class=0c-03-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=c, irq=11 map[10]: type 1, range 32, base c0000000, size 10, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.LNKH) pcib0: slot 29 INTD is routed to irq 11 found-> vendor=0x8086, dev=0x24cd, revid=0x01 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=11 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x2448, revid=0x81 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24cc, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001860, size 4, enabled found-> vendor=0x8086, dev=0x24ca, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 6 found-> vendor=0x8086, dev=0x24c3, revid=0x01 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=6 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 4, range 32, base 000018c0, size 6, enabled map[18]: type 1, range 32, base c0000c00, size 9, enabled map[1c]: type 1, range 32, base c0000800, size 8, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 6 found-> vendor=0x8086, dev=0x24c5, revid=0x01 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002400, size 8, enabled map[14]: type 4, range 32, base 00002000, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 6 found-> vendor=0x8086, dev=0x24c6, revid=0x01 bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 2 supports D0 D3 current D0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 agp0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xc0100000-0xc01fffff pcib1: prefetched decode 0xe0000000-0xe7ffffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 ACPI PCI link before setting link priority: ACPI PCI link before fixup for boot-disabled links: ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe7ffffff map[14]: type 4, range 32, base 00003000, size 8, enabled pcib1: device (null) requested decoded I/O range 0x3000-0x30ff map[18]: type 1, range 32, base c0100000, size 16, enabled pcib1: device (null) requested decoded memory range 0xc0100000-0xc010ffff pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA) pcib1: slot 0 INTA is routed to irq 4 found-> vendor=0x1002, dev=0x4c66, revid=0x02 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 2 supports D0 D1 D2 D3 current D0 drm0: port 0x3000-0x30ff mem 0xc0100000-0xc010ffff,0xe0000000-0xe7ffffff irq 4 at device 0.0 on pci1 info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized radeon 1.10.0 20020828 on minor 0 uhci0: port 0x1800-0x181f irq 4 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 10 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ums0: IBM Corporation product 0x3107, rev 1.10/5.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xc0000000 ehci0: (New EHCI DeviceId=0x24cd8086) ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 8 pcib2: I/O decode 0x4000-0x8fff pcib2: memory decode 0xc0200000-0xcfffffff pcib2: prefetched decode 0xe8000000-0xefffffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.2 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.1.0 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.1 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.2 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.1 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.2 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.3 \\_SB_.LNKE irq 0: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.8.0 ACPI PCI link before setting link priority: \\_SB_.LNKE: interrupts: 3 4 5 6 7 9 10 11 penalty: 1110 1710 110 1610 1110 110 410 710 references: 1 priority: 0 ACPI PCI link before fixup for boot-disabled links: \\_SB_.LNKE: interrupts: 3 4 5 6 7 9 10 11 penalty: 1110 1710 110 1610 1110 110 410 710 references: 1 priority: 860 ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.0 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.2 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.1.0 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.1 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.2 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.0 \\_SB_.LNKD irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.1 \\_SB_.LNKA irq 4: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.2 \\_SB_.LNKB irq 6: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.3 \\_SB_.LNKE irq 9: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.8.0 pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base b0000000, size 12, enabled pcib2: device (null) requested decoded memory range 0xb0000000-0xb0000fff pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKA) pcib2: slot 0 INTA is routed to irq 4 found-> vendor=0x104c, dev=0xac55, revid=0x01 bus=2, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=4 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b1000000, size 12, enabled pcib2: device (null) requested decoded memory range 0xb1000000-0xb1000fff pcib2: matched entry for 2.0.INTB (src \\_SB_.LNKB) pcib2: slot 0 INTB is routed to irq 6 found-> vendor=0x104c, dev=0xac55, revid=0x01 bus=2, slot=0, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=b, irq=6 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base c0220000, size 17, enabled pcib2: device (null) requested decoded memory range 0xc0220000-0xc023ffff map[14]: type 1, range 32, base c0200000, size 16, enabled pcib2: device (null) requested decoded memory range 0xc0200000-0xc020ffff map[18]: type 4, range 32, base 00008000, size 6, enabled pcib2: device (null) requested decoded I/O range 0x8000-0x803f pcib2: matched entry for 2.1.INTA (src \\_SB_.LNKA) pcib2: slot 1 INTA is routed to irq 4 found-> vendor=0x8086, dev=0x101e, revid=0x03 bus=2, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base c0210000, size 16, enabled pcib2: device (null) requested decoded memory range 0xc0210000-0xc021ffff pcib2: matched entry for 2.2.INTA (src \\_SB_.LNKC) pcib2: slot 2 INTA is routed to irq 11 found-> vendor=0x168c, dev=0x1014, revid=0x01 bus=2, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 cbb0: mem 0xb0000000-0xb0000fff irq 4 at device 0.0 on pci2 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb0000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac55104c 0x02100107 0x06070001 0x00824008 0x10: 0xb0000000 0x020000a0 0xb0050302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400104 0x40: 0x05121014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d071 0x00000000 0x00000000 0x01d21022 0x90: 0x406422c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x0000000f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0xb1000000-0xb1000fff irq 6 at device 0.1 on pci2 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb1000000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac55104c 0x02100107 0x06070001 0x00824008 0x10: 0xb1000000 0x020000a0 0xb0080602 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400206 0x40: 0x05121014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d071 0x00000000 0x00000000 0x01d21022 0x90: 0x406422c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x0000000f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 4 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0220000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [GIANT-LOCKED] em0: bpf attached em0: Ethernet address: 00:0d:60:76:52:1e em0: Speed:N/A Duplex:N/A ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc0210000 ath0: [GIANT-LOCKED] ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ath0: bpf attached ath0: Ethernet address: 00:05:5e:50:fc:22 ath0: bpf attached ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: bpf attached isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] 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=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=00 stat1=00 devices=0xc ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xc0000800-0xc00008ff,0xc0000c00-0xc0000dff irq 6 at device 31.5 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1c00 pcm0: Reserved 0x40 bytes for rid 0x14 type 4 at 0x18c0 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 20 bit DAC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, AMAP, reserved 4 pcm0: sndbuf_setmap 268000, 4000; 0xdddef000 -> 268000 pcm0: sndbuf_setmap 284000, 4000; 0xdddf3000 -> 284000 pci0: at device 31.6 (no driver attached) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 unknown: not probed (disabled) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0xa01 0xa01 0xa01 0xa01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 8250 or not responding unknown: not probed (disabled) ppc0: using extended I/O port range PC873xx probe at 0x2e got unknown ID 0x0 ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 plip0: bpf attached sio1: irq maps: 0xa01 0xa09 0xa01 0xa01 sio1 port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A acpi_ec0: Changing GLK from 1 to 0 unknown: not probed (disabled) acpi_cmbat0: on acpi0 unknown: not probed (disabled) acpi_acad0: on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 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 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: