From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 10:15:51 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4152C16A4DE for ; Sun, 23 Jul 2006 10:15:51 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94BF643D49 for ; Sun, 23 Jul 2006 10:15:50 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com (melfina.ninth-nine.com [192.168.36.6]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k6NAFVHQ028952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Jul 2006 19:15:32 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 23 Jul 2006 19:15:30 +0900 From: Norikatsu Shigemura To: Iain Templeton Message-Id: <20060723191530.80bf186d.nork@FreeBSD.org> In-Reply-To: <44BC1FBF.8050603@cisra.canon.com.au> References: <20060716232338.2357f50a.nork@FreeBSD.org> <200607171309.34139.jhb@freebsd.org> <20060718070334.496cfdf0.nork@FreeBSD.org> <44BC1FBF.8050603@cisra.canon.com.au> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 23 Jul 2006 19:15:32 +0900 (JST) Cc: freebsd-current@FreeBSD.org Subject: Re: many thread applications are unstable on 7-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 10:15:51 -0000 On Tue, 18 Jul 2006 09:39:43 +1000 Iain Templeton wrote: > > 5 nork@nadesico$ firefox > > /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" > > 6 nork@nadesico$ cvsync > > /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" > If you have set SYMVER_ENABLED when building libc, then you may not have > thr_getscheduler(), thr_setscheduler() and thr_setschedparam() in the > src/lib/libc/sys/Versions.def file for the syscalls. (Path and syscall > name may vary...) I knew why these functions are not. Some syscall functions are not in Symbol.map. Please apply following patch. --- lib/libc/sys/Symbol.map.orig Mon Mar 13 09:53:20 2006 +++ lib/libc/sys/Symbol.map Sun Jul 23 12:18:24 2006 @@ -42,6 +42,7 @@ adjtime; aio_cancel; aio_error; + aio_fsync; aio_read; aio_return; aio_suspend; @@ -293,10 +294,13 @@ syscall; thr_create; thr_exit; + thr_getscheduler; thr_kill; thr_new; thr_self; thr_set_name; + thr_setschedparam; + thr_setscheduler thr_suspend; thr_wake; ktimer_create; # Do we want these to be publc interfaces? @@ -400,6 +404,8 @@ __sys_aio_cancel; _aio_error; __sys_aio_error; + _aio_fsync; + __sys_aio_fsync; _aio_read; __sys_aio_read; _aio_return; @@ -902,6 +908,8 @@ __sys_thr_create; _thr_exit; __sys_thr_exit; + _thr_getscheduler; + __sys_thr_getscheduler; _thr_kill; __sys_thr_kill; _thr_new; @@ -910,6 +918,10 @@ __sys_thr_self; _thr_set_name; __sys_thr_set_name; + _thr_setschedparam; + __sys_thr_setscheduler; + _thr_setscheduler; + __sys_thr_setscheduler; _thr_suspend; __sys_thr_suspend; _thr_wake; I found above functions by runing following command: $ cd /usr/obj/usr/src/lib/libc $ readelf -sW *.o | fgrep -e GLOBAL -e WEAK | fgrep -v -e HIDDEN -e UND | fgrep FUNC | awk '{print $8}' | while read i; do echo -n "$i "; if fgrep -qw $i Version.map; then echo "*EXIST*"; else echo "*NONE*"; fi; done From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 12:08:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4615116A4DA for ; Sun, 23 Jul 2006 12:08:00 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98E9843D6E for ; Sun, 23 Jul 2006 12:07:52 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1973591uge for ; Sun, 23 Jul 2006 05:07:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=sAcCJu3i7HceFQU71VY5nKWr4yxbamNlYDx9IxT9J9El1YGJMhGUrDyji5+Ok3YOuLahhhTm4u/dqL9R6n1aSG9Hkrs3RPq/jpy4xUoIR6z+rNbHWlWR7M2YY1RCymRuOQ1DwipXJGqTl4ZVYYmrF8PCdULVBLrtZcagCZCO+JQ= Received: by 10.78.185.7 with SMTP id i7mr1108661huf; Sun, 23 Jul 2006 05:07:49 -0700 (PDT) Received: from ?192.168.1.200? ( [80.217.194.157]) by mx.gmail.com with ESMTP id 39sm1598350hug.2006.07.23.05.07.48; Sun, 23 Jul 2006 05:07:48 -0700 (PDT) Message-ID: <44C36691.5030501@gmail.com> Date: Sun, 23 Jul 2006 14:07:45 +0200 From: Pawel Worach User-Agent: Thunderbird 1.5.0.4 (X11/20060715) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: page fault panic in kern_access/crcopy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 12:08:00 -0000 Hi, While testing SCTP with NetPIPE I found a reproducible panic, I'm not sure if this one is SCTP's fault. This is using: FreeBSD 7.0-CURRENT #0: Sun Jul 23 13:23:06 CEST 2006 + SCTP patches from today. Procedure: NPsctp & NPsctp -h 127.0.0.1 this ends with a "write error" after a while, likely out of resources try again. NPsctp and this happens: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x20:0xc05342f6 stack pointer = 0x28:0xd4880ba8 frame pointer = 0x28:0xd4880bc4 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 = 1047 (NPsctp) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(c076731d,c07c8660,c075bc1f,d4880a5c,100,...) at kdb_backtrace+0x2e panic(c075bc1f,c0784dbc,c257483c,1,1,...) at panic+0xb7 trap_fatal(d4880b68,1c,1,0,c276faa4,...) at trap_fatal+0x342 trap_pfault(d4880b68,0,1c,c07bf820,1c,...) at trap_pfault+0x245 trap(c2760008,c1030028,c1040028,c25706c0,c257469c,...) at trap+0x3e3 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc05342f6, esp = 0xd4880ba8, ebp = 0xd4880bc4 --- uihold(0,c28f4804,64,c28f4800,d4880bf0,...) at uihold+0x16 crcopy(c28f4800,c28f4800,0,d4880c6c,c05b1f73,...) at crcopy+0x32 crdup(c28f4800,0,0,0,c25706c0,...) at crdup+0x1d kern_access(c25706c0,28083000,0,0,d4880d30,...) at kern_access+0x23 access(c25706c0,d4880d04,8,c25706c0,d4880d30,...) at access+0x29 syscall(3b,3b,3b,4,28083000,...) at syscall+0x3d3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (33, FreeBSD ELF32, access), eip = 0x28058b4f, esp = 0xbfbbf65c, ebp = 0xbfbbf678 --- Uptime: 11m13s Physical memory: 502 MB Dumping 83 MB: 68 52 36 20 4 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc0535dd4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc053614d in panic (fmt=0xc075bc1f "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc072d7c2 in trap_fatal (frame=0xd4880b68, eva=28) at /usr/src/sys/i386/i386/trap.c:869 #4 0xc072d455 in trap_pfault (frame=0xd4880b68, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc072cfa3 in trap (frame= {tf_fs = -1032454136, tf_es = -1056767960, tf_ds = -1056702424, tf_edi = -1034484032, tf_esi = -1034467684, tf_ebp = -729281596, tf_isp = -729281644, tf_ebx = 0, tf_edx = 0, tf_ecx = -1034484032, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068285194, tf_cs = 32, tf_eflags = 66194, tf_esp = -1068339599, tf_ss = -1065760352}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc071c1ea in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc05342f6 in uihold (uip=0x0) at pcpu.h:166 #8 0xc0531b92 in crcopy (dest=0xc28f4800, src=0xc28f4800) at /usr/src/sys/kern/kern_prot.c:1954 #9 0xc0531bed in crdup (cr=0x0) at /usr/src/sys/kern/kern_prot.c:1973 #10 0xc05b1f73 in kern_access (td=0xc25706c0, path=0x0, pathseg=UIO_USERSPACE, flags=0) at /usr/src/sys/kern/vfs_syscalls.c:1895 #11 0xc05b1f49 in access (td=0x0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:1877 ---Type to continue, or q to quit--- #12 0xc072dc03 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 4, tf_esi = 671625216, tf_ebp = -1078200712, tf_isp = -729281180, tf_ebx = 671568152, tf_edx = -1078199800, tf_ecx = 671625229, tf_eax = 33, tf_trapno = 12, tf_err = 2, tf_eip = 671451983, tf_cs = 51, tf_eflags = 582, tf_esp = -1078200740, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1015 #13 0xc071c23f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:191 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 8 #8 0xc0531b92 in crcopy (dest=0xc28f4800, src=0xc28f4800) at /usr/src/sys/kern/kern_prot.c:1954 1954 uihold(dest->cr_uidinfo); (kgdb) p *dest $1 = {cr_ref = 1, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 0, cr_groups = {0 }, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_label = 0x0} (kgdb) p *src $2 = {cr_ref = 1, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 0, cr_groups = {0 }, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_label = 0x0} (kgdb) list 1949 1950 KASSERT(crshared(dest) == 0, ("crcopy of shared ucred")); 1951 bcopy(&src->cr_startcopy, &dest->cr_startcopy, 1952 (unsigned)((caddr_t)&src->cr_endcopy - 1953 (caddr_t)&src->cr_startcopy)); 1954 uihold(dest->cr_uidinfo); 1955 uihold(dest->cr_ruidinfo); 1956 if (jailed(dest)) 1957 prison_hold(dest->cr_prison); 1958 #ifdef MAC Regards -- Pawel From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 12:40:46 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A1F16A4DF for ; Sun, 23 Jul 2006 12:40:46 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1444943D55 for ; Sun, 23 Jul 2006 12:40:44 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G4dG9-000Pco-TW; Sun, 23 Jul 2006 13:40:37 +0100 Date: Sun, 23 Jul 2006 13:40:37 +0100 From: Ceri Davies To: current@FreeBSD.org Message-ID: <20060723124037.GI64253@submonkey.net> Mail-Followup-To: Ceri Davies , current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.12-2006-07-14 Sender: Ceri Davies Cc: Subject: Panic on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 12:40:46 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With yesterday's -HEAD, while doing a simultaneous 'portupgrade -a' and a 'make buildworld', with the source and object trees for the buildworld on a NFS mount from a 6-STABLE server. Kernel config is GENERIC, plus: device cpufreq device puc device sound device snd_via8233 makeoptions DEBUG=3D-g options KDB_UNATTENDED This is probably reproducable, as I also experienced a panic yesterday while doing the same thing, but I didn't have dumps configured then. Ceri ----- quinch# uname -a FreeBSD quinch.private.submonkey.net 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Sa= t Jul 22 18:06:40 BST 2006 root@quinch.private.submonkey.net:/usr/obj/u= sr/src/sys/QUINCH amd64 quinch# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x48 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xffffffff80437e89 stack pointer =3D 0x10:0xffffffff95320750 frame pointer =3D 0x10:0xffffffff95320780 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 79501 (script) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 18h46m56s Physical memory: 499 MB Dumping 156 MB: 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); (kgdb) list *0xffffffff80437e89 0xffffffff80437e89 is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:27= 9). 274 void 275 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line) 276 { 277 278 MPASS(curthread !=3D NULL); 279 KASSERT(LOCK_CLASS(&m->mtx_object) =3D=3D &lock_class_mtx_s= leep, 280 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.l= o_name, 281 file, line)); 282 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LO= P_EXCLUSIVE, 283 file, line); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xffffffff804419c9 in boot (howto=3D260) at /usr/src/sys/kern/kern_shut= down.c:409 #2 0xffffffff8044145b in panic (fmt=3D0xffffffff806b262c "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xffffffff806445ba in trap_fatal (frame=3D0xc, eva=3D184467429744119746= 72) at /usr/src/sys/amd64/amd64/trap.c:690 #4 0xffffffff80644903 in trap_pfault (frame=3D0xffffffff953206a0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:609 #5 0xffffffff80644b54 in trap (frame=3D {tf_rdi =3D 56, tf_rsi =3D 0, tf_rdx =3D -2140004967, tf_rcx =3D 419,= tf_r8 =3D 1, tf_r9 =3D -1099297576944, tf_rax =3D -1099297576944, tf_rbx = =3D 56, tf_rbp =3D -1791883392, tf_r10 =3D 0, tf_r11 =3D -2142509056, tf_r1= 2 =3D 0, tf_r13 =3D 419, tf_r14 =3D -2140004967, tf_r15 =3D 1, tf_trapno = =3D 12, tf_addr =3D 72, tf_flags =3D 582, tf_err =3D 0, tf_rip =3D -2143060= 343, tf_cs =3D 8, tf_rflags =3D 66178, tf_rsp =3D -1791883424, tf_ss =3D 16= }) at /usr/src/sys/amd64/amd64/trap.c:383 #6 0xffffffff8062fccb in calltrap () at /usr/src/sys/amd64/amd64/exception= =2ES:168 #7 0xffffffff80437e89 in _mtx_lock_flags (m=3D0x38, opts=3D0,=20 file=3D0xffffffff80721d99 "/usr/src/sys/kern/vfs_mount.c", line=3D419) = at pcpu.h:169 #8 0xffffffff804a87fe in vfs_ref (mp=3D0x0) at /usr/src/sys/kern/vfs_mount= =2Ec:419 #9 0xffffffff804a53b4 in vop_stdgetwritemount (ap=3D0xffffffff953207f0) at /usr/src/sys/kern/vfs_default.c:356 #10 0xffffffff8069d547 in VOP_GETWRITEMOUNT_APV (vop=3D0xffffff000cc22810, = a=3D0xffffffff953207f0) at vnode_if.c:1823 #11 0xffffffff804bcfca in vn_start_write (vp=3D0xffffff000b9683b0, mpp=3D0x= ffffffff95320858, flags=3D1) at vnode_if.h:951 #12 0xffffffff804bd4ed in vn_close (vp=3D0xffffff000b9683b0, flags=3D3, fil= e_cred=3D0xffffff0014d80300,=20 td=3D0xffffff000cc22810) at /usr/src/sys/kern/vfs_vnops.c:284 #13 0xffffffff804be88a in vn_closefile (fp=3D0xffffff0012d40168, td=3D0xfff= fff000cc22810) at /usr/src/sys/kern/vfs_vnops.c:870 #14 0xffffffff8041a851 in fdrop_locked (fp=3D0xffffff0012d40168, td=3D0xfff= fff000cc22810) at file.h:296 #15 0xffffffff8041ac84 in closef (fp=3D0xffffff0012d40168, td=3D0xffffff000= cc22810) at /usr/src/sys/kern/kern_descrip.c:1979 #16 0xffffffff8041c369 in fdfree (td=3D0xffffff000cc22810) at /usr/src/sys/= kern/kern_descrip.c:1653 #17 0xffffffff80426016 in exit1 (td=3D0xffffff000cc22810, rv=3D0) at /usr/s= rc/sys/kern/kern_exit.c:280 #18 0xffffffff80426e1e in sys_exit (td=3D0x38, uap=3D0x0) at /usr/src/sys/k= ern/kern_exit.c:101 #19 0xffffffff80645437 in syscall (frame=3D {tf_rdi =3D 0, tf_rsi =3D 34365169976, tf_rdx =3D 34366229216, tf_rcx= =3D 10, tf_r8 =3D 0, tf_r9 =3D 0, tf_rax =3D 1, tf_rbx =3D 0, tf_rbp =3D 3= 0, tf_r10 =3D 0, tf_r11 =3D 2, tf_r12 =3D 140737488348832, tf_r13 =3D 30, t= f_r14 =3D 0, tf_r15 =3D 1153657258, tf_trapno =3D 12, tf_addr =3D 343679756= 32, tf_flags =3D 0, tf_err =3D 2, tf_rip =3D 34367821068, tf_cs =3D 43, tf_= rflags =3D 514, tf_rsp =3D 140737488346568, tf_ss =3D 35}) at /usr/src/sys/amd64/amd64/trap.c:825 #20 0xffffffff8062fe68 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:270 #21 0x00000008007b550c in ?? () Previous frame inner to this frame (corrupt stack?) --=20 That must be wonderful! I don't understand it at all. -- Moliere --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEw25FocfcwTS3JF8RAlXMAJ4z7lI88sec6DqiW+SKuM23GSmQOACfbGwV wBBlo8gxRLP9y/LHGq5CjKo= =rgKE -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 12:52:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A329916A4DF; Sun, 23 Jul 2006 12:52:30 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 410D043D49; Sun, 23 Jul 2006 12:52:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k6NCqOF8029018; Sun, 23 Jul 2006 08:52:24 -0400 (EDT) Date: Sun, 23 Jul 2006 08:52:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Norikatsu Shigemura In-Reply-To: <20060723191530.80bf186d.nork@FreeBSD.org> Message-ID: References: <20060716232338.2357f50a.nork@FreeBSD.org> <200607171309.34139.jhb@freebsd.org> <20060718070334.496cfdf0.nork@FreeBSD.org> <44BC1FBF.8050603@cisra.canon.com.au> <20060723191530.80bf186d.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Iain Templeton , freebsd-current@freebsd.org Subject: Re: many thread applications are unstable on 7-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 12:52:30 -0000 On Sun, 23 Jul 2006, Norikatsu Shigemura wrote: > On Tue, 18 Jul 2006 09:39:43 +1000 > Iain Templeton wrote: >>> 5 nork@nadesico$ firefox >>> /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" >>> 6 nork@nadesico$ cvsync >>> /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" >> If you have set SYMVER_ENABLED when building libc, then you may not have >> thr_getscheduler(), thr_setscheduler() and thr_setschedparam() in the >> src/lib/libc/sys/Versions.def file for the syscalls. (Path and syscall >> name may vary...) > > I knew why these functions are not. Some syscall functions > are not in Symbol.map. Please apply following patch. Yes, please commit this or forward it to whomever added aio_fsync(), thr_getscheduler(), ... -- DE From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 13:10:47 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 603C016A4DA; Sun, 23 Jul 2006 13:10:47 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E8FA43D45; Sun, 23 Jul 2006 13:10:43 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com (melfina.ninth-nine.com [192.168.36.6]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k6NDAcWo033748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Jul 2006 22:10:38 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 23 Jul 2006 22:10:38 +0900 From: Norikatsu Shigemura To: Daniel Eischen Message-Id: <20060723221038.ff63ec76.nork@FreeBSD.org> In-Reply-To: References: <20060716232338.2357f50a.nork@FreeBSD.org> <200607171309.34139.jhb@freebsd.org> <20060718070334.496cfdf0.nork@FreeBSD.org> <44BC1FBF.8050603@cisra.canon.com.au> <20060723191530.80bf186d.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 23 Jul 2006 22:10:38 +0900 (JST) Cc: iain.templeton@cisra.canon.com.au, freebsd-current@FreeBSD.org, nork@FreeBSD.org Subject: Re: many thread applications are unstable on 7-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 13:10:47 -0000 On Sun, 23 Jul 2006 08:52:24 -0400 (EDT) Daniel Eischen wrote: > > I knew why these functions are not. Some syscall functions > > are not in Symbol.map. Please apply following patch. > Yes, please commit this or forward it to whomever added > aio_fsync(), thr_getscheduler(), ... Thank you. I committed. But I am using libthr. These problems are, yet:-(. From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 15:05:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEC1B16A4DA for ; Sun, 23 Jul 2006 15:05:53 +0000 (UTC) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F27043D45 for ; Sun, 23 Jul 2006 15:05:53 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Sun, 23 Jul 2006 10:05:47 -0500 id 00095808.44C3904B.0000A54C Received: from dsl-201-144-83-153.prod-infinitum.com.mx (dsl-201-144-83-153.prod-infinitum.com.mx [201.144.83.153]) by mail.bafirst.com (Horde MIME library) with HTTP; Sun, 23 Jul 2006 10:05:47 -0500 Message-ID: <20060723100547.14muf6reo4cg084k@mail.bafirst.com> Date: Sun, 23 Jul 2006 10:05:47 -0500 From: eculp@bafirst.com To: freebsd-current@freebsd.org References: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> In-Reply-To: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.1-cvs Subject: Re: New Dell PowerEdge 2900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 15:05:54 -0000 Quoting eculp@bafirst.com: > Does anyone know of any outstanding issues with the Dell PowerEdge > 2900 that comes with the > > PERC 5/i disk controller > Dual Embedded Broadcom=AE NetXtreme II 5708 Gigabit Ethernet NIC's Replying to my own post: From the information that I have seen, the PERC 5 controller and no management software for FreeBSD. Does anyone have any experience with this. I'm thinking that I should reconsider this before it ships and revert back to a 28?0. Thanks, ed > 300GB, SAS, 3.5-inch, 10K RPM Hard Drive > Memory 4GB 533MHz (4x1GB) > > that are my principal concerns with current or RELENG_6 ? > > I would also apreciate knowing What the max ram that current will > recognize is > and > if there are tools for remote administration for a RAID configuracion > on the PERC5 in FreeBSD Current? > > Thanks, > > ed > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 16:04:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90A0316A4E0 for ; Sun, 23 Jul 2006 16:04:33 +0000 (UTC) (envelope-from martin@gneto.com) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD90143D46 for ; Sun, 23 Jul 2006 16:04:31 +0000 (GMT) (envelope-from martin@gneto.com) Received: from ua-83-227-181-30.cust.bredbandsbolaget.se ([83.227.181.30] [83.227.181.30]) by mxfep02.bredband.com with ESMTP id <20060723160430.EOLP3659.mxfep02.bredband.com@ua-83-227-181-30.cust.bredbandsbolaget.se>; Sun, 23 Jul 2006 18:04:30 +0200 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by ua-83-227-181-30.cust.bredbandsbolaget.se (Postfix) with ESMTP id 2A70F67922; Sun, 23 Jul 2006 18:04:21 +0200 (CEST) Message-ID: <44C39E06.80202@gneto.com> Date: Sun, 23 Jul 2006 18:04:22 +0200 From: Martin Nilsson User-Agent: Thunderbird 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: eculp@bafirst.com References: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> In-Reply-To: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: New Dell PowerEdge 2900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 16:04:33 -0000 eculp@bafirst.com wrote: > Does anyone know of any outstanding issues with the Dell PowerEdge 2900 > that comes with the > > PERC 5/i disk controller > Dual Embedded Broadcom® NetXtreme II 5708 Gigabit Ethernet NIC's > 300GB, SAS, 3.5-inch, 10K RPM Hard Drive > Memory 4GB 533MHz (4x1GB) Why don't you buy a system from a vendor who knows FreeBSD and can tell you what parts will work and how well supported they are? There is a long list at: http://www.freebsd.org/commercial/hardware.html Dell is for people who don't care what's inside the box and they tend to run Windows! /Martin From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 16:19:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D7F16A4DF for ; Sun, 23 Jul 2006 16:19:47 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35FD543D46 for ; Sun, 23 Jul 2006 16:19:46 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 14B2C2D4A72; Sun, 23 Jul 2006 16:19:42 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 6D0291141D; Sun, 23 Jul 2006 18:19:41 +0200 (CEST) Date: Sun, 23 Jul 2006 18:19:41 +0200 From: "Simon L. Nielsen" To: Martin Nilsson Message-ID: <20060723161940.GB1088@zaphod.nitro.dk> References: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> <44C39E06.80202@gneto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44C39E06.80202@gneto.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: New Dell PowerEdge 2900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 16:19:48 -0000 On 2006.07.23 18:04:22 +0200, Martin Nilsson wrote: > eculp@bafirst.com wrote: > >Does anyone know of any outstanding issues with the Dell PowerEdge 2900 > >that comes with the > > > >PERC 5/i disk controller > >Dual Embedded Broadcom® NetXtreme II 5708 Gigabit Ethernet NIC's > >300GB, SAS, 3.5-inch, 10K RPM Hard Drive > >Memory 4GB 533MHz (4x1GB) > > Why don't you buy a system from a vendor who knows FreeBSD and can tell > you what parts will work and how well supported they are? > > There is a long list at: http://www.freebsd.org/commercial/hardware.html > > Dell is for people who don't care what's inside the box and they tend to > run Windows! That's not really true, and Dell does care (at least a bit) about non-Windows customers. E.g. see http://cvsweb.freebsd.org/src/sys/dev/mfi/mfi.c (the RAID driver for PERC 5/i: Sponsored by: Dell, Ironport -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 16:02:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0016316A4DD for ; Sun, 23 Jul 2006 16:02:14 +0000 (UTC) (envelope-from casper@mail.web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5C0B43D55 for ; Sun, 23 Jul 2006 16:02:13 +0000 (GMT) (envelope-from casper@mail.web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id 88AC861C0E for ; Sun, 23 Jul 2006 21:02:06 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 4B07061C02 for ; Sun, 23 Jul 2006 21:02:06 +0500 (AMST) Received: from [192.168.0.3] (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id 142CD61C19 for ; Sun, 23 Jul 2006 21:02:06 +0500 (AMST) Message-ID: <44C39D7E.30102@mail.web.am> Date: Sun, 23 Jul 2006 21:02:06 +0500 From: Gaspar Chilingarov User-Agent: Thunderbird 1.5.0.2 (X11/20060528) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: X-Mailman-Approved-At: Sun, 23 Jul 2006 17:47:17 +0000 Subject: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 16:02:15 -0000 Hi all! After upgrading from -CURRENT mid-Mart to Jul 22 current I got a failures for Linux applications which try to use X. About my system: amd64, I'm trying to run openoffice and skype, but they fail with "Segmentation fault". ktrace also produces dump, which makes kdump fail also with segfault. Is this known issue or I've messed somethng on my system while upgrading? Thanks in advice, Gaspar From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 16:02:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C44216A4DD for ; Sun, 23 Jul 2006 16:02:24 +0000 (UTC) (envelope-from casper@mail.web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5622243D46 for ; Sun, 23 Jul 2006 16:02:23 +0000 (GMT) (envelope-from casper@mail.web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id A3EB461C09 for ; Sun, 23 Jul 2006 21:02:18 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id 65A9561C02 for ; Sun, 23 Jul 2006 21:02:18 +0500 (AMST) Received: from [192.168.0.3] (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id 8712B61C07 for ; Sun, 23 Jul 2006 20:59:51 +0500 (AMST) Message-ID: <44C39CF7.3040808@mail.web.am> Date: Sun, 23 Jul 2006 20:59:51 +0500 From: Gaspar Chilingarov User-Agent: Thunderbird 1.5.0.2 (X11/20060528) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: X-Mailman-Approved-At: Sun, 23 Jul 2006 17:47:31 +0000 Subject: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 16:02:24 -0000 Hi all! After upgrading from -CURRENT mid-Mart to Jul 22 current I got a failures for Linux applications which try to use X. About my system: amd64, I'm trying to run openoffice and skype, but they fail with "Segmentation fault". ktrace also produces dump, which makes kdump fail also with segfault. Is this known issue or I've messed somethng on my system while upgrading? Thanks in advice, Gaspar From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 17:49:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 943D616A4DE for ; Sun, 23 Jul 2006 17:49:17 +0000 (UTC) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C9043D78 for ; Sun, 23 Jul 2006 17:49:12 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.6/8.13.6) with ESMTP id k6NHn39c030744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Jul 2006 19:49:03 +0200 Message-ID: <44C3B674.3040804@wm-access.no> Date: Sun, 23 Jul 2006 19:48:36 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "M. Warner Losh" References: <1153312635.1261.22.camel@genius.i.cz> <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060720.093457.1661914908.imp@bsdimp.com> In-Reply-To: <20060720.093457.1661914908.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 17:49:17 -0000 M. Warner Losh wrote: > > One approach that we could use for 64-bit counters would be to just > use 32-bits one, and poll them for overflow and bump an overflow > count. This assumes that the 32-bit counters overflow much less often > than the polling interval, and easily triples the amount of storage > for each of them... It is ugly :-( >=20 What's wrong with the add+adc (asm) approach found on any i386? It would cost you just a few cpu cycles unless i'm mistaken. --=20 Sten Daniel S=F8rsdal From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 17:49:39 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A0DF16A4F4 for ; Sun, 23 Jul 2006 17:49:39 +0000 (UTC) (envelope-from orm_vartis@bk.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3061A43D5F for ; Sun, 23 Jul 2006 17:49:24 +0000 (GMT) (envelope-from orm_vartis@bk.ru) Received: from [212.248.26.91] (port=37952 helo=[212.248.26.91]) by mx3.mail.ru with asmtp id 1G4i4x-000BQp-00 for current@FreeBSD.org; Sun, 23 Jul 2006 21:49:23 +0400 Date: Sun, 23 Jul 2006 21:49:23 +0400 From: Walery X-Mailer: The Bat! (v3.65.03) Professional X-Priority: 3 (Normal) Message-ID: <132106974.20060723214923@bk.ru> To: current@FreeBSD.org In-Reply-To: <20060723124037.GI64253@submonkey.net> References: <20060723124037.GI64253@submonkey.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------12016F8626AAA3D9" Cc: Subject: Re: Panic on amd64 (and i386?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yablochkin Walery List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 17:49:39 -0000 ------------12016F8626AAA3D9 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello Ceri, Sunday, July 23, 2006, 4:40:37 PM, you wrote: CD> With yesterday's -HEAD, while doing a simultaneous CD> 'portupgrade -a' and a 'make buildworld', with the source and object CD> trees for the buildworld on a NFS mount from a 6-STABLE server. CD> Kernel config is GENERIC, plus: CD> device cpufreq CD> device puc CD> device sound CD> device snd_via8233 CD> makeoptions DEBUG=3D-g CD> options KDB_UNATTENDED CD> This is probably reproducable, as I also experienced a panic yesterday CD> while doing the same thing, but I didn't have dumps configured then. CD> Ceri CD> ----- CD> quinch# uname -a CD> FreeBSD quinch.private.submonkey.net 7.0-CURRENT FreeBSD CD> 7.0-CURRENT #4: Sat Jul 22 18:06:40 BST 2006 =20 CD> root@quinch.private.submonkey.net:/usr/obj/usr/src/sys/QUINCH amd64 CD> quinch# kgdb kernel.debug /var/crash/vmcore.0 CD> [GDB will not be able to debug user-mode threads: CD> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] CD> GNU gdb 6.1.1 [FreeBSD] CD> Copyright 2004 Free Software Foundation, Inc. CD> GDB is free software, covered by the GNU General Public License, and yo= u are CD> welcome to change it and/or distribute copies of it under certain condi= tions. CD> Type "show copying" to see the conditions. CD> There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. CD> This GDB was configured as "amd64-marcel-freebsd". CD> Unread portion of the kernel message buffer: CD> Fatal trap 12: page fault while in kernel mode CD> cpuid =3D 0; apic id =3D 00 CD> fault virtual address =3D 0x48 CD> fault code =3D supervisor read, page not present CD> instruction pointer =3D 0x8:0xffffffff80437e89 CD> stack pointer =3D 0x10:0xffffffff95320750 CD> frame pointer =3D 0x10:0xffffffff95320780 CD> code segment =3D base 0x0, limit 0xfffff, type 0x1b CD> =3D DPL 0, pres 1, long 1, def32 0, gran 1 CD> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 CD> current process =3D 79501 (script) CD> trap number =3D 12 CD> panic: page fault CD> cpuid =3D 0 CD> Uptime: 18h46m56s CD> Physical memory: 499 MB CD> Dumping 156 MB: 141 125 109 93 77 61 45 29 13 CD> #0 doadump () at pcpu.h:172 CD> 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); CD> (kgdb) list *0xffffffff80437e89 CD> 0xffffffff80437e89 is in _mtx_lock_flags CD> (/usr/src/sys/kern/kern_mutex.c:279). CD> 274 void CD> 275 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int = line) CD> 276 { CD> 277 CD> 278 MPASS(curthread !=3D NULL); CD> 279 KASSERT(LOCK_CLASS(&m->mtx_object) =3D=3D &lock_class_m= tx_sleep, CD> 280 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_obje= ct.lo_name, CD> 281 file, line)); CD> 282 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER = | LOP_EXCLUSIVE, CD> 283 file, line); CD> (kgdb) backtrace CD> #0 doadump () at pcpu.h:172 CD> #1 0xffffffff804419c9 in boot (howto=3D260) at CD> /usr/src/sys/kern/kern_shutdown.c:409 CD> #2 0xffffffff8044145b in panic (fmt=3D0xffffffff806b262c "%s") CD> at /usr/src/sys/kern/kern_shutdown.c:565 CD> #3 0xffffffff806445ba in trap_fatal (frame=3D0xc, eva=3D18446742974411= 974672) CD> at /usr/src/sys/amd64/amd64/trap.c:690 CD> #4 0xffffffff80644903 in trap_pfault (frame=3D0xffffffff953206a0, user= mode=3D0) CD> at /usr/src/sys/amd64/amd64/trap.c:609 CD> #5 0xffffffff80644b54 in trap (frame=3D CD> {tf_rdi =3D 56, tf_rsi =3D 0, tf_rdx =3D -2140004967, tf_rcx =3D CD> 419, tf_r8 =3D 1, tf_r9 =3D -1099297576944, tf_rax =3D -1099297576944, CD> tf_rbx =3D 56, tf_rbp =3D -1791883392, tf_r10 =3D 0, tf_r11 =3D CD> -2142509056, tf_r12 =3D 0, tf_r13 =3D 419, tf_r14 =3D -2140004967, CD> tf_r15 =3D 1, tf_trapno =3D 12, tf_addr =3D 72, tf_flags =3D 582, tf_er= r =3D CD> 0, tf_rip =3D -2143060343, tf_cs =3D 8, tf_rflags =3D 66178, tf_rsp =3D CD> -1791883424, tf_ss =3D 16}) at /usr/src/sys/amd64/amd64/trap.c:383 CD> #6 0xffffffff8062fccb in calltrap () at CD> /usr/src/sys/amd64/amd64/exception.S:168 CD> #7 0xffffffff80437e89 in _mtx_lock_flags (m=3D0x38, opts=3D0,=20 CD> file=3D0xffffffff80721d99 "/usr/src/sys/kern/vfs_mount.c", line=3D4= 19) at pcpu.h:169 CD> #8 0xffffffff804a87fe in vfs_ref (mp=3D0x0) at CD> /usr/src/sys/kern/vfs_mount.c:419 CD> #9 0xffffffff804a53b4 in vop_stdgetwritemount (ap=3D0xffffffff953207f0) CD> at /usr/src/sys/kern/vfs_default.c:356 CD> #10 0xffffffff8069d547 in VOP_GETWRITEMOUNT_APV CD> (vop=3D0xffffff000cc22810, a=3D0xffffffff953207f0) CD> at vnode_if.c:1823 CD> #11 0xffffffff804bcfca in vn_start_write (vp=3D0xffffff000b9683b0, mpp= =3D0xffffffff95320858, flags=3D1) CD> at vnode_if.h:951 CD> #12 0xffffffff804bd4ed in vn_close (vp=3D0xffffff000b9683b0, CD> flags=3D3, file_cred=3D0xffffff0014d80300,=20 CD> td=3D0xffffff000cc22810) at /usr/src/sys/kern/vfs_vnops.c:284 CD> #13 0xffffffff804be88a in vn_closefile (fp=3D0xffffff0012d40168, td=3D0= xffffff000cc22810) CD> at /usr/src/sys/kern/vfs_vnops.c:870 CD> #14 0xffffffff8041a851 in fdrop_locked (fp=3D0xffffff0012d40168, CD> td=3D0xffffff000cc22810) at file.h:296 CD> #15 0xffffffff8041ac84 in closef (fp=3D0xffffff0012d40168, td=3D0xfffff= f000cc22810) CD> at /usr/src/sys/kern/kern_descrip.c:1979 CD> #16 0xffffffff8041c369 in fdfree (td=3D0xffffff000cc22810) at CD> /usr/src/sys/kern/kern_descrip.c:1653 CD> #17 0xffffffff80426016 in exit1 (td=3D0xffffff000cc22810, rv=3D0) at CD> /usr/src/sys/kern/kern_exit.c:280 CD> #18 0xffffffff80426e1e in sys_exit (td=3D0x38, uap=3D0x0) at CD> /usr/src/sys/kern/kern_exit.c:101 CD> #19 0xffffffff80645437 in syscall (frame=3D CD> {tf_rdi =3D 0, tf_rsi =3D 34365169976, tf_rdx =3D 34366229216, CD> tf_rcx =3D 10, tf_r8 =3D 0, tf_r9 =3D 0, tf_rax =3D 1, tf_rbx =3D 0, tf= _rbp CD> =3D 30, tf_r10 =3D 0, tf_r11 =3D 2, tf_r12 =3D 140737488348832, tf_r13 = =3D CD> 30, tf_r14 =3D 0, tf_r15 =3D 1153657258, tf_trapno =3D 12, tf_addr =3D CD> 34367975632, tf_flags =3D 0, tf_err =3D 2, tf_rip =3D 34367821068, tf_cs CD> =3D 43, tf_rflags =3D 514, tf_rsp =3D 140737488346568, tf_ss =3D 35}) CD> at /usr/src/sys/amd64/amd64/trap.c:825 CD> #20 0xffffffff8062fe68 in Xfast_syscall () at CD> /usr/src/sys/amd64/amd64/exception.S:270 CD> #21 0x00000008007b550c in ?? () CD> Previous frame inner to this frame (corrupt stack?) Sorry, my english is bad :( pcpu.h is broken? My system is i386 HEAD, see KERNCONF in attached kernel.txt, dmesg in dmesg.txt, kldstat in kldstat.txt, version pcpu.h is 1.46. Panic on pcpu.h:166 on my i386-box on high load (make -j3 buildworld + xmm= s music + glxgears full screen): [orm@xxx.ru]/usr/obj/usr/home/cvs-snap/freebsd/current/src/sys/ORM_MODULES>= sudo kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 condition= s. 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-marcel-freebsd". Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x2c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0531cbb stack pointer =3D 0x28:0xdeaceb7c frame pointer =3D 0x28:0xdeaceba4 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 34653 (xmms) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 50m34s Physical memory: 499 MB Dumping 108 MB: 93 77 61 45 29 13 #0 doadump () at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); (kgdb) (kgdb) where #0 doadump () at pcpu.h:166 During symbol reading, Incomplete CFI data; unspecified registers at 0xc050= 1ba3. #1 0xc0502219 in boot (howto=3D0x104) at /usr/home/cvs-snap/freebsd/curren= t/src/sys/kern/kern_shutdown.c:409 #2 0xc0502614 in panic (fmt=3D0xc06c4e57 "%s") at /usr/home/cvs-snap/freeb= sd/current/src/sys/kern/kern_shutdown.c:565 #3 0xc06a24fc in trap_fatal (frame=3D0xdeaceb3c, eva=3D0x0) at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/trap.c:869 #4 0xc06a1aae in trap (frame=3D {tf_fs =3D 0xc4170008, tf_es =3D 0xc0720028, tf_ds =3D 0xdeac0028, tf= _edi =3D 0xc4172b40, tf_esi =3D 0xc4172b40, tf_ebp =3D 0xdeaceba4, tf_isp = =3D 0xdeaceb68, tf_ebx =3D 0xc4172d20, tf_edx =3D 0xaf, tf_ecx =3D 0x0, tf_= eax =3D 0x0, tf_trapno =3D 0xc, tf_err =3D 0x0, tf_eip =3D 0xc0531cbb, tf_c= s =3D 0x20, tf_eflags =3D 0x10082, tf_esp =3D 0xc4172b40, tf_ss =3D 0xaf}) at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/trap.c:279 #5 0xc068a69a in calltrap () at /usr/home/cvs-snap/freebsd/current/src/sys= /i386/i386/exception.s:138 #6 0xc0531cbb in propagate_priority (td=3D0xc4172b40) at /usr/home/cvs-snap/freebsd/current/src/sys/kern/subr_turnstile.c:246 #7 0xc053285c in turnstile_wait (lock=3D0xc4173068, owner=3D0x0, queue=3D0= x0) at /usr/home/cvs-snap/freebsd/current/src/sys/kern/subr_turnstile.c:677 #8 0xc04f719a in _mtx_lock_sleep (m=3D0xc4173068, tid=3D0xc4172d20, opts= =3D0x0, file=3D0x0, line=3D0x0) at /usr/home/cvs-snap/freebsd/current/src/sys/kern/kern_mutex.c:563 #9 0xc0510fcc in thread_single (mode=3D0x0) at /usr/home/cvs-snap/freebsd/= current/src/sys/kern/kern_thread.c:837 #10 0xc04e6219 in fork1 (td=3D0xc4172d20, flags=3D0x14, pages=3D0x0, procp= =3D0xdeacec7c) at /usr/home/cvs-snap/freebsd/current/src/sys/kern/kern_fork.c:275 #11 0xc04e5d99 in fork (td=3D0xc4172d20, uap=3D0xdeaced04) at /usr/home/cvs-snap/freebsd/current/src/sys/kern/kern_fork.c:98 #12 0xc06a2933 in syscall (frame=3D {tf_fs =3D 0x825003b, tf_es =3D 0xbf3f003b, tf_ds =3D 0xbf3f003b, tf_= edi =3D 0xac44, tf_esi =3D 0x286b1fa0, tf_ebp =3D 0xbf2f7e28, tf_isp =3D 0x= deaced64, tf_ebx =3D 0x285ba954, tf_edx =3D 0x0, tf_ecx =3D 0x82041b0, tf_e= ax =3D 0x2, tf_trapno =3D 0xc, tf_err =3D 0x2, tf_eip =3D 0x2861c563, tf_cs= =3D 0x33, tf_eflags =3D 0x282, tf_esp =3D 0xbf2f7dcc, tf_ss =3D 0x3b}) at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/trap.c:1015 #13 0xc068a6ef in Xint0x80_syscall () at /usr/home/cvs-snap/freebsd/current= /src/sys/i386/i386/exception.s:191 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) =20 orm_vartiS a=EA=E0 =C2=E0=EB=E5=F0=E0. E-mail: orm_vartis NOSPAM NOSPAM bk ru ICQ UIN: 174977614. ------------12016F8626AAA3D9 Content-Type: TEXT/PLAIN; name="Kernel.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="Kernel.txt" bWFjaGluZQkJaTM4NgpjcHUJCUk2ODZfQ1BVCmlkZW50CQlPUk1fTU9EVUxFUwptYXh1c2Vy cwkwCm9wdGlvbnMgCUlQRklSRVdBTEwKb3B0aW9ucyAgCUlQRklSRVdBTExfREVGQVVMVF9U T19BQ0NFUFQKb3B0aW9ucyAJSVBGSVJFV0FMTF9WRVJCT1NFCm9wdGlvbnMgCUlQRklSRVdB TExfVkVSQk9TRV9MSU1JVD0yMDAwCm9wdGlvbnMJCUlQRklSRVdBTExfRk9SV0FSRApvcHRp b25zCQlJUEZJUkVXQUxMX0ZPUldBUkRfRVhURU5ERUQKb3B0aW9ucwkJVENQX0RST1BfU1lO RklOCm9wdGlvbnMgCUxJQklDT05WCm9wdGlvbnMJCUxJQk1DSEFJTgpvcHRpb25zIAlORVRT TUIJICAgIAkjU01CL0NJRlMgcmVxdWVzdGVyCm9wdGlvbnMJCVNNQkZTCm9wdGlvbnMgCVpF Uk9fQ09QWV9TT0NLRVRTCm9wdGlvbnMgICAgICAgICBJUFNURUFMVEggICAgICAgICAgICAg ICAjc3VwcG9ydCBmb3Igc3RlYWx0aCBmb3J3YXJkaW5nCm9wdGlvbnMgCVNDSEVEXzRCU0QJ CSM0QlNEIHNjaGVkdWxlcgpvcHRpb25zIAlJTkVUCQkJI0ludGVyTkVUd29ya2luZwpvcHRp b25zIAlGRlMJCQkjQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRVUERB VEVTCQkjRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNM CQkJI1N1cHBvcnQgZm9yIGFjY2VzcyBjb250cm9sIGxpc3RzCm9wdGlvbnMgCVVGU19ESVJI QVNICQkjSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAg ICAgICAgIFVGU19FWFRBVFRSCm9wdGlvbnMgICAgICAgICBVRlNfRVhUQVRUUl9BVVRPU1RB UlQKb3B0aW9ucyAJQ09NUEFUXzQzCQkjQ29tcGF0aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAg VEhJUyFdCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjUG9zaXggUDEw MDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAgICAgICAgIFAxMDAzXzFCX1NF TUFQSE9SRVMKb3B0aW9ucyAgICAgICAgIFAxMDAzXzFCX01RVUVVRQoJCQkJCSMgb3V0cHV0 LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRv IGRyaXZlci4Kb3B0aW9ucyAgICAgICAgIFBFQ09GRl9TVVBQT1JUCm9wdGlvbnMgICAgICAg ICBQQU5JQ19SRUJPT1RfV0FJVF9USU1FPTI1Cm9wdGlvbnMJCUZBU1RfSVBTRUMKb3B0aW9u cwkJSVBTRUNfRklMVEVSR0lGICAgICAgICAgI2ZpbHRlciBpcHNlYyBwYWNrZXRzIGZyb20g YSB0dW5uZWwKZGV2aWNlCQljcnlwdG8Kb3B0aW9ucwkJVENQX1NJR05BVFVSRSAgICAgICAg ICAgI2luY2x1ZGUgc3VwcG9ydCBmb3IgUkZDIDIzODUKb3B0aW9ucyAJU01QCQkJIyBTeW1t ZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsCmRldmljZQkJYXBpYwkJCSMgSS9PIEFQSUMK b3B0aW9ucyAgICAgICAgIFBSRUVNUFRJT04Kb3B0aW9ucwkJSVBJX1BSRUVNUFRJT04KZGV2 aWNlCQlpc2EKZGV2aWNlCQlwY2kKZGV2aWNlCQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkJIyBB VEEgZGlzayBkcml2ZXMKZGV2aWNlCQlhdGFwaWNkCQkJIyBBVEFQSSBDRFJPTSBkcml2ZXMK b3B0aW9ucyAJQVRBX1NUQVRJQ19JRAkJIyBTdGF0aWMgZGV2aWNlIG51bWJlcmluZwpkZXZp Y2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NTSSkKZGV2aWNlCQljaAkJ IyBTQ1NJIG1lZGlhIGNoYW5nZXJzCmRldmljZQkJZGEJCSMgRGlyZWN0IEFjY2VzcyAoZGlz a3MpCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UJ CXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NTSSBhY2Nlc3MpCmRldmlj ZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkKZGV2 aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZpY2UJCWF0a2JkCQkj IEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKZGV2aWNlCQl2Z2EJCSMg VkdBIHZpZGVvIGNhcmQgZHJpdmVyCm9wdGlvbnMJCVZFU0EKZGV2aWNlCQlzcGxhc2gJCSMg U3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKZGV2aWNlCQlzYwpvcHRp b25zCQlTQ19QSVhFTF9NT0RFCm9wdGlvbnMJCVNDX0RJU0FCTEVfUkVCT09UCm9wdGlvbnMJ CVNDX0hJU1RPUllfU0laRT0xMDAwCm9wdGlvbnMgICAgICAgICBTQ19NT1VTRV9DSEFSPTB4 MDMKZGV2aWNlCQlucHgKZGV2aWNlCQlwbXRpbWVyCmRldmljZQkJcHBjCmRldmljZQkJcHBi dXMJCSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQpkZXZpY2UJCXJhbmRvbQkJIyBF bnRyb3B5IGRldmljZQpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpkZXZpY2Ug ICAgICAgICAgbWVtICAgICAgICAgICAgICMgTWVtb3J5IGFuZCBrZXJuZWwgbWVtb3J5IGRl dmljZXMKZGV2aWNlICAgICAgICAgIGlvICAgICAgICAgICAgICAjIEkvTyBkZXZpY2UKZGV2 aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0CmRldmljZSAgICAgICAgICBwcHAJCSNQ b2ludC10by1wb2ludCBwcm90b2NvbApvcHRpb25zICAgICAgICAgUFBQX0JTRENPTVAJI1BQ UCBCU0QtY29tcHJlc3Mgc3VwcG9ydApvcHRpb25zICAgICAgICAgUFBQX0RFRkxBVEUJI1BQ UCB6bGliL2RlZmxhdGUvZ3ppcCBzdXBwb3J0Cm9wdGlvbnMgICAgICAgICBQUFBfRklMVEVS CSNlbmFibGUgYnBmIGZpbHRlcmluZyAobmVlZHMgYnBmKQpkZXZpY2UgICAgICAgICAgcGYg ICAgICAgICAgICAgICAgICAgICAgI1BGIE9wZW5CU0QgcGFja2V0LWZpbHRlciBmaXJld2Fs bApkZXZpY2UgICAgICAgICAgcGZsb2cgICAgICAgICAgICAgICAgICAgI2xvZ2dpbmcgc3Vw cG9ydCBpbnRlcmZhY2UgZm9yIFBGCmRldmljZQkJcHR5CQkjIFBzZXVkby10dHlzICh0ZWxu ZXQgZXRjKQpkZXZpY2UJCW1kCQkjIE1lbW9yeSAiZGlza3MiCmRldmljZQkJYnBmCQkjIEJl cmtlbGV5IHBhY2tldCBmaWx0ZXIKZGV2aWNlICAgICAgICAgIGh3cG1jICAgICAgICAgICAg ICAgICAgICMgRHJpdmVyIChhbHNvIGEgbG9hZGFibGUgbW9kdWxlKQpvcHRpb25zICAgICAg ICAgSFdQTUNfSE9PS1MgICAgICAgICAgICAgIyBPdGhlciBuZWNlc3Nhcnkga2VybmVsIGhv b2tzCg== ------------12016F8626AAA3D9 Content-Type: TEXT/PLAIN; name="dmesg.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="dmesg.txt" SnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5OTItMjAw NiBUaGUgRnJlZUJTRCBQcm9qZWN0LgpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6 IENvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IFRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMg cmVzZXJ2ZWQuCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogRnJlZUJTRCA3LjAt Q1VSUkVOVCAjMTogVGh1IEp1biAyOSAwMzozNDo1MiBNU0QgMjAwNgpKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IHJvb3RAb3JtaG9tZS5vaC5jYzEucnU6L3Vzci9vYmovdXNy L2hvbWUvY3ZzLXNuYXAvZnJlZWJzZC9jdXJyZW50L3NyYy9zeXMvT1JNX01PRFVMRVMKSnVs ICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJu ZWw6IENQVTogSW50ZWwoUikgQ2VsZXJvbihUTSkgQ1BVICAgICAgICAgICAgICAgIDEyMDBN SHogKDEyNjguMTAtTUh6IDY4Ni1jbGFzcyBDUFUpCkp1bCAgNiAxODoxNzoyNiBvcm1ob21l IGtlcm5lbDogT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2YjEgIFN0ZXBwaW5n ID0gMQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IEZlYXR1cmVzPTB4MzgzZjlm ZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0Es Q01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NFPgpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBr ZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDUzNjgwNTM3NiAoNTExIE1CKQpKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IGF2YWlsIG1lbW9yeSA9IDUxMTgxOTc3NiAoNDg4IE1CKQpK dWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGxvY2ttZ3I6IHRocmVhZCAweGMwNzA2 M2Q4IHVubG9ja2luZyB1bmhlbGQgbG9jawpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJu ZWw6IG5ldHNtYl9kZXY6IGxvYWRlZApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6 IGFjcGkwOiA8SW50ZWxSIEFXUkRBQ1BJPiBvbiBtb3RoZXJib2FyZApKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IGFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpKdWwgIDYg MTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBr ZXJuZWw6IGFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0 IDB4NDAwOC0weDQwMGIgb24gYWNwaTAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVs OiBjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtl cm5lbDogYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCkp1 bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0 dG9uPiBvbiBhY3BpMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBjaWIwOiA8 QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYsMHg0MDAwLTB4NDBmNyBv biBhY3BpMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBjaTA6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogcGNpYjE6 IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCkp1bCAgNiAxODoxNzoy NiBvcm1ob21lIGtlcm5lbDogcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxCkp1bCAgNiAxODox NzoyNiBvcm1ob21lIGtlcm5lbDogbnZpZGlhMDogPEdlRm9yY2UgNjIwMD4gbWVtIDB4ZTQw MDAwMDAtMHhlNGZmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhlNTAwMDAwMC0weGU1 ZmZmZmZmIGlycSA1IGF0IGRldmljZSAwLjAgb24gcGNpMQpKdWwgIDYgMTg6MTc6MjYgb3Jt aG9tZSBrZXJuZWw6IG52aWRpYTA6IFtHSUFOVC1MT0NLRURdCkp1bCAgNiAxODoxNzoyNiBv cm1ob21lIGtlcm5lbDogcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MzAuMCBvbiBwY2kwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjIKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBw Y2kyOiA8bmV0d29yaywgZXRoZXJuZXQ+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBpc2FiMDogPFBDSS1JU0Eg YnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21l IGtlcm5lbDogaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCkp1bCAgNiAxODoxNzoyNiBvcm1o b21lIGtlcm5lbDogYXRhcGNpMDogPEludGVsIElDSDIgVURNQTEwMCBjb250cm9sbGVyPiBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZjAwMC0weGYwMGYg YXQgZGV2aWNlIDMxLjEgb24gcGNpMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6 IGF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCkp1bCAgNiAxODoxNzoyNiBvcm1o b21lIGtlcm5lbDogYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKSnVsICA2IDE4 OjE3OjI2IG9ybWhvbWUga2VybmVsOiB1aGNpMDogPEludGVsIDgyODAxQkEvQkFNIChJQ0gy KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweGQwMDAtMHhkMDFmIGlycSAxMSBhdCBk ZXZpY2UgMzEuMiBvbiBwY2kwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogdWhj aTA6IFtHSUFOVC1MT0NLRURdCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogdXNi MDogPEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24g dWhjaTAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiB1c2IwOiBVU0IgcmV2aXNp b24gMS4wCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogdWh1YjA6IDxJbnRlbCBV SENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi MApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHVodWIwOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJu ZWw6IHBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZl ciBhdHRhY2hlZCkKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiB1aGNpMTogPElu dGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweGQ0 MDAtMHhkNDFmIGlycSAxMSBhdCBkZXZpY2UgMzEuNCBvbiBwY2kwCkp1bCAgNiAxODoxNzoy NiBvcm1ob21lIGtlcm5lbDogdWhjaTE6IFtHSUFOVC1MT0NLRURdCkp1bCAgNiAxODoxNzoy NiBvcm1ob21lIGtlcm5lbDogdXNiMTogPEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0Ig Y29udHJvbGxlciBVU0ItQj4gb24gdWhjaTEKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2Vy bmVsOiB1c2IxOiBVU0IgcmV2aXNpb24gMS4wCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtl cm5lbDogdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNiMQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6 IHVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApKdWwgIDYg MTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQg ZGV2aWNlIDMxLjUgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsICA2IDE4OjE3OjI2IG9ybWhv bWUga2VybmVsOiBhY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKSnVsICA2IDE4 OjE3OjI2IG9ybWhvbWUga2VybmVsOiBhdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAo aTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMApKdWwgIDYgMTg6MTc6MjYg b3JtaG9tZSBrZXJuZWw6IGF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMw Ckp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogYXRrYmQwOiBbR0lBTlQtTE9DS0VE XQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBzbTA6IDxQUy8yIE1vdXNlPiBp cnEgMTIgb24gYXRrYmRjMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBzbTA6 IFtHSUFOVC1MT0NLRURdCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogcHNtMDog bW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxvcmVyLCBkZXZpY2UgSUQgNApKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IHBtdGltZXIwIG9uIGlzYTAKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAw LTB4Y2VmZmYsMHhkMDAwMC0weGQwN2ZmIHBucGlkIE9STTAwMDAgb24gaXNhMApKdWwgIDYg MTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFn cyAweDEwMCBvbiBpc2EwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpKdWwgIDYgMTg6MTc6MjYg b3JtaG9tZSBrZXJuZWw6IHZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAt MHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBwcGMwOiA8UGFyYWxsZWwgcG9ydD4gYXQgcG9ydCAweDM3OC0weDM3 ZiBpcnEgNyBvbiBpc2EwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogcHBjMDog U01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1v ZGUKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBwcGMwOiBGSUZPIHdpdGggMTYv MTYvMTYgYnl0ZXMgdGhyZXNob2xkCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDog cHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBwcGJ1czA6IElFRUUxMjg0IGRldmljZSBmb3VuZCAvTklCQkxFCkp1 bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogUHJvYmluZyBmb3IgUG5QIGRldmljZXMg b24gcHBidXMwOgpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHBwYnVzMDogPENh bm9uIEJKQy0zMDAwLzEuMTE+IFBSSU5URVIgQkpMLEJKUmFzdGVyMyxCU0NDLFRYVDAxLEJK U2NhbjIKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBwcGMwOiBbR0lBTlQtTE9D S0VEXQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IFRpbWVjb3VudGVyICJUU0Mi IGZyZXF1ZW5jeSAxMjY4MTAzNTU0IEh6IHF1YWxpdHkgODAwCkp1bCAgNiAxODoxNzoyNiBv cm1ob21lIGtlcm5lbDogVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpKdWwg IDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IEZhc3QgSVBzZWM6IEluaXRpYWxpemVkIFNl Y3VyaXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCkp1bCAgNiAxODoxNzoyNiBvcm1ob21l IGtlcm5lbDogaXBmdzIgaW5pdGlhbGl6ZWQsIGRpdmVydCBsb2FkYWJsZSwgcnVsZS1iYXNl ZCBmb3J3YXJkaW5nIGVuYWJsZWQsIGRlZmF1bHQgdG8gYWNjZXB0LCBsb2dnaW5nIGxpbWl0 ZWQgdG8gMjAwMCBwYWNrZXRzL2VudHJ5IGJ5IGRlZmF1bHQKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBhZDA6IDc2MzE5TUIgPFNlYWdhdGUgU1QzODAwMTFBIDguMDE+IGF0 IGF0YTAtbWFzdGVyIFVETUExMDAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBh ZDE6IDc2MzE5TUIgPFNlYWdhdGUgU1QzODAwMTFBIDMuMDY+IGF0IGF0YTAtc2xhdmUgVURN QTEwMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGFjZDA6IENEUlcgPFRFQUMg RFctNTUyRy9ONEsxPiBhdCBhdGExLW1hc3RlciBVRE1BMzMKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBod3BtYzogVFNDLzEvMHgyMDxSRUE+IFA2LzIvMHgxZmU8VVNSLFNZ UyxFREcsVEhSLFJFQSxXUkksSU5WLFFVQT4KSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2Vy bmVsOiBXQVJOSU5HOiBFeHBlY3RlZCByYXdvZmZzZXQgMTI1Njc2NDk1LCBmb3VuZCA0NzUz NjMzNQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IFRyeWluZyB0byBtb3VudCBy b290IGZyb20gdWZzOi9kZXYvYWQxczFhCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5l bDogZmRjMDogPEVuaGFuY2VkIGZsb3BweSBjb250cm9sbGVyPiBhdCBwb3J0IDB4M2YwLTB4 M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUg a2VybmVsOiBmZGMwOiBbRkFTVF0KSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBm ZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IGZkYzE6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4gcG9y dCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApKdWwgIDYgMTg6MTc6 MjYgb3JtaG9tZSBrZXJuZWw6IGZkYzE6IE5vIEZET1VUIHJlZ2lzdGVyIQpKdWwgIDYgMTg6 MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGRldmljZV9hdHRhY2g6IGZkYzEgYXR0YWNoIHJldHVy bmVkIDYKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBrcWVtdSB2ZXJzaW9uIDB4 MDAwMTAzMDAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBrcWVtdTogS1FFTVUg aW5zdGFsbGVkLCBtYXhfbG9ja2VkX21lbT0yNTU2OTJrQi4KSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBmZGMxOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgz ZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBmZGMxOiBObyBGRE9VVCByZWdpc3RlciEKSnVsICA2IDE4OjE3OjI2 IG9ybWhvbWUga2VybmVsOiBkZXZpY2VfYXR0YWNoOiBmZGMxIGF0dGFjaCByZXR1cm5lZCA2 Ckp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogc2lvNDogPDE2NTUwQS1jb21wYXRp YmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IG9uIGFjcGkwCkp1bCAgNiAx ODoxNzoyNiBvcm1ob21lIGtlcm5lbDogc2lvNDogdHlwZSAxNjU1MEEKSnVsICA2IDE4OjE3 OjI2IG9ybWhvbWUga2VybmVsOiBzaW80OiBbRkFTVF0KSnVsICA2IDE4OjE3OjI2IG9ybWhv bWUga2VybmVsOiBzaW81OiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgy ZjgtMHgyZmYgaXJxIDMgb24gYWNwaTAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVs OiBzaW81OiB0eXBlIDE2NTUwQQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHNp bzU6IFtGQVNUXQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGxwdDA6IDxQcmlu dGVyPiBvbiBwcGJ1czAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBscHQwOiBJ bnRlcnJ1cHQtZHJpdmVuIHBvcnQKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiBp Y2hzbWIwOiA8SW50ZWwgODI4MDFCQSAoSUNIMikgU01CdXMgY29udHJvbGxlcj4gcG9ydCAw eDUwMDAtMHg1MDBmIGF0IGRldmljZSAzMS4zIG9uIHBjaTAKSnVsICA2IDE4OjE3OjI2IG9y bWhvbWUga2VybmVsOiBpY2hzbWIwOiBbR0lBTlQtTE9DS0VEXQpKdWwgIDYgMTg6MTc6MjYg b3JtaG9tZSBrZXJuZWw6IHNtYnVzMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaWNo c21iMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHNtYjA6IDxTTUJ1cyBnZW5l cmljIEkvTz4gb24gc21idXMwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogaWNo d2QgbW9kdWxlIGxvYWRlZApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGljaHdk MDogPEludGVsIDgyODAxQkEgd2F0Y2hkb2cgdGltZXI+IG9uIGlzYTAKSnVsICA2IDE4OjE3 OjI2IG9ybWhvbWUga2VybmVsOiB1Y29tMDogPHZlbmRvciAweDA2N2IgcHJvZHVjdCAweDIz MDMsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMi4wMiwgYWRkciAyPiBvbiB1aHViMApKdWwgIDYg MTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHVjb20wOiB2ZW5kb3IgMHgwNjdiIHByb2R1Y3Qg MHgyMzAzLCByZXYgMS4xMC8yLjAyLCBhZGRyIDIKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUg a2VybmVsOiB4bDA6IDwzQ29tIDNjOTA1Qy1UWCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAw eGMwMDAtMHhjMDdmIG1lbSAweGU4MDAwMDAwLTB4ZTgwMDAwN2YgaXJxIDExIGF0IGRldmlj ZSAzLjAgb24gcGNpMgpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IG1paWJ1czA6 IDxNSUkgYnVzPiBvbiB4bDAKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2VybmVsOiB4bHBo eTA6IDwzYzkwNUMgMTAvMTAwIGludGVybmFsIFBIWT4gb24gbWlpYnVzMApKdWwgIDYgMTg6 MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHhscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAx MDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUg a2VybmVsOiB4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA0Ojc5OjY2Ojk0OjVhCkp1bCAg NiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogc2VxdWVuY2VyIDAgY3JlYXRlZCBzY3AgMHhj MjJjYWEwMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IHNlcV9ldmVudHRocmVh ZCBzdGFydGVkCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogcGNtMDogPEludGVs IElDSDIgKDgyODAxQkEpPiBwb3J0IDB4ZDgwMC0weGQ4ZmYsMHhkYzAwLTB4ZGMzZiBpcnEg OSBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5l bDogcGNtMDogPEF2YW5jZSBMb2dpYyBBTEMyMDAgQUM5NyBDb2RlYz4KSnVsICA2IDE4OjE3 OjI2IG9ybWhvbWUga2VybmVsOiBzcGVha2VyMDogPFBDIHNwZWFrZXI+IHBvcnQgMHg2MSBv biBhY3BpMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGZkYzE6IDxmbG9wcHkg ZHJpdmUgY29udHJvbGxlcj4gcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBv biBhY3BpMApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGZkYzE6IE5vIEZET1VU IHJlZ2lzdGVyIQpKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBrZXJuZWw6IGRldmljZV9hdHRh Y2g6IGZkYzEgYXR0YWNoIHJldHVybmVkIDYKSnVsICA2IDE4OjE3OjI2IG9ybWhvbWUga2Vy bmVsOiBXQVJOSU5HOiAvbW50L29sZC91c3Igd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVk Ckp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogV0FSTklORzogL21udC9vbGQvdmFy IHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZApKdWwgIDYgMTg6MTc6MjYgb3JtaG9tZSBr ZXJuZWw6IFdBUk5JTkc6IC9tbnQvb2xkL3Zhci9sb2cgd2FzIG5vdCBwcm9wZXJseSBkaXNt b3VudGVkCkp1bCAgNiAxODoxNzoyNiBvcm1ob21lIGtlcm5lbDogY3B1MDogdG9vIG1hbnkg c2hvcnQgc2xlZXBzLCBiYWNraW5nIG9mZiB0byBDMgo= ------------12016F8626AAA3D9 Content-Type: TEXT/PLAIN; name="kldstat.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="kldstat.txt" SWQgUmVmcyBBZGRyZXNzICAgIFNpemUgICAgIE5hbWUKIDEgICA2OCAweGMwNDAwMDAwIDNl YzM3YyAgIGtlcm5lbAogMiAgICA1IDB4YzA3ZWQwMDAgMjI0MzAgICAgbGludXgua28KIDMg ICAgMiAweGMwODEwMDAwIDQ4MDAgICAgIHN5c3Ztc2cua28KIDQgICAgMiAweGMwODE1MDAw IDYxYzQgICAgIHN5c3ZzZW0ua28KIDUgICAgMiAweGMwODFjMDAwIDU0NTQgICAgIHN5c3Zz aG0ua28KIDYgICAgNyAweGMwODIyMDAwIDI0NGFjICAgIHVzYi5rbwogNyAgICAxIDB4YzA4 NDcwMDAgNDAwYyAgICAgdW1zLmtvCiA4ICAgIDEgMHhjMDg0YzAwMCA0YTU5ZDQgICBudmlk aWEua28KIDkgICAgMSAweGMwY2YyMDAwIDYyYTIwICAgIGFjcGkua28KMTAgICAgMSAweGMy NDRlMDAwIDUwMDAgICAgIGtiZG11eC5rbwoxMSAgICAxIDB4YzI0NzMwMDAgOTAwMCAgICAg ZmRjLmtvCjEyICAgIDEgMHhjMjQ4NTAwMCA5MDAwICAgICBjcHVmcmVxLmtvCjEzICAgIDEg MHhjMjQ5MTAwMCBhMDAwICAgICBsaWJhbGlhcy5rbwoxNCAgICAxIDB4YzI0OWIwMDAgNDAw MCAgICAgaXBkaXZlcnQua28KMTUgICAgMSAweGMyNDlmMDAwIDcwMDAgICAgIGR1bW15bmV0 LmtvCjE2ICAgIDIgMHhjMjRhNjAwMCBiMDAwICAgICBuZXRncmFwaC5rbwoxNyAgICAxIDB4 YzI0YjcwMDAgNDAwMCAgICAgbmdfZXRoZXIua28KMTggICAgMSAweGMyNGJiMDAwIDUwMDAg ICAgIGlmX3RhcC5rbwoxOSAgICAxIDB4YzI0YzAwMDAgMzUwMDAgICAgbmZzY2xpZW50Lmtv CjIwICAgIDEgMHhjMjRmZDAwMCAyMjAwMCAgICBuZnNzZXJ2ZXIua28KMjEgICAgMSAweGMy NTI0MDAwIDFjMDAwICAgIGtxZW11LmtvCjIyICAgIDEgMHhjMjU1MDAwMCA4MDAwICAgICBz aW8ua28KMjMgICAgMSAweGMyNTY1MDAwIDQwMDAgICAgIGxwdC5rbwoyNCAgICA0IDB4YzI1 NjkwMDAgMzAwMCAgICAgc21idXMua28KMjUgICAgMSAweGMyNTZjMDAwIDMwMDAgICAgIHNt Yi5rbwoyNiAgICAzIDB4YzI1NmYwMDAgMzAwMCAgICAgaWljYnVzLmtvCjI3ICAgIDEgMHhj MjU3MjAwMCAzMDAwICAgICBpaWNzbWIua28KMjggICAgMSAweGMyNTc2MDAwIDQwMDAgICAg IGlpY2JiLmtvCjI5ICAgIDEgMHhjMjU4MjAwMCA0MDAwICAgICBpY2hzbWIua28KMzAgICAg MSAweGMyNThkMDAwIDMwMDAgICAgIGljaHdkLmtvCjMxICAgIDEgMHhjMjU5MTAwMCA0MDAw ICAgICB1aGlkLmtvCjMyICAgIDEgMHhjMjU5NTAwMCA3MDAwICAgICB1a2JkLmtvCjMzICAg IDEgMHhjMjU5YzAwMCA3MDAwICAgICB1bWFzcy5rbwozNCAgICAyIDB4YzI1YTQwMDAgMzAw MCAgICAgdWNvbS5rbwozNSAgICAxIDB4YzI1YTgwMDAgNDAwMCAgICAgdXBsY29tLmtvCjM2 ICAgIDEgMHhjMjViNDAwMCA5MDAwICAgICBpZl9icmlkZ2Uua28KMzcgICAgMSAweGMyNWJl MDAwIGEwMDAgICAgIGlmX3hsLmtvCjM4ICAgIDIgMHhjMjVjODAwMCAxODAwMCAgICBtaWli dXMua28KMzkgICAgMSAweGMyNWYzMDAwIDUwMDAgICAgIGlmX3R1bi5rbwo0MCAgICAxIDB4 YzI1ZjgwMDAgNTAwMCAgICAgaWZfdmxhbi5rbwo0MSAgICAxIDB4YzI2MGUwMDAgNDAwMCAg ICAgaWZfZ2lmLmtvCjQyICAgIDIgMHhjMjYxMjAwMCAxMzAwMCAgICBmaXJld2lyZS5rbwo0 MyAgICAxIDB4YzI2MmIwMDAgNDAwMCAgICAgaWZfZndlLmtvCjQ0ICAgIDIgMHhjMjYyZjAw MCAyZDAwMCAgICBzb3VuZC5rbwo0NSAgICAxIDB4YzI2NmMwMDAgNjAwMCAgICAgc25kX2lj aC5rbwo0NiAgICAxIDB4YzI2ODQwMDAgMzAwMCAgICAgc3BlYWtlci5rbwo0NyAgICAxIDB4 YzI2YjUwMDAgMjAwMCAgICAgbXNkb3Nmc19pY29udi5rbwo0OCAgICAxIDB4YzI3MDIwMDAg ZTAwMCAgICAgbXNkb3Nmcy5rbwo0OSAgICAxIDB4YzI3OWUwMDAgMjAwMCAgICAgbnRmc19p Y29udi5rbwo1MCAgICAxIDB4YzI3YTAwMDAgYjAwMCAgICAgbnRmcy5rbwo1MSAgICAxIDB4 YzI3ZjIwMDAgNzAwMCAgICAgbGlucHJvY2ZzLmtvCjUyICAgIDEgMHhjMjdmOTAwMCA2MDAw ICAgICBwcm9jZnMua28KNTMgICAgMyAweGMyN2ZmMDAwIDYwMDAgICAgIHBzZXVkb2ZzLmtv CjU0ICAgIDEgMHhjMjgwODAwMCAzMDAwICAgICBsaW5zeXNmcy5rbwo1NSAgICAxIDB4YzJk NzIwMDAgOTAwMCAgICAgY2Q5NjYwLmtvCjU2ICAgIDEgMHhjMmQ5YzAwMCAyMDAwICAgICBy dGMua28K ------------12016F8626AAA3D9-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 18:58:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E92F16A556 for ; Sun, 23 Jul 2006 18:58:05 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 8768243D49 for ; Sun, 23 Jul 2006 18:58:01 +0000 (GMT) (envelope-from sthaug@nethelp.no) Received: (qmail 49137 invoked from network); 23 Jul 2006 18:57:59 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Jul 2006 18:57:59 -0000 Date: Sun, 23 Jul 2006 20:57:59 +0200 (CEST) Message-Id: <20060723.205759.74723866.sthaug@nethelp.no> To: lists@wm-access.no From: sthaug@nethelp.no In-Reply-To: <44C3B674.3040804@wm-access.no> References: <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060720.093457.1661914908.imp@bsdimp.com> <44C3B674.3040804@wm-access.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, imp@bsdimp.com Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 18:58:05 -0000 > > One approach that we could use for 64-bit counters would be to just > > use 32-bits one, and poll them for overflow and bump an overflow > > count. This assumes that the 32-bit counters overflow much less often > > than the polling interval, and easily triples the amount of storage > > for each of them... It is ugly :-( > > > > What's wrong with the add+adc (asm) approach found on any i386? Presumably the fact that add + adc isn't an atomic operation. So if you want to guarantee 64 bit consistency, you need locking or similar. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 21:35:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A39416A4DF for ; Sun, 23 Jul 2006 21:35:40 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B611143D49 for ; Sun, 23 Jul 2006 21:35:39 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id AE502D91B7D for ; Sun, 23 Jul 2006 17:35:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Sun, 23 Jul 2006 17:35:40 -0400 X-Sasl-enc: s2qfrEWs6TshHomshlKc6saxntxcSIJ98UIR9NcCj/Dk 1153690530 Received: from [10.50.31.168] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id 23E566E0D for ; Sun, 23 Jul 2006 17:35:29 -0400 (EDT) Message-ID: <44C3EBA5.7030007@fastmail.fm> Date: Sun, 23 Jul 2006 16:35:33 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <44BADEC8.5030807@fastmail.fm> In-Reply-To: <44BADEC8.5030807@fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Firefox on -current dumps core. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 21:35:40 -0000 Patrick Bowen wrote: > Hello. > > I recently upgraded a Gateway MX6121 from 6.1 stable to -current, > following the canonical procedure in /usr/src/UPDATING, and now > whenever I try to start firefox, it dumps a core file (segmentation > fault). Firefox was compiled from source under 6.1. > > Should I have upgraded from 6.1 to -current, and /then/ start adding > ports, or does that matter? I've done some preliminary googling, but > not found anything that looks terribly recent or promising. > > Any hints appreciated. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > Just to close this out... These are the steps I followed to move to current, and eliminate the seg-faults from firefox. 1. Installed 6.1 on a clean partition (I wanted to elimiate any extraneous cruft). 2. Sysinstall'ed portupgrade, csup, firefox, and windowmaker. 3. Did portupgrade -FRv on the ports I added in step 2 (this way I'd have the files I needed, without having to have a wireless connection after step 4). 4. Canonical upgrade to current. 5. Did make && make install for /usr/ports/sysutils/portupgrade and /usr/ports/lang/perl5.8 (otherwise portupgrade seg-faulted). 6. Did portupgrade -aR to bring everything up to date. Works fine, lasts a long time. If I paint it green, I think it might grow! Thanks to everyone for their help. Patrick Addendum: from now on I'm sticking to distfiles instead of packages. From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 22:57:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAAD216A4DF for ; Sun, 23 Jul 2006 22:57:39 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CCF843D45 for ; Sun, 23 Jul 2006 22:57:38 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 34894D91BF5 for ; Sun, 23 Jul 2006 18:57:37 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sun, 23 Jul 2006 18:57:39 -0400 X-Sasl-enc: zVWShK3o15QUum9ABlJZl51UYMC76ou2IWv8Z9IP/uDY 1153695458 Received: from [10.50.31.168] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id 72C4E372A for ; Sun, 23 Jul 2006 18:57:38 -0400 (EDT) Message-ID: <44C3FEDA.5060501@fastmail.fm> Date: Sun, 23 Jul 2006 17:57:30 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: D-Link ath card not recognized X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 22:57:39 -0000 Just upgraded from 6.1 RELEASE to -current, and a previously working D-Link DWL-G630 AirPlus G wireless notebook adapter no longer works. H/W ver.: C2 F/W ver.: 3.01 This from dmesg; cbb alloc res fail cbb alloc res fail cardbus0: at device 0.0 (no driver attached) and this from dumpcis on Linux; Socket 0: manfid 0x0271, 0x0012 config_cb base 0x0000 last_index 0x01 cftable_entry_cb 0x01 [default] [master] [parity] [serr] [fast back] Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA irq mask 0xffff [level] mem_base 1 BAR 1 size 64kb [mem] vers_1 7.1, "Atheros Communications, Inc.", "AR5001-0000-0000", "Wireless LAN Reference Card", "00" funcid network_adapter [post] lan_speed 6 mb/sec lan_speed 9 mb/sec lan_speed 12 mb/sec lan_speed 18 mb/sec lan_speed 24 mb/sec lan_speed 36 mb/sec lan_speed 48 mb/sec lan_speed 54 mb/sec lan_speed 72 mb/sec lan_media 5.4_GHz lan_node_id 00 03 2f 55 55 55 lan_connector Closed connector standard Ialso snagged this from Linux's dmesg; [17179589.744000] pccard: CardBus card inserted into slot 0 [17179589.776000] ath_hal: module license 'Proprietary' taints kernel. [17179589.776000] ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2 413) [17179589.796000] cs: IO port probe 0x100-0x3af: clean. [17179589.800000] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 [17179589.800000] cs: IO port probe 0x820-0x8ff: clean. [17179589.800000] cs: IO port probe 0xc00-0xcf7: clean. [17179589.800000] cs: IO port probe 0xa00-0xaff: clean. [17179589.824000] wlan: 0.8.6.0 (EXPERIMENTAL) [17179589.824000] ath_rate_sample: 1.2 [17179589.832000] ath_pci: 0.9.6.0 (EXPERIMENTAL) [17179589.832000] PCI: Enabling device 0000:07:00.0 (0000 -> 0002) [17179589.832000] ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 16 (level, low) -> IRQ 177 [17179590.416000] Build date: Jul 10 2006 [17179590.416000] Debugging version (IEEE80211) [17179590.416000] ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps [17179590.416000] ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps [17179590.416000] ath0: H/W encryption support: WEP AES AES_CCM TKIP [17179590.416000] ath0: mac 7.8 phy 4.5 radio 5.6 [17179590.416000] ath0: Use hw queue 1 for WME_AC_BE traffic [17179590.416000] ath0: Use hw queue 0 for WME_AC_BK traffic [17179590.416000] ath0: Use hw queue 2 for WME_AC_VI traffic [17179590.416000] ath0: Use hw queue 3 for WME_AC_VO traffic [17179590.416000] ath0: Use hw queue 8 for CAB traffic [17179590.416000] ath0: Use hw queue 9 for beacons [17179590.416000] Debugging version (ATH) [17179590.416000] ath0: Atheros 5212: mem=0x24000000, irq=177 If I can provide any more info, please let me know. Thanks, Patrick From owner-freebsd-current@FreeBSD.ORG Sun Jul 23 23:05:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C49A16A4DD for ; Sun, 23 Jul 2006 23:05:37 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B09543D53 for ; Sun, 23 Jul 2006 23:05:36 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id C154BD91A63 for ; Sun, 23 Jul 2006 19:05:34 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Sun, 23 Jul 2006 19:05:37 -0400 X-Sasl-enc: VWppt7FsC40SoaQ7mrkRYUaKInxl47iwDIc+Y+Rp175D 1153695924 Received: from [10.50.31.168] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id 397F2714B for ; Sun, 23 Jul 2006 19:05:23 -0400 (EDT) Message-ID: <44C400BC.80502@fastmail.fm> Date: Sun, 23 Jul 2006 18:05:32 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <44C39D7E.30102@mail.web.am> In-Reply-To: <44C39D7E.30102@mail.web.am> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2006 23:05:37 -0000 Gaspar Chilingarov wrote: > Hi all! > > After upgrading from -CURRENT mid-Mart to Jul 22 current I got a > failures for Linux applications which try to use X. > > About my system: amd64, I'm trying to run openoffice and skype, but they > fail with "Segmentation fault". ktrace also produces dump, which makes > kdump fail also with segfault. > > Is this known issue or I've messed somethng on my system while upgrading? > > Thanks in advice, > Gaspar > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Gaspar; I had similar problems with firefox after upgrading to -current. It seems that some libraries are at fault. You'll need to remake your ports so that they use the new libraries. Patrick From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 00:04:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12BBA16A4DD for ; Mon, 24 Jul 2006 00:04:22 +0000 (UTC) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C7443D4C for ; Mon, 24 Jul 2006 00:04:21 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.6/8.13.6) with ESMTP id k6O04KPP030033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jul 2006 02:04:20 +0200 Message-ID: <44C40E66.8080805@wm-access.no> Date: Mon, 24 Jul 2006 02:03:50 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sthaug@nethelp.no References: <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060720.093457.1661914908.imp@bsdimp.com> <44C3B674.3040804@wm-access.no> <20060723.205759.74723866.sthaug@nethelp.no> In-Reply-To: <20060723.205759.74723866.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 00:04:22 -0000 sthaug@nethelp.no wrote: >>> One approach that we could use for 64-bit counters would be to just >>> use 32-bits one, and poll them for overflow and bump an overflow >>> count. This assumes that the 32-bit counters overflow much less ofte= n >>> than the polling interval, and easily triples the amount of storage >>> for each of them... It is ugly :-( >>> >> What's wrong with the add+adc (asm) approach found on any i386? >=20 > Presumably the fact that add + adc isn't an atomic operation. So if > you want to guarantee 64 bit consistency, you need locking or similar. >=20 Would it not be necessary to do this locking anyway? I don't see how polling for overflow would help this consistency. Are both suggestions insufficient? --=20 Sten Daniel S=F8rsdal From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 05:31:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53FC816A4DD for ; Mon, 24 Jul 2006 05:31:10 +0000 (UTC) (envelope-from tyler@bleepsoft.com) Received: from zeus.lunarpages.com (zeus.lunarpages.com [216.193.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D315B43D5F for ; Mon, 24 Jul 2006 05:31:09 +0000 (GMT) (envelope-from tyler@bleepsoft.com) Received: from 24-240-211-104.dhcp.sprn.tx.charter.com ([24.240.211.104] helo=[192.168.250.100]) by zeus.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.52) id 1G4t37-0005c2-7f for freebsd-current@freebsd.org; Sun, 23 Jul 2006 22:32:13 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: "R. Tyler Ballance" Date: Mon, 24 Jul 2006 00:31:05 -0500 X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zeus.lunarpages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - bleepsoft.com X-Source: X-Source-Args: X-Source-Dir: Subject: Failing `make buildworld` with today's source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 05:31:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recently integrated today's (ok, sunday's) source code into my branch in perforce, and I'm getting these build errors: Anybody seen anything similar? ./gengenrtl > genrtl.c ./gengenrtl -h > genrtl.h cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H - DPREFIX=\"/usr\" -DCROSS_COMPILE -I/usr/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../ cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/ gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/home/tyler/ perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../../../../ contrib/gcc/config -DGENERATOR_FILE -I/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/tmp/legacy/usr/include -c / usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/genattr.c In file included from /usr/home/tyler/perforce/projects/l4bsd/src/gnu/ usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:27: ./tm.h:4:15: /.h: No such file or directory ./tm.h:10:22: /freebsd.h: No such file or directory In file included from /usr/home/tyler/perforce/projects/l4bsd/src/gnu/ usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:28: /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2209: warning: parameter has incomplete type *** Error code 1 Stop in /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools. *** Error code 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFExFsbqO6nEJfroRsRApY8AJ9vbI88wohJdzjb/W29kxFYwW6e6gCfa94r C+A4qVhDRd2r7rI10nDGsoc= =4Maf -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 08:06:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4282A16A4DF for ; Mon, 24 Jul 2006 08:06:30 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5456343D7B for ; Mon, 24 Jul 2006 08:06:25 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6O86Kn0039995 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Jul 2006 10:06:20 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6O86KUU039994; Mon, 24 Jul 2006 10:06:20 +0200 (CEST) Date: Mon, 24 Jul 2006 10:06:20 +0200 From: Divacky Roman To: Gaspar Chilingarov Message-ID: <20060724080620.GA39934@stud.fit.vutbr.cz> References: <44C39D7E.30102@mail.web.am> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C39D7E.30102@mail.web.am> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 08:06:30 -0000 On Sun, Jul 23, 2006 at 09:02:06PM +0500, Gaspar Chilingarov wrote: > Hi all! > > After upgrading from -CURRENT mid-Mart to Jul 22 current I got a > failures for Linux applications which try to use X. > > About my system: amd64, I'm trying to run openoffice and skype, but they > fail with "Segmentation fault". ktrace also produces dump, which makes > kdump fail also with segfault. > > Is this known issue or I've messed somethng on my system while upgrading? yes... linuxolator@amd64 is currently broken. afaik the commit to linux_ipc removing stackgap usage broke it. I hope someone (jhb?) is working on it roman From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 08:57:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DDF916A4DF; Mon, 24 Jul 2006 08:57:31 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1629B43D55; Mon, 24 Jul 2006 08:57:29 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5FF9C.dip.t-dialin.net [84.165.255.156]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k6O8jf8s094990; Mon, 24 Jul 2006 10:45:42 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k6O8vUnP068964; Mon, 24 Jul 2006 10:57:30 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 24 Jul 2006 10:57:29 +0200 Message-ID: <20060724105729.kueau56u8ks8c8gw@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 24 Jul 2006 10:57:29 +0200 From: Alexander Leidinger To: Divacky Roman References: <44C39D7E.30102@mail.web.am> <20060724080620.GA39934@stud.fit.vutbr.cz> In-Reply-To: <20060724080620.GA39934@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 08:57:31 -0000 Quoting Divacky Roman (from Mon, 24 Jul =20 2006 10:06:20 +0200): > On Sun, Jul 23, 2006 at 09:02:06PM +0500, Gaspar Chilingarov wrote: >> Hi all! >> >> After upgrading from -CURRENT mid-Mart to Jul 22 current I got a >> failures for Linux applications which try to use X. >> >> About my system: amd64, I'm trying to run openoffice and skype, but they >> fail with "Segmentation fault". ktrace also produces dump, which makes >> kdump fail also with segfault. >> >> Is this known issue or I've messed somethng on my system while upgrading? > > yes... linuxolator@amd64 is currently broken. afaik the commit to linux_ip= c > removing stackgap usage broke it. I hope someone (jhb?) is working on it We like to work on it. But so far I haven't seen someone provide the =20 necessary debugging (maybe jhb got something and I didn't got a CC). =20 We need a ktrace of it. Most of the time a wrapper script is called when running a linux =20 program. This is at least true for skype and acroread. So there are =20 two possibilities: - run "ktrace -i" and hope the mixed information (FreeBSD sh and =20 linux binary) can be decoded - modify the wrapper script to run ktrace on the real linux binary To process the ktrace.out file, you need to use the linux_kdump =20 program. I made a package (32bit) available at =20 http://www.leidinger/net/FreeBSD/ Most interesting is the information which syscall is called before the =20 coredump, but the entire log would be ok too (please don't send it to =20 the list if it is large). So if anyone is able to provide this =20 information: we prefer to get it even from several people instead of =20 not at all. Bye, Alexander. --=20 Let the meek inherit the earth -- they have it coming to them. =09=09-- James Thurber http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 09:13:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FFCD16A4DD for ; Mon, 24 Jul 2006 09:13:42 +0000 (UTC) (envelope-from amogilny@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 664E143D46 for ; Mon, 24 Jul 2006 09:13:41 +0000 (GMT) (envelope-from amogilny@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so2255826uge for ; Mon, 24 Jul 2006 02:13:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=aNg+liftPZqj+pyhkSkUi932bhfJDOMfhhhWUvE01PjSbZjY2jfLuWqCJnvjhVddWuk8qdDecY+sujQ8DvBqlW5z8s9DoUCvwoS/Bi6CELfbevSZHjTCrRrlBrCyCMwPori85VJbz+EYM8Tcy6wTL2kXqWLg+Zz6wvPxqzGcpE4= Received: by 10.78.177.11 with SMTP id z11mr1396028hue; Mon, 24 Jul 2006 02:13:39 -0700 (PDT) Received: by 10.78.178.3 with HTTP; Mon, 24 Jul 2006 02:13:39 -0700 (PDT) Message-ID: <7403d2a30607240213v522b7f21t2e2e0e90dbe6a7c4@mail.gmail.com> Date: Mon, 24 Jul 2006 12:13:39 +0300 From: "Alexander Mogilny" Sender: amogilny@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: b0f56b4bde3629c2 Subject: [patch] Broadcom BCM5751F Gigabit Ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 09:13:42 -0000 I have recently installed FreeBSD 6.0 to IBM machine with subject integrated NIC. It did not work. The first decision I made is upgrading to RELENG_6_1. That also did not help. According to 'pciconf -lv' information I found that chipid of BCM5751F NIC was not present in bge driver so I added it and recompiled the kernel. NIC started working. Here is the patch with chipid: --- if_bge.c.orig Mon Jul 24 12:11:27 2006 +++ if_bge.c Mon Jul 24 12:13:02 2006 @@ -172,6 +172,8 @@ "Broadcom BCM5751 Gigabit Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5751M, "Broadcom BCM5751M Gigabit Ethernet" }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5751F, + "Broadcom BCM5751F Gigabit Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5752, "Broadcom BCM5752 Gigabit Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5782, --- if_bgereg.h.orig Mon Jul 24 12:11:32 2006 +++ if_bgereg.h Mon Jul 24 12:12:17 2006 @@ -1955,6 +1955,7 @@ #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 #define BCOM_DEVICEID_BCM5751M 0x167D +#define BCOM_DEVICEID_BCM5751F 0x167E #define BCOM_DEVICEID_BCM5752 0x1600 #define BCOM_DEVICEID_BCM5782 0x1696 #define BCOM_DEVICEID_BCM5788 0x169C -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 10:38:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB2F16A4E0; Mon, 24 Jul 2006 10:38:44 +0000 (UTC) (envelope-from tyler@bleepsoft.com) Received: from zeus.lunarpages.com (zeus.lunarpages.com [216.193.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25ECF43D49; Mon, 24 Jul 2006 10:38:44 +0000 (GMT) (envelope-from tyler@bleepsoft.com) Received: from 24-240-211-104.dhcp.sprn.tx.charter.com ([24.240.211.104] helo=[192.168.250.100]) by zeus.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.52) id 1G4xql-0000pT-TQ; Mon, 24 Jul 2006 03:39:48 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "R. Tyler Ballance" Date: Mon, 24 Jul 2006 05:38:39 -0500 To: freebsd-current@freebsd.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zeus.lunarpages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - bleepsoft.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Hackers Subject: Re: Failing `make buildworld` with today's source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 10:38:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 freebsd-current: I figured out why this was failing on my machine, I did a clean `make buildworld` which succeeded without a hitch freebsd-hackers: After taking Warner's advice, I am building world with a different target arch, but I cannot track down exactly where this error is occurring, I'm including a new version of the error transcript in case it's helpful at all. Any porters seen this before, kmacy? arm guys? anybody? :P Cheers, - -R. Tyler Ballance =================== cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H - DPREFIX=\"/usr\" -DCROSS_COMPILE -I/usr/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../ cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/ gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/home/tyler/ perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../../../../ contrib/gcc/config -DGENERATOR_FILE -I/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/tmp/legacy/usr/include -c / usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/gengenrtl.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H - DPREFIX=\"/usr\" -DCROSS_COMPILE -I/usr/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../ cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/ gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/home/tyler/ perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../../../../ contrib/gcc/config -DGENERATOR_FILE -I/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/tmp/legacy/usr/include -L/ home/tyler/builds/obj/iguana/usr/home/tyler/perforce/projects/l4bsd/ src/tmp/legacy/usr/lib -o gengenrtl gengenrtl.o errors.o libiberty.a ./gengenrtl > genrtl.c ./gengenrtl -h > genrtl.h cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H - DPREFIX=\"/usr\" -DCROSS_COMPILE -I/usr/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../ cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/ gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/home/tyler/ perforce/projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../../../../ contrib/gcc/config -DGENERATOR_FILE -I/home/tyler/builds/obj/iguana/ usr/home/tyler/perforce/projects/l4bsd/src/tmp/legacy/usr/include -c / usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/genattr.c In file included from /usr/home/tyler/perforce/projects/l4bsd/src/gnu/ usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:27: ./tm.h:4:15: /.h: No such file or directory ./tm.h:10:22: /freebsd.h: No such file or directory In file included from /usr/home/tyler/perforce/projects/l4bsd/src/gnu/ usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:28: /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has incomplete type /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/rtl.h:2209: warning: parameter has incomplete type *** Error code 1 Stop in /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ cc_tools. *** Error code 1 Stop in /usr/home/tyler/perforce/projects/l4bsd/src. *** Error code 1 Stop in /usr/home/tyler/perforce/projects/l4bsd/src. *** Error code 1 Stop in /usr/home/tyler/perforce/projects/l4bsd/src. % =================== On Jul 24, 2006, at 12:31 AM, R. Tyler Ballance wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I recently integrated today's (ok, sunday's) source code into my > branch in perforce, and I'm getting these build errors: > > Anybody seen anything similar? > > ./gengenrtl > genrtl.c > ./gengenrtl -h > genrtl.h > cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H - > DPREFIX=\"/usr\" -DCROSS_COMPILE -I/usr/home/tyler/builds/obj/ > iguana/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../cc_tools -I/usr/home/tyler/perforce/projects/l4bsd/src/ > gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/home/tyler/perforce/ > projects/l4bsd/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc - > I/usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/config -DGENERATOR_FILE -I/home/ > tyler/builds/obj/iguana/usr/home/tyler/perforce/projects/l4bsd/src/ > tmp/legacy/usr/include -c /usr/home/tyler/perforce/projects/l4bsd/ > src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c > In file included from /usr/home/tyler/perforce/projects/l4bsd/src/ > gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:27: > ./tm.h:4:15: /.h: No such file or directory > ./tm.h:10:22: /freebsd.h: No such file or directory > In file included from /usr/home/tyler/perforce/projects/l4bsd/src/ > gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:28: > /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has > incomplete type > /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/rtl.h:2189: warning: parameter has > incomplete type > /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has > incomplete type > /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/rtl.h:2190: warning: parameter has > incomplete type > /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/rtl.h:2209: warning: parameter has > incomplete type > *** Error code 1 > > Stop in /usr/home/tyler/perforce/projects/l4bsd/src/gnu/usr.bin/cc/ > cc_tools. > *** Error code 1 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFExFsbqO6nEJfroRsRApY8AJ9vbI88wohJdzjb/W29kxFYwW6e6gCfa94r > C+A4qVhDRd2r7rI10nDGsoc= > =4Maf > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFExKMxqO6nEJfroRsRAlVLAJ9lCVe6F55hldMVrZGp3mn4G6oKlwCeLqPn iIp1appbD1RFA2KB/17js6Q= =IsFh -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 08:40:35 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DAE16A4DD for ; Mon, 24 Jul 2006 08:40:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A3443D5D for ; Mon, 24 Jul 2006 08:40:34 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (hsrqxa@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6O8eRod037555 for ; Mon, 24 Jul 2006 10:40:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6O8eRJn037554; Mon, 24 Jul 2006 10:40:27 +0200 (CEST) (envelope-from olli) Date: Mon, 24 Jul 2006 10:40:27 +0200 (CEST) Message-Id: <200607240840.k6O8eRJn037554@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <44C40E66.8080805@wm-access.no> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 24 Jul 2006 10:40:32 +0200 (CEST) X-Mailman-Approved-At: Mon, 24 Jul 2006 11:39:03 +0000 Cc: Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 08:40:35 -0000 Sten Daniel Sųrsdal wrote: > sthaug@nethelp.no wrote: > > > > > > One approach that we could use for 64-bit counters would be to just > > > > use 32-bits one, and poll them for overflow and bump an overflow > > > > count. This assumes that the 32-bit counters overflow much less often > > > > than the polling interval, and easily triples the amount of storage > > > > for each of them... It is ugly :-( > > > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > you want to guarantee 64 bit consistency, you need locking or similar. > > Would it not be necessary to do this locking anyway? > I don't see how polling for overflow would help this consistency. When using the polling solution, the overhead of checking for atomicity is moved to the "client" side, so no locking is necessary. The idea is that most counters are updated much more often than they're read, so the updating code should be as efficient as possible, at the cost of more overhead in the reading code. For example, the code reading the sysctl has to perform the following actions (pseudo code): 1. OV1 = read overflow counter 2. OLD = read old counter value 3. NEW = read new counter value 4. OV2 = read overflow counter 5. if OV2 != OV1: go back to 1. 6. if OLD > NEW: OV1++ 7. return OV1 * 2^32 + NEW I think that should cover all possible race conditions. The code updating the overflow counter at certain polling intervals would have to do something similar, of course. The main advantage of that approach is the fact that the counter updating code is a simple 32bit "add". There's no locking or anything required, i.e. it's most efficient, which is important if the counter is updated very often, like vm.stats.sys.v_swtch or vm.stats.sys.v_syscall or vm.stats.sys.v_intr. The disadvantage is that polling the counters for overflows is somewhat ugly, in terms of design. However, personally I think that it's an acceptable solution, given the fact that it is only required for 32bit "legacy" hardware. 64bit machines will be more and more common and become the "standard", and they don't need such work-arounds for 64bit counters. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 14:23:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65E516A4EC for ; Mon, 24 Jul 2006 14:23:23 +0000 (UTC) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C4A943D68 for ; Mon, 24 Jul 2006 14:22:15 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Mon, 24 Jul 2006 09:21:55 -0500 id 00095811.44C4D783.00008BD6 Received: from dsl-201-144-88-38.prod-infinitum.com.mx (dsl-201-144-88-38.prod-infinitum.com.mx [201.144.88.38]) by mail.bafirst.com (Horde MIME library) with HTTP; Mon, 24 Jul 2006 09:21:55 -0500 Message-ID: <20060724092155.3d2gids6jkggggsw@mail.bafirst.com> Date: Mon, 24 Jul 2006 09:21:55 -0500 From: eculp@bafirst.com To: Martin Nilsson References: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> <44C39E06.80202@gneto.com> In-Reply-To: <44C39E06.80202@gneto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.1-cvs Cc: freebsd-current@freebsd.org Subject: Re: New Dell PowerEdge 2900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 14:23:24 -0000 Quoting Martin Nilsson : > eculp@bafirst.com wrote: >> Does anyone know of any outstanding issues with the Dell PowerEdge >> 2900 that comes with the >> >> PERC 5/i disk controller >> Dual Embedded Broadcom=AE NetXtreme II 5708 Gigabit Ethernet NIC's >> 300GB, SAS, 3.5-inch, 10K RPM Hard Drive >> Memory 4GB 533MHz (4x1GB) > > Why don't you buy a system from a vendor who knows FreeBSD and can > tell you what parts will work and how well supported they are? > > There is a long list at: http://www.freebsd.org/commercial/hardware.html > > Dell is for people who don't care what's inside the box and they tend > to run Windows! Martin, Thanks for your answer, I've purchased from freebsd venders and I agree in part but I have also run dell servers for years and they, both the hardward and the company, have given me very good service. In this specific case the customer is a large corporation that is not in the U.S. and they need both name recognition and acceptable local service and dell provides both. I really don't have a choice and even if I did I'm not sure I would want to look elsewhere for this company. Thanks again for the suggestion, ed > > /Martin > From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 14:30:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24FC116A4E2; Mon, 24 Jul 2006 14:30:07 +0000 (UTC) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id C658D43D45; Mon, 24 Jul 2006 14:29:38 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Mon, 24 Jul 2006 09:29:32 -0500 id 00095811.44C4D94C.00008C57 Received: from dsl-201-144-88-38.prod-infinitum.com.mx (dsl-201-144-88-38.prod-infinitum.com.mx [201.144.88.38]) by mail.bafirst.com (Horde MIME library) with HTTP; Mon, 24 Jul 2006 09:29:32 -0500 Message-ID: <20060724092932.eht1fouxokk8ggoo@mail.bafirst.com> Date: Mon, 24 Jul 2006 09:29:32 -0500 From: eculp@bafirst.com To: "Simon L. Nielsen" References: <20060722114052.cwsuco6u80o4okkw@mail.bafirst.com> <44C39E06.80202@gneto.com> <20060723161940.GB1088@zaphod.nitro.dk> In-Reply-To: <20060723161940.GB1088@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.1-cvs Cc: freebsd-current@freebsd.org Subject: Re: New Dell PowerEdge 2900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 14:30:07 -0000 Quoting "Simon L. Nielsen" : > On 2006.07.23 18:04:22 +0200, Martin Nilsson wrote: >> eculp@bafirst.com wrote: >> >Does anyone know of any outstanding issues with the Dell PowerEdge 2900 >> >that comes with the >> > >> >PERC 5/i disk controller >> >Dual Embedded Broadcom=AE NetXtreme II 5708 Gigabit Ethernet NIC's >> >300GB, SAS, 3.5-inch, 10K RPM Hard Drive >> >Memory 4GB 533MHz (4x1GB) >> >> Why don't you buy a system from a vendor who knows FreeBSD and can tell >> you what parts will work and how well supported they are? >> >> There is a long list at: http://www.freebsd.org/commercial/hardware.html >> >> Dell is for people who don't care what's inside the box and they tend to >> run Windows! > > That's not really true, and Dell does care (at least a bit) about > non-Windows customers. E.g. see > http://cvsweb.freebsd.org/src/sys/dev/mfi/mfi.c (the RAID > driver for PERC 5/i: > > =09Sponsored by: Dell, Ironport Simon, Thanks for the answer. It is already in the tree then but it isn't in the handbook yet afaik and since it seems to have been mfc'ed so it should be stable. I can relax a bit. Thanks, ed > > -- > Simon L. Nielsen > From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:28:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2451516A4E1 for ; Mon, 24 Jul 2006 21:28:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F00243D45 for ; Mon, 24 Jul 2006 21:28:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpE8028792; Mon, 24 Jul 2006 17:28:52 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Jul 2006 17:12:23 -0400 User-Agent: KMail/1.9.1 References: <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060723.205759.74723866.sthaug@nethelp.no> <44C40E66.8080805@wm-access.no> In-Reply-To: <44C40E66.8080805@wm-access.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607241712.23917.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:53 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Sten Daniel =?iso-8859-1?q?S=F8rsdal?= , sthaug@nethelp.no Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:28:55 -0000 On Sunday 23 July 2006 20:03, Sten Daniel S=F8rsdal wrote: > sthaug@nethelp.no wrote: > >>> One approach that we could use for 64-bit counters would be to just > >>> use 32-bits one, and poll them for overflow and bump an overflow > >>> count. This assumes that the 32-bit counters overflow much less often > >>> than the polling interval, and easily triples the amount of storage > >>> for each of them... It is ugly :-( > >>> > >> What's wrong with the add+adc (asm) approach found on any i386? > >=20 > > Presumably the fact that add + adc isn't an atomic operation. So if > > you want to guarantee 64 bit consistency, you need locking or similar. > >=20 >=20 > Would it not be necessary to do this locking anyway? > I don't see how polling for overflow would help this consistency. > Are both suggestions insufficient? I actually think that add + adc is ok for the case of incrementing simple=20 counters. You can even do 'inc ; addc $0' =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:28:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 474F316A4E7 for ; Mon, 24 Jul 2006 21:28:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5E1B43D45 for ; Mon, 24 Jul 2006 21:28:55 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpE9028792; Mon, 24 Jul 2006 17:28:54 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Jul 2006 17:16:09 -0400 User-Agent: KMail/1.9.1 References: <44C36691.5030501@gmail.com> In-Reply-To: <44C36691.5030501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241716.09548.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:55 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Subject: Re: page fault panic in kern_access/crcopy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:28:56 -0000 On Sunday 23 July 2006 08:07, Pawel Worach wrote: > Hi, > > While testing SCTP with NetPIPE I found a reproducible panic, I'm not > sure if this one is SCTP's fault. This is using: > FreeBSD 7.0-CURRENT #0: Sun Jul 23 13:23:06 CEST 2006 + SCTP patches > from today. > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 8 > #8 0xc0531b92 in crcopy (dest=0xc28f4800, src=0xc28f4800) > at /usr/src/sys/kern/kern_prot.c:1954 > 1954 uihold(dest->cr_uidinfo); > (kgdb) p *dest > $1 = {cr_ref = 1, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 0, > cr_groups = {0 }, cr_rgid = 0, cr_svgid = 0, > cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_label = 0x0} > (kgdb) p *src > $2 = {cr_ref = 1, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 0, > cr_groups = {0 }, cr_rgid = 0, cr_svgid = 0, > cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_label = 0x0} This implies that curthread has a bogus td_ucred. Lots of things should break if this happens. :( You need to find where td_ucred gets set to a bogus credential. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:28:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0938416A4DD; Mon, 24 Jul 2006 21:28:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A0143D46; Mon, 24 Jul 2006 21:28:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpEA028792; Mon, 24 Jul 2006 17:28:56 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Jul 2006 17:17:56 -0400 User-Agent: KMail/1.9.1 References: <20060723124037.GI64253@submonkey.net> In-Reply-To: <20060723124037.GI64253@submonkey.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241717.56709.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Ceri Davies , current@freebsd.org Subject: Re: Panic on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:28:58 -0000 On Sunday 23 July 2006 08:40, Ceri Davies wrote: > With yesterday's -HEAD, while doing a simultaneous > 'portupgrade -a' and a 'make buildworld', with the source and object > trees for the buildworld on a NFS mount from a 6-STABLE server. > > Kernel config is GENERIC, plus: > > device cpufreq > device puc > device sound > device snd_via8233 > > makeoptions DEBUG=-g > options KDB_UNATTENDED > > This is probably reproducable, as I also experienced a panic yesterday > while doing the same thing, but I didn't have dumps configured then. > #8 0xffffffff804a87fe in vfs_ref (mp=0x0) at /usr/src/sys/kern/vfs_mount.c:419 This looks to be your problem. mp is NULL. Not sure why it is NULL though. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:28:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0938416A4DD; Mon, 24 Jul 2006 21:28:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A0143D46; Mon, 24 Jul 2006 21:28:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpEA028792; Mon, 24 Jul 2006 17:28:56 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Jul 2006 17:17:56 -0400 User-Agent: KMail/1.9.1 References: <20060723124037.GI64253@submonkey.net> In-Reply-To: <20060723124037.GI64253@submonkey.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241717.56709.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Ceri Davies , current@freebsd.org Subject: Re: Panic on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:28:58 -0000 On Sunday 23 July 2006 08:40, Ceri Davies wrote: > With yesterday's -HEAD, while doing a simultaneous > 'portupgrade -a' and a 'make buildworld', with the source and object > trees for the buildworld on a NFS mount from a 6-STABLE server. > > Kernel config is GENERIC, plus: > > device cpufreq > device puc > device sound > device snd_via8233 > > makeoptions DEBUG=-g > options KDB_UNATTENDED > > This is probably reproducable, as I also experienced a panic yesterday > while doing the same thing, but I didn't have dumps configured then. > #8 0xffffffff804a87fe in vfs_ref (mp=0x0) at /usr/src/sys/kern/vfs_mount.c:419 This looks to be your problem. mp is NULL. Not sure why it is NULL though. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:29:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B76616A5D9; Mon, 24 Jul 2006 21:29:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADE9343D45; Mon, 24 Jul 2006 21:29:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpEB028792; Mon, 24 Jul 2006 17:28:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, Yablochkin Walery Date: Mon, 24 Jul 2006 17:19:22 -0400 User-Agent: KMail/1.9.1 References: <20060723124037.GI64253@submonkey.net> <132106974.20060723214923@bk.ru> In-Reply-To: <132106974.20060723214923@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241719.23168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:59 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: Panic on amd64 (and i386?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:29:02 -0000 On Sunday 23 July 2006 13:49, Walery wrote: > Sorry, my english is bad :( > > pcpu.h is broken? Nah, not in your case. > Panic on pcpu.h:166 on my i386-box on high load (make -j3 buildworld + xmms music + > glxgears full screen): > > at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/trap.c:279 > #5 0xc068a69a in calltrap () at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/exception.s:138 > #6 0xc0531cbb in propagate_priority (td=0xc4172b40) > at /usr/home/cvs-snap/freebsd/current/src/sys/kern/subr_turnstile.c:246 This is generally the result of a thread sleeping while holding a mutex. If your sources are up to date then it should have spit out a stack trace of the misbehaving thread on the console before panic'ing. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:29:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B76616A5D9; Mon, 24 Jul 2006 21:29:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADE9343D45; Mon, 24 Jul 2006 21:29:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpEB028792; Mon, 24 Jul 2006 17:28:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, Yablochkin Walery Date: Mon, 24 Jul 2006 17:19:22 -0400 User-Agent: KMail/1.9.1 References: <20060723124037.GI64253@submonkey.net> <132106974.20060723214923@bk.ru> In-Reply-To: <132106974.20060723214923@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241719.23168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:28:59 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: Panic on amd64 (and i386?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:29:02 -0000 On Sunday 23 July 2006 13:49, Walery wrote: > Sorry, my english is bad :( > > pcpu.h is broken? Nah, not in your case. > Panic on pcpu.h:166 on my i386-box on high load (make -j3 buildworld + xmms music + > glxgears full screen): > > at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/trap.c:279 > #5 0xc068a69a in calltrap () at /usr/home/cvs-snap/freebsd/current/src/sys/i386/i386/exception.s:138 > #6 0xc0531cbb in propagate_priority (td=0xc4172b40) > at /usr/home/cvs-snap/freebsd/current/src/sys/kern/subr_turnstile.c:246 This is generally the result of a thread sleeping while holding a mutex. If your sources are up to date then it should have spit out a stack trace of the misbehaving thread on the console before panic'ing. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 21:29:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48C2716A6D4 for ; Mon, 24 Jul 2006 21:29:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 242CD43D49 for ; Mon, 24 Jul 2006 21:29:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpEC028792; Mon, 24 Jul 2006 17:29:00 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Jul 2006 17:20:35 -0400 User-Agent: KMail/1.9.1 References: <44C39D7E.30102@mail.web.am> <20060724080620.GA39934@stud.fit.vutbr.cz> In-Reply-To: <20060724080620.GA39934@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241720.36606.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 17:29:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Divacky Roman , Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:29:06 -0000 On Monday 24 July 2006 04:06, Divacky Roman wrote: > On Sun, Jul 23, 2006 at 09:02:06PM +0500, Gaspar Chilingarov wrote: > > Hi all! > > > > After upgrading from -CURRENT mid-Mart to Jul 22 current I got a > > failures for Linux applications which try to use X. > > > > About my system: amd64, I'm trying to run openoffice and skype, but they > > fail with "Segmentation fault". ktrace also produces dump, which makes > > kdump fail also with segfault. > > > > Is this known issue or I've messed somethng on my system while upgrading? > > yes... linuxolator@amd64 is currently broken. afaik the commit to linux_ipc > removing stackgap usage broke it. I hope someone (jhb?) is working on it I'm waiting for someone to help figure out which specific linux_semctl() request is broken. All the attempts to use ktrace so far have failed. :( If someone would like to engage in some printf or KTR spelunking that would be helpful. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 23:23:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F5F816A4DF; Mon, 24 Jul 2006 23:23:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14A6E43D46; Mon, 24 Jul 2006 23:23:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6ONMKA2003597; Mon, 24 Jul 2006 17:22:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 24 Jul 2006 17:22:41 -0600 (MDT) Message-Id: <20060724.172241.139505616.imp@bsdimp.com> To: tyler@bleepsoft.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 24 Jul 2006 17:22:21 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Failing `make buildworld` with today's source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 23:23:45 -0000 The problem is that gcc doesn't know how to map iguana onto something it groks. Maybe you need to have TARGET_ARCH be one of the supported CPUs? I'm unsure what iguana runs on, so I'm not sure which one you should pick. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 00:19:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4810116A4DD; Tue, 25 Jul 2006 00:19:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E88943D55; Tue, 25 Jul 2006 00:19:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6P0JArh068057; Mon, 24 Jul 2006 20:19:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k6P0JBFC098002; Mon, 24 Jul 2006 20:19:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 12B0B7302F; Mon, 24 Jul 2006 20:19:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060725001911.12B0B7302F@freebsd-current.sentex.ca> Date: Mon, 24 Jul 2006 20:19:11 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 00:19:13 -0000 TB --- 2006-07-24 22:20:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-24 22:20:56 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-07-24 22:20:57 - cleaning the object tree TB --- 2006-07-24 22:21:39 - checking out the source tree TB --- 2006-07-24 22:21:39 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-07-24 22:21:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-07-24 22:29:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-24 22:29:14 - cd /src TB --- 2006-07-24 22:29:14 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-07-25 00:04:03 - generating LINT kernel config TB --- 2006-07-25 00:04:03 - cd /src/sys/amd64/conf TB --- 2006-07-25 00:04:03 - /usr/bin/make -B LINT TB --- 2006-07-25 00:04:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-07-25 00:04:03 - cd /src TB --- 2006-07-25 00:04:03 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 25 00:04:03 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] smb_trantcp.o(.text+0x174f): In function `smb_nbst_intr': : undefined reference to `sowakeup' nfs_socket.o(.text+0x17c2): In function `nfs_connect': : undefined reference to `soreserve' nfs_syscalls.o(.text+0x1af): In function `nfssvc_addsock': : undefined reference to `soreserve' rpcclnt.o(.text+0x76e): In function `rpcclnt_connect': : undefined reference to `soreserve' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-25 00:19:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-25 00:19:10 - ERROR: failed to build lint kernel TB --- 2006-07-25 00:19:10 - tinderbox aborted TB --- 1.27 user 7.23 system 7093.84 real From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 01:51:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E93A216A4DF; Tue, 25 Jul 2006 01:51:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD2D43D45; Tue, 25 Jul 2006 01:51:22 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6P1pKUZ072037; Mon, 24 Jul 2006 21:51:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k6P1pLfw045417; Mon, 24 Jul 2006 21:51:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D4EA7302F; Mon, 24 Jul 2006 21:51:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060725015121.0D4EA7302F@freebsd-current.sentex.ca> Date: Mon, 24 Jul 2006 21:51:21 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 01:51:23 -0000 TB --- 2006-07-25 00:19:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-25 00:19:11 - starting HEAD tinderbox run for i386/i386 TB --- 2006-07-25 00:19:11 - cleaning the object tree TB --- 2006-07-25 00:19:39 - checking out the source tree TB --- 2006-07-25 00:19:39 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-07-25 00:19:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-07-25 00:26:51 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-25 00:26:51 - cd /src TB --- 2006-07-25 00:26:51 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-07-25 01:34:20 - generating LINT kernel config TB --- 2006-07-25 01:34:20 - cd /src/sys/i386/conf TB --- 2006-07-25 01:34:20 - /usr/bin/make -B LINT TB --- 2006-07-25 01:34:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-07-25 01:34:20 - cd /src TB --- 2006-07-25 01:34:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 25 01:34:20 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] smb_trantcp.o(.text+0x1380): In function `smb_nbst_intr': : undefined reference to `sowakeup' nfs_socket.o(.text+0x1463): In function `nfs_connect': : undefined reference to `soreserve' nfs_syscalls.o(.text+0x167): In function `nfssvc_addsock': : undefined reference to `soreserve' rpcclnt.o(.text+0x636): In function `rpcclnt_connect': : undefined reference to `soreserve' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-25 01:51:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-25 01:51:20 - ERROR: failed to build lint kernel TB --- 2006-07-25 01:51:20 - tinderbox aborted TB --- 1.22 user 5.94 system 5529.70 real From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 03:20:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9FB16A4DD; Tue, 25 Jul 2006 03:20:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76EFE43D46; Tue, 25 Jul 2006 03:20:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6P3KTCe075176; Mon, 24 Jul 2006 23:20:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k6P3KUHm002444; Mon, 24 Jul 2006 23:20:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1ED0E7302F; Mon, 24 Jul 2006 23:20:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060725032030.1ED0E7302F@freebsd-current.sentex.ca> Date: Mon, 24 Jul 2006 23:20:30 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 03:20:32 -0000 TB --- 2006-07-25 01:51:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-25 01:51:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-07-25 01:51:21 - cleaning the object tree TB --- 2006-07-25 01:51:46 - checking out the source tree TB --- 2006-07-25 01:51:46 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-07-25 01:51:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-07-25 01:58:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-25 01:58:58 - cd /src TB --- 2006-07-25 01:58:58 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-07-25 03:06:16 - generating LINT kernel config TB --- 2006-07-25 03:06:16 - cd /src/sys/pc98/conf TB --- 2006-07-25 03:06:16 - /usr/bin/make -B LINT TB --- 2006-07-25 03:06:16 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-07-25 03:06:16 - cd /src TB --- 2006-07-25 03:06:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 25 03:06:16 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] smb_trantcp.o(.text+0x1380): In function `smb_nbst_intr': : undefined reference to `sowakeup' nfs_socket.o(.text+0x1463): In function `nfs_connect': : undefined reference to `soreserve' nfs_syscalls.o(.text+0x167): In function `nfssvc_addsock': : undefined reference to `soreserve' rpcclnt.o(.text+0x636): In function `rpcclnt_connect': : undefined reference to `soreserve' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-25 03:20:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-25 03:20:29 - ERROR: failed to build lint kernel TB --- 2006-07-25 03:20:29 - tinderbox aborted TB --- 1.09 user 5.73 system 5348.69 real From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 06:07:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FAF616A4DE for ; Tue, 25 Jul 2006 06:07:10 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B43EB43D46 for ; Tue, 25 Jul 2006 06:07:07 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G5G4O-000FRX-6O for current@freebsd.org; Tue, 25 Jul 2006 08:07:04 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Tue, 25 Jul 2006 08:07:04 +0200 Sender: ianf@hetzner.co.za Message-Id: Cc: Subject: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 06:07:10 -0000 Hi It seems that placing an em(4) interface into promiscuous mode the card stops doing hardware offload of 802.1Q tagging, in fact, it stops tagging entirely if vlanhwtag is enabled on the card. With vlanhwtag: 15:40:48.050645 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 44821, offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.42.167,148.235.231.80,70.180.123.113,201.169.28.232,19.31.18.203,59.148.50.175 Without vlanhwtag: 15:40:57.419522 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 74: vlan 1001, p 0, ethertype IPv4, (tos 0x10, ttl 255, id 44867, offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.42.176,8.148.142.115,171.178.137.11,211.216.40.239,67.124.122.122,253.155.32.152 The interface is placed in promiscuous mode by the carp driver. em0: flags=8943 mtu 1500 options=cb ether 00:04:23:cf:50:00 media: Ethernet autoselect (1000baseTX ) status: active vlan1001: flags=8943 mtu 1500 inet 196.30.82.62 netmask 0xfffffff0 broadcast 196.30.82.63 ether 00:04:23:cf:50:00 media: Ethernet autoselect (1000baseTX ) status: active vlan: 1001 parent interface: em0 carp1001: flags=49 mtu 1500 inet 196.30.82.60 netmask 0xfffffff0 carp: BACKUP vhid 2 advbase 1 advskew 0 I've also noticed that the re(4) driver on the 8169 chip miss-tags frames when vlanhwtag is enabled. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 06:35:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B85F816A4E0 for ; Tue, 25 Jul 2006 06:35:19 +0000 (UTC) (envelope-from keichii@freebsd.org) Received: from mail.cps.utexas.edu (mail.cps.utexas.edu [128.83.188.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54C8143D45 for ; Tue, 25 Jul 2006 06:35:19 +0000 (GMT) (envelope-from keichii@freebsd.org) Received: from [128.83.157.105] (dhcp-128-83-157-105.psy.utexas.edu [128.83.157.105]) by mail.cps.utexas.edu (8.13.1/8.13.1) with ESMTP id k6P6MUaa025521 for ; Tue, 25 Jul 2006 01:22:30 -0500 Message-ID: <44C5BBB4.8080102@freebsd.org> Date: Tue, 25 Jul 2006 01:35:32 -0500 From: "Michael C. Wu" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: amd64 page fault situation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 06:35:19 -0000 Hi Everyone, I am wondering what we actually do in the following situation. Suppose that there is an op code on amd64 that calls for a 64bit word. This word crosses a page boundary. i.e. The first byte or 2 of the word is on the last part of the page, and the second part of the word is on the next page. Do we just have a TLB miss or page miss? I'd like to know what happens. There seems to be a good optimization opportunity here. Thanks, Michael From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 07:09:19 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 027D216A4DA; Tue, 25 Jul 2006 07:09:19 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8040743D46; Tue, 25 Jul 2006 07:09:18 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G4uaB-000BUp-0u; Mon, 24 Jul 2006 09:10:27 +0200 To: Doug Barton From: Ian FREISLICH In-Reply-To: Message from Doug Barton of "Sat, 22 Jul 2006 00:06:27 MST." <44C1CE73.7030200@FreeBSD.org> X-Attribution: BOFH Date: Mon, 24 Jul 2006 09:10:27 +0200 Sender: ianf@hetzner.co.za Message-Id: Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 07:09:19 -0000 Doug Barton wrote: > Jeremie Le Hen wrote: > > Hi, > > > > I am running a two month old current (dated from May 24) > > SOP with -current is that before you submit a bug report for a system this > old you should upgrade to the latest world and kernel. Two months is > _really_ old in -current terms. Well, I can confirm that this problem exists with a recent kernel (late last week). Polling makes it go away, but I suspect that the problem is more wide spread because without polling I've been seeing interface resets on re and rl cards as well. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 10:17:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0007C16A4E1; Tue, 25 Jul 2006 10:17:42 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE79F43D58; Tue, 25 Jul 2006 10:17:36 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6PAHUeS013584 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Jul 2006 12:17:30 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6PAHUU7013583; Tue, 25 Jul 2006 12:17:30 +0200 (CEST) Date: Tue, 25 Jul 2006 12:17:29 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20060725101729.GA13468@stud.fit.vutbr.cz> References: <44C39D7E.30102@mail.web.am> <20060724080620.GA39934@stud.fit.vutbr.cz> <200607241720.36606.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607241720.36606.jhb@freebsd.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 10:17:43 -0000 On Mon, Jul 24, 2006 at 05:20:35PM -0400, John Baldwin wrote: > On Monday 24 July 2006 04:06, Divacky Roman wrote: > > On Sun, Jul 23, 2006 at 09:02:06PM +0500, Gaspar Chilingarov wrote: > > > Hi all! > > > > > > After upgrading from -CURRENT mid-Mart to Jul 22 current I got a > > > failures for Linux applications which try to use X. > > > > > > About my system: amd64, I'm trying to run openoffice and skype, but they > > > fail with "Segmentation fault". ktrace also produces dump, which makes > > > kdump fail also with segfault. > > > > > > Is this known issue or I've messed somethng on my system while upgrading? > > > > yes... linuxolator@amd64 is currently broken. afaik the commit to linux_ipc > > removing stackgap usage broke it. I hope someone (jhb?) is working on it > > I'm waiting for someone to help figure out which specific linux_semctl() > request is broken. All the attempts to use ktrace so far have failed. :( If > someone would like to engage in some printf or KTR spelunking that would be > helpful. I had much better luck with truss then with kdump when playing with linux apps. this thursday at work I'll try to provide some more info, what exaclty do you need? is what -DDEBUG prints enough? roman From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:35:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D3A416A4DA for ; Tue, 25 Jul 2006 12:35:39 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E82BA43D72 for ; Tue, 25 Jul 2006 12:35:35 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp6-g19.free.fr (Postfix) with ESMTP id DA13622672; Tue, 25 Jul 2006 14:35:34 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id CEF8B9C9B4; Tue, 25 Jul 2006 12:36:03 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id C0476405F; Tue, 25 Jul 2006 14:36:03 +0200 (CEST) Date: Tue, 25 Jul 2006 14:36:03 +0200 From: Jeremie Le Hen To: Jack Vogel Message-ID: <20060725123603.GH6253@obiwan.tataz.chchile.org> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <2a41acea0607210927s108d1326qdad02b7d29376a09@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0607210927s108d1326qdad02b7d29376a09@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 12:35:39 -0000 On Fri, Jul 21, 2006 at 09:27:31AM -0700, Jack Vogel wrote: > hitting watchdog means you have a hang of some sort. > try 'sysctl dev.em.0.debug_info=1' and see if that gives any clues. dev.em.0.debug_info: % em0: Adapter hardware address = 0xc2a32130 % em0: CTRL = 0x18f00241 RCTL = 0x801a % em0: Packet buffer = Tx=16k Rx=48k % em0: Flow control watermarks high = 47104 low = 45604 % em0: tx_int_delay = 66, tx_abs_int_delay = 66 % em0: rx_int_delay = 0, rx_abs_int_delay = 66 % em0: fifo workaround = 0, fifo_reset_count = 0 % em0: hw tdh = 149, hw tdt = 149 % em0: Num Tx descriptors avail = 256 % em0: Tx Descriptors not avail1 = 0 % em0: Tx Descriptors not avail2 = 0 % em0: Std mbuf failed = 0 % em0: Std mbuf cluster failed = 0 % em0: Driver dropped packets = 0 dev.em.0.stats: % em0: Excessive collisions = 0 % em0: Symbol errors = 0 % em0: Sequence errors = 0 % em0: Defer count = 0 % em0: Missed Packets = 0 % em0: Receive No Buffers = 0 % em0: Receive length errors = 0 % em0: Receive errors = 0 % em0: Crc errors = 0 % em0: Alignment errors = 0 % em0: Carrier extension errors = 0 % em0: RX overruns = 0 % em0: watchdog timeouts = 6 % em0: XON Rcvd = 0 % em0: XON Xmtd = 0 % em0: XOFF Rcvd = 0 % em0: XOFF Xmtd = 0 % em0: Good Packets Rcvd = 3720143 % em0: Good Packets Xmtd = 1246413 Most of provided debugging informations are meaningless for me. Is any minded soul able to understand this ? Thank you, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:43:01 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2375116A4DD; Tue, 25 Jul 2006 12:43:01 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF24943D46; Tue, 25 Jul 2006 12:43:00 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 138817597A; Tue, 25 Jul 2006 14:43:00 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 843439B983; Tue, 25 Jul 2006 12:43:28 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 7013D405F; Tue, 25 Jul 2006 14:43:28 +0200 (CEST) Date: Tue, 25 Jul 2006 14:43:28 +0200 From: Jeremie Le Hen To: Doug Barton Message-ID: <20060725124328.GI6253@obiwan.tataz.chchile.org> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <44C1CE73.7030200@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C1CE73.7030200@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.org Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 12:43:01 -0000 On Sat, Jul 22, 2006 at 12:06:27AM -0700, Doug Barton wrote: > Jeremie Le Hen wrote: > > Hi, > > > > I am running a two month old current (dated from May 24) > > SOP with -current is that before you submit a bug report for a system this > old you should upgrade to the latest world and kernel. Two months is > _really_ old in -current terms. I am rebuilding a fresher one right now. According to Ian's post, the problem is likely to remain. What do you advice me to do to track this down ? FYI, my -CURRENT kernel (as well userland) is patched with ProPolice. I don't think this can lead to this kind of problem, the overhead is really small, in an order of 3 percent. Do you think such an overhead in a time-critial path could trigger a watchdog timeout ? Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:46:18 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0157016A4DE for ; Tue, 25 Jul 2006 12:46:18 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E0BC43D4C for ; Tue, 25 Jul 2006 12:46:17 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G5MIe-000Gbd-Tp for freebsd-current@FreeBSD.org; Tue, 25 Jul 2006 14:46:12 +0200 To: Doug Barton From: Ian FREISLICH In-Reply-To: Message from Doug Barton of "Sat, 22 Jul 2006 00:06:27 MST." <44C1CE73.7030200@FreeBSD.org> X-Attribution: BOFH Date: Mon, 24 Jul 2006 09:10:27 +0200 Sender: ianf@hetzner.co.za Resent-To: freebsd-current@FreeBSD.org Resent-Date: Tue, 25 Jul 2006 14:46:12 +0200 Resent-From: Ian FREISLICH Resent-Message-Id: Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 12:46:18 -0000 Doug Barton wrote: > Jeremie Le Hen wrote: > > Hi, > > > > I am running a two month old current (dated from May 24) > > SOP with -current is that before you submit a bug report for a system this > old you should upgrade to the latest world and kernel. Two months is > _really_ old in -current terms. Well, I can confirm that this problem exists with a recent kernel (late last week). Polling makes it go away, but I suspect that the problem is more wide spread because without polling I've been seeing interface resets on re and rl cards as well. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:54:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5CD516A4DA; Tue, 25 Jul 2006 12:54:22 +0000 (UTC) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60CAE43D46; Tue, 25 Jul 2006 12:54:21 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 7383C1A734; Tue, 25 Jul 2006 14:54:19 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47256-05; Tue, 25 Jul 2006 14:54:16 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 3BDB21A720; Tue, 25 Jul 2006 14:54:16 +0200 (CEST) Message-ID: <44C61470.3070005@shapeshifter.se> Date: Tue, 25 Jul 2006 14:54:08 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.2 (X11/20060423) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------080406040804030105080707" X-Virus-Scanned: amavisd-new at h3q.net Cc: jmg@freebsd.org Subject: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 12:54:23 -0000 This is a multi-part message in MIME format. --------------080406040804030105080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a suggestion to add support for ip-address changes to the kqueue (EVFILT_NETDEV) system. The infrastructure for EVFILT_NETDEV is already in place and this only introduce NOTE_NEWADDR and NOTE_DELADDR and minor modifications to the interface ioctl handler. The purpose is not to replicate the functionality of the routing socket, but to provide a low overhead mechanism for monitoring a given interface for address changes. No information about the event is sent through the kqueue system, instead it will be up to the caller to query the system (if wanted) to obtain information about the current state of the interface that is being monitored. I have attached a suggested patch, any thoughts? Fredrik Lindberg --------------080406040804030105080707 Content-Type: text/plain; name="kqueue-netdev-20060725.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kqueue-netdev-20060725.patch" Index: sys/event.h =================================================================== RCS file: /home/ncvs/src/sys/sys/event.h,v retrieving revision 1.36 diff -u -r1.36 event.h --- sys/event.h 16 Mar 2006 11:19:36 -0000 1.36 +++ sys/event.h 25 Jul 2006 12:18:16 -0000 @@ -115,6 +115,8 @@ #define NOTE_LINKUP 0x0001 /* link is up */ #define NOTE_LINKDOWN 0x0002 /* link is down */ #define NOTE_LINKINV 0x0004 /* link state is invalid */ +#define NOTE_NEWADDR 0x0008 /* ip-address added */ +#define NOTE_DELADDR 0x0010 /* ip-address removed */ struct knote; SLIST_HEAD(klist, knote); Index: netinet/in.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.93 diff -u -r1.93 in.c --- netinet/in.c 24 Jan 2006 16:19:31 -0000 1.93 +++ netinet/in.c 25 Jul 2006 12:18:16 -0000 @@ -399,8 +399,10 @@ (struct sockaddr_in *) &ifr->ifr_addr, 1); if (error != 0 && iaIsNew) break; - if (error == 0) + if (error == 0) { EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_NEWADDR); + } return (0); case SIOCSIFNETMASK: @@ -443,8 +445,10 @@ if ((ifp->if_flags & IFF_BROADCAST) && (ifra->ifra_broadaddr.sin_family == AF_INET)) ia->ia_broadaddr = ifra->ifra_broadaddr; - if (error == 0) + if (error == 0) { EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_NEWADDR); + } return (error); case SIOCDIFADDR: @@ -460,6 +464,7 @@ */ in_ifadown(&ia->ia_ifa, 1); EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_DELADDR); error = 0; break; --------------080406040804030105080707-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:54:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F4E316A4DD; Tue, 25 Jul 2006 12:54:55 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2952943D4C; Tue, 25 Jul 2006 12:54:55 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 7E5955D44; Tue, 25 Jul 2006 08:54:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqH3fHn2vw0Y; Tue, 25 Jul 2006 08:54:53 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id BC9565CB5; Tue, 25 Jul 2006 08:54:52 -0400 (EDT) Message-ID: <44C61492.6020808@mac.com> Date: Tue, 25 Jul 2006 08:54:42 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Michael C. Wu" References: <44C5BBB4.8080102@freebsd.org> In-Reply-To: <44C5BBB4.8080102@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: amd64 page fault situation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 12:54:55 -0000 Michael C. Wu wrote: > Suppose that there is an op code on amd64 that calls for a 64bit word. > This word crosses a page boundary. i.e. The first byte or 2 of the word > is on the last part of the page, and the second part of the word > is on the next page. > > Do we just have a TLB miss or page miss? If the second part of the opcode is in a page which is resident in physical RAM & present in the TLB, neither. Otherwise the system will query the TLB, and if it doesn't find an entry, it will then scan the page tables. If the entry is found, the CPU will load that entry into the TLB and retry the instruction. If not, that becomes a page fault and the system will have to read in the requested frame of memory from secondary storage and retry the opcode... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:54:19 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA3AA16A4DE for ; Tue, 25 Jul 2006 12:54:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E15F743D4C for ; Tue, 25 Jul 2006 12:54:18 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dybkve@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6PCsBUb092738 for ; Tue, 25 Jul 2006 14:54:16 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6PCsBef092737; Tue, 25 Jul 2006 14:54:11 +0200 (CEST) (envelope-from olli) Date: Tue, 25 Jul 2006 14:54:11 +0200 (CEST) Message-Id: <200607251254.k6PCsBef092737@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <200607241712.23917.jhb@freebsd.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 25 Jul 2006 14:54:16 +0200 (CEST) X-Mailman-Approved-At: Tue, 25 Jul 2006 13:40:40 +0000 Cc: Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 12:54:19 -0000 John Baldwin wrote: > On Sunday 23 July 2006 20:03, Sten Daniel Sųrsdal wrote: > > sthaug@nethelp.no wrote: > > > > > One approach that we could use for 64-bit counters would be to just > > > > > use 32-bits one, and poll them for overflow and bump an overflow > > > > > count. This assumes that the 32-bit counters overflow much less often > > > > > than the polling interval, and easily triples the amount of storage > > > > > for each of them... It is ugly :-( > > > > > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > > you want to guarantee 64 bit consistency, you need locking or similar. > > > > > > > Would it not be necessary to do this locking anyway? > > I don't see how polling for overflow would help this consistency. > > Are both suggestions insufficient? > > I actually think that add + adc is ok for the case of incrementing simple > counters. You can even do 'inc ; addc $0' (I'm familiar with asm programming, but I'm not a low-level threading or SMP expert, so please excuse me if this is a dumb question ...) If you just do add+adc (or inc+adc) and another thread (on the same or different processor, I don't know) happens to read the counter value at the same time (i.e. after the lower 32bit have overflowed, but before the upper 32bit get incremented), then that other thread would get a value that's off by 2^32. What am I missing? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 14:42:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D8716A4E2 for ; Tue, 25 Jul 2006 14:42:39 +0000 (UTC) (envelope-from amogilny@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 783D643E3C for ; Tue, 25 Jul 2006 14:41:38 +0000 (GMT) (envelope-from amogilny@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so2865465uge for ; Tue, 25 Jul 2006 07:41:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IqMDxRK60EQrvF1o0PcTyjmoVKJnijaUbPWyGmXu8u4styZvWWiBYBkt5Al1akTLEq22xzyixwKRJyt+WTpdk2foXuMFN9hySWbWvRkG3sYOWrVr6/Ro8sjkASOSsAF879nR7U07ix1QDA9cD6ZbgfnR8LDJzkiBoNjiqwrykRg= Received: by 10.78.122.11 with SMTP id u11mr2354864huc; Tue, 25 Jul 2006 07:41:36 -0700 (PDT) Received: by 10.78.178.3 with HTTP; Tue, 25 Jul 2006 07:41:36 -0700 (PDT) Message-ID: <7403d2a30607250741m30d8fdd8wb0055363f7bb8338@mail.gmail.com> Date: Tue, 25 Jul 2006 17:41:36 +0300 From: "Alexander Mogilny" Sender: amogilny@gmail.com To: "Mark Linimon" In-Reply-To: <20060724185052.GA3695@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7403d2a30607240213v522b7f21t2e2e0e90dbe6a7c4@mail.gmail.com> <20060724185052.GA3695@soaustin.net> X-Google-Sender-Auth: db266eb3e883fc39 Cc: freebsd-current@freebsd.org Subject: Re: [patch] Broadcom BCM5751F Gigabit Ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 14:42:39 -0000 On 7/24/06, Mark Linimon wrote: > > You should send-pr(1) this so it doesn't just get lost among all the > mailing list chatter. > I have just checked the surces on my laptop using CURRENT and found that this NIC is supported in current branch. As soon as I can see from cvs repository information this NIC is supported since revision 1.49 of if_bgereg.h and 1.132 of if_bge.c (commited on Thu Jun 15 14:31:49 2006 UTC (5 weeks, 5 days ago) by glebius). This change is still not present in RELENG_6 branch. Should I write pr regarding support of this NIC in RELENG_6 branch? -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 16:34:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE24E16A56A for ; Tue, 25 Jul 2006 16:34:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1AF643D72 for ; Tue, 25 Jul 2006 16:34:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6PGY0UD036542; Tue, 25 Jul 2006 12:34:03 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Divacky Roman Date: Tue, 25 Jul 2006 12:30:39 -0400 User-Agent: KMail/1.9.1 References: <44C39D7E.30102@mail.web.am> <200607241720.36606.jhb@freebsd.org> <20060725101729.GA13468@stud.fit.vutbr.cz> In-Reply-To: <20060725101729.GA13468@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607251230.39953.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 25 Jul 2006 12:34:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1618/Mon Jul 24 21:12:40 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 16:34:06 -0000 On Tuesday 25 July 2006 06:17, Divacky Roman wrote: > On Mon, Jul 24, 2006 at 05:20:35PM -0400, John Baldwin wrote: > > On Monday 24 July 2006 04:06, Divacky Roman wrote: > > > On Sun, Jul 23, 2006 at 09:02:06PM +0500, Gaspar Chilingarov wrote: > > > > Hi all! > > > > > > > > After upgrading from -CURRENT mid-Mart to Jul 22 current I got a > > > > failures for Linux applications which try to use X. > > > > > > > > About my system: amd64, I'm trying to run openoffice and skype, but they > > > > fail with "Segmentation fault". ktrace also produces dump, which makes > > > > kdump fail also with segfault. > > > > > > > > Is this known issue or I've messed somethng on my system while upgrading? > > > > > > yes... linuxolator@amd64 is currently broken. afaik the commit to linux_ipc > > > removing stackgap usage broke it. I hope someone (jhb?) is working on it > > > > I'm waiting for someone to help figure out which specific linux_semctl() > > request is broken. All the attempts to use ktrace so far have failed. :( If > > someone would like to engage in some printf or KTR spelunking that would be > > helpful. > > I had much better luck with truss then with kdump when playing with linux apps. > > this thursday at work I'll try to provide some more info, what exaclty do you > need? is what -DDEBUG prints enough? Probably. The changes in question were just in the linux semctl function, so you really only need printf's for that function to figure out which case it is blowing up one and why. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 17:39:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11ED816A50D for ; Tue, 25 Jul 2006 17:39:31 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id B368743D70 for ; Tue, 25 Jul 2006 17:39:28 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (v56wxwg9ccbl6xfz@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k6PHdRtK066272; Tue, 25 Jul 2006 10:39:27 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k6PHdOvj066271; Tue, 25 Jul 2006 10:39:24 -0700 (PDT) (envelope-from jmg) Date: Tue, 25 Jul 2006 10:39:24 -0700 From: John-Mark Gurney To: Fredrik Lindberg Message-ID: <20060725173924.GR96589@funkthat.com> Mail-Followup-To: Fredrik Lindberg , freebsd-current@freebsd.org References: <44C61470.3070005@shapeshifter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C61470.3070005@shapeshifter.se> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 17:39:31 -0000 Fredrik Lindberg wrote this message on Tue, Jul 25, 2006 at 14:54 +0200: > I have a suggestion to add support for ip-address changes to the > kqueue (EVFILT_NETDEV) system. > The infrastructure for EVFILT_NETDEV is already in place and this > only introduce NOTE_NEWADDR and NOTE_DELADDR and minor modifications > to the interface ioctl handler. > > The purpose is not to replicate the functionality of the > routing socket, but to provide a low overhead mechanism for > monitoring a given interface for address changes. > No information about the event is sent through the kqueue system, > instead it will be up to the caller to query the system (if wanted) > to obtain information about the current state of the interface > that is being monitored. > > I have attached a suggested patch, any thoughts? Looks basicly good, though you will need to rethink how the filt_netdev handles the hint.. since right now it just sets kn_data to whatever hint is.. This is fine when it was simply one of NOTE_LINK{UP,DOWN,INV}, but now that you have an extra flag, the NOTE_DELADDR could make an app miss the LINK status if it was looking at data instead of fflags.. Plus, are you sure everyone that is using NOTE_LINK* are treating them as a bit mask? maybe we need to redefine NOTE_LINK* as a mask plus set of values, since each of the NOTE_LINK* can only be set once... but the NOTE_ADDR{NEW,DEL} should probably be flags... We may want to reverse the naming to NOTE_ADDR{NEW,DEL} so that we have the more generic first before the more specific... similar to NOTE_LINK*... Suffice it to say, this cannot be back ported to RELENG_6 due to API breakage... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 18:19:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEAA316A4DF for ; Tue, 25 Jul 2006 18:19:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 279D543D69 for ; Tue, 25 Jul 2006 18:19:22 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so2490645pyb for ; Tue, 25 Jul 2006 11:19:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mkIhTiIszWnTozHPjax7mEBMduO70Os3zgfdtJspME7cajVcKMli8R1hyo5U0mQ8aLcdPyiHhOKi1A5VhSrbZHI67QU/45c1QyGOOX/uo154s2wCcJM7eqnA1Tvz3+iCNohIWbK6KNo/tsyBlW4tusCUOMOZVqhjdpdtyof1bE8= Received: by 10.35.111.14 with SMTP id o14mr627614pym; Tue, 25 Jul 2006 11:19:22 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Tue, 25 Jul 2006 11:19:22 -0700 (PDT) Message-ID: <2a41acea0607251119i33176020pfc4183ecd2251dd2@mail.gmail.com> Date: Tue, 25 Jul 2006 11:19:22 -0700 From: "Jack Vogel" To: "Jeremie Le Hen" In-Reply-To: <20060725124328.GI6253@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <44C1CE73.7030200@FreeBSD.org> <20060725124328.GI6253@obiwan.tataz.chchile.org> Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 18:19:26 -0000 On 7/25/06, Jeremie Le Hen wrote: > On Sat, Jul 22, 2006 at 12:06:27AM -0700, Doug Barton wrote: > > Jeremie Le Hen wrote: > > > Hi, > > > > > > I am running a two month old current (dated from May 24) > > > > SOP with -current is that before you submit a bug report for a system this > > old you should upgrade to the latest world and kernel. Two months is > > _really_ old in -current terms. > > I am rebuilding a fresher one right now. According to Ian's post, > the problem is likely to remain. What do you advice me to do to > track this down ? > > FYI, my -CURRENT kernel (as well userland) is patched with ProPolice. > I don't think this can lead to this kind of problem, the overhead is > really small, in an order of 3 percent. Do you think such an > overhead in a time-critial path could trigger a watchdog timeout ? Well, watchdogs ARE about timeouts :) I know nothing about ProPolice but would suggest removing for a test and see if the problem goes away. As for the debug_info and stats data you sent, there was nothing that looked bad in it, but those are more of a dynamic tool, its when the problem occurs that this will possibly show why.... I know, it doesnt make it easy :( Jack From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 20:58:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AECED16A504 for ; Tue, 25 Jul 2006 20:58:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 295B443D68 for ; Tue, 25 Jul 2006 20:58:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 25 Jul 2006 13:58:43 -0700 Message-ID: <44C68602.50105@elischer.org> Date: Tue, 25 Jul 2006 13:58:42 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com> In-Reply-To: <20060725173924.GR96589@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Fredrik Lindberg , freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 20:58:55 -0000 John-Mark Gurney wrote: >Fredrik Lindberg wrote this message on Tue, Jul 25, 2006 at 14:54 +0200: > > >>I have a suggestion to add support for ip-address changes to the >>kqueue (EVFILT_NETDEV) system. >>The infrastructure for EVFILT_NETDEV is already in place and this >>only introduce NOTE_NEWADDR and NOTE_DELADDR and minor modifications >>to the interface ioctl handler. >> >>The purpose is not to replicate the functionality of the >>routing socket, but to provide a low overhead mechanism for >>monitoring a given interface for address changes. >>No information about the event is sent through the kqueue system, >>instead it will be up to the caller to query the system (if wanted) >>to obtain information about the current state of the interface >>that is being monitored. >> >>I have attached a suggested patch, any thoughts? >> >> I may be wrong but doesn't an address change already trigger a routing socket event? > >Looks basicly good, though you will need to rethink how the filt_netdev >handles the hint.. since right now it just sets kn_data to whatever >hint is.. This is fine when it was simply one of NOTE_LINK{UP,DOWN,INV}, >but now that you have an extra flag, the NOTE_DELADDR could make an >app miss the LINK status if it was looking at data instead of fflags.. > >Plus, are you sure everyone that is using NOTE_LINK* are treating them >as a bit mask? maybe we need to redefine NOTE_LINK* as a mask plus set >of values, since each of the NOTE_LINK* can only be set once... but >the NOTE_ADDR{NEW,DEL} should probably be flags... > >We may want to reverse the naming to NOTE_ADDR{NEW,DEL} so that we have >the more generic first before the more specific... similar to NOTE_LINK*... > >Suffice it to say, this cannot be back ported to RELENG_6 due to API >breakage... > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 21:58:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AA5216A4DD for ; Tue, 25 Jul 2006 21:58:58 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFACF43D46; Tue, 25 Jul 2006 21:58:57 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 357E23BE8F; Tue, 25 Jul 2006 16:58:57 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09083-01-5; Tue, 25 Jul 2006 16:58:57 -0500 (CDT) Received: from [10.12.163.251] (unknown [10.12.163.251]) by mailgate1b.savvis.net (Postfix) with ESMTP id BEE603BE29; Tue, 25 Jul 2006 16:58:56 -0500 (CDT) Message-ID: <44C69416.4090104@savvis.net> Date: Tue, 25 Jul 2006 14:58:46 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060710212815.GA46336@dragon.NUXI.org> <200607102027.18106.jhb@freebsd.org> <20060711181600.GB64759@dragon.NUXI.org> <44B3ECFC.1050806@savvis.net> <44B3F154.7030001@centtech.com> <44B4015D.8050105@savvis.net> In-Reply-To: <44B4015D.8050105@savvis.net> Content-Type: multipart/mixed; boundary="------------070501090004020303040002" X-Virus-Scanned: amavisd-new at savvis.net Cc: brien@freebsd.org Subject: Re: PS/2 keyboard support in mid-boot borked [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 21:58:58 -0000 This is a multi-part message in MIME format. --------------070501090004020303040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hackers, [...] >>> like i said before, i think, the problem is that atkbd(4) does not >>> deal with "polled" mode properly. kbdmux(4) never sees input from >>> atkbd(4) because (imo) atkbd(4) interrupt handler is never called. >>> the atkbd(4) patch i posted awhile ago has a regression, i.e. >>> atkbd(4) produces duplicate characters in ddb(4), midboot, etc. >>> *without* kbdmux(4). patched atkbd(4) with kbdmux(4) works fine. >>> >>> i'm actually a bit puzzled why atkbd(4) works without kbdmux(4) in >>> ddb(4), midboot,e etc. obviously i need to spend some quality time >>> with the debugger :) i hope to get to it, eventually :) sorry for the >>> delay. >> >> What can we do to help you debug it? I know for me, it's a major >> pain, and I'm sure others have gotten jammed up too. > > i just spent half of my lunch hour with the debugger :) and, i think, i > know what is going on here. i think, there is some twisted interaction > going on in > > sccngetch(int flags) > { > ... > kbd_poll(scp->sc->kbd, TRUE); > c = scgetc(scp->sc, SCGETC_CN | flags); > kbd_poll(scp->sc->kbd, FALSE); > ... > } > > and > > sckbdevent() > { > ... > while ((c = scgetc(sc, SCGETC_NONBLOCK)) != NOKEY) { > ... > } > > code that causes duplicated input in atkbd(4) without kbdmux(4). so, my > original patch was not 100% correct. i will try to redo it to see if i > can work around the problem. if you have problems with kbdmux(4) and atkbd(4) NOT working mid-boot, could you please try the attached patch. i decided to add a little hack to kbdmux(4) instead of messing around with atkbd(4). please let me know if it works for you. thanks, max --------------070501090004020303040002 Content-Type: text/plain; name="kbdmux.c.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kbdmux.c.diff.txt" --- kbdmux.c.orig Tue Jul 25 14:50:22 2006 +++ kbdmux.c Tue Jul 25 14:41:47 2006 @@ -657,6 +657,27 @@ /* see if there is something in the keyboard queue */ scancode = getc(&state->ks_inq); if (scancode == -1) { + if (state->ks_flags & POLLING) { + kbdmux_kbd_t *k; + + SLIST_FOREACH(k, &state->ks_kbds, next) { + while (KBDMUX_CHECK_CHAR(k->kbd)) { + scancode = KBDMUX_READ_CHAR(k->kbd, 0); + if (scancode == NOKEY) + break; + if (scancode == ERRKEY) + continue; + if (!KBD_IS_BUSY(k->kbd)) + continue; + + putc(scancode, &state->ks_inq); + } + } + + if (state->ks_inq.c_cc > 0) + goto next_code; + } + KBDMUX_UNLOCK(state); return (NOKEY); } --------------070501090004020303040002-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 23:06:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A068C16A4E5 for ; Tue, 25 Jul 2006 23:06:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C9943D58 for ; Tue, 25 Jul 2006 23:06:53 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 1C4999A9AC; Wed, 26 Jul 2006 01:06:53 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 909A99C9CA; Tue, 25 Jul 2006 23:07:21 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 70093405F; Wed, 26 Jul 2006 01:07:21 +0200 (CEST) Date: Wed, 26 Jul 2006 01:07:21 +0200 From: Jeremie Le Hen To: Jack Vogel Message-ID: <20060725230721.GL6253@obiwan.tataz.chchile.org> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <44C1CE73.7030200@FreeBSD.org> <20060725124328.GI6253@obiwan.tataz.chchile.org> <2a41acea0607251119i33176020pfc4183ecd2251dd2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0607251119i33176020pfc4183ecd2251dd2@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 23:06:54 -0000 Jack, others, On Tue, Jul 25, 2006 at 11:19:22AM -0700, Jack Vogel wrote: > On 7/25/06, Jeremie Le Hen wrote: > >I am rebuilding a fresher one right now. According to Ian's post, > >the problem is likely to remain. What do you advice me to do to > >track this down ? > > > >FYI, my -CURRENT kernel (as well userland) is patched with ProPolice. > >I don't think this can lead to this kind of problem, the overhead is > >really small, in an order of 3 percent. Do you think such an > >overhead in a time-critial path could trigger a watchdog timeout ? > > Well, watchdogs ARE about timeouts :) > > I know nothing about ProPolice but would suggest removing for a test > and see if the problem goes away. As a matter of fact ProPolice protects stack-based buffer overflows by pushing an additional value in the stack during vulnerable functions' prologue and checking it within the epilogue. This is really a matter of a few CPU cycles. Nevertheless, I will try to reproduce the problem as-is and will also recompile my kernel without ProPolice ASAP. > As for the debug_info and stats data you sent, there was nothing that > looked bad in it, but those are more of a dynamic tool, its when the > problem occurs that this will possibly show why.... I know, it doesnt > make it easy :( It would be a pain to do it manually, I will try to write a small script thates watch over dmesg and issues a few sysctl on debug_info whenever it detects a watch dog timeout. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 01:12:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E44216A4DF; Wed, 26 Jul 2006 01:12:29 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA30A43D45; Wed, 26 Jul 2006 01:12:28 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6Q1CQhd040305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 26 Jul 2006 03:12:26 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 26 Jul 2006 03:12:13 +0200 Message-Id: <1153876334.55623.49.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: olli@lurza.secnetix.de Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 01:12:29 -0000 Oliver Fromme wrote: > John Baldwin wrote: > > On Sunday 23 July 2006 20:03, Sten Daniel Sųrsdal wrote: > > > sthaug at nethelp.no wrote: > > > > > > One approach that we could use for 64-bit counters would be to just > > > > > > use 32-bits one, and poll them for overflow and bump an overflow > > > > > > count. This assumes that the 32-bit counters overflow much less often > > > > > > than the polling interval, and easily triples the amount of storage > > > > > > for each of them... It is ugly :-( > > > > > > > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > > > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > > > you want to guarantee 64 bit consistency, you need locking or similar. > > > > > > > > > > Would it not be necessary to do this locking anyway? > > > I don't see how polling for overflow would help this consistency. > > > Are both suggestions insufficient? > > > > I actually think that add + adc is ok for the case of incrementing simple > > counters. You can even do 'inc ; addc $0' > > (I'm familiar with asm programming, but I'm not a low-level > threading or SMP expert, so please excuse me if this is a > dumb question ...) > > If you just do add+adc (or inc+adc) and another thread (on > the same or different processor, I don't know) happens to > read the counter value at the same time (i.e. after the > lower 32bit have overflowed, but before the upper 32bit get > incremented), then that other thread would get a value > that's off by 2^32. > > What am I missing? I don't remember all the details, but when I was proposing (with patches) the change in network counters several years ago, I gave up to the (possibly right) opposition. Probably from BDE, I don't remember. Your explanation of a possible failure scenario is just one example of what can possibly get wrong there. It ('add' instruction followed by 'addc' - or more generally working with 64bit counters on a 32bit architecture - or even more generally working with an integer in a kernel context in multiprocossor environment) can get wrong in more "exotic" ways on architectures without implicitly coherent cache - you can read an old value of something, modify it, and write it back, overwriting much more recent copy or something like it. Even a simple increment may not be fully safe (it is also, in the end, read-modify-write operation, which can be, in theory at least, interrupted in between any two operations). I have not studied enough of it, but it makes sense to me and I believe these were among the reasons why 64 bit counters on 32 bit I386 were rejected at the time. The modifications of the counters may be wrapped into preprocessor macros though. The right implementation of the macro can be 100% correct, but it will add big overhead - e.g. lock instrunction prefix (needed in I386 SMP) takes possibly hundreds of cycles to execute). Therefore, I think that we should either go with per-CPU copies of the counter in whatever size appropriate and have the total be sum of the values (possibly also taking care of overflow) or we should just accept the status quo - use something "natural" for the architecture (e.g. int or long) and hope for the best (a wrong counter normally doesn't cause any problems). It (int or sometimes long) has been good enough for decades. The first way (per-CPU counters) shouldn't be that difficult to do (almost?) correctly either, I just wanted to propose the change with lesser potential for a bikeshed (even possibly fruitful :-)) and higher potential for real change in the sources (and better value of the counters for me - I believe that I won't build any new 32bit system, so long should be long enough for me). I believe I should be able to code both ways (and can easily test I386 and AMD64, but these are not a good architectures AFAIK, as they ensure cache coherency). My patch for network counters wrapped every counter operation in a macro which could have been expanded to different code. Doing the operations absolutely safely was terribly inefficient. Even per-CPU increments aren't probable 100% safe and that was the reason PCPU_LAZY_INC was introduced - so that consumers knew they can't really rely on the counter value. Michal From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 19:20:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA6A616A4DA for ; Tue, 25 Jul 2006 19:20:35 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5125C43D93 for ; Tue, 25 Jul 2006 19:20:24 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 9A37241FC; Tue, 25 Jul 2006 14:20:24 -0500 (CDT) Date: Tue, 25 Jul 2006 14:20:24 -0500 To: Alexander Mogilny Message-ID: <20060725192024.GB21014@soaustin.net> References: <7403d2a30607240213v522b7f21t2e2e0e90dbe6a7c4@mail.gmail.com> <20060724185052.GA3695@soaustin.net> <7403d2a30607250741m30d8fdd8wb0055363f7bb8338@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7403d2a30607250741m30d8fdd8wb0055363f7bb8338@mail.gmail.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Wed, 26 Jul 2006 01:56:40 +0000 Cc: Mark Linimon , freebsd-current@freebsd.org Subject: Re: [patch] Broadcom BCM5751F Gigabit Ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2006 19:20:35 -0000 On Tue, Jul 25, 2006 at 05:41:36PM +0300, Alexander Mogilny wrote: > Should I write pr regarding support of this NIC in RELENG_6 branch? Probably first ask whoever did the commit (via email) whether they plan to MFC it. If they don't respond, a PR would be appropriate. mcl From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 02:22:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A1C016A4DE for ; Wed, 26 Jul 2006 02:22:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D95143D4C for ; Wed, 26 Jul 2006 02:22:18 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so2609397pyb for ; Tue, 25 Jul 2006 19:22:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=qPSNOpAJYkrtKUUn/3Tl4Ay6YlRsUTs9W2E11IqvkU5eAZ048ILUAGEZIg8U+L5b9zThZMwepE3agvEsQeVmylCPM0vBEBCxA1XEwG2/ZBUOffffJWm11oAhQ0lj5ww407ziqJyOlHfd/1yjpOJAvcuABgJeX5Z+D0qS9vN88uE= Received: by 10.35.63.2 with SMTP id q2mr10473914pyk; Tue, 25 Jul 2006 19:22:17 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 19sm1829218nzp.2006.07.25.19.22.15; Tue, 25 Jul 2006 19:22:16 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6Q2MbcJ015501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 11:22:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6Q2MZsM015500; Wed, 26 Jul 2006 11:22:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 26 Jul 2006 11:22:35 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20060726022235.GB14991@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 02:22:19 -0000 On Tue, Jul 25, 2006 at 08:07:04AM +0200, Ian FREISLICH wrote: > Hi > > It seems that placing an em(4) interface into promiscuous mode the > card stops doing hardware offload of 802.1Q tagging, in fact, it > stops tagging entirely if vlanhwtag is enabled on the card. > > With vlanhwtag: > 15:40:48.050645 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 44821, offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.42.167,148.235.231.80,70.180.123.113,201.169.28.232,19.31.18.203,59.148.50.175 > > Without vlanhwtag: > 15:40:57.419522 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 74: vlan 1001, p 0, ethertype IPv4, (tos 0x10, ttl 255, id 44867, offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.42.176,8.148.142.115,171.178.137.11,211.216.40.239,67.124.122.122,253.155.32.152 > > The interface is placed in promiscuous mode by the carp driver. > > em0: flags=8943 mtu 1500 > options=cb > ether 00:04:23:cf:50:00 > media: Ethernet autoselect (1000baseTX ) > status: active > > vlan1001: flags=8943 mtu 1500 > inet 196.30.82.62 netmask 0xfffffff0 broadcast 196.30.82.63 > ether 00:04:23:cf:50:00 > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 1001 parent interface: em0 > > carp1001: flags=49 mtu 1500 > inet 196.30.82.60 netmask 0xfffffff0 > carp: BACKUP vhid 2 advbase 1 advskew 0 > Hardware VLAN tagging was disabled in em(4) when it operates in promiscuous mode and em(4) will insert a VLAN tag in the driver. I think em(4) does very bad thing regarding VLAN when the NIC is operating in promiscuous mode. At present em(4) can prepend a new mbuf to an existing mbuf chain after loading DMA maps. Since the mbuf chain used on loading DMA maps and VLAN tag inserted mbuf chain is not the same chain, it could result in unexpected result. You may work around it by disabling vlanhwtag. Anyway, the hardware VLAN feature is not used at all when the NIC is in promiscuous mode. > I've also noticed that the re(4) driver on the 8169 chip miss-tags > frames when vlanhwtag is enabled. > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 06:36:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2FC616A4E0 for ; Wed, 26 Jul 2006 06:36:41 +0000 (UTC) (envelope-from yar@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD16243D5C; Wed, 26 Jul 2006 06:36:41 +0000 (GMT) (envelope-from yar@FreeBSD.org) Received: from freefall.freebsd.org (yar@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6Q6acNS059896; Wed, 26 Jul 2006 06:36:38 GMT (envelope-from yar@freefall.freebsd.org) Received: (from yar@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6Q6aaOM059895; Wed, 26 Jul 2006 06:36:36 GMT (envelope-from yar) Date: Wed, 26 Jul 2006 06:36:36 +0000 From: Yar Tikhiy To: "Bjoern A. Zeeb" Message-ID: <20060726063636.GA58151@freefall.freebsd.org> References: <44210801.90609@micom.mng.net> <20060322083546.N2181@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060322083546.N2181@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.1i Cc: Ganbold , freebsd-current@freebsd.org Subject: Re: LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 06:36:42 -0000 On Wed, Mar 22, 2006 at 08:38:22AM +0000, Bjoern A. Zeeb wrote: > On Wed, 22 Mar 2006, Ganbold wrote: > > >When booting recent current I get LOR: > > lock order reversal: > 1st 0xc23d5090 inp (divinp) @ sys/netinet/ip_divert.c:327 > 2nd 0xc07f21d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > sys/net/pfil.c:73 > > added this LOR with # 181 to 'the LOR page': > http://sources.zabbadoz.net/freebsd/lor.html#181 FWIW, the LOR still is there. I was seeing it yesterday while fiddling with the ipfw and natd rc.d scripts. lock order reversal: 1st 0xc1a36090 inp (divinp) @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0a11598,c0a119d0,c09be4c4,...) at kdb_backtrace+0x29 witness_checkorder(c0a51918,1,c0922658,49) at witness_checkorder+0x586 _rw_rlock(c0a51918,c0922658,49) at _rw_rlock+0x54 pfil_run_hooks(c0a51900,c7f1bb40,c1692c00,2,0,...) at pfil_run_hooks+0x2c ip_output(c1760a00,0,c7f1bb0c,22,0,...) at ip_output+0x627 div_send(c17fa000,0,c1760a00,c16ed990,0,c166ad80) at div_send+0x208 sosend(c17fa000,c16ed990,c7f1bbe8,c1760a00,0,0,c166ad80) at sosend+0x3e5 kern_sendit(c166ad80,3,c7f1bc64,0,0,0) at kern_sendit+0x108 sendit(c166ad80,3,c7f1bc64,0,bfbdebfc,...) at sendit+0x87 sendto(c166ad80,c7f1bd04) at sendto+0x46 syscall(3b,3b,3b,2,3c,...) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x2813cbc7, esp = 0xbfbdeb2c, ebp = 0xbfbeebd8 --- -- Yar From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 11:30:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B45F716A4E2 for ; Wed, 26 Jul 2006 11:30:01 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE63B43D73 for ; Wed, 26 Jul 2006 11:29:55 +0000 (GMT) (envelope-from daffy@xview.net) Received: from localhost (mail.oav.net [193.218.105.18]) by mail02.oav.net (Postfix) with ESMTP id DDA313F44B for ; Wed, 26 Jul 2006 13:29:54 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail02.oav.net Received: from mail02.oav.net ([193.218.105.18]) by localhost (mail02.oav.net [172.31.1.2]) (amavisd-new, port 10026) with LMTP id SE+1u5qbgOQF for ; Wed, 26 Jul 2006 13:29:54 +0200 (CEST) Received: from [192.168.0.200] (kiwi.oav.net [82.225.248.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail02.oav.net (Postfix) with ESMTP id A9F823F448 for ; Wed, 26 Jul 2006 13:29:53 +0200 (CEST) (envelope-from daffy@xview.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Olivier Warin Date: Wed, 26 Jul 2006 13:29:13 +0200 X-Mailer: Apple Mail (2.752.2) Subject: KTR ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 11:30:01 -0000 Hi, FreeBSD 7.0-CURRENT (LSD_SMP) #0: Sun Jul 16 10:39:02 CEST 2006 daffy@gw:~ %> sysctl debug.ktr -[11:21]- debug.ktr.alq_enable: 1 debug.ktr.alq_file: /tmp/ktr.out debug.ktr.alq_depth: 32768 debug.ktr.alq_failed: 0 debug.ktr.alq_cnt: 0 debug.ktr.alq_max: 0 debug.ktr.clear: 0 debug.ktr.version: 2 debug.ktr.entries: 32768 debug.ktr.compile: 536871424 debug.ktr.mask: 1 debug.ktr.cpumask: -1 /tmp/ktr.out is empty & nothing is printed out on console when alq_enable is set to 0. Is does not work neither with UP nor SMP kernel. What am I missing ? Best regards, -- Olivier Warin From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 11:37:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9299316A4DD for ; Wed, 26 Jul 2006 11:37:24 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 235A943D49 for ; Wed, 26 Jul 2006 11:37:24 +0000 (GMT) (envelope-from daffy@xview.net) Received: from localhost (mail.oav.net [193.218.105.18]) by mail02.oav.net (Postfix) with ESMTP id 3456A3F442 for ; Wed, 26 Jul 2006 13:37:23 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail02.oav.net Received: from mail03.oav.net ([193.218.105.18]) by localhost (mail02.oav.net [172.31.1.2]) (amavisd-new, port 10026) with LMTP id xH2SbEeFaRmr for ; Wed, 26 Jul 2006 13:37:22 +0200 (CEST) Received: from [192.168.0.200] (kiwi.oav.net [82.225.248.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail03.oav.net (Postfix) with ESMTP id B325233C1F for ; Wed, 26 Jul 2006 13:37:22 +0200 (CEST) (envelope-from daffy@xview.net) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8F83C6CB-78B8-4BAE-994A-F1840FBB7FC3@xview.net> Content-Transfer-Encoding: quoted-printable From: Olivier Warin Date: Wed, 26 Jul 2006 13:36:43 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: KTR ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 11:37:24 -0000 Le 26 juil. 06 =E0 13:29, Olivier Warin a =E9crit : > Hi, > > FreeBSD 7.0-CURRENT (LSD_SMP) #0: Sun Jul 16 10:39:02 CEST 2006 > > daffy@gw:~ %> sysctl =20 > debug.ktr -[11:21]- > debug.ktr.alq_enable: 1 > debug.ktr.alq_file: /tmp/ktr.out > debug.ktr.alq_depth: 32768 > debug.ktr.alq_failed: 0 > debug.ktr.alq_cnt: 0 > debug.ktr.alq_max: 0 > debug.ktr.clear: 0 > debug.ktr.version: 2 > debug.ktr.entries: 32768 > debug.ktr.compile: 536871424 > debug.ktr.mask: 1 > debug.ktr.cpumask: -1 > > /tmp/ktr.out is empty & nothing is printed out on console when =20 > alq_enable is set to 0. > Is does not work neither with UP nor SMP kernel. What am I missing ? Sorry for this e-mail, I forgot to set debug.ktr.mask which only log =20 KTR_GEN by default. Now, everything seems to work as expected. -- Olivier Warin From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 16:38:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C53E016A4E1 for ; Wed, 26 Jul 2006 16:38:06 +0000 (UTC) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F94B43D49 for ; Wed, 26 Jul 2006 16:38:05 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 919131A734; Wed, 26 Jul 2006 18:38:03 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67690-03; Wed, 26 Jul 2006 18:38:02 +0200 (CEST) Received: from [192.168.1.91] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 8D2321A6B2; Wed, 26 Jul 2006 18:38:02 +0200 (CEST) Message-ID: <44C79A66.6000204@shapeshifter.se> Date: Wed, 26 Jul 2006 18:37:58 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.2 (X11/20060423) MIME-Version: 1.0 To: gurney_j@resnet.uoregon.edu References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com> In-Reply-To: <20060725173924.GR96589@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 16:38:06 -0000 John-Mark Gurney wrote: > > Looks basicly good, though you will need to rethink how the filt_netdev > handles the hint.. since right now it just sets kn_data to whatever > hint is.. This is fine when it was simply one of NOTE_LINK{UP,DOWN,INV}, > but now that you have an extra flag, the NOTE_DELADDR could make an > app miss the LINK status if it was looking at data instead of fflags.. > > Plus, are you sure everyone that is using NOTE_LINK* are treating them > as a bit mask? maybe we need to redefine NOTE_LINK* as a mask plus set > of values, since each of the NOTE_LINK* can only be set once... but > the NOTE_ADDR{NEW,DEL} should probably be flags... > > We may want to reverse the naming to NOTE_ADDR{NEW,DEL} so that we have > the more generic first before the more specific... similar to NOTE_LINK*... The documented way of using EVFILT_NETDEV according to kqueue(2) is to obtain the status from fflags, but as it apparently sets data too somebody is using it, that's for sure. Users of EVFILT_NETDEV are required to pass a mask of NOTE_LINK{UP,DOWN,INV} in fflags with the initial kevent call, otherwise no events will fire. What if we add NOTE_ADDR{NEW,DEL} as bit masks and change filt_netdev to only set kn_data when a monitored event occurs instead of just setting it regardless of if the event is being monitored or not. If we also restrict the values of kn_data to NOTE_LINK{UP,DOWN,INV}, existing applications shouldn't break as they would only receive the events they subscribed to and both data and fflags would be intact. NOTE_ADDR{NEW,DEL} would be obtain only through fflags and kn_data would be left as it is in these cases (0 with EV_CLEAR set). What I'm thinking of is something like this for filt_netdev if (kn->kn_sfflags & hint) { kn->kn_fflags |= hint; if (hint & (NOTE_LINKUP | NOTE_LINKDOWN | NOTE_LINKINV)) kn->kn_data = hint; /* current link status */ } > > Suffice it to say, this cannot be back ported to RELENG_6 due to API > breakage... > Doing it this way shouldn't break the API, as no fields would be touched because kn_sfflags & hint would fail for ADDR{NEW,DEL} on existing applications as they would only be subscribed to one or more of the NOTE_LINK{UP,DOWN,INV} events. But maybe I'm missing some rare edge case... Fredrik Lindberg From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 16:45:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C92C16A4DF for ; Wed, 26 Jul 2006 16:45:09 +0000 (UTC) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 887FF43D53 for ; Wed, 26 Jul 2006 16:45:04 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 85A5C1A734; Wed, 26 Jul 2006 18:45:03 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65761-10; Wed, 26 Jul 2006 18:45:01 +0200 (CEST) Received: from [192.168.1.91] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 2B7081A6B2; Wed, 26 Jul 2006 18:45:01 +0200 (CEST) Message-ID: <44C79C0B.6060900@shapeshifter.se> Date: Wed, 26 Jul 2006 18:44:59 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.2 (X11/20060423) MIME-Version: 1.0 To: Julian Elischer References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com> <44C68602.50105@elischer.org> In-Reply-To: <44C68602.50105@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: John-Mark Gurney , freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 16:45:09 -0000 Julian Elischer wrote: > > I may be wrong but doesn't an address change already trigger a routing > socket event? > Yes, a routing message is sent on address addition/removal, but the point (as I noted in my first mail) was to avoid the routing socket-read-parse dance and provide a lightweight and direct (the routing socket broadcasts events about all interfaces) mechanism for address addition/removal events. Also, the NOTE_ADDR{NEW,DEL} are sent AFTER interface configuration is complete, at least RTM_DELADDR is broadcasted before the ip-address actually is removed from the interface because it's sent from the routing code and not the interface configuration code. Fredrik Lindberg From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 17:51:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E165516A4E0 for ; Wed, 26 Jul 2006 17:51:01 +0000 (UTC) (envelope-from haro@h4.dion.ne.jp) Received: from smtp1.dcns.ne.jp (smtp1.dcns.ne.jp [203.178.100.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 257C543D4C for ; Wed, 26 Jul 2006 17:51:00 +0000 (GMT) (envelope-from haro@h4.dion.ne.jp) Received: (qmail 16584 invoked from network); 27 Jul 2006 02:50:59 +0900 Received: from unknown (HELO localhost) (211.10.184.118) by smtp1.dcns.ne.jp with SMTP; 27 Jul 2006 02:50:59 +0900 Date: Thu, 27 Jul 2006 02:50:58 +0900 (JST) Message-Id: <20060727.025058.07646261.haro@h4.dion.ne.jp> To: rwatson@FreeBSD.ORG From: Munehiro Matsuda X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Panic with recent uipc changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 17:51:02 -0000 Hi Robert Watson, Recent changes to uipc, the UNIX domain sockets, seems to cause my -current laptop to panic and reboot whenever I stop emacs. Is there anything I can do to help debug this? =-------------------------------------------------------------------------- kdb_backtrace(2,c378569c,c,c3488d80,de34fa10,...) at kdb_backtrace+0x29 witness_warn(5,0,c07208c5) at witness_warn+0x192 trap(c07b0008,28,c06f0028,c357c9dc,c357c914,...) at trap+0x108 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc050fc8e, esp = 0xde34fa58, ebp = 0xde34fa58 --- knlist_mtx_locked(0) at knlist_mtx_locked+0x6 knote(c357c9dc,0,1,c357c9f4,c357c914,...) at knote+0x1d sowakeup(c357c914,c357c9d0) at sowakeup+0x61 soisdisconnected(c357c914,c357c9f4,c357c914,0,de34fad4,...) at soisdisconnected+0xdc uipc_detach(c357c914) at uipc_detach+0xe3 sofree(c357c914) at sofree+0x27b soclose(c357c914) at soclose+0x2d9 soo_close(c359eb88,c3488d80) at soo_close+0x4b fdrop_locked(c359eb88,c3488d80,c2dfa220,0,c06f91cb,...) at fdrop_locked+0x88 fdrop(c359eb88,c3488d80,6b5,c0777974,0,...) at fdrop+0x24 closef(c359eb88,c3488d80) at closef+0x367 fdfree(c3488d80) at fdfree+0x4a3 exit1(c3488d80,0,de34fd30,c06b8cea,c3488d80,...) at exit1+0x420 exit1(c3488d80,de34fd04) at exit1 syscall(58de003b,827003b,bfbf003b,bfbfdce0,bfbfdce0,...) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x284da41b, esp = 0xbfbfdc7c, ebp = 0xbfbfdc98 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc050fc8e stack pointer = 0x28:0xde34fa58 frame pointer = 0x28:0xde34fa58 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 = 39065 (emacs) trap number = 12 panic: page fault cpuid = 0 KDB: enter: panic =-------------------------------------------------------------------------- Thanks in advance, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: haro@kgt.co.jp From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 18:13:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B08B16A4DD for ; Wed, 26 Jul 2006 18:13:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E3D543D4C for ; Wed, 26 Jul 2006 18:13:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0386946CAD; Wed, 26 Jul 2006 14:13:35 -0400 (EDT) Date: Wed, 26 Jul 2006 19:13:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Munehiro Matsuda In-Reply-To: <20060727.025058.07646261.haro@h4.dion.ne.jp> Message-ID: <20060726191125.T56364@fledge.watson.org> References: <20060727.025058.07646261.haro@h4.dion.ne.jp> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1770554632-1153937614=:56364" Cc: freebsd-current@freebsd.org Subject: Re: Panic with recent uipc changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 18:13:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1770554632-1153937614=:56364 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 27 Jul 2006, Munehiro Matsuda wrote: > Hi Robert Watson, > > Recent changes to uipc, the UNIX domain sockets, seems to cause my -current > laptop to panic and reboot whenever I stop emacs. > > Is there anything I can do to help debug this? I think that the information you attached is sufficient. Could you try removing the call to soisdisconnected() in uipc_detach()? It should now occur in the close path. Patch attached. Robert N M Watson Computer Laboratory University of Cambridge > > =-------------------------------------------------------------------------- > kdb_backtrace(2,c378569c,c,c3488d80,de34fa10,...) at kdb_backtrace+0x29 > witness_warn(5,0,c07208c5) at witness_warn+0x192 > trap(c07b0008,28,c06f0028,c357c9dc,c357c914,...) at trap+0x108 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc050fc8e, esp = 0xde34fa58, ebp = 0xde34fa58 --- > knlist_mtx_locked(0) at knlist_mtx_locked+0x6 > knote(c357c9dc,0,1,c357c9f4,c357c914,...) at knote+0x1d > sowakeup(c357c914,c357c9d0) at sowakeup+0x61 > soisdisconnected(c357c914,c357c9f4,c357c914,0,de34fad4,...) at soisdisconnected+0xdc > uipc_detach(c357c914) at uipc_detach+0xe3 > sofree(c357c914) at sofree+0x27b > soclose(c357c914) at soclose+0x2d9 > soo_close(c359eb88,c3488d80) at soo_close+0x4b > fdrop_locked(c359eb88,c3488d80,c2dfa220,0,c06f91cb,...) at fdrop_locked+0x88 > fdrop(c359eb88,c3488d80,6b5,c0777974,0,...) at fdrop+0x24 > closef(c359eb88,c3488d80) at closef+0x367 > fdfree(c3488d80) at fdfree+0x4a3 > exit1(c3488d80,0,de34fd30,c06b8cea,c3488d80,...) at exit1+0x420 > exit1(c3488d80,de34fd04) at exit1 > syscall(58de003b,827003b,bfbf003b,bfbfdce0,bfbfdce0,...) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x284da41b, esp = 0xbfbfdc7c, ebp = 0xbfbfdc98 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc050fc8e > stack pointer = 0x28:0xde34fa58 > frame pointer = 0x28:0xde34fa58 > 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 = 39065 (emacs) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: enter: panic > =-------------------------------------------------------------------------- > > > Thanks in advance, > Haro > =------------------------------------------------------------------------------ > _ _ Munehiro (haro) Matsuda > -|- /_\ |_|_| Internet Solution Dept., KGT Inc. > /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan > Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 > Email: haro@kgt.co.jp > --0-1770554632-1153937614=:56364 Content-Type: TEXT/plain; charset=US-ASCII; name=20060726-uipc_detach.diff Content-Transfer-Encoding: BASE64 Content-ID: <20060726191334.D56364@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=20060726-uipc_detach.diff SW5kZXg6IHVpcGNfdXNycmVxLmMNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMva2Vy bi91aXBjX3VzcnJlcS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xODEN CmRpZmYgLXUgLXIxLjE4MSB1aXBjX3VzcnJlcS5jDQotLS0gdWlwY191c3Jy ZXEuYwkyNCBKdWwgMjAwNiAxNToyMDowNyAtMDAwMAkxLjE4MQ0KKysrIHVp cGNfdXNycmVxLmMJMjYgSnVsIDIwMDYgMTg6MTE6MjIgLTAwMDANCkBAIC00 NDMsNyArNDQzLDYgQEANCiAJCXN0cnVjdCB1bnBjYiAqcmVmID0gTElTVF9G SVJTVCgmdW5wLT51bnBfcmVmcyk7DQogCQl1bnBfZHJvcChyZWYsIEVDT05O UkVTRVQpOw0KIAl9DQotCXNvaXNkaXNjb25uZWN0ZWQodW5wLT51bnBfc29j a2V0KTsNCiAJdW5wLT51bnBfc29ja2V0LT5zb19wY2IgPSBOVUxMOw0KIAls b2NhbF91bnBfcmlnaHRzID0gdW5wX3JpZ2h0czsNCiAJVU5QX1VOTE9DSygp Ow0K --0-1770554632-1153937614=:56364-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 18:46:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1CD116A4E7 for ; Wed, 26 Jul 2006 18:46:41 +0000 (UTC) (envelope-from haro@h4.dion.ne.jp) Received: from smtp1.dcns.ne.jp (smtp1.dcns.ne.jp [203.178.100.134]) by mx1.FreeBSD.org (Postfix) with SMTP id BB20643D46 for ; Wed, 26 Jul 2006 18:46:40 +0000 (GMT) (envelope-from haro@h4.dion.ne.jp) Received: (qmail 23399 invoked from network); 27 Jul 2006 03:46:39 +0900 Received: from unknown (HELO localhost) (211.10.184.118) by smtp1.dcns.ne.jp with SMTP; 27 Jul 2006 03:46:39 +0900 Date: Thu, 27 Jul 2006 03:46:38 +0900 (JST) Message-Id: <20060727.034638.74756333.haro@h4.dion.ne.jp> To: rwatson@FreeBSD.org From: Munehiro Matsuda In-Reply-To: <20060726191125.T56364@fledge.watson.org> References: <20060727.025058.07646261.haro@h4.dion.ne.jp> <20060726191125.T56364@fledge.watson.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Panic with recent uipc changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2006 18:46:42 -0000 Hi Robert Watson, From: Robert Watson Date: Wed, 26 Jul 2006 19:13:34 +0100 (BST) :: ::On Thu, 27 Jul 2006, Munehiro Matsuda wrote: :: ::> Hi Robert Watson, ::> ::> Recent changes to uipc, the UNIX domain sockets, seems to cause my -current ::> laptop to panic and reboot whenever I stop emacs. ::> ::> Is there anything I can do to help debug this? :: ::I think that the information you attached is sufficient. Could you try ::removing the call to soisdisconnected() in uipc_detach()? It should now occur ::in the close path. Patch attached. Thank you for your very quick reply. The patch worked. ::Robert N M Watson ::Computer Laboratory ::University of Cambridge Thank you, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 :: ::> ::> =-------------------------------------------------------------------------- ::> kdb_backtrace(2,c378569c,c,c3488d80,de34fa10,...) at kdb_backtrace+0x29 ::> witness_warn(5,0,c07208c5) at witness_warn+0x192 ::> trap(c07b0008,28,c06f0028,c357c9dc,c357c914,...) at trap+0x108 ::> calltrap() at calltrap+0x5 ::> --- trap 0xc, eip = 0xc050fc8e, esp = 0xde34fa58, ebp = 0xde34fa58 --- ::> knlist_mtx_locked(0) at knlist_mtx_locked+0x6 ::> knote(c357c9dc,0,1,c357c9f4,c357c914,...) at knote+0x1d ::> sowakeup(c357c914,c357c9d0) at sowakeup+0x61 ::> soisdisconnected(c357c914,c357c9f4,c357c914,0,de34fad4,...) at soisdisconnected+0xdc ::> uipc_detach(c357c914) at uipc_detach+0xe3 ::> sofree(c357c914) at sofree+0x27b ::> soclose(c357c914) at soclose+0x2d9 ::> soo_close(c359eb88,c3488d80) at soo_close+0x4b ::> fdrop_locked(c359eb88,c3488d80,c2dfa220,0,c06f91cb,...) at fdrop_locked+0x88 ::> fdrop(c359eb88,c3488d80,6b5,c0777974,0,...) at fdrop+0x24 ::> closef(c359eb88,c3488d80) at closef+0x367 ::> fdfree(c3488d80) at fdfree+0x4a3 ::> exit1(c3488d80,0,de34fd30,c06b8cea,c3488d80,...) at exit1+0x420 ::> exit1(c3488d80,de34fd04) at exit1 ::> syscall(58de003b,827003b,bfbf003b,bfbfdce0,bfbfdce0,...) at syscall+0x27e ::> Xint0x80_syscall() at Xint0x80_syscall+0x1f ::> --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x284da41b, esp = 0xbfbfdc7c, ebp = 0xbfbfdc98 --- ::> ::> ::> Fatal trap 12: page fault while in kernel mode ::> cpuid = 0; apic id = 00 ::> fault virtual address = 0x10 ::> fault code = supervisor read, page not present ::> instruction pointer = 0x20:0xc050fc8e ::> stack pointer = 0x28:0xde34fa58 ::> frame pointer = 0x28:0xde34fa58 ::> 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 = 39065 (emacs) ::> trap number = 12 ::> panic: page fault ::> cpuid = 0 ::> KDB: enter: panic ::> =-------------------------------------------------------------------------- ::> ::> ::> Thanks in advance, ::> Haro ::> =------------------------------------------------------------------------------ ::> _ _ Munehiro (haro) Matsuda ::> -|- /_\ |_|_| Internet Solution Dept., KGT Inc. ::> /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan ::> Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 00:52:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C4116A4DD for ; Thu, 27 Jul 2006 00:52:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2E5443D49 for ; Thu, 27 Jul 2006 00:52:57 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id c63so20847pyc for ; Wed, 26 Jul 2006 17:52:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=FVlfTwtbn8Hm8mAcIaUtgauy3zw3xdQGwzIBFTa0qrYZB5Y67NQN3TS0t7ZVHvv9CCAVgvVojlag12HqEeubR0r7iCMbgfYKhXX3Z/wkU/+ygSTspRQ9BREzLrU6WBpFNpIIwzZQxwM3gFsSgDaGetEfPm1dS+y6GRwVWn0H7Gk= Received: by 10.35.61.14 with SMTP id o14mr12186316pyk; Wed, 26 Jul 2006 17:52:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 38sm2215763nzk.2006.07.26.17.52.54; Wed, 26 Jul 2006 17:52:56 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6R0rSIv019787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 09:53:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6R0rR5B019786; Thu, 27 Jul 2006 09:53:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 27 Jul 2006 09:53:27 +0900 From: Pyun YongHyeon To: Jeremie Le Hen Message-ID: <20060727005326.GA19286@cdnetworks.co.kr> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <2a41acea0607210927s108d1326qdad02b7d29376a09@mail.gmail.com> <20060725123603.GH6253@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060725123603.GH6253@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Jack Vogel Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 00:52:58 -0000 On Tue, Jul 25, 2006 at 02:36:03PM +0200, Jeremie Le Hen wrote: > On Fri, Jul 21, 2006 at 09:27:31AM -0700, Jack Vogel wrote: > > hitting watchdog means you have a hang of some sort. > > try 'sysctl dev.em.0.debug_info=1' and see if that gives any clues. > > dev.em.0.debug_info: > % em0: Adapter hardware address = 0xc2a32130 > % em0: CTRL = 0x18f00241 RCTL = 0x801a > % em0: Packet buffer = Tx=16k Rx=48k > % em0: Flow control watermarks high = 47104 low = 45604 > % em0: tx_int_delay = 66, tx_abs_int_delay = 66 > % em0: rx_int_delay = 0, rx_abs_int_delay = 66 > % em0: fifo workaround = 0, fifo_reset_count = 0 > % em0: hw tdh = 149, hw tdt = 149 > % em0: Num Tx descriptors avail = 256 > % em0: Tx Descriptors not avail1 = 0 > % em0: Tx Descriptors not avail2 = 0 > % em0: Std mbuf failed = 0 > % em0: Std mbuf cluster failed = 0 > % em0: Driver dropped packets = 0 > > dev.em.0.stats: > % em0: Excessive collisions = 0 > % em0: Symbol errors = 0 > % em0: Sequence errors = 0 > % em0: Defer count = 0 > % em0: Missed Packets = 0 > % em0: Receive No Buffers = 0 > % em0: Receive length errors = 0 > % em0: Receive errors = 0 > % em0: Crc errors = 0 > % em0: Alignment errors = 0 > % em0: Carrier extension errors = 0 > % em0: RX overruns = 0 > % em0: watchdog timeouts = 6 > % em0: XON Rcvd = 0 > % em0: XON Xmtd = 0 > % em0: XOFF Rcvd = 0 > % em0: XOFF Xmtd = 0 > % em0: Good Packets Rcvd = 3720143 > % em0: Good Packets Xmtd = 1246413 > > Most of provided debugging informations are meaningless for me. > Is any minded soul able to understand this ? > I think the debug_info is useless as it's the output after hardware reset. Would you try latest em(4) in CURRENT? I've fixed a DMA related bug. Not sure it helps. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 06:07:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2855116A4DA; Thu, 27 Jul 2006 06:07:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B08D343D53; Thu, 27 Jul 2006 06:07:25 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6R67NBA066370; Thu, 27 Jul 2006 02:07:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k6R67OUN003414; Thu, 27 Jul 2006 02:07:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8112E7302F; Thu, 27 Jul 2006 02:07:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060727060724.8112E7302F@freebsd-current.sentex.ca> Date: Thu, 27 Jul 2006 02:07:24 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 06:07:26 -0000 TB --- 2006-07-27 04:11:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-27 04:11:46 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-07-27 04:11:46 - cleaning the object tree TB --- 2006-07-27 04:12:24 - checking out the source tree TB --- 2006-07-27 04:12:24 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-07-27 04:12:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-07-27 04:20:06 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-27 04:20:06 - cd /src TB --- 2006-07-27 04:20:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-07-27 05:55:38 - generating LINT kernel config TB --- 2006-07-27 05:55:38 - cd /src/sys/amd64/conf TB --- 2006-07-27 05:55:38 - /usr/bin/make -B LINT TB --- 2006-07-27 05:55:38 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-07-27 05:55:38 - cd /src TB --- 2006-07-27 05:55:38 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 27 05:55:39 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_cisco.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_device.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_echo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_eiface.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_ether.c In file included from /src/sys/netgraph/ng_ether.c:64: /src/sys/net/if_bridgevar.h:203: error: field `bif_stp' has incomplete type /src/sys/net/if_bridgevar.h:239: error: field `sc_stp' has incomplete type *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-27 06:07:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-27 06:07:24 - ERROR: failed to build lint kernel TB --- 2006-07-27 06:07:24 - tinderbox aborted TB --- 1.31 user 7.29 system 6937.58 real From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 07:40:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7C8E16A4DD; Thu, 27 Jul 2006 07:40:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B8343D46; Thu, 27 Jul 2006 07:40:15 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6R7eDv4069204; Thu, 27 Jul 2006 03:40:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k6R7eEjI094443; Thu, 27 Jul 2006 03:40:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6807D7302F; Thu, 27 Jul 2006 03:40:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060727074014.6807D7302F@freebsd-current.sentex.ca> Date: Thu, 27 Jul 2006 03:40:14 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 07:40:16 -0000 TB --- 2006-07-27 06:07:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-27 06:07:24 - starting HEAD tinderbox run for i386/i386 TB --- 2006-07-27 06:07:24 - cleaning the object tree TB --- 2006-07-27 06:07:55 - checking out the source tree TB --- 2006-07-27 06:07:55 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-07-27 06:07:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-07-27 06:15:06 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-27 06:15:06 - cd /src TB --- 2006-07-27 06:15:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-07-27 07:27:51 - generating LINT kernel config TB --- 2006-07-27 07:27:51 - cd /src/sys/i386/conf TB --- 2006-07-27 07:27:51 - /usr/bin/make -B LINT TB --- 2006-07-27 07:27:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-07-27 07:27:51 - cd /src TB --- 2006-07-27 07:27:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 27 07:27:51 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_cisco.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_device.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_echo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_eiface.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/netgraph/ng_ether.c In file included from /src/sys/netgraph/ng_ether.c:64: /src/sys/net/if_bridgevar.h:203: error: field `bif_stp' has incomplete type /src/sys/net/if_bridgevar.h:239: error: field `sc_stp' has incomplete type *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-27 07:40:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-27 07:40:14 - ERROR: failed to build lint kernel TB --- 2006-07-27 07:40:14 - tinderbox aborted TB --- 1.19 user 5.92 system 5569.72 real From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 11:56:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AF7816A4F0 for ; Thu, 27 Jul 2006 11:56:52 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F25143D4C for ; Thu, 27 Jul 2006 11:56:50 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 837B8262AF; Thu, 27 Jul 2006 13:56:49 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 2847B9B589; Thu, 27 Jul 2006 11:57:28 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 0F7E5405A; Thu, 27 Jul 2006 13:57:28 +0200 (CEST) Date: Thu, 27 Jul 2006 13:57:27 +0200 From: Jeremie Le Hen To: Pyun YongHyeon Message-ID: <20060727115727.GD1458@obiwan.tataz.chchile.org> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <2a41acea0607210927s108d1326qdad02b7d29376a09@mail.gmail.com> <20060725123603.GH6253@obiwan.tataz.chchile.org> <20060727005326.GA19286@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060727005326.GA19286@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Jeremie Le Hen , Jack Vogel Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 11:56:52 -0000 Hi Pyun, On Thu, Jul 27, 2006 at 09:53:27AM +0900, Pyun YongHyeon wrote: > I think the debug_info is useless as it's the output after > hardware reset. Would you try latest em(4) in CURRENT? > I've fixed a DMA related bug. Not sure it helps. I am now running with a very recent -CURRENT from 2006.07.22.08.00.00, is it enough ? From CVSweb, it seems the lastest change dates from 2006.07.20, if_em.h rev 1.45. My box has been running for nearly two days, and I saw no em(4) watchdog timeout so far. I am going to run some heavy computanional workload this afternoon, trying to trigger it. Note that I have switched to davidxu's SCHED_CORE during my latest upgrade, it may hide the bug. If I can't trigger any watchdog timeout with it, I will back to SCHED_4BSD. Thank you for your work. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 12:07:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA5E016A4DA for ; Thu, 27 Jul 2006 12:07:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE74843D49 for ; Thu, 27 Jul 2006 12:07:32 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id m22so81457nzf for ; Thu, 27 Jul 2006 05:07:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ldHVgfS+91VewSsnfGiYxdhDiPIS4ewQR43GlQAQaD15J3CvLjiLlmuqL7K27x7mhjnQdj0gOf71TsOIWiFvPIpHCsqMEiaQSaN3g8mEmSiSesRIbh239BqGyEwAYuIlRz6WQvtBxNA/uNZFJ6Gouf7ymMshO6L9EToeiZqzpbA= Received: by 10.64.27.1 with SMTP id a1mr663718qba; Thu, 27 Jul 2006 05:07:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 5sm742162nzk.2006.07.27.05.07.28; Thu, 27 Jul 2006 05:07:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6RC88kg021698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 21:08:09 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6RC87dN021697; Thu, 27 Jul 2006 21:08:07 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 27 Jul 2006 21:08:07 +0900 From: Pyun YongHyeon To: Jeremie Le Hen Message-ID: <20060727120807.GB19286@cdnetworks.co.kr> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <2a41acea0607210927s108d1326qdad02b7d29376a09@mail.gmail.com> <20060725123603.GH6253@obiwan.tataz.chchile.org> <20060727005326.GA19286@cdnetworks.co.kr> <20060727115727.GD1458@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060727115727.GD1458@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Jack Vogel Subject: Re: [fbsd] Re: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 12:07:40 -0000 On Thu, Jul 27, 2006 at 01:57:27PM +0200, Jeremie Le Hen wrote: > Hi Pyun, > > On Thu, Jul 27, 2006 at 09:53:27AM +0900, Pyun YongHyeon wrote: > > I think the debug_info is useless as it's the output after > > hardware reset. Would you try latest em(4) in CURRENT? > > I've fixed a DMA related bug. Not sure it helps. > > I am now running with a very recent -CURRENT from 2006.07.22.08.00.00, > is it enough ? From CVSweb, it seems the lastest change dates from > 2006.07.20, if_em.h rev 1.45. > You need if_em.c rev 1.120 or higher to verify it. > My box has been running for nearly two days, and I saw no em(4) watchdog > timeout so far. I am going to run some heavy computanional workload > this afternoon, trying to trigger it. Note that I have switched to > davidxu's SCHED_CORE during my latest upgrade, it may hide the bug. > If I can't trigger any watchdog timeout with it, I will back to > SCHED_4BSD. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 13:13:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9291916A4E1; Thu, 27 Jul 2006 13:13:56 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA6A143D49; Thu, 27 Jul 2006 13:13:54 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6RDDkuq081433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jul 2006 15:13:46 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6RDDiEM081430; Thu, 27 Jul 2006 15:13:44 +0200 (CEST) Date: Thu, 27 Jul 2006 15:13:44 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20060727131344.GA81122@stud.fit.vutbr.cz> References: <44C39D7E.30102@mail.web.am> <200607241720.36606.jhb@freebsd.org> <20060725101729.GA13468@stud.fit.vutbr.cz> <200607251230.39953.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607251230.39953.jhb@freebsd.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 13:13:56 -0000 > > this thursday at work I'll try to provide some more info, what exaclty do you > > need? is what -DDEBUG prints enough? > > Probably. The changes in question were just in the linux semctl function, so you > really only need printf's for that function to figure out which case it is blowing > up one and why. soooo.... I checked the coredump and found this: 1) its not acroread what coredumps but bash binary (the binary used for the script) when I manually tried running the bash and "exec /bin/ls" etc. it worked I havent investigated further waht causes the coredump 2) I put printf() at the very begining of the linux_semctl() function and ran the acroread binary. The printf was not printed (ie. it didnt used the linxu_semctl function) 3) here is a outpuit od -DDEBUG compiled linuxolator and running of acroread (the first 3 lines are output of command line, it might be interesting to see the VA = 0x0) www.stud.fit.vutbr.cz/~xdivac02/linuxamd64 if you needed anything else tell me.. I am going to work this monday again roman From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 13:16:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8E3316A4E7 for ; Thu, 27 Jul 2006 13:16:47 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7ADE43D6B for ; Thu, 27 Jul 2006 13:16:46 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k6RDGiF9004238 for ; Thu, 27 Jul 2006 17:16:44 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k6RDGits004233 for current@freebsd.org; Thu, 27 Jul 2006 17:16:44 +0400 (MSD) (envelope-from yar) Date: Thu, 27 Jul 2006 17:16:43 +0400 From: Yar Tikhiy To: current@freebsd.org Message-ID: <20060727131643.GA3298@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: JFYI: NO_MAN and X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 13:16:47 -0000 Hi folks, This doesn't seem documented, so I'd like to tell what I found. (Any ideas where to document this?) NO_MAN is handled by now, which has a consequence. If a Makefile sets NO_MAN and includes , it should do the former before the latter; NO_MAN would have no effect otherwise. E.g.: # $FreeBSD$ PROG= mumble NO_MAN= .include .if ${MK_FOO_SUPPORT} != "no" CFLAGS+= -DFOO .endif .include -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 15:06:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBBF516A4DE for ; Thu, 27 Jul 2006 15:06:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA69F43D49 for ; Thu, 27 Jul 2006 15:06:21 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6RF6H4t077661; Thu, 27 Jul 2006 11:06:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 27 Jul 2006 10:58:12 -0400 User-Agent: KMail/1.9.1 References: <200607251254.k6PCsBef092737@lurza.secnetix.de> In-Reply-To: <200607251254.k6PCsBef092737@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607271058.13055.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 27 Jul 2006 11:06:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1623/Wed Jul 26 18:35:11 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Oliver Fromme Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:06:23 -0000 On Tuesday 25 July 2006 08:54, Oliver Fromme wrote: > John Baldwin wrote: > > On Sunday 23 July 2006 20:03, Sten Daniel S=F8rsdal wrote: > > > sthaug@nethelp.no wrote: > > > > > > One approach that we could use for 64-bit counters would be to= =20 just > > > > > > use 32-bits one, and poll them for overflow and bump an overfl= ow > > > > > > count. This assumes that the 32-bit counters overflow much le= ss=20 often > > > > > > than the polling interval, and easily triples the amount of=20 storage > > > > > > for each of them... It is ugly :-( > > > > > >=20 > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > >=20 > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > > > you want to guarantee 64 bit consistency, you need locking or=20 similar. > > > >=20 > > >=20 > > > Would it not be necessary to do this locking anyway? > > > I don't see how polling for overflow would help this consistency. > > > Are both suggestions insufficient? > >=20 > > I actually think that add + adc is ok for the case of incrementing sim= ple=20 > > counters. You can even do 'inc ; addc $0' >=20 > (I'm familiar with asm programming, but I'm not a low-level > threading or SMP expert, so please excuse me if this is a > dumb question ...) >=20 > If you just do add+adc (or inc+adc) and another thread (on > the same or different processor, I don't know) happens to > read the counter value at the same time (i.e. after the > lower 32bit have overflowed, but before the upper 32bit get > incremented), then that other thread would get a value > that's off by 2^32. >=20 > What am I missing? That these counters are for stats. :) You always have a race when reading = the=20 amount, so you can choose what is "good enough" to satisfy the conflicting= =20 requirements of "cheap" and "accurate". To me, the cheapness of add+adc=20 (compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you= =20 have this rare race. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 15:10:53 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31AE316A601 for ; Thu, 27 Jul 2006 15:10:53 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id F13F343D4C for ; Thu, 27 Jul 2006 15:10:51 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mzebix@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6RFAiGV038977 for ; Thu, 27 Jul 2006 17:10:49 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6RFAik6038976; Thu, 27 Jul 2006 17:10:44 +0200 (CEST) (envelope-from olli) Date: Thu, 27 Jul 2006 17:10:44 +0200 (CEST) Message-Id: <200607271510.k6RFAik6038976@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <1153876334.55623.49.camel@genius.i.cz> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 27 Jul 2006 17:10:49 +0200 (CEST) X-Mailman-Approved-At: Thu, 27 Jul 2006 15:51:09 +0000 Cc: Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:10:53 -0000 Michal Mertl wrote: > Even a simple increment may not be fully safe (it is also, in the end, > read-modify-write operation, which can be, in theory at least, > interrupted in between any two operations). I have not studied enough > of it, but it makes sense to me and I believe these were among the > reasons why 64 bit counters on 32 bit I386 were rejected at the time. > > The modifications of the counters may be wrapped into preprocessor > macros though. The right implementation of the macro can be 100% > correct, but it will add big overhead - e.g. lock instrunction prefix > (needed in I386 SMP) takes possibly hundreds of cycles to execute). Yes. I've had a look at the IPFW and PF code (both have 64bit counetrs for packets and bytes). They use mtx_lock for locking -- not just for the counter access, but for large parts of their packet-processing code. > Therefore, I think that we should either go with per-CPU copies of the > counter in whatever size appropriate and have the total be sum of the > values (possibly also taking care of overflow) Sounds fine. > or we should just accept > the status quo - use something "natural" for the architecture (e.g. int > or long) and hope for the best (a wrong counter normally doesn't cause > any problems). Well, it causes PRs once in a while, because people notice the wrong values. It can make debugging more difficult. It makes the counters pretty much useless, because you can't trust their values ... You could just as well remove the counters completely, especially those that are incremented quickly and overflow soon. > It (int or sometimes long) has been good enough for decades. "Has been good enough for decades" doesn't mean that it is still good enough. You have to take into account that the data width of the i386 architecture (i.e. 32bit) hasn't changed in the past 20 years, while the computing power, throughput of memory and disks, bandwidth of networking etc. have increased by several orders of magnitude. That means that statistics counters are incremented much faster, overflowing a 32 bit value in shorter time. So the problem becomes more and more serious. Of course, one possible way to "solve" the problem is to just sit there and wait until 64bit architectures are main- stream, and i386 almost non-existent. But how long will that take? I think even in 10 years from now, 32bit CPUs will still play an important role, for example in embedded environments, for small / mobile applications etc. You don't need 64bit for everything. (Even today, some 16bit processors are in use for special purposes. They don't run BSD, though.) I have just recently bought a new laptop with 32bit CPU, and I don't intend to replace it anytime soon (my previous laptop was in use for 5 years). The root server that I rented privately has a 32bit processor. All workstations and the office server at the company I work at are 32bit. Most servers of our customers are 32bit. Even many of those that _are_ 64bit run only a 32bit OS (for various reasons). Oh by the way, do you think that even 64bit counters are sufficient for the foreseeable future? For example, a 64bit counter for 10GB-Ethernet can overflow in 58 years, which sounds sufficient ... But keep in mind that 10GB will not be the end of the road. Maybe in 5 years, some fat boxes at large ISPs will do 1 Tbit/s. Then the 64bit counter can overflow in 7 months. A 32bit counter will last only 0.004 seconds in that case. :-) Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. PI: int f[9814],b,c=9814,g,i;long a=1e4,d,e,h; main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a) while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;} From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 18:15:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 491DA16A55D for ; Thu, 27 Jul 2006 18:15:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id D405A43D69 for ; Thu, 27 Jul 2006 18:15:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6RIFP31078798; Thu, 27 Jul 2006 14:15:27 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Divacky Roman Date: Thu, 27 Jul 2006 13:57:36 -0400 User-Agent: KMail/1.9.1 References: <44C39D7E.30102@mail.web.am> <200607251230.39953.jhb@freebsd.org> <20060727131344.GA81122@stud.fit.vutbr.cz> In-Reply-To: <20060727131344.GA81122@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607271357.36839.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 27 Jul 2006 14:15:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1623/Wed Jul 26 18:35:11 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:15:46 -0000 On Thursday 27 July 2006 09:13, Divacky Roman wrote: > > > this thursday at work I'll try to provide some more info, what exaclty do you > > > need? is what -DDEBUG prints enough? > > > > Probably. The changes in question were just in the linux semctl function, so you > > really only need printf's for that function to figure out which case it is blowing > > up one and why. > > soooo.... > > I checked the coredump and found this: > > 1) its not acroread what coredumps but bash binary (the binary used for the > script) > when I manually tried running the bash and "exec /bin/ls" etc. it worked > I havent investigated further waht causes the coredump > > 2) I put printf() at the very begining of the linux_semctl() function and > ran the acroread binary. The printf was not printed (ie. it didnt used the > linxu_semctl function) That's odd, because the person who did the binary test claimed it was just the change to this file that caused the breakage. That is, if they reverted linux_ipc.c to the revision before the kern_semctl() changes it worked fine. Can you test that to see if that's true for you? (You'll have to revert last revision of linux_util.h as well.) > 3) here is a outpuit od -DDEBUG compiled linuxolator and running of acroread > (the first 3 lines are output of command line, it might be interesting to see > the VA = 0x0) > > www.stud.fit.vutbr.cz/~xdivac02/linuxamd64 Unfortunately I really can't see what is failing. Perhaps if you could capture the output from starting acroread on a working system so we can see where the output starts to change that would help. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 21:23:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F8216A4DA for ; Thu, 27 Jul 2006 21:23:39 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3890F43D46 for ; Thu, 27 Jul 2006 21:23:39 +0000 (GMT) (envelope-from daffy@xview.net) Received: from localhost (mail.oav.net [193.218.105.18]) by mail01.oav.net (Postfix) with ESMTP id 2B3CC3F41E for ; Thu, 27 Jul 2006 23:23:38 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail01.oav.net Received: from mail03.oav.net ([193.218.105.18]) by localhost (mail01.oav.net [172.31.1.1]) (amavisd-new, port 10026) with LMTP id N9Zd0MsK32PN for ; Thu, 27 Jul 2006 23:23:37 +0200 (CEST) Received: from [192.168.0.3] (bne75-1-81-57-236-141.fbx.proxad.net [81.57.236.141]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail03.oav.net (Postfix) with ESMTP id A9A9033C1E for ; Thu, 27 Jul 2006 23:23:37 +0200 (CEST) (envelope-from daffy@xview.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <05BA8FC7-820D-44FB-B0F9-940AA8BCBDA4@xview.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Olivier Warin Date: Thu, 27 Jul 2006 23:22:56 +0200 X-Mailer: Apple Mail (2.752.2) Subject: KTR_SCHED broken ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 21:23:39 -0000 Hi, root@gw:~/RTBench-0.1/results #> sysctl debug.ktr debug.ktr.alq_enable: 1 debug.ktr.alq_file: /tmp/ktr.out debug.ktr.alq_depth: 32768 debug.ktr.alq_failed: 0 debug.ktr.alq_cnt: 0 debug.ktr.alq_max: 0 debug.ktr.clear: 0 debug.ktr.version: 2 debug.ktr.entries: 32768 debug.ktr.compile: 536870912 debug.ktr.mask: 536870912 debug.ktr.cpumask: -1 daffy@gw:~ %> ll /tmp/ktr.out -rw------- 1 root wheel 0B Jul 17 21:13 /tmp/ktr.out root@gw:~ #> ktrdump -ct index cpu timestamp trace ------ --- ---------------- ----- nothing... [FROM MY KERNCONF] options KTR options ALQ options KTR_ALQ options KTR_ENTRIES=32768 options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED [EOF] While KTR_INTR works, it seems that KTR_SCHED does not or maybee there is a magic sause ? Best regards, -- Olivier Warin From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 12:15:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B38BE16A4DE; Fri, 28 Jul 2006 12:15:31 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CAE043D45; Fri, 28 Jul 2006 12:15:31 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 4B1587B63F; Fri, 28 Jul 2006 08:15:52 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id D6F8179B61; Fri, 28 Jul 2006 08:15:49 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G6RFW-000Bh4-0p; Fri, 28 Jul 2006 13:15:26 +0100 Date: Fri, 28 Jul 2006 13:15:25 +0100 From: Brian Candler To: John Baldwin Message-ID: <20060728121525.GA44917@uk.tiscali.com> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607271058.13055.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 12:15:31 -0000 On Thu, Jul 27, 2006 at 10:58:12AM -0400, John Baldwin wrote: > That these counters are for stats. :) You always have a race when reading the > amount, so you can choose what is "good enough" to satisfy the conflicting > requirements of "cheap" and "accurate". To me, the cheapness of add+adc > (compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you > have this rare race. You can work around the problem when reading - e.g. read twice and check the values are close. But is add + adc safe for update? What about the following: - processor 1 reads low32 as FFFFFFFF - processor 2 reads low32 as FFFFFFFF - processor 1 writes low32 as 00000000 and sets carry - processor 2 writes low32 as 00000000 and sets carry - processor 1 adds 1 to high32 - processor 2 adds 1 to high32 I'm not saying this sequence can definitely occur - I'm thinking from a general point of view, and I don't know the i386 instruction set. It just seems plausible. OTOH, if the above race can occur, it would imply that even a simple 32-bit counter update could lose counts. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 12:32:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEEE216A4DE for ; Fri, 28 Jul 2006 12:32:06 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C98C43D53 for ; Fri, 28 Jul 2006 12:32:06 +0000 (GMT) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 28 Jul 2006 08:32:09 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LYJ66994; Fri, 28 Jul 2006 08:31:58 -0400 (EDT) Received: from 65-78-24-149.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.24.149]) by smtp01.lnh.mail.rcn.net with ESMTP; 28 Jul 2006 08:31:55 -0400 X-IronPort-AV: i="4.07,191,1151899200"; d="scan'208"; a="245238792:sNHT69377660" From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17610.836.663396.331448@jerusalem.litteratus.org> Date: Fri, 28 Jul 2006 08:29:56 -0400 To: freebsd-current@freebsd.org In-Reply-To: <20060726063636.GA58151@freefall.freebsd.org> References: <20060726063636.GA58151@freefall.freebsd.org> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-Junkmail-Status: score=10/300, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090204.46AB3703.0074,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Subject: Re: LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 12:32:06 -0000 Yar Tikhiy writes: > FWIW, the LOR still is there. I was seeing it yesterday while > fiddling with the ipfw and natd rc.d scripts. > > lock order reversal: > 1st 0xc1a36090 inp (divinp) @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350 > 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 For the record, I'm (still) getting this also. Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 12:40:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A7D316A4E0 for ; Fri, 28 Jul 2006 12:40:03 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from gw.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C52A143D46 for ; Fri, 28 Jul 2006 12:40:02 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com ([192.168.1.10]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 08:40:01 -0400 Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 08:40:01 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 0FD65115DF; Fri, 28 Jul 2006 08:40:01 -0400 (EDT) Date: Fri, 28 Jul 2006 08:40:00 -0400 From: Ed Maste To: Olivier Warin Message-ID: <20060728124000.GA58825@sandvine.com> References: <05BA8FC7-820D-44FB-B0F9-940AA8BCBDA4@xview.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05BA8FC7-820D-44FB-B0F9-940AA8BCBDA4@xview.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 28 Jul 2006 12:40:01.0262 (UTC) FILETIME=[F14DA0E0:01C6B242] Cc: freebsd-current@freebsd.org Subject: Re: KTR_SCHED broken ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 12:40:15 -0000 On Thu, Jul 27, 2006 at 11:22:56PM +0200, Olivier Warin wrote: > [FROM MY KERNCONF] > options KTR > options ALQ > options KTR_ALQ > options KTR_ENTRIES=32768 > options KTR_COMPILE=KTR_SCHED > options KTR_MASK=KTR_SCHED > [EOF] > > While KTR_INTR works, it seems that KTR_SCHED does not or maybee > there is a magic sause ? It seems that KTR_SCHED doesn't work with KTR_ALQ. With that combination ktr_tracepoint() requires that td->td_critnest == 0, which won't be true in the code paths that use KTR_SCHED. For now your best bet is probably to use KTR without ALQ, but of course you're limited to a fixed number of entries. I've thought about adding to ktrdump the ability to loop on reading the ring buffer, so that it would be possible to read an arbitrarily long sequence of KTR events without ALQ. It's quite easy to implement, but I haven't yet tried it out. - Ed Maste From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 13:33:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF8B516A4F2 for ; Fri, 28 Jul 2006 13:33:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F85A43D53 for ; Fri, 28 Jul 2006 13:33:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6SDXAWo086102; Fri, 28 Jul 2006 09:33:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Brian Candler Date: Fri, 28 Jul 2006 09:28:36 -0400 User-Agent: KMail/1.9.1 References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> In-Reply-To: <20060728121525.GA44917@uk.tiscali.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607280928.36573.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 28 Jul 2006 09:33:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1624/Thu Jul 27 13:11:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:33:19 -0000 On Friday 28 July 2006 08:15, Brian Candler wrote: > On Thu, Jul 27, 2006 at 10:58:12AM -0400, John Baldwin wrote: > > That these counters are for stats. :) You always have a race when reading the > > amount, so you can choose what is "good enough" to satisfy the conflicting > > requirements of "cheap" and "accurate". To me, the cheapness of add+adc > > (compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you > > have this rare race. > > You can work around the problem when reading - e.g. read twice and check the > values are close. > > But is add + adc safe for update? What about the following: > > - processor 1 reads low32 as FFFFFFFF > - processor 2 reads low32 as FFFFFFFF > - processor 1 writes low32 as 00000000 and sets carry > - processor 2 writes low32 as 00000000 and sets carry > - processor 1 adds 1 to high32 > - processor 2 adds 1 to high32 > > I'm not saying this sequence can definitely occur - I'm thinking from a > general point of view, and I don't know the i386 instruction set. It just > seems plausible. > > OTOH, if the above race can occur, it would imply that even a simple 32-bit > counter update could lose counts. If you do a 'lock add' (atomic add) for the first 'add' this race won't occur. Because the adc wrapping so rare (relatively, you'd have to have 4 billion atomic add's occur in the time it takes 2 different CPU's to do the pair of instructions) you don't need to use 'lock' for the adc under the assumption that simultaneous adc instructions (that aren't just effective nops) won't happen often. However, I've just thought of a problem with that. :( Even if carry is clear, 'adc foo, $0' isn't a NOP, it still wants to do a read-modify-write, so you could use an update to high32 if you have two CPUs do this: CPU1 : bump low from ffffffff to 00000000 CPU2 : bump low from 00000000 to 00000001 CPU1 : adds 1 to high32 CPU2 : adds 0 to high32 and CPU2 reads an old value of high32 to add 0 to that is prior to CPU1's update to high32. To fix that you'd have to either use 'lock' with both instructions, or use a branch to only do adc when it's not a nop. So more like this to increment a counter: lock incl counter jnc 1f lock incl counter+4 1: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 13:47:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD48016A4DA; Fri, 28 Jul 2006 13:47:06 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 630FE43D66; Fri, 28 Jul 2006 13:47:06 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 729AB788E2; Fri, 28 Jul 2006 09:47:27 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 09A1D7865B; Fri, 28 Jul 2006 09:47:24 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G6Sg9-000Bmm-GB; Fri, 28 Jul 2006 14:47:01 +0100 Date: Fri, 28 Jul 2006 14:47:01 +0100 From: Brian Candler To: John Baldwin Message-ID: <20060728134701.GA45273@uk.tiscali.com> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607280928.36573.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:47:06 -0000 On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: > lock incl counter > jnc 1f > lock incl counter+4 > 1: That looks safe to me. How expensive is a forward jump like that, i.e. do you get a pipeline bubble? The 'polling' argument says just do lock incl counter and poll all counters every 5 minutes, looking for a wrap. I think that's almost certainly going to be cheaper, as long as you can keep track of where all these counters are located. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 13:54:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BBE216A4E2; Fri, 28 Jul 2006 13:54:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53DFC43D49; Fri, 28 Jul 2006 13:54:47 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unefez@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6SDseMo082246; Fri, 28 Jul 2006 15:54:46 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6SDse78082244; Fri, 28 Jul 2006 15:54:40 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200607281354.k6SDse78082244@lurza.secnetix.de> To: B.Candler@pobox.com (Brian Candler) Date: Fri, 28 Jul 2006 15:54:40 +0200 (CEST) In-Reply-To: <20060728134701.GA45273@uk.tiscali.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 28 Jul 2006 15:54:46 +0200 (CEST) X-Mailman-Approved-At: Fri, 28 Jul 2006 14:32:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:54:49 -0000 Brian Candler wrote: > John Baldwin wrote: > > lock incl counter > > jnc 1f > > lock incl counter+4 > > 1: > > That looks safe to me. How expensive is a forward jump like that, i.e. do > you get a pipeline bubble? The jump is not executed only once out of 4 billion times, so the processor's branch prediction should be handle to optimize away it pretty well. As far as I can tell, the "lock" prefixes are _much_ more to worry about. > The 'polling' argument says just do > > lock incl counter > > and poll all counters every 5 minutes, looking for a wrap. I think that's > almost certainly going to be cheaper, as long as you can keep track of where > all these counters are located. It's not much cheaper (it still seems to need a "lock"), and it's ugly, and there are situations where it can break, e.g. if the counter is incremented fast enough to overflow twice within the polling interval. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-current@FreeBSD.ORG Fri Jul 28 21:02:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0633316A4DA; Fri, 28 Jul 2006 21:02:00 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail29.syd.optusnet.com.au (mail29.syd.optusnet.com.au [211.29.132.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4638543D45; Fri, 28 Jul 2006 21:01:58 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail29.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6SL1uVn004766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 29 Jul 2006 07:01:56 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6SL1tPp003672; Sat, 29 Jul 2006 07:01:56 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6SL1t4T003671; Sat, 29 Jul 2006 07:01:55 +1000 (EST) (envelope-from peter) Date: Sat, 29 Jul 2006 07:01:55 +1000 From: Peter Jeremy To: Brian Candler Message-ID: <20060728210154.GC748@turion.vk2pj.dyndns.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20060728134701.GA45273@uk.tiscali.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 21:02:00 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote: >On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: >> lock incl counter >> jnc 1f >> lock incl counter+4 >> 1: This approach still requires the reader to loop with something like do { a.lo =3D counter.lo; a.hi =3D counter.hi; b.lo =3D counter.lo; b.hi =3D counter.hi; } while (a.hi !=3D b.hi || a.lo > b.lo); to ensure that the reader doesn't read the middle of an update. >The 'polling' argument says just do > lock incl counter >and poll all counters every 5 minutes, looking for a wrap. I think that's >almost certainly going to be cheaper, as long as you can keep track of whe= re >all these counters are located. lock prefixes are always going to be extremely expensive on a MP system because they require physical bus cycles. RISC architectures usually only have TAS lock primitives (because "inc mem" doesn't exist) and so require a spinlock to perform an atomic update. In a MP configuration where it doesn't particularly matter if a particular update gets counted this time or next time, I think the cheapest option is to have per-CPU 32-bit counters (so no locks are needed to update the counters) with a polling function to accumulate all the individual counters into a 64-bit total. This pushes the cost =66rom the update (very frequent) into the read (which is relatively infrequent), for a lower overall cost. This turns the update into something like: PCPU_SET(counter, PCPU_GET(counter)+1); or incl %fs:counter (no locks or atomic operations) Whilst the poll/read pseudo code looks something like lock counter foreach cpu { uint32 a =3D cpu->counter; uint32 b =3D cpu->last_counter; uint32 c =3D counter.lo; if (b > a) counter.hi++; counter.lo +=3D a - b; if (counter.lo < c) counter.hi++; cpu->last_counter =3D a; } unlock counter; (the lock prevents multiple readers updating counter simultaneously). You execute this whenever a reader wants the counter value (eg via SYSCTL_PROC), as well as a rate sufficient to prevent missing wraps (eg every 2 seconds for a 10g byte counter). This rate is sufficiently lower than the update rate to make the whole exercise worthwhile. --=20 Peter Jeremy --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEyntC/opHv/APuIcRAqJ2AJ4k3tbyma4jFGQOuv5eoxS0vP6BJwCfU4WS kC7zjOPnIFrdBGhkZ4+NMIM= =sWWy -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 07:01:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5E8D16A4DA for ; Sat, 29 Jul 2006 07:01:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id E640F43D45 for ; Sat, 29 Jul 2006 07:01:33 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so11735nzn for ; Sat, 29 Jul 2006 00:01:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=NC0hMu44C0hZ3AT1Tqrjqfea7cr7m+7BeMLB0SlKFDWRspTS5FCF+DJsjyEE+BI8ahw1VNMMpfmNgV/SLU6LReD3dORy6zKtvMkqHfRKNHGf4eYgHhnMoymceLzj2FpxH9XLXe10LamTEb26HJEfWguWmbpY+wVsDzqtDfKm2P8= Received: by 10.65.236.14 with SMTP id n14mr287509qbr; Sat, 29 Jul 2006 00:01:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 16sm1644563nzo.2006.07.29.00.01.31; Sat, 29 Jul 2006 00:01:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6T71eQS029363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Jul 2006 16:01:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6T71d22029362 for freebsd-current@FreeBSD.org; Sat, 29 Jul 2006 16:01:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 29 Jul 2006 16:01:39 +0900 From: Pyun YongHyeon To: freebsd-current@FreeBSD.org Message-ID: <20060729070139.GB27724@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: em(4) patch for ENOBUFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 07:01:34 -0000 Hi, Whilst reading em(4) code to fix jb's sun4v issue I noticed em(4) is very vulnerable to ENOBUFS situation on receive path. If em(4) encounter an ENOBUFS it just breaks receive loop and then try to process the packet next time. However it didn't update the Rx descriptor status so it never process receive path again(em_handle_rxtx task runs but it couldn't complete its job and the task takes up all your CPU). I've revised receive path to cope with the ENOBUFS situation more gracefully. It also contains a fix to handle DMA map loading failure case on receive path by allocating a spare DMA map. If you have em(4) and experienced ENOBUFS problem please try the following patch and let me know the result. http://people.freebsd.org/~yongari/em.ENOBUFS.patch You can reproduce current issue by lowering number of mbuf clusters in /boot/loader.conf. For example, add kern.ipc.nmbclusters="1000" to limit number of mbuf clusters. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 10:59:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 554F316A4DA for ; Sat, 29 Jul 2006 10:59:45 +0000 (UTC) (envelope-from markus@trippelsdorf.de) Received: from blue-ld-032.synserver.de (blue-ld-032.synserver.de [217.119.50.235]) by mx1.FreeBSD.org (Postfix) with SMTP id BAF5D43D53 for ; Sat, 29 Jul 2006 10:59:44 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: (qmail 29109 invoked by uid 0); 29 Jul 2006 10:59:34 -0000 X-SynServer-RemoteDnsName: port-212-202-34-169.dynamic.qsc.de X-SynServer-AuthUser: markus@trippelsdorf.de Received: from port-212-202-34-169.dynamic.qsc.de (HELO bsd.trippelsdorf.de) (212.202.34.169) by mx-04.synserver.de with SMTP; 29 Jul 2006 10:59:34 -0000 Date: Sat, 29 Jul 2006 12:59:33 +0200 From: Markus Trippelsdorf To: freebsd-current@freebsd.org Message-ID: <20060729105933.GA687@bsd.trippelsdorf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Keyboard LEDs always on X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 10:59:45 -0000 After upgrading from -stable to -current, the three LEDs on my USB keyboard are switched on at boot time and cannot be controlled by the caps-, num- or scroll-lock keys anymore. Is this a known problem? I would be grateful for any hints. Thanks. -- Markus From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 16:13:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EADD716A4DA for ; Sat, 29 Jul 2006 16:13:50 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50E0643D49 for ; Sat, 29 Jul 2006 16:13:50 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6TGDlt7000431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 29 Jul 2006 18:13:48 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Peter Jeremy In-Reply-To: <20060728210154.GC748@turion.vk2pj.dyndns.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> Content-Type: text/plain Date: Sat, 29 Jul 2006 18:13:32 +0200 Message-Id: <1154189612.1565.10.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 16:13:51 -0000 Peter Jeremy wrote: > On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote: > >On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: > In a MP configuration where it doesn't particularly matter if a > particular update gets counted this time or next time, I think the > cheapest option is to have per-CPU 32-bit counters (so no locks are > needed to update the counters) with a polling function to accumulate > all the individual counters into a 64-bit total. This pushes the cost > from the update (very frequent) into the read (which is relatively > infrequent), for a lower overall cost. What you describe has already been there for some time. >From sys/sys/pcpu.h #define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) and function vcnt from sys/vm/vm_meter.c Michal From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 19:05:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D19216A4DD for ; Sat, 29 Jul 2006 19:05:58 +0000 (UTC) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB7443D77 for ; Sat, 29 Jul 2006 19:05:56 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.6/8.13.6) with ESMTP id k6TJ5sI8018460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 Jul 2006 21:05:55 +0200 Message-ID: <44CBB179.6070904@wm-access.no> Date: Sat, 29 Jul 2006 21:05:29 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Jeremy References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> In-Reply-To: <20060728210154.GC748@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 19:05:58 -0000 Peter Jeremy wrote: > On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote: >> On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: >>> lock incl counter >>> jnc 1f >>> lock incl counter+4 >>> 1: >=20 > This approach still requires the reader to loop with something like > do { > a.lo =3D counter.lo; > a.hi =3D counter.hi; > b.lo =3D counter.lo; > b.hi =3D counter.hi; > } while (a.hi !=3D b.hi || a.lo > b.lo); > to ensure that the reader doesn't read the middle of an update. >=20 >> The 'polling' argument says just do >> lock incl counter >> and poll all counters every 5 minutes, looking for a wrap. I think tha= t's >> almost certainly going to be cheaper, as long as you can keep track of= where >> all these counters are located. >=20 > lock prefixes are always going to be extremely expensive on a MP > system because they require physical bus cycles. RISC architectures > usually only have TAS lock primitives (because "inc mem" doesn't > exist) and so require a spinlock to perform an atomic update. >=20 > In a MP configuration where it doesn't particularly matter if a > particular update gets counted this time or next time, I think the > cheapest option is to have per-CPU 32-bit counters (so no locks are > needed to update the counters) with a polling function to accumulate > all the individual counters into a 64-bit total. This pushes the cost > from the update (very frequent) into the read (which is relatively > infrequent), for a lower overall cost. >=20 > This turns the update into something like: > PCPU_SET(counter, PCPU_GET(counter)+1); > or > incl %fs:counter > (no locks or atomic operations) >=20 > Whilst the poll/read pseudo code looks something like > lock counter > foreach cpu { > uint32 a =3D cpu->counter; > uint32 b =3D cpu->last_counter; > uint32 c =3D counter.lo; > if (b > a) > counter.hi++; > counter.lo +=3D a - b; > if (counter.lo < c) > counter.hi++; > cpu->last_counter =3D a; > } > unlock counter; > (the lock prevents multiple readers updating counter simultaneously). >=20 > You execute this whenever a reader wants the counter value (eg via > SYSCTL_PROC), as well as a rate sufficient to prevent missing wraps > (eg every 2 seconds for a 10g byte counter). This rate is sufficiently= > lower than the update rate to make the whole exercise worthwhile. >=20 Is caching necessary somewhere or can the function return the value directly without storing the global accumulated counter? ( trying to get an understanding ) --=20 Sten Daniel S=F8rsdal From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 19:07:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F4B916A4E9 for ; Sat, 29 Jul 2006 19:07:00 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id F277143D46 for ; Sat, 29 Jul 2006 19:06:59 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 7C4142D67DD for ; Sat, 29 Jul 2006 19:06:58 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 3D23911444; Sat, 29 Jul 2006 21:06:58 +0200 (CEST) Date: Sat, 29 Jul 2006 21:06:58 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20060729190657.GB1085@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 19:07:00 -0000 Hey, Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system very shortly. There will be a short window while committing where the tree will be broken, but I expect it to be short (a few minutes). I will start a buildworld after the import. Let me know if you run into any problems (though I don't expect it, but...). -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:00:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 410BD16A4E6 for ; Sat, 29 Jul 2006 20:00:00 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2447D43DE3 for ; Sat, 29 Jul 2006 19:57:58 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id AF2A72D6767 for ; Sat, 29 Jul 2006 19:57:56 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 8840511444; Sat, 29 Jul 2006 21:57:56 +0200 (CEST) Date: Sat, 29 Jul 2006 21:57:56 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20060729195755.GC1085@zaphod.nitro.dk> References: <20060729190657.GB1085@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060729190657.GB1085@zaphod.nitro.dk> User-Agent: Mutt/1.5.11 Subject: Re: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:00:00 -0000 On 2006.07.29 21:06:58 +0200, Simon L. Nielsen wrote: > Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system > very shortly. There will be a short window while committing where the > tree will be broken, but I expect it to be short (a few minutes). > > I will start a buildworld after the import. Let me know if you run > into any problems (though I don't expect it, but...). OK, import should be done now. Let me know if there are any issues. -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:15:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29F0F16A4DA for ; Sat, 29 Jul 2006 20:15:06 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD6243D6D for ; Sat, 29 Jul 2006 20:15:01 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k6TKExTv031571 for ; Sun, 30 Jul 2006 00:14:59 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k6TKExWa031566 for current@freebsd.org; Sun, 30 Jul 2006 00:14:59 +0400 (MSD) (envelope-from yar) Date: Sun, 30 Jul 2006 00:14:58 +0400 From: Yar Tikhiy To: current@freebsd.org Message-ID: <20060729201458.GA30499@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: moused + ScrollLock + reboot = fun X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:15:06 -0000 Hi all, Rebooting a system while scrolling is activated on the syscons with moused proceeds in a funny way: the system goes on with the shutdown as usual until "All buffers synced." is printed, and then it waits for about 5 minutes before finishing the shutdown. Any ideas about what it waits for? Pressing the reset button during the pause results in dirty file systems, which means they were not unmounted yet. No moused or no scrolling = no pause, reboot normal. -- Yar From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:20:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33A6F16A4DD for ; Sat, 29 Jul 2006 20:20:27 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75BF343D45 for ; Sat, 29 Jul 2006 20:20:21 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 79EFCD911DD for ; Sat, 29 Jul 2006 16:20:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Sat, 29 Jul 2006 16:20:24 -0400 X-Sasl-enc: XqNpQ7KuKVJj8cajbu+ijp+lHQGW7+jzPhyFnUuufKKW 1154204424 Received: from [10.50.209.120] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id CF0107110 for ; Sat, 29 Jul 2006 16:20:23 -0400 (EDT) Message-ID: <44CBC2FD.4030709@fastmail.fm> Date: Sat, 29 Jul 2006 15:20:13 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060729190657.GB1085@zaphod.nitro.dk> <20060729195755.GC1085@zaphod.nitro.dk> In-Reply-To: <20060729195755.GC1085@zaphod.nitro.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:20:27 -0000 Simon L. Nielsen wrote: > On 2006.07.29 21:06:58 +0200, Simon L. Nielsen wrote: > > >> Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system >> very shortly. There will be a short window while committing where the >> tree will be broken, but I expect it to be short (a few minutes). >> >> I will start a buildworld after the import. Let me know if you run >> into any problems (though I don't expect it, but...). >> > > OK, import should be done now. Let me know if there are any issues. > > Just got this during "make buildworld". Don't know if it's related to your commits... cd /usr/src/secure; make buildincludes; make installincludes ===> secure/lib (buildincludes) ===> secure/lib/libcrypto (buildincludes) make: don't know how to make hw_4758_cca_err.h. Stop *** Error code 2 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks, Patrick From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:44:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9737216A4E0 for ; Sat, 29 Jul 2006 20:44:51 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B2943D5F for ; Sat, 29 Jul 2006 20:44:49 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 694C02D4A5C; Sat, 29 Jul 2006 20:44:48 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 2509411444; Sat, 29 Jul 2006 22:44:47 +0200 (CEST) Date: Sat, 29 Jul 2006 22:44:47 +0200 From: "Simon L. Nielsen" To: Patrick Bowen Message-ID: <20060729204447.GE1085@zaphod.nitro.dk> References: <20060729190657.GB1085@zaphod.nitro.dk> <20060729195755.GC1085@zaphod.nitro.dk> <44CBC2FD.4030709@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CBC2FD.4030709@fastmail.fm> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:44:51 -0000 On 2006.07.29 15:20:13 -0500, Patrick Bowen wrote: > Simon L. Nielsen wrote: > >On 2006.07.29 21:06:58 +0200, Simon L. Nielsen wrote: > > > >>Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system > >>very shortly. There will be a short window while committing where the > >>tree will be broken, but I expect it to be short (a few minutes). > >> > >>I will start a buildworld after the import. Let me know if you run > >>into any problems (though I don't expect it, but...). > > > >OK, import should be done now. Let me know if there are any issues. > > > Just got this during "make buildworld". Don't know if it's related to > your commits... > > cd /usr/src/secure; make buildincludes; make installincludes > ===> secure/lib (buildincludes) > ===> secure/lib/libcrypto (buildincludes) > make: don't know how to make hw_4758_cca_err.h. Stop > *** Error code 2 That is related to my commit, but I think it's caused by getting half of the import (before I committed the updates to makefiles). At least I didn't get a build failure there on the buildworld I started after the import was completed. Check if you have src/secure/lib/libcrypto/Makefile rev. 1.78. Could you try to cvsup again and see if the problem is still there? -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:52:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F273316A4E7 for ; Sat, 29 Jul 2006 20:52:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A565443D46 for ; Sat, 29 Jul 2006 20:52:25 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail13.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6TKqM9X027053 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Jul 2006 06:52:23 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6TKqLeB007628; Sun, 30 Jul 2006 06:52:22 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6TKqKT5007627; Sun, 30 Jul 2006 06:52:20 +1000 (EST) (envelope-from peter) Date: Sun, 30 Jul 2006 06:52:20 +1000 From: Peter Jeremy To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Message-ID: <20060729205220.GD748@turion.vk2pj.dyndns.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <44CBB179.6070904@wm-access.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: <44CBB179.6070904@wm-access.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:52:27 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2006-Jul-29 21:05:29 +0200, Sten Daniel Srsdal wrote: >Peter Jeremy wrote: >> In a MP configuration where it doesn't particularly matter if a >> particular update gets counted this time or next time, I think the >> cheapest option is to have per-CPU 32-bit counters (so no locks are >> needed to update the counters) with a polling function to accumulate >> all the individual counters into a 64-bit total. This pushes the cost >> from the update (very frequent) into the read (which is relatively >> infrequent), for a lower overall cost. >Is caching necessary somewhere or can the function return the value >directly without storing the global accumulated counter? If you want a 64-bit final result that takes into account overflows in the 32-bit per-CPU counters, then you will need some way to keep track of the number of overflows in each counter. --=20 Peter Jeremy --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEy8qE/opHv/APuIcRAvm/AJ4mwLBMec9CemgPajL0Tx+KbPB23ACdF2ym EgSFOmTnNKAPSo5ViLKjgpk= =g8X1 -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:57:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5595216A4E8 for ; Sat, 29 Jul 2006 20:57:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id B075B43D6E for ; Sat, 29 Jul 2006 20:56:59 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6TKuuPW031468 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Jul 2006 06:56:57 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6TKutgQ007659; Sun, 30 Jul 2006 06:56:56 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6TKutbM007658; Sun, 30 Jul 2006 06:56:55 +1000 (EST) (envelope-from peter) Date: Sun, 30 Jul 2006 06:56:55 +1000 From: Peter Jeremy To: Michal Mertl Message-ID: <20060729205655.GE748@turion.vk2pj.dyndns.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline In-Reply-To: <1154189612.1565.10.camel@genius.i.cz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:57:03 -0000 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2006-Jul-29 18:13:32 +0200, Michal Mertl wrote: >#define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) I missed that. >and function vcnt from sys/vm/vm_meter.c vcnt() accumulates multiple 32-bit counters into a 32-bit result. Getting a 64-bit result means additionally tracking overflows in each counter. --=20 Peter Jeremy --47eKBCiAZYFK5l32 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEy8uW/opHv/APuIcRAl+AAJ40wXfhNmr6cdkqLdtwwq/M6F4vwgCePcMf p89d6AZPAGyXoBlitxHlT04= =Uq6Y -----END PGP SIGNATURE----- --47eKBCiAZYFK5l32-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 20:59:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AD5616A4DA for ; Sat, 29 Jul 2006 20:59:10 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64EA543D6A for ; Sat, 29 Jul 2006 20:59:09 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id BC116D9221D for ; Sat, 29 Jul 2006 16:59:07 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sat, 29 Jul 2006 16:59:11 -0400 X-Sasl-enc: yiyM0gyVnejsk2sfMxuL9OknSrlPk0y8K+o06jZ5fuAY 1154206751 Received: from [10.50.209.120] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id 1BBE216B0 for ; Sat, 29 Jul 2006 16:59:10 -0400 (EDT) Message-ID: <44CBCC1A.5060007@fastmail.fm> Date: Sat, 29 Jul 2006 15:59:06 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060729190657.GB1085@zaphod.nitro.dk> <20060729195755.GC1085@zaphod.nitro.dk> <44CBC2FD.4030709@fastmail.fm> <20060729204447.GE1085@zaphod.nitro.dk> In-Reply-To: <20060729204447.GE1085@zaphod.nitro.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:59:10 -0000 Simon L. Nielsen wrote: > On 2006.07.29 15:20:13 -0500, Patrick Bowen wrote: > >> Simon L. Nielsen wrote: >> >>> On 2006.07.29 21:06:58 +0200, Simon L. Nielsen wrote: >>> >>> >>>> Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system >>>> very shortly. There will be a short window while committing where the >>>> tree will be broken, but I expect it to be short (a few minutes). >>>> >>>> I will start a buildworld after the import. Let me know if you run >>>> into any problems (though I don't expect it, but...). >>>> >>> OK, import should be done now. Let me know if there are any issues. >>> >>> >> Just got this during "make buildworld". Don't know if it's related to >> your commits... >> >> cd /usr/src/secure; make buildincludes; make installincludes >> ===> secure/lib (buildincludes) >> ===> secure/lib/libcrypto (buildincludes) >> make: don't know how to make hw_4758_cca_err.h. Stop >> *** Error code 2 >> > > That is related to my commit, but I think it's caused by getting half > of the import (before I committed the updates to makefiles). At least > I didn't get a build failure there on the buildworld I started after > the import was completed. > > Check if you have src/secure/lib/libcrypto/Makefile rev. 1.78. > > Could you try to cvsup again and see if the problem is still there? > > Right. I had 1.77. I re-csuped right after your msg the the commit was done, but I must have been too fast. I'm re-building world now... Patrick From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 21:15:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2C7E16A4DE for ; Sat, 29 Jul 2006 21:15:36 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9050F43D45 for ; Sat, 29 Jul 2006 21:15:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 89F197B936; Sat, 29 Jul 2006 17:15:57 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 1E1D878904; Sat, 29 Jul 2006 17:15:54 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G6w9j-000D6J-9y; Sat, 29 Jul 2006 22:15:31 +0100 Date: Sat, 29 Jul 2006 22:15:31 +0100 From: Brian Candler To: Peter Jeremy Message-ID: <20060729211530.GA50342@uk.tiscali.com> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060729205655.GE748@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: Michal Mertl , freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 21:15:37 -0000 On Sun, Jul 30, 2006 at 06:56:55AM +1000, Peter Jeremy wrote: > On Sat, 2006-Jul-29 18:13:32 +0200, Michal Mertl wrote: > >#define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) > > I missed that. > > >and function vcnt from sys/vm/vm_meter.c > > vcnt() accumulates multiple 32-bit counters into a 32-bit result. Getting > a 64-bit result means additionally tracking overflows in each counter. But if you have per-CPU counters, there's no problem with accumulating 64-bit values in the first place. So in the above macro I don't see why 'var' can't be a pointer to a uint64_t, with relevant minor changes to vcnt() of course. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 22:28:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99D6716A4DE for ; Sat, 29 Jul 2006 22:28:04 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26DCD43D45 for ; Sat, 29 Jul 2006 22:28:03 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id EC641D91575 for ; Sat, 29 Jul 2006 18:28:01 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sat, 29 Jul 2006 18:28:06 -0400 X-Sasl-enc: XY4XEBMDI9DyF+/0fXuje6o8pdsYtlrIlzvgVPGbK0lj 1154212085 Received: from [10.50.209.120] (unknown [204.110.228.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8960116AD for ; Sat, 29 Jul 2006 18:28:05 -0400 (EDT) Message-ID: <44CBE0F1.6020008@fastmail.fm> Date: Sat, 29 Jul 2006 17:28:01 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060729190657.GB1085@zaphod.nitro.dk> <20060729195755.GC1085@zaphod.nitro.dk> <44CBC2FD.4030709@fastmail.fm> <20060729204447.GE1085@zaphod.nitro.dk> <44CBCC1A.5060007@fastmail.fm> In-Reply-To: <44CBCC1A.5060007@fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: OpenSSL 0.9.8b import shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 22:28:04 -0000 Patrick Bowen wrote: > Simon L. Nielsen wrote: >> On 2006.07.29 15:20:13 -0500, Patrick Bowen wrote: >> >>> Simon L. Nielsen wrote: >>> >>>> On 2006.07.29 21:06:58 +0200, Simon L. Nielsen wrote: >>>> >>>> >>>>> Just FYI, I'm starting to import OpenSSL 0.9.8b into the base system >>>>> very shortly. There will be a short window while committing where >>>>> the >>>>> tree will be broken, but I expect it to be short (a few minutes). >>>>> >>>>> I will start a buildworld after the import. Let me know if you run >>>>> into any problems (though I don't expect it, but...). >>>>> >>>> OK, import should be done now. Let me know if there are any issues. >>>> >>>> >>> Just got this during "make buildworld". Don't know if it's related >>> to your commits... >>> >>> cd /usr/src/secure; make buildincludes; make installincludes >>> ===> secure/lib (buildincludes) >>> ===> secure/lib/libcrypto (buildincludes) >>> make: don't know how to make hw_4758_cca_err.h. Stop >>> *** Error code 2 >>> >> >> That is related to my commit, but I think it's caused by getting half >> of the import (before I committed the updates to makefiles). At least >> I didn't get a build failure there on the buildworld I started after >> the import was completed. >> >> Check if you have src/secure/lib/libcrypto/Makefile rev. 1.78. >> >> Could you try to cvsup again and see if the problem is still there? >> >> > > > Right. I had 1.77. I re-csuped right after your msg the the commit was > done, but I must have been too fast. > > I'm re-building world now... > > Patrick > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > Buildworld went fine. No problems. Thanks, Patrick From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 22:32:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB04A16A4DD for ; Sat, 29 Jul 2006 22:32:38 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4175D43D53 for ; Sat, 29 Jul 2006 22:32:37 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6TMWZf3064985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 00:32:36 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Brian Candler In-Reply-To: <20060729211530.GA50342@uk.tiscali.com> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-2 Date: Sun, 30 Jul 2006 00:32:20 +0200 Message-Id: <1154212340.3609.18.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 22:32:38 -0000 Brian Candler pķ¹e v so 29. 07. 2006 v 22:15 +0100: > On Sun, Jul 30, 2006 at 06:56:55AM +1000, Peter Jeremy wrote: > > On Sat, 2006-Jul-29 18:13:32 +0200, Michal Mertl wrote: > > >#define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) > > > > I missed that. > > > > >and function vcnt from sys/vm/vm_meter.c > > > > vcnt() accumulates multiple 32-bit counters into a 32-bit result. Getting > > a 64-bit result means additionally tracking overflows in each counter. > > But if you have per-CPU counters, there's no problem with accumulating > 64-bit values in the first place. No. AFAIK the fact that the data is per-CPU does not guarantee that much. If the operation is not atomic you can not really believe in anything. That is the reason why the macro is called LAZY. As multiple people already stated, there is no ideal solution. Either the counting is cheap or it is correct. The comment in src/sys/pcpu.h says: /* * MI PCPU support functions * * PCPU_LAZY_INC() - Lazily increment a per-cpu stats counter, without * guarenteeing atomicity or even necessarily consistency. * * XXX we need to create MD primitives to support * this to guarentee at least some level of consistency, * i.e., to prevent us from totally corrupting the * counters due to preemption in a multi-instruction * increment sequence for architectures that do not * support single-instruction memory increments. */ Michal From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 23:02:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F9816A4DE for ; Sat, 29 Jul 2006 23:02:15 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 464F543D45 for ; Sat, 29 Jul 2006 23:02:15 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id 5E8795880B; Sat, 29 Jul 2006 16:02:14 -0700 (PDT) Date: Sat, 29 Jul 2006 16:02:14 -0700 From: Paul Allen To: Michal Mertl Message-ID: <20060729230214.GI12597@groat.ugcs.caltech.edu> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1154212340.3609.18.camel@genius.i.cz> Sender: jd@ugcs.caltech.edu Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 23:02:15 -0000 Surely all you need to do is a cheap crit_enter,crit_exit while updating the 64-bit per cpu counters. and on a 64-bit arch you skip the crit_enter,crit_exit. Seriously this is a bike shed. We can summarize it thus: statistics should be maintained in 64-bit counters, these counters should be per-cpu and consistent in that context, nothing else should appear on the critical path. **end of story** Paul p.s., and as a general of thumb, if a per-cpu solution doesn't explode in complexity/memory usage it should be preferred over a mutex by default. From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 23:39:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97F9F16A4DA for ; Sat, 29 Jul 2006 23:39:09 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C136443D5C for ; Sat, 29 Jul 2006 23:38:57 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6TNcsm6074923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 01:38:55 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Paul Allen In-Reply-To: <20060729230214.GI12597@groat.ugcs.caltech.edu> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> Content-Type: text/plain Date: Sun, 30 Jul 2006 01:38:39 +0200 Message-Id: <1154216319.23616.23.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 23:39:09 -0000 Paul Allen wrote: > Surely all you need to do is a cheap crit_enter,crit_exit > while updating the 64-bit per cpu counters. and on > a 64-bit arch you skip the crit_enter,crit_exit. Critical_enter/exit seem to be quite lightweight (single read/modify/write of a variable). > Seriously this is a bike shed. We can summarize it thus: > statistics should be maintained in 64-bit counters, these > counters should be per-cpu and consistent in that context, > nothing else should appear on the critical path. Why do you call it a bikesched? I think that your proposal could work but as nobody proposed doing the stuff with critical_* before, the thread may be fruitful. Is critical_* good enough protection though? What if two threads were updating the same per-CPU counter on the same CPU at the same time? With 64bits counter on a 32bit architecture? I expect the cache coherency issues are completely eliminated with per-CPU data, aren't they? I did not think of preventing the migration of the thread to different CPU before. I would have expected this was expensive operation... Michal From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 23:50:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40D7016A4DA for ; Sat, 29 Jul 2006 23:50:54 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97A9C43D4C for ; Sat, 29 Jul 2006 23:50:53 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6TNoqjQ076716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 01:50:52 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Paul Allen In-Reply-To: <1154216319.23616.23.camel@genius.i.cz> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> Content-Type: text/plain Date: Sun, 30 Jul 2006 01:50:36 +0200 Message-Id: <1154217036.23616.28.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 23:50:54 -0000 Michal Mertl wrote: > Paul Allen wrote: > > Surely all you need to do is a cheap crit_enter,crit_exit > > while updating the 64-bit per cpu counters. and on > > a 64-bit arch you skip the crit_enter,crit_exit. > > Critical_enter/exit seem to be quite lightweight (single > read/modify/write of a variable). One more question. Why do you say that crit_* can be avoided on 64-bit arch? If the reason was that "increment of a 64 bit number is one operation there" it probably is not true - as somebody already stated, some instruction sets don't allow atomic increment of a memory location. Michal