From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 04:39:57 2005 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 6C26916A41F; Sun, 10 Jul 2005 04:39:57 +0000 (GMT) (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 DBB5543D46; Sun, 10 Jul 2005 04:39:55 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with SMTP id j6A4dlMK074874; Sun, 10 Jul 2005 13:39:47 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 10 Jul 2005 13:39:47 +0900 (JST) Message-Id: <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> From: Norikatsu Shigemura To: qemu-devel@nongnu.org, freebsd-current@FreeBSD.org In-Reply-To: <200507040037.j640bg0v085158@gate.bitblocks.com> References: <20050704010715.A36404@saturn.kn-bremen.de> <200507040037.j640bg0v085158@gate.bitblocks.com> X-Mailer: Sylpheed version 2.0.0beta5 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sakura.ninth-nine.com [219.127.74.121]); Sun, 10 Jul 2005 13:39:50 +0900 (JST) Cc: Craig Boston , jhb@FreeBSD.org, jeff@FreeBSD.org, alc@FreeBSD.org, Bakul Shah , Juergen Lock Subject: Re: [Qemu-devel] kqemu freebsd host smp problems? 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, 10 Jul 2005 04:39:57 -0000 On Sun, 03 Jul 2005 17:37:42 -0700 Bakul Shah wrote: > Lock writes: > > Is kqemu and the freebsd wrapper smp aware? I just saw this panic > > report again, > > http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050161.html > > and noticed it apparently happened with an smp kernel. > My guess is > .d_flags = D_NEEDGIANT, > needs to be added to the initializer of kqemu_cdevsw for the > freebsd-current case. AFAIK this flag ensures only one > thread can be in this driver at a time (but caveat emptor: I > don't play in the kernel these days). I confirmed that qemu on latest FreeBSD 6-current got more stability!!, but more little slowly:-( and a panic:-( too. Now I'm testing improved qemu port: http://tmp.ninth-nine.com/qemu/qemu.20050708-2.port.tar.bz2 1. Merge /dev/kqemu cloning support to kmod_bsd.c. Obtained from: http://lists.gnu.org/archive/html/qemu-devel/2005-06/msg00135.html Submitted by: Craig Boston > $ fstat /dev/kqemu* > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME > nork qemu 33805 5 /dev 168 crw-rw---- #C:0:0x0 rw /dev/kqemu1 > root qemu 20779 6 /dev 152 crw-rw---- #C:0:0x0 rw /dev/kqemu0 In this time, I'm installing Windows XP SP2 and FreeBSD 5.4-R. 2. Giant-lock kqemu.ko. Obtained from: http://lists.gnu.org/archive/html/qemu-devel/2005-07/msg00070.html Suggested by: Bakul Shah 3. Add experimental IDE WDMA support. Obtained from: I forgot:-( Submitted by(AFAIK): Juergen Lock 4. Utilize BSDMakefile to compile kqemu.ko, and cosmetic change. I contacted a panic. Please check following message. PANIC MESSAGE ON CONSOLE: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FreeBSD/i386 (nadesico.ninth-nine.com) (dcons) login: info: [drm] Loading R200 Microcode info: [drm] Loading R200 Microcode panic: vm_page_insert: page already inserted cpuid = 0 KDB: enter: panic [thread pid 49875 tid 100270 ] Stopped at kdb_enter+0x30: leave db> tr Tracing pid 49875 tid 100270 td 0xc3374480 kdb_enter(c06672e3,0,c067582a,efc55870,c50b1b60) at kdb_enter+0x30 panic(c067582a,c3374480,2,c1a99178,2) at panic+0x14e vm_page_insert(c1a99178,c60e19cc,5d2c,0,c11d3030) at vm_page_insert+0x2a vm_page_alloc(c60e19cc,5d2c,0,222,d65549d8) at vm_page_alloc+0x348 allocbuf(d65549d8,4000,0,4000,3863b048) at allocbuf+0x721 getblk(c50b1aa0,174b,0,4000,0) at getblk+0x5ad ffs_balloc_ufs2(c50b1aa0,5d2c000,0,1000,c345d300) at ffs_balloc_ufs2+0x1b67 ffs_write(efc55be8,efc55b94,4,0,0) at ffs_write+0x389 VOP_WRITE_APV(c069ade0,efc55be8,c3374480,c2325c00,0) at VOP_WRITE_APV+0xec vn_write(c3259a20,efc55cb0,c345d300,0,c3374480) at vn_write+0x240 dofilewrite(c3374480,4,c3259a20,efc55cb0,ffffffff) at dofilewrite+0x85 kern_writev(c3374480,4,efc55cb0,804e000,1000) at kern_writev+0x65 write(c3374480,efc55d04,c,c3374480,efc55d2c) at write+0x4f syscall(3b,3b,bfbf003b,1000,682b2258) at syscall+0x370 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x682148bf, esp = 0xbfbfd8fc, ebp = 0xbfbfd918 --- db> show pcpu 0 cpuid = 0 curthread = 0xc3374480: pid 49875 "fetch" curpcb = 0xefc55d90 fpcurthread = none idlethread = 0xc22d7900: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 db> show pcpu 1 cpuid = 1 curthread = 0xc328e900: pid 20779 "qemu" curpcb = 0xefbbfd90 fpcurthread = none idlethread = 0xc22d7780: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 db> call doadump() Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok Dump complete = 0xf db> reset - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # kgdb /boot/kernel/kernel.debug /var/crash/vmcore.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (snip) (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc0431b66 in db_fncall (dummy1=-272279900, dummy2=0, dummy3=9600, dummy4=0xefc55688 "`\004p$B@x(B\003") at /usr/src/sys/ddb/db_command.c:489 #2 0xc04318e2 in db_command (last_cmdp=0xc06a85e4, cmd_table=0x0, aux_cmd_tablep=0xc067cb40, aux_cmd_tablep_end=0xc067cb44) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04319f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0433ba5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc04d5ece in kdb_trap (type=0, code=0, tf=0xefc557e8) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc06434c8 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = -272302040, tf_edi = 256, tf_esi = 1, tf_ebp = -272279504, tf_isp = -272279532, tf_ebx = -272279440, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068672096, tf_cs = 32, tf_eflags = 642, tf_esp = -1067021478, tf_ss = -1067027741}) at /usr/src/sys/i386/i386/trap.c:600 #7 0xc062ec5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0x00000008 in ?? () #9 0x00000028 in ?? () #10 0xefc50028 in ?? () #11 0x00000100 in ?? () #12 0x00000001 in ?? () #13 0xefc55830 in ?? () #14 0xefc55814 in ?? () #15 0xefc55870 in ?? () #16 0x00000000 in ?? () #17 0xc1033000 in ?? () #18 0x00000012 in ?? () #19 0x00000003 in ?? () #20 0x00000000 in ?? () #21 0xc04d5ba0 in kdb_enter (msg=0x0) at cpufunc.h:60 #22 0xc04b553e in panic ( fmt=0xc067582a "vm_page_insert: page already inserted") at /usr/src/sys/kern/kern_shutdown.c:537 #23 0xc05fb8fa in vm_page_insert (m=0xc1a99178, object=0xc60e19cc, pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:539 #24 0xc05fc018 in vm_page_alloc (object=0xc60e19cc, pindex=23852, req=546) at /usr/src/sys/vm/vm_page.c:867 #25 0xc0510241 in allocbuf (bp=0xd65549d8, size=16384) at /usr/src/sys/kern/vfs_bio.c:2770 #26 0xc050fa9d in getblk (vp=0xc50b1aa0, blkno=5963, size=16384, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2541 #27 0xc05b73e7 in ffs_balloc_ufs2 (vp=0xc50b1aa0, startoffset=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:817 ---Type to continue, or q to quit--- #28 0xc05d1b49 in ffs_write (ap=0xefc55be8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:662 #29 0xc064f5bc in VOP_WRITE_APV (vop=0xc069ade0, a=0xefc55be8) at vnode_if.c:698 #30 0xc0530660 in vn_write (fp=0xc3259a20, uio=0xefc55cb0, active_cred=0xc345d300, flags=0, td=0xc3374480) at vnode_if.h:372 #31 0xc04e29e5 in dofilewrite (td=0xc3374480, fd=0, fp=0xc3259a20, auio=0xefc55cb0, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:246 #32 0xc04e2805 in kern_writev (td=0xc3374480, fd=4, auio=0x0) at /usr/src/sys/kern/sys_generic.c:402 #33 0xc04e26bf in write (td=0x0, uap=0x0) at /usr/src/sys/kern/sys_generic.c:326 #34 0xc0643f80 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = -1078001605, tf_edi = 4096, tf_esi = 1747657304, tf_ebp = -1077946088, tf_isp = -272278172, tf_ebx = 1747579940, tf_edx = 134537216, tf_ecx = 134574080, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 1747011775, tf_cs = 51, tf_eflags = 534, tf_esp = -1077946116, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:985 #35 0xc062ecaf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #36 0x0000003b in ?? () #37 0x0000003b in ?? () #38 0xbfbf003b in ?? () #39 0x00001000 in ?? () #40 0x682b2258 in ?? () #41 0xbfbfd918 in ?? () #42 0xefc55d64 in ?? () #43 0x6829f424 in ?? () #44 0x0804e000 in ?? () #45 0x08057000 in ?? () #46 0x00000004 in ?? () #47 0x00000000 in ?? () #48 0x00000002 in ?? () #49 0x682148bf in ?? () #50 0x00000033 in ?? () #51 0x00000216 in ?? () #52 0xbfbfd8fc in ?? () #53 0x0000003b in ?? () #54 0x49806749 in ?? () #55 0x67498067 in ?? () #56 0x80674980 in ?? () #57 0x49806749 in ?? () #58 0x19b2c000 in ?? () #59 0xc255ea3c in ?? () #60 0xc3374480 in ?? () ---Type to continue, or q to quit--- #61 0xefc55c94 in ?? () #62 0xefc55c78 in ?? () #63 0xc22d8300 in ?? () #64 0xc04cc0c0 in sched_switch (td=0x682b2258, newtd=0x6829f424, flags=Cannot access memory at address 0xbfbfd928 ) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) (kgdb) x/72b 0xc1a99178 0xc1a99178: 0x40 0xab 0x4c 0xc1 0x60 0xf5 0x6f 0xc0 0xc1a99180: 0xc0 0xa1 0xff 0xc1 0x38 0xfd 0xe8 0xc1 0xc1a99188: 0x30 0xfd 0xe8 0xc1 0xc0 0xa1 0xff 0xc1 0xc1a99190: 0x38 0x97 0x70 0xc3 0x1a 0xd4 0x00 0x00 0xc1a99198: 0x00 0x00 0x00 0x00 0x00 0x80 0x27 0x24 0xc1a991a0: 0x01 0x00 0x00 0x00 0x88 0x52 0x22 0xe1 0xc1a991a8: 0x90 0x52 0x22 0xe1 0x00 0x00 0x00 0x00 0xc1a991b0: 0x78 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0xc1a991b8: 0x00 0x00 0x00 0x00 0x00 0xff 0x00 0x00 (kgdb) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 05:55:42 2005 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 4E8BF16A41C; Sun, 10 Jul 2005 05:55:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 175B543D48; Sun, 10 Jul 2005 05:55:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id DE28B1F6643; Sat, 9 Jul 2005 22:55:41 -0700 (PDT) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j6A5tfOQ002276; Sat, 9 Jul 2005 22:55:41 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42D0B85C.5050209@elischer.org> Date: Sat, 09 Jul 2005 22:55:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: sebastian ssmoller References: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> In-Reply-To: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: Fw: Re: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes) 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, 10 Jul 2005 05:55:42 -0000 sebastian ssmoller wrote: > just FYI ... > > regards, > seb > > Begin forwarded message: > > Date: Sat, 9 Jul 2005 10:24:57 +0200 > From: sebastian ssmoller > To: freebsd-multimedia@freebsd.org > Subject: Re: Massive sound changes / fix (24/32bit pcm support, new > sampling rate converter, various fixes) > > > hi, > i just wonna say: THX! really GREAT work! ... this improves sound > quality on my boxes much !! ;-) > > THX, > regards, > seb > > >>After sometimes, I've decided to release this (massive 4k lines) diff >>to our sound driver. This need proper review and confirmation, before >>it can be committed. >> >>Patches for both HEAD / RELENG_5 available at: >> How do these changes affect the recently submitted changes to improve OSS compatibility? From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 07:31:38 2005 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 9B4F716A41C; Sun, 10 Jul 2005 07:31:38 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF8E43D48; Sun, 10 Jul 2005 07:31:36 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j6A7TlI1004869; Sun, 10 Jul 2005 16:59:47 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Sun, 10 Jul 2005 17:01:30 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j6A7RW006056; Sun, 10 Jul 2005 16:57:32 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N8MYT9KS; Sun, 10 Jul 2005 16:57:27 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.13.3/8.13.3) with ESMTP id j6A7RsoB039198; Sun, 10 Jul 2005 16:57:54 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.13.3/8.13.3/Submit) id j6A7RqIx039197; Sun, 10 Jul 2005 16:57:52 +0930 (CST) (envelope-from wilkinsa) Date: Sun, 10 Jul 2005 16:57:52 +0930 From: "Wilkinson, Alex" To: Poul-Henning Kamp Message-ID: <20050710072752.GA39156@squash.dsto.defence.gov.au> References: <200507090932.12973.jhb@FreeBSD.org> <20514.1120916772@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20514.1120916772@phk.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 10 Jul 2005 07:31:38 -0000 0n Sat, Jul 09, 2005 at 03:46:12PM +0200, Poul-Henning Kamp wrote: >In message <200507090932.12973.jhb@FreeBSD.org>, John Baldwin writes: >>On Tuesday 05 July 2005 04:44 pm, Poul-Henning Kamp wrote: >>> This is an attempt to fix an boot0cfg/fdisk issue which I have >>> overlooked. >>> >>> The patch adds a g_ctl method to geom_mbr and makes boot0cfg and >>> fdisk use it to modify the MBR if possible. >>> >>> Please test and report ASAP in order to get this solution into >>> RELENG_6 >> >>Only thing I noted is that it seems that you changed boot0 to always only >>write 512 bytes which means it will break trying to use boot0cfg to install >>boot0ext (which is 2 sectors). Perhaps you should check the filesize of the >>boot you are writing and if it's > 512, write the other data with a write(2) >>after the g_ctl()? Perhaps I don't see quite understand what your g_ctl() is >>doing though. > >Damn, didn't think of that... what is boot0ext ? - aW From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 07:31:38 2005 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 9B4F716A41C; Sun, 10 Jul 2005 07:31:38 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF8E43D48; Sun, 10 Jul 2005 07:31:36 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j6A7TlI1004869; Sun, 10 Jul 2005 16:59:47 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Sun, 10 Jul 2005 17:01:30 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j6A7RW006056; Sun, 10 Jul 2005 16:57:32 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N8MYT9KS; Sun, 10 Jul 2005 16:57:27 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.13.3/8.13.3) with ESMTP id j6A7RsoB039198; Sun, 10 Jul 2005 16:57:54 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.13.3/8.13.3/Submit) id j6A7RqIx039197; Sun, 10 Jul 2005 16:57:52 +0930 (CST) (envelope-from wilkinsa) Date: Sun, 10 Jul 2005 16:57:52 +0930 From: "Wilkinson, Alex" To: Poul-Henning Kamp Message-ID: <20050710072752.GA39156@squash.dsto.defence.gov.au> References: <200507090932.12973.jhb@FreeBSD.org> <20514.1120916772@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20514.1120916772@phk.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 10 Jul 2005 07:31:38 -0000 0n Sat, Jul 09, 2005 at 03:46:12PM +0200, Poul-Henning Kamp wrote: >In message <200507090932.12973.jhb@FreeBSD.org>, John Baldwin writes: >>On Tuesday 05 July 2005 04:44 pm, Poul-Henning Kamp wrote: >>> This is an attempt to fix an boot0cfg/fdisk issue which I have >>> overlooked. >>> >>> The patch adds a g_ctl method to geom_mbr and makes boot0cfg and >>> fdisk use it to modify the MBR if possible. >>> >>> Please test and report ASAP in order to get this solution into >>> RELENG_6 >> >>Only thing I noted is that it seems that you changed boot0 to always only >>write 512 bytes which means it will break trying to use boot0cfg to install >>boot0ext (which is 2 sectors). Perhaps you should check the filesize of the >>boot you are writing and if it's > 512, write the other data with a write(2) >>after the g_ctl()? Perhaps I don't see quite understand what your g_ctl() is >>doing though. > >Damn, didn't think of that... what is boot0ext ? - aW From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 08:51:46 2005 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 0804F16A41C for ; Sun, 10 Jul 2005 08:51:46 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9988243D46 for ; Sun, 10 Jul 2005 08:51:45 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from [83.237.204.121] (port=36815 helo=[192.168.0.8]) by mx6.mail.ru with esmtp id 1DrXXL-000NjP-00 for freebsd-current@freebsd.org; Sun, 10 Jul 2005 12:51:43 +0400 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050708215620.GN39292@obiwan.tataz.chchile.org> References: <20041102222000.GA65845@xor.obsecurity.org> <20050706073205.GA942@galgenberg.net> <20050706085737.GT73907@obiwan.tataz.chchile.org> <200507061116.17267.thierry@herbelot.com> <20050708215620.GN39292@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FCC20EB-A240-4EDC-B09A-31BEE5129676@mail.ru> Content-Transfer-Encoding: 7bit From: Artem Ignatiev Date: Sun, 10 Jul 2005 12:51:30 +0400 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.730) Subject: Re: HEADS UP: Ports are not ready for CFLAGS=-O2 in 6.0 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, 10 Jul 2005 08:51:46 -0000 On 09.07.2005, at 1:56, Jeremie Le Hen wrote: > Hi Thierry, > > >> and it does not work if he ports tree is "physically" elsewhere >> (mine is >> shared over NFS from /files2/ports -> .CURDIR does not begin >> with /usr/ports). >> >> Perhaps a better way would be to use a variable set in bsd.ports.mk >> (BUILDING_PORT="YES") >> > > I thought a bit more about this. This seems to be a better idea than > having a PORT_CFLAGS variable, because when a user wants to compile a > port with uncommon CFLAGS, he will do the following (for instance) : > %%% > cd /usr/ports/misc/vera > make CFLAGS='-O3' install clean > %%% > > If we add something like this in ports/Mk/bsd.port.mk : > %%% > .if defined(PORT_CFLAGS) > CFLAGS=${PORT_CFLAGS} > .end > %%% > > This will obviously break POLA because setting CFLAGS won't work as > expected. Why not : .if defined(PORT_CFLAGS) && !defined(CFLAGS) CFLAGS=${PORT_CFLAGS} .endif or even: .if defined(PORT_CFLAGS) CFLAGS=${PORT_CFLAGS} ${CFLAGS} .endif From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 09:48:54 2005 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 42F8E16A41C; Sun, 10 Jul 2005 09:48:54 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from mta204-rme.xtra.co.nz (mta204-rme.xtra.co.nz [210.86.15.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CA4943D48; Sun, 10 Jul 2005 09:48:52 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from pop2-rme.xtra.co.nz ([210.86.15.240]) by mta204-rme.xtra.co.nz with ESMTP id <20050710094851.EYZU1559.mta204-rme.xtra.co.nz@pop2-rme.xtra.co.nz>; Sun, 10 Jul 2005 21:48:51 +1200 Received: from serv.int.fubar.geek.nz ([222.152.103.254]) by pop2-rme.xtra.co.nz with ESMTP id <20050710094850.LIZE16943.pop2-rme.xtra.co.nz@serv.int.fubar.geek.nz>; Sun, 10 Jul 2005 21:48:50 +1200 Received: from [192.168.1.99] (beta.int.fubar.geek.nz [192.168.1.99]) by serv.int.fubar.geek.nz (Postfix) with ESMTP id 6B4CA6166; Sun, 10 Jul 2005 21:48:49 +1200 (NZST) Message-ID: <42D0EF01.3070805@fubar.geek.nz> Date: Sun, 10 Jul 2005 21:48:49 +1200 From: Andrew Turner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050404 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050701094904.GA98642@lpthe.jussieu.fr> <42C626C9.60206@fubar.geek.nz> <200507090917.19520.jhb@FreeBSD.org> In-Reply-To: <200507090917.19520.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Michel Talon Subject: Re: June Snapshot of 6.0 woes under qemu 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, 10 Jul 2005 09:48:54 -0000 John Baldwin wrote: > >This is not a LOR. LORs involving "system map" or "user map" are almost >always false positives. The real issue is a panic in ata_pio_read(), >probably due to a NULL pointer. > > > I found by removing PREEMPTION from the kernel the problem went away. Andrew -- 437742420 From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 10:29:09 2005 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 E0F1A16A41C for ; Sun, 10 Jul 2005 10:29:09 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1EBBB43D49 for ; Sun, 10 Jul 2005 10:29:08 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 10 Jul 2005 10:29:07 -0000 Received: from p5090C76D.dip.t-dialin.net (EHLO klotz.local) [80.144.199.109] by mail.gmx.net (mp019) with SMTP; 10 Jul 2005 12:29:07 +0200 X-Authenticated: #989277 Received: from [127.0.0.1] (localhost [127.0.0.1]) by klotz.local (8.13.3/8.13.3) with ESMTP id j6AASkA3001691 for ; Sun, 10 Jul 2005 12:28:47 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42D0F85D.3020405@nurfuerspam.de> Date: Sun, 10 Jul 2005 12:28:45 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: LOR: vr0 vs ACPI root bus 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, 10 Jul 2005 10:29:10 -0000 Hi, the other witness warning which I promised to report in my last email is actually a LOR which occurs on ACPI shutdown/reboot/halt. I haven't seen it mentioned in the LOR-list yet. Here the output. These are two pages, so I wrote down only the essential info. lock order reversal 1st vr0 @/usr/src/sys/pci/if_vr.c:806 2nd ACPI root bus @/usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:1056 KDB stack backtrace: kdb_backtrace witness_checkorder _sx_xlock acpi_release_ressource bus_generic_release_ressource ressource_list_release bus_generic_rl_release_ressource bus_release_ressource vr_detach vr_shutdown device_shutdown bus_generic_shutdown device_shutdown bus_generic_shutdown device_shutdown bus_generic_shutdown acpi_shutdown device_shutdown bus_generic_shutdown device_shutdown bus_generic_shutdown device_shutdown root_bus_module_handler module_shutdown boot reboot syscall Xint0x80_syscall Martin From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 11:10:35 2005 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 CA3A216A41C; Sun, 10 Jul 2005 11:10:35 +0000 (GMT) (envelope-from antony.t.curtis@ntlworld.com) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79CD243D45; Sun, 10 Jul 2005 11:10:33 +0000 (GMT) (envelope-from antony.t.curtis@ntlworld.com) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20050710111035.DXPJ889.mta08-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>; Sun, 10 Jul 2005 12:10:35 +0100 Received: from pcgem.xiphis.org ([81.103.110.177]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20050710111032.CGNI4721.aamta12-winn.ispmail.ntl.com@pcgem.xiphis.org>; Sun, 10 Jul 2005 12:10:32 +0100 From: Antony T Curtis To: Norikatsu Shigemura In-Reply-To: <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> References: <20050704010715.A36404@saturn.kn-bremen.de> <200507040037.j640bg0v085158@gate.bitblocks.com> <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> Content-Type: text/plain Date: Sun, 10 Jul 2005 12:10:28 +0100 Message-Id: <1120993828.46929.7.camel@pcgem.xiphis.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Craig Boston , jhb@FreeBSD.org, alc@FreeBSD.org, jeff@FreeBSD.org, qemu-devel@nongnu.org, freebsd-current@FreeBSD.org, Bakul Shah , Juergen Lock Subject: Re: [Qemu-devel] kqemu freebsd host smp problems? 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, 10 Jul 2005 11:10:35 -0000 On Sun, 2005-07-10 at 13:39 +0900, Norikatsu Shigemura wrote: > On Sun, 03 Jul 2005 17:37:42 -0700 > Bakul Shah wrote: > > Lock writes: > > > Is kqemu and the freebsd wrapper smp aware? I just saw this panic > > > report again, > > > http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050161.html > > > and noticed it apparently happened with an smp kernel. > > My guess is > > .d_flags = D_NEEDGIANT, > > needs to be added to the initializer of kqemu_cdevsw for the > > freebsd-current case. AFAIK this flag ensures only one > > thread can be in this driver at a time (but caveat emptor: I > > don't play in the kernel these days). > > I confirmed that qemu on latest FreeBSD 6-current got more > stability!!, but more little slowly:-( and a panic:-( too. IMO, That flag is not the cause of the panics and that it should(tm) work without requiring GIANT... I think it is possible that the kqemu code is freeing a page without unlocking it so that when another process does file IO which requires pages to be allocated, attempts to wire those pages results in failure and so a panic occurrs. Perhaps if a different method for allocating memory rather than contigmalloc/contigfree should be used by the kernel module. Offtopic - but am I the only person who has modified the if_tap driver to permit opening by non-superuser? -- Antony T Curtis, BSc. UNIX, Linux, *BSD, Networking antony.t.curtis@ntlworld.com C++, J2EE, Perl, MySQL, Apache IT Consultancy. From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 11:29:09 2005 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 1D26616A41C; Sun, 10 Jul 2005 11:29:09 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4BBE43D46; Sun, 10 Jul 2005 11:29:08 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd33.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1DrZze-0001jF-00; Sun, 10 Jul 2005 13:29:06 +0200 Received: from Andro-Beta.Leidinger.net (r3FD52Zfwe+BWyMsVp+f04CCwG6krDRZvSTugsxkZMo2Ni-gcps7ZI@[84.165.226.122]) by fwd33.sul.t-online.de with esmtp id 1DrZzP-0qSlWa0; Sun, 10 Jul 2005 13:28:51 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6ABSoZQ034033; Sun, 10 Jul 2005 13:28:50 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 10 Jul 2005 13:28:50 +0200 From: Alexander Leidinger To: noackjr@alumni.rice.edu, stable@freebsd.org, current@freebsd.org Message-ID: <20050710132850.08d42978@Magellan.Leidinger.net> In-Reply-To: <42D02E8F.3070200@alumni.rice.edu> References: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> <42D02E8F.3070200@alumni.rice.edu> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: r3FD52Zfwe+BWyMsVp+f04CCwG6krDRZvSTugsxkZMo2Ni-gcps7ZI@t-dialin.net X-TOI-MSGID: d4a03b0c-df20-4c01-84f9-93ea9981c6ec Cc: Subject: Re: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes) 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, 10 Jul 2005 11:29:09 -0000 On Sat, 09 Jul 2005 15:07:43 -0500 Jonathan Noack wrote: > On 07/09/05 03:26, sebastian ssmoller wrote: > > i just wonna say: THX! really GREAT work! ... this improves sound > > quality on my boxes much !! ;-) > > Is there a plan to get this into 6.0-RELEASE? I certainly hope so and > I'll do my part by testing it as much as possible... I think we're too late in the release cycle to get this in with a reasonable amount of testing. But I think Mat will commit it when the code freeze is over. And there's no reason to not have it in 6.1. Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 11:31:56 2005 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 1469F16A41C for ; Sun, 10 Jul 2005 11:31:56 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B8ED43D46 for ; Sun, 10 Jul 2005 11:31:55 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd18.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Dra2M-0005S1-06; Sun, 10 Jul 2005 13:31:54 +0200 Received: from Andro-Beta.Leidinger.net (XH9M5OZSYeeTynTkecs21-I+Ui8dOAQQXJvTymYvA5EaXKpGgTEEEx@[84.165.226.122]) by fwd18.sul.t-online.de with esmtp id 1Dra2H-20XmMq0; Sun, 10 Jul 2005 13:31:49 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6ABVm9v034472 for ; Sun, 10 Jul 2005 13:31:49 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 10 Jul 2005 13:31:48 +0200 From: Alexander Leidinger To: freebsd-current@freebsd.org Message-ID: <20050710133148.0c9985ed@Magellan.Leidinger.net> In-Reply-To: <42D0B85C.5050209@elischer.org> References: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> <42D0B85C.5050209@elischer.org> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: XH9M5OZSYeeTynTkecs21-I+Ui8dOAQQXJvTymYvA5EaXKpGgTEEEx@t-dialin.net X-TOI-MSGID: be64858d-abaa-4c8b-84f3-03deeffd2bb0 Subject: Re: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes) 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, 10 Jul 2005 11:31:56 -0000 On Sat, 09 Jul 2005 22:55:40 -0700 Julian Elischer wrote: > How do these changes affect the recently submitted changes to improve OSS > compatibility? I think I missed something. Can you please point me to the changes? Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 12:42:08 2005 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 130FC16A41F for ; Sat, 9 Jul 2005 12:42:08 +0000 (GMT) (envelope-from blacknova@tut.by) Received: from tut.by (speedy.tutby.com [195.209.41.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ACC243D53 for ; Sat, 9 Jul 2005 12:42:04 +0000 (GMT) (envelope-from blacknova@tut.by) X-VBA32: Checked Received: from [82.209.204.239] (account blacknova HELO bp-204-239.dialup.vitebsk.by) by tut.by (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 83585120 for freebsd-current@freebsd.org; Sat, 09 Jul 2005 15:41:57 +0300 From: Novoseltsev Vladimir To: freebsd-current@freebsd.org Content-Type: text/plain Organization: Home Date: Sat, 09 Jul 2005 15:41:47 +0300 Message-Id: <1120912907.636.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 10 Jul 2005 12:18:20 +0000 Subject: strange system slowdown 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, 09 Jul 2005 12:42:08 -0000 Hello everyone, for quiet a will I experience a strange system slowdowns. It looks like system freezes for a moment and then continues to work. The most noticeable result of this slowdown is sloppy mouse movement and skips in sound card buffer updates (with nVidia graphics card driver loaded). It can also be noticed when scrolling large amount of text in console (no x started). Sound skips only in X and with nvidia proprietary driver, there is no skips with Xorg nv driver (since it not installs interrupt handler), but mouse cursor still moves sloopy. The same problem present in FreeBSD 5.4-RELEASE. There is no such a problem in Linux or Windows. Hardware: Foxconn i925X, 512Mb, iPentium4 530 (Prescott)@3000Ghz, HTT enabled, GeForce 6600GT, SATA HDD. The system is: FreeBSD main.my.domain 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu Jul 7 21:55:30 UTC 2005 root@main.my.domain:/usr/obj/usr/src/sys/BLACK i386 Kernel config: machine i386 cpu I686_CPU ident BLACK # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapicam options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VESA device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE #device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners device smb device smbus device ichsmb The following device drivers are loaded: 2 3 0xc073d000 1cdcc linux.ko 3 1 0xc075a000 8080 if_re.ko 4 2 0xc0763000 1aaf8 miibus.ko 5 1 0xc077e000 8088 snd_emu10k1.ko 6 2 0xc0787000 1f528 sound.ko 7 1 0xc07a7000 1d9c cd9660_iconv.ko 8 6 0xc07a9000 49dc libiconv.ko 9 2 0xc07ae000 8bec cd9660.ko 10 1 0xc07b7000 8ec0 ng_ubt.ko 11 2 0xc07c0000 da3c netgraph.ko 12 1 0xc07ce000 3c00c0 nvidia.ko 13 16 0xc0b8f000 5f450 acpi.ko 14 1 0xc1d7c000 2000 ntfs_iconv.ko 15 1 0xc1d7e000 b000 ntfs.ko 16 1 0xc1dfd000 2000 msdosfs_iconv.ko 17 1 0xc1e02000 e000 msdosfs.ko 18 1 0xc1f93000 2000 blank_saver.ko 19 1 0xc1ff6000 2000 rtc.ko With best regards, Vladimir Novoseltsev From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 09:58:00 2005 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 23A6B16A41C for ; Sun, 10 Jul 2005 09:58:00 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4FCB43D45 for ; Sun, 10 Jul 2005 09:57:59 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 0A9661704D; Sun, 10 Jul 2005 11:57:58 +0200 (CEST) Date: Sun, 10 Jul 2005 11:57:58 +0200 From: Ed Schouten To: S?ren Lott Message-ID: <20050710095758.GB756@hoeg.nl> References: <200507090321.44704.soren3@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: <200507090321.44704.soren3@gmail.com> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sun, 10 Jul 2005 12:18:20 +0000 Cc: FreeBSD Current Subject: Re: installword broke everything 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, 10 Jul 2005 09:58:00 -0000 --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * S?ren Lott wrote: > boot -s > fsck -p > mount -u / > mount -a > adjkerntz -i > mergemaster -p > make installworld Aren't you supposed to run `mergemaster` afterwards? Yours, --=20 Ed Schouten --GPJrCs/72TxItFYR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0PElmVI4SHXwmhERAjhhAJ9JM2VohcEaywgEEuKI0zYeXRpULACgoVaU pD2TlqTiBw/g9UntJyzNhN4= =TBFx -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 12:27:37 2005 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 9D0ED16A41C; Sun, 10 Jul 2005 12:27:37 +0000 (GMT) (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 1BD4143D46; Sun, 10 Jul 2005 12:27:35 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with SMTP id j6ACRQck086292; Sun, 10 Jul 2005 21:27:26 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 10 Jul 2005 21:27:26 +0900 (JST) Message-Id: <200507101227.j6ACRQck086292@sakura.ninth-nine.com> From: Norikatsu Shigemura To: Antony T Curtis In-Reply-To: <1120993828.46929.7.camel@pcgem.xiphis.org> References: <20050704010715.A36404@saturn.kn-bremen.de> <200507040037.j640bg0v085158@gate.bitblocks.com> <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> <1120993828.46929.7.camel@pcgem.xiphis.org> X-Mailer: Sylpheed version 2.0.0beta5 (GTK+ 2.6.8; i386-portbld-freebsd6.0) 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-1.6 (sakura.ninth-nine.com [219.127.74.121]); Sun, 10 Jul 2005 21:27:29 +0900 (JST) X-Mailman-Approved-At: Sun, 10 Jul 2005 13:26:17 +0000 Cc: craig@xfoil.gank.org, jhb@FreeBSD.org, alc@FreeBSD.org, jeff@FreeBSD.org, nork@FreeBSD.org, qemu-devel@nongnu.org, freebsd-current@FreeBSD.org, bakul@BitBlocks.com, qemu-l@jelal.kn-bremen.de Subject: Re: [Qemu-devel] kqemu freebsd host smp problems? 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, 10 Jul 2005 12:27:37 -0000 On Sun, 10 Jul 2005 12:10:28 +0100 Antony T Curtis wrote: > > I confirmed that qemu on latest FreeBSD 6-current got more > > stability!!, but more little slowly:-( and a panic:-( too. > IMO, That flag is not the cause of the panics and that it should(tm) > work without requiring GIANT... > I think it is possible that the kqemu code is freeing a page without > unlocking it so that when another process does file IO which requires > pages to be allocated, attempts to wire those pages results in failure > and so a panic occurrs. > Perhaps if a different method for allocating memory rather than > contigmalloc/contigfree should be used by the kernel module. Hummm... I can't fix this issue. Please, please:-). > > Offtopic - but am I the only person who has modified the if_tap driver > to permit opening by non-superuser? Did you modify if_tap driver? I didn't, I set follwoing setting. 1. Add following lines to /etc/devfs.conf # Allow a user in the wheel group to query the if_tap device perm tap* 0660 2. Add following line to /etc/sysctl.conf net.link.tap.user_open=1 From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 16:34:43 2005 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 7E4E416A41C for ; Sun, 10 Jul 2005 16:34:43 +0000 (GMT) (envelope-from patfbsdc@davenulle.org) Received: from smtp.lamaiziere.net (lamaiziere.net [213.41.172.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D8843D4C for ; Sun, 10 Jul 2005 16:34:42 +0000 (GMT) (envelope-from patfbsdc@davenulle.org) Received: from localhost (unknown [192.168.1.2]) by smtp.lamaiziere.net (Postfix) with ESMTP id 7F7B026DC27 for ; Sun, 10 Jul 2005 18:34:40 +0200 (CEST) Received: from smtp.lamaiziere.net ([192.168.1.2]) by localhost (malpractice-12.lamaiziere.net [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 99473-04 for ; Sun, 10 Jul 2005 18:34:36 +0200 (CEST) Received: from feelgood (unknown [192.168.0.1]) by smtp.lamaiziere.net (Postfix) with ESMTP id D725826D153 for ; Sun, 10 Jul 2005 18:34:36 +0200 (CEST) From: Patrick =?iso-8859-1?q?Lamaizi=E8re?= Organization: >dave/nulle To: freebsd-current@freebsd.org Date: Sun, 10 Jul 2005 18:34:35 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507101834.35960.patfbsdc@davenulle.org> X-Virus-Scanned: by amavisd-new at lamaiziere.net Subject: July snapshot - acpi problem 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, 10 Jul 2005 16:34:43 -0000 Hi, With acpi enabled, my box freeze (no panic) after one or two minutes, even in single user. It seems related to some disk access (?). I tried to disable all integrated peripherals (usb and lan). I don't have any problem with ACPI enabled under 5.3 and 5.4. The MB is an abit NF7, with nForce2 chipset. dmesg with acpi: http://www.lamaiziere.net/private/dmesg-acpi.txt without acpi: http://www.lamaiziere.net/private/dmesg-wo-acpi.txt and with acpi under 5.4 http://www.lamaiziere.net/private/dmesg-54.txt How can i provide more usefull informations ? Regards. From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 16:56:24 2005 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 161E416A41C for ; Sun, 10 Jul 2005 16:56:24 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC7E043D4C for ; Sun, 10 Jul 2005 16:56:23 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id B2798173496; Sun, 10 Jul 2005 18:56:22 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 4CCC5405B; Sun, 10 Jul 2005 18:56:22 +0200 (CEST) Date: Sun, 10 Jul 2005 18:56:22 +0200 From: Jeremie Le Hen To: Artem Ignatiev Message-ID: <20050710165622.GW39292@obiwan.tataz.chchile.org> References: <20041102222000.GA65845@xor.obsecurity.org> <20050706073205.GA942@galgenberg.net> <20050706085737.GT73907@obiwan.tataz.chchile.org> <200507061116.17267.thierry@herbelot.com> <20050708215620.GN39292@obiwan.tataz.chchile.org> <7FCC20EB-A240-4EDC-B09A-31BEE5129676@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FCC20EB-A240-4EDC-B09A-31BEE5129676@mail.ru> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Ports are not ready for CFLAGS=-O2 in 6.0 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, 10 Jul 2005 16:56:24 -0000 Hi Artem, > >If we add something like this in ports/Mk/bsd.port.mk : > >%%% > > .if defined(PORT_CFLAGS) > > CFLAGS=${PORT_CFLAGS} > > .end > >%%% > > > >This will obviously break POLA because setting CFLAGS won't work as > >expected. > > Why not : > .if defined(PORT_CFLAGS) && !defined(CFLAGS) > CFLAGS=${PORT_CFLAGS} > .endif For me, the goal of PORT_CFLAGS is to bring the possibility to specify _alternate_ CFLAGs when building port. This means that PORT_CFLAGS needs to be usable even if CFLAGS is specified. Typically, make.conf(5) would contain both variables. > or even: > .if defined(PORT_CFLAGS) > CFLAGS=${PORT_CFLAGS} ${CFLAGS} > .endif The problem is mostly the same here. If make.conf(5) contains : %%% CFLAGS="-O2 -pipe -fomit-frame-pointer" PORT_CFLAGS="-O -pipe" %%% what you have written above would lead to have CFLAGS containing : %%% -O -pipe -O2 -pipe -fomit-frame-pointer %%% However, I'm maybe misunderstanding what you said. In this case, correct me please. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 17:26:44 2005 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 8AE8116A41C for ; Sun, 10 Jul 2005 17:26:44 +0000 (GMT) (envelope-from soren3@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23FEF43D4C for ; Sun, 10 Jul 2005 17:26:44 +0000 (GMT) (envelope-from soren3@gmail.com) Received: by wproxy.gmail.com with SMTP id i13so765739wra for ; Sun, 10 Jul 2005 10:26:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SUJZFv8ZIpL6Gdod8c9gTB9viNDqkirfkkv2SNRtHnBfmmZ0Y++3bQjIeUj8RXgUnHr/9YxDSVYGbuka3MsC3TstKc7ig22KqbuvVTNEml5b/X3l4cgfIXpLow8KQh6vnh1Tn94hfP6Yxqqrg1D4kZkLLWSvgGzTyJKbjCdegCg= Received: by 10.54.39.29 with SMTP id m29mr2924106wrm; Sun, 10 Jul 2005 10:26:43 -0700 (PDT) Received: by 10.54.39.18 with HTTP; Sun, 10 Jul 2005 10:26:43 -0700 (PDT) Message-ID: Date: Sun, 10 Jul 2005 14:26:43 -0300 From: =?ISO-8859-1?Q?S=F8ren_Lott?= To: freebsd-current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: installworld error rendering machine unusable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?S=F8ren_Lott?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2005 17:26:44 -0000 running installworld failed when upgrading from SNAP005 to newest -CURRENT, stops when installing kerberos5 but dont give a description of the error, after that everything dumps core with signal 11, running installworld again returns: Makefile, line 156: warning: "LC_ALL=3DC date" returned non-zero status and the machine is completly unusable. Installing on to a diferent $DESTDIR dont give any errors. i followed the exact steps in UPDATING: make buildworld make buildkernel KERNCONF=3Dcurrent6 make installkernel KERNCONF=3Dcurrent6 boot -s fsck -p mount -u / mount -a adjkerntz -i mergemaster -p make installworld From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 17:43:51 2005 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 A8D1016A41C for ; Sun, 10 Jul 2005 17:43:51 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB35743D45 for ; Sun, 10 Jul 2005 17:43:50 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 050D711A79; Sun, 10 Jul 2005 19:43:48 +0200 (CEST) Date: Sun, 10 Jul 2005 19:43:48 +0200 From: "Simon L. Nielsen" To: Poul-Henning Kamp Message-ID: <20050710174348.GB868@zaphod.nitro.dk> References: <1919.1120596290@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline In-Reply-To: <1919.1120596290@phk.freebsd.dk> User-Agent: Mutt/1.5.9i X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 10 Jul 2005 17:43:51 -0000 --T7mxYSe680VjQnyC Content-Type: multipart/mixed; boundary="z4+8/lEcDcG5Ke9S" Content-Disposition: inline --z4+8/lEcDcG5Ke9S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.07.05 22:44:50 +0200, Poul-Henning Kamp wrote: > This is an attempt to fix an boot0cfg/fdisk issue which I have > overlooked. >=20 > The patch adds a g_ctl method to geom_mbr and makes boot0cfg and > fdisk use it to modify the MBR if possible. >=20 > Please test and report ASAP in order to get this solution into > RELENG_6 I played around with this and made the attached regression test script and your patch seems to work fine, except for the "fdisk: Geom not found" output from fdisk (which I already mentioned to you) when it's not using the GEOM API. Test result for unpatched -CURRENT, with kern.geom.debugflags=3D0 : =2E/geom_mbr....1..38 ok 1 - MBR init ok 2 - reinstall boot0 bootblock; no slices ok 3 - set active slice; no slices ok 4 - add slice 1 ok 5 - reinstall boot0 bootblock; one slice ok 6 - set active slice; one slice ok 7 - add slice 2 ok 8 - reinstall boot0 bootblock; two slices ok 9 - set active slice; two slices ok 10 - add slice 3 ok 11 - reinstall boot0 bootblock; three slices ok 12 - set active slice; three slices ok 13 - add slice 4 ok 14 - reinstall boot0 bootblock; four slices ok 15 - set active slice; four slices ok 16 - del slice 4 ok 17 - del slice 3 ok 18 - del slice 2 ok 19 - reinstall boot0 bootblock ok 20 - set active slice not ok 21 - reinstall boot0 bootblock; one slice; mounted FS not ok 22 - set active slice; one slice; mounted FS not ok 23 - add slice 2; mounted FS not ok 24 - reinstall boot0 bootblock; two slices; mounted FS not ok 25 - set active slice; two slices; mounted FS not ok 26 - add slice 3; mounted FS not ok 27 - reinstall boot0 bootblock; three slices; mounted FS not ok 28 - set active slice; three slices; mounted FS not ok 29 - add slice 4; mounted FS not ok 30 - reinstall boot0 bootblock; four slices; mounted FS not ok 31 - set active slice; four slices; mounted FS not ok 32 - del slice 4; mounted FS not ok 33 - del slice 3; mounted FS ok 34 - del slice 2; mounted FS ok 35 - del all slices, with mounted FS not ok 36 - add slice 1-4, with mounted FS ok 37 - unmount FS not ok 38 - post md reconfig FAILED tests 21-33, 36, 38 Failed 15/38 tests, 60.53% okay Failed Test Stat Wstat Total Fail Failed List of Failed ---------------------------------------------------------------------------= ---- =2E/geom_mbr.t 38 15 39.47% 21-33 36 38 Failed 1/1 test scripts, 0.00% okay. 15/38 subtests failed, 60.53% okay. Test result for unpatched -CURRENT, with kern.geom.debugflags=3D16 : =2E/geom_mbr....1..38 ok 1 - MBR init ok 2 - reinstall boot0 bootblock; no slices ok 3 - set active slice; no slices ok 4 - add slice 1 ok 5 - reinstall boot0 bootblock; one slice ok 6 - set active slice; one slice ok 7 - add slice 2 ok 8 - reinstall boot0 bootblock; two slices ok 9 - set active slice; two slices ok 10 - add slice 3 ok 11 - reinstall boot0 bootblock; three slices ok 12 - set active slice; three slices ok 13 - add slice 4 ok 14 - reinstall boot0 bootblock; four slices ok 15 - set active slice; four slices ok 16 - del slice 4 ok 17 - del slice 3 ok 18 - del slice 2 ok 19 - reinstall boot0 bootblock ok 20 - set active slice ok 21 - reinstall boot0 bootblock; one slice; mounted FS ok 22 - set active slice; one slice; mounted FS not ok 23 - add slice 2; mounted FS ok 24 - reinstall boot0 bootblock; two slices; mounted FS ok 25 - set active slice; two slices; mounted FS not ok 26 - add slice 3; mounted FS ok 27 - reinstall boot0 bootblock; three slices; mounted FS ok 28 - set active slice; three slices; mounted FS not ok 29 - add slice 4; mounted FS ok 30 - reinstall boot0 bootblock; four slices; mounted FS ok 31 - set active slice; four slices; mounted FS not ok 32 - del slice 4; mounted FS not ok 33 - del slice 3; mounted FS ok 34 - del slice 2; mounted FS ok 35 - del all slices, with mounted FS not ok 36 - add slice 1-4, with mounted FS ok 37 - unmount FS ok 38 - post md reconfig FAILED tests 23, 26, 29, 32-33, 36 Failed 6/38 tests, 84.21% okay Failed Test Stat Wstat Total Fail Failed List of Failed ---------------------------------------------------------------------------= ---- =2E/geom_mbr.t 38 6 15.79% 23 26 29 32-33 36 Failed 1/1 test scripts, 0.00% okay. 6/38 subtests failed, 84.21% okay. Patched -CURRENT (not run verbose since there is no reason for verbose): =2E/geom_mbr....ok All tests successful. Files=3D1, Tests=3D38, 1 wallclock secs ( 0.12 cusr + 0.20 csys =3D 0.33= CPU) --=20 Simon L. Nielsen --z4+8/lEcDcG5Ke9S-- --T7mxYSe680VjQnyC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0V5Uh9pcDSc1mlERAo7+AKDJVznliT31dZLBLEZ91WKsq4VgjwCgxET2 cTSDrPZGstor/+Im16/6ByY= =csNp -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 17:55:48 2005 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 2630616A41C for ; Sun, 10 Jul 2005 17:55:48 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58C5043D46 for ; Sun, 10 Jul 2005 17:55:47 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 3BC1311A79; Sun, 10 Jul 2005 19:55:46 +0200 (CEST) Date: Sun, 10 Jul 2005 19:55:46 +0200 From: "Simon L. Nielsen" To: Poul-Henning Kamp Message-ID: <20050710175545.GC868@zaphod.nitro.dk> References: <1919.1120596290@phk.freebsd.dk> <20050710174348.GB868@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FeAIMMcddNRN4P4/" Content-Disposition: inline In-Reply-To: <20050710174348.GB868@zaphod.nitro.dk> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 10 Jul 2005 17:55:48 -0000 --FeAIMMcddNRN4P4/ Content-Type: multipart/mixed; boundary="CGDBiGfvSTbxKZlW" Content-Disposition: inline --CGDBiGfvSTbxKZlW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.07.10 19:43:48 +0200, Simon L. Nielsen wrote: > On 2005.07.05 22:44:50 +0200, Poul-Henning Kamp wrote: >=20 > > This is an attempt to fix an boot0cfg/fdisk issue which I have > > overlooked. > >=20 > > The patch adds a g_ctl method to geom_mbr and makes boot0cfg and > > fdisk use it to modify the MBR if possible. > >=20 > > Please test and report ASAP in order to get this solution into > > RELENG_6 >=20 > I played around with this and made the attached regression test script > and your patch seems to work fine, except for the "fdisk: Geom not > found" output from fdisk (which I already mentioned to you) when it's > not using the GEOM API. Mailman removed the attachment so I will try once more. I also put it at http://people.freebsd.org/~simon/tmp/geom_mbr.t . --=20 Simon L. Nielsen --CGDBiGfvSTbxKZlW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="geom_mbr.t" #!/bin/sh # # Copyright (c) 2005 Simon L. Nielsen # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $FreeBSD$ # Note, set the DEBUG environment variable for some debug output. # Simple error "handling" during setup set -e name="test" base=`basename $0` mdbacking=`mktemp -t ${base}` tmpfile=`mktemp -t ${base}` tmpmnt=`mktemp -d -t ${base}` # Slice entries for disk p1="p 1 165 0 4032" p1_0="p 1 0 0 0" p2="p 2 165 4095 3969" p3="p 3 165 8127 3969" p4="p 4 165 12096 4032" actpar=1 nr=1 expectstr() { expect=$1 txt=$2 tname=$3 if [ x"$tname" != x ]; then tname="- $tname" fi if [ x"$expect" = x"$txt" ]; then echo "ok $nr" $tname else echo "not ok $nr" $tname [ -n "$DEBUG" ] && echo "$expect" != "$txt" >&2 fi nr=$(($nr + 1)) } expectdevs() { expect=$1 tname=$2 devs=$(cd /dev && echo ${dev}*) expectstr "$expect" "$devs" "$tname" } expectslices() { expect=$1 tname=$2 devs=$(cd /dev && echo ${dev}* | sed -e s/${dev}//g -e 's/ / /g' \ -e 's/^ //g') expectstr "$expect" "$devs" "$tname" } fdiskf() { p=$1 expect=$2 tname=$3 printf "$p\n" > ${tmpfile} if [ -z "$DEBUG" ]; then fdisk -f ${tmpfile} -i ${dev} >/dev/null 2>&1 | \ grep -v "^fdisk: Geom not found" else fdisk -f ${tmpfile} -i ${dev} fi expectslices "$expect" "$tname" } boot0tests() { tnameextra=$1 boot0cfg -B $dev >/dev/null 2>&1 expectstr "0" "$?" "reinstall boot0 bootblock${tnameextra}" boot0cfg -s ${actpar} $dev >/dev/null 2>&1 expectstr "0" "$?" "set active slice${tnameextra}" if [ $actpar = 2 ]; then actpar=1 else actpar=2 fi } echo '1..38' # Init md dd if=/dev/zero of=${mdbacking} bs=1m count=5 >/dev/null 2>&1 dev=`mdconfig -a -t vnode -f ${mdbacking} -x 63 -y 16` || exit 1 [ -n "${dev}" ] || exit 1 # Init done set +e # Init disk, no slices fdisk -f /dev/null -i ${dev} > /dev/null 2>&1 \ | grep -v "fdisk: invalid fdisk partition table found" expectdevs "$dev" "MBR init" # First basic tests without any RW consumers of the MBR boot0tests "; no slices" fdiskf "$p1" "s1" "add slice 1" boot0tests "; one slice" fdiskf "$p1\n$p2" "s1 s2" "add slice 2" boot0tests "; two slices" fdiskf "$p1\n$p2\n$p3" "s1 s2 s3" "add slice 3" boot0tests "; three slices" fdiskf "$p1\n$p2\n$p3\n$p4" "s1 s2 s3 s4" "add slice 4" boot0tests "; four slices" fdiskf "$p1\n$p2\n$p3" "s1 s2 s3" "del slice 4" fdiskf "$p1\n$p2" "s1 s2" "del slice 3" fdiskf "$p1" "s1" "del slice 2" boot0tests "" # Now try to do stuff with a mounted FS, IE. we have a RW consumer of the MBR newfs /dev/${dev}s1 >/dev/null 2>&1 mount /dev/${dev}s1 ${tmpmnt} boot0tests "; one slice; mounted FS" fdiskf "$p1\n$p2" "s1 s2" "add slice 2; mounted FS" boot0tests "; two slices; mounted FS" fdiskf "$p1\n$p2\n$p3" "s1 s2 s3" "add slice 3; mounted FS" boot0tests "; three slices; mounted FS" fdiskf "$p1\n$p2\n$p3\n$p4" "s1 s2 s3 s4" "add slice 4; mounted FS" boot0tests "; four slices; mounted FS" fdiskf "$p1\n$p2\n$p3" "s1 s2 s3" "del slice 4; mounted FS" fdiskf "$p1\n$p2" "s1 s2" "del slice 3; mounted FS" fdiskf "$p1" "s1" "del slice 2; mounted FS" # Now try to shoot our foot off and hope GEOM saves us: fdiskf "${p1_0}" "s1" "del all slices, with mounted FS" # Now prepare so we can test if md reattach will pick stuff up fdiskf "$p1\n$p2\n$p3\n$p4" "s1 s2 s3 s4" "add slice 1-4, with mounted FS" umount ${tmpmnt} expectstr "0" "$?" "unmount FS" # Reattach md device so we _really_ pick up any change mdconfig -d -u $dev dev=`mdconfig -a -t vnode -f ${mdbacking} -x 63 -y 16` || exit 1 expectslices "s1 s2 s3 s4" "post md reconfig" # Cleanup rm -f ${tmpfile} rmdir ${tmpmnt} mdconfig -d -u $dev rm -f ${mdbacking} --CGDBiGfvSTbxKZlW-- --FeAIMMcddNRN4P4/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0WEhh9pcDSc1mlERAqK7AKC2ChyEtSDqHsuSPyW92jTRPvd+fQCffZSZ vfhgORTQnveq5TADrkAN3nw= =V1Hq -----END PGP SIGNATURE----- --FeAIMMcddNRN4P4/-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 19:07:54 2005 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 0D00E16A41C for ; Sun, 10 Jul 2005 19:07:54 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9737643D46 for ; Sun, 10 Jul 2005 19:07:53 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from [83.237.204.121] (port=48646 helo=[192.168.0.8]) by mx3.mail.ru with esmtp id 1Drh9c-0000IN-00 for freebsd-current@freebsd.org; Sun, 10 Jul 2005 23:07:52 +0400 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050710165622.GW39292@obiwan.tataz.chchile.org> References: <20041102222000.GA65845@xor.obsecurity.org> <20050706073205.GA942@galgenberg.net> <20050706085737.GT73907@obiwan.tataz.chchile.org> <200507061116.17267.thierry@herbelot.com> <20050708215620.GN39292@obiwan.tataz.chchile.org> <7FCC20EB-A240-4EDC-B09A-31BEE5129676@mail.ru> <20050710165622.GW39292@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <393F7F07-FE7C-41A1-9A7B-0F6552124EC2@mail.ru> Content-Transfer-Encoding: 7bit From: Artem Ignatiev Date: Sun, 10 Jul 2005 23:07:47 +0400 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.730) Subject: Re: HEADS UP: Ports are not ready for CFLAGS=-O2 in 6.0 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, 10 Jul 2005 19:07:54 -0000 On 10.07.2005, at 20:56, Jeremie Le Hen wrote: > Hi Artem, >>> If we add something like this in ports/Mk/bsd.port.mk : >>> %%% >>> .if defined(PORT_CFLAGS) >>> CFLAGS=${PORT_CFLAGS} >>> .end >>> %%% >>> >>> This will obviously break POLA because setting CFLAGS won't work as >>> expected. >>> >> >> Why not : >> .if defined(PORT_CFLAGS) && !defined(CFLAGS) >> CFLAGS=${PORT_CFLAGS} >> .endif > For me, the goal of PORT_CFLAGS is to bring the possibility to specify > _alternate_ CFLAGs when building port. This means that PORT_CFLAGS > needs to be usable even if CFLAGS is specified. Typically, > make.conf(5) > would contain both variables. >> or even: >> .if defined(PORT_CFLAGS) >> CFLAGS=${PORT_CFLAGS} ${CFLAGS} >> .endif > > The problem is mostly the same here. If make.conf(5) contains : > %%% > CFLAGS="-O2 -pipe -fomit-frame-pointer" > PORT_CFLAGS="-O -pipe" > %%% > > what you have written above would lead to have CFLAGS containing : > -O -pipe -O2 -pipe -fomit-frame-pointer > > However, I'm maybe misunderstanding what you said. In this case, > correct me please. Yeah, I missed this. I was trying to reach this: If nothing regarding CFLAGS is given in the command line, port is built with PORTS_CFLAGS. If CFLAGS are set in command line, they are appended to PORTS_CFLAGS, thus effectively overriding PORTS_CFLAGS. I had missed that CFLAGS may be set in make.conf Then, one of the solutions may be to change sys.mk so it saves CFLAGS given from environment/command line before parsing make.conf, and if we are building some port, restore or reevaluate CFLAGS using PORT_CFLAGS and user-set CFLAGS. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 02:42:07 2005 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 BB9EC16A41C for ; Mon, 11 Jul 2005 02:42:07 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B0443D4C for ; Mon, 11 Jul 2005 02:42:07 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j6B2fmaW062810; Sun, 10 Jul 2005 22:41:48 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j6B2fi6d062807; Sun, 10 Jul 2005 22:41:48 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 10 Jul 2005 22:41:44 -0400 (EDT) From: Andre Guibert de Bruet To: "Li, Qing" In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C019E8ECC@bcs-mail3.internal.cacheflow.com> Message-ID: <20050710224030.U80892@lexi.siliconlandmark.com> References: <48D44BB27BDE3840BDF18E59CB169A5C019E8ECC@bcs-mail3.internal.cacheflow.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.538, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: "Mahdavi, Jamshid" , freebsd-current@freebsd.org Subject: Re: monday 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, 11 Jul 2005 02:42:07 -0000 On Fri, 8 Jul 2005, Li, Qing wrote: > Are we meeting at the office on Monday > and going to the airport together? Go without me, I will be mulling some code then... Andy ;-) /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 02:45:12 2005 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 3F3F116A41C; Mon, 11 Jul 2005 02:45:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6868D43D49; Mon, 11 Jul 2005 02:45:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6FD2351419; Sun, 10 Jul 2005 22:44:51 -0400 (EDT) Date: Sun, 10 Jul 2005 22:44:51 -0400 From: Kris Kennaway To: phk@FreeBSD.org, current@FreeBSD.org Message-ID: <20050711024451.GA69406@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: panic: ruleset 0 already running 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, 11 Jul 2005 02:45:12 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Up-to-date 6.0 SMP machine. Devfs mounts are coming and going, but there should be no transient devices (which are known to cause panics when racing with umount), and I am not using any explicit rulesets. Tracing pid 46736 tid 100131 td 0xc6b1aa80 kdb_enter(c07400fa,1,c07397b9,ee25ab60,c6b1aa80) at kdb_enter+0x30 panic(c07397b9,0,c6740d00,3,c7352980) at panic+0x13e devfs_ruleset_applyde(c66ee160,c7352980,ee25abc8,c0515fdf,c9345100) at devfs_ruleset_applyde+0x2a devfs_rules_apply(c9345100,c7352980,0,c6b1aa80,c0739625) at devfs_rules_apply+0x37 devfs_populate(c9345100,1,0,c6b1aa80,c0739625) at devfs_populate+0x2f3 devfs_readdir(ee25ac88,0,0,cada7e70,ee25acd4) at devfs_readdir+0x96 VOP_READDIR_APV(c07751a0,ee25ac88,c6b1aa80,c074824c,e4d) at VOP_READDIR_APV+0x9d getdirentries(c6b1aa80,ee25ad04,10,421,4) at getdirentries+0x171 syscall(806003b,806003b,bfbf003b,8056200,1) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0x280d020f, esp = 0xbfbfe7ac, ebp = 0xbfbfe7d8 --- I am not able to dump core on this machine, so I will leave it in DDB for now. Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0d0iWry0BWjoQKURAtXRAJwPayMOqjOuWeLy+dKqBXs9U+x3NwCgy5tb 5Rpq9e23Bt05RpAJKHolEeg= =5wDd -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 05:24:19 2005 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 086B816A41C for ; Mon, 11 Jul 2005 05:24:19 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E25D43D48 for ; Mon, 11 Jul 2005 05:24:18 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so733240rne for ; Sun, 10 Jul 2005 22:24:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nCoGJETJs5tBiph+qOG8kgTsQetZOk24p9E7X6hctlZ131PNeSAk5NDkeMj8Vo1s1bn1nKKnQ2VAn9KkohfcpOXPw8JUUza2YTz7WoZqKi4CBKWQdlsd8g2b0hHpDRmu6YSHw7qJVbqenDedSkwfBZWps3h6WBdS6JcBVFYQUSk= Received: by 10.38.104.15 with SMTP id b15mr1756764rnc; Sun, 10 Jul 2005 22:24:17 -0700 (PDT) Received: by 10.38.101.41 with HTTP; Sun, 10 Jul 2005 22:24:17 -0700 (PDT) Message-ID: Date: Mon, 11 Jul 2005 14:24:17 +0900 From: Eric Kjeldergaard To: Neh In-Reply-To: <20050706012948.DFE9643D45@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050706012948.DFE9643D45@mx1.FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: Ext2fs strange errors on -CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Kjeldergaard List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2005 05:24:19 -0000 On 7/6/05, Neh wrote: > I'm having some problems using ext2fs. > I have a mounted ext2 partition. It mounts ok. > I can do "ls dir" and it show me the contents. > But when i type "ls -l dir" for example, i got messages like: > "no such file or directory" >=20 > I can do "cp" to that partition, can do "rm" in some file, but copying fr= om > there or deleting recursive, like "rm -rf" show me "no such file or > directory" >=20 > some outputs: >=20 > root@plasma# uname -a > FreeBSD plasma.box.org 6.0-CURRENT FreeBSD 6.0-CURRENT #3: Tue Jul 5 > 21:22:11 BRT 2005 root@plasma.box.org:/usr/src/sys/i386/compile/JAH= =20 > i386 >=20 > root@plasma# mount > /dev/ad0s4a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/ad0s4e on /tmp (ufs, local, soft-updates) > /dev/ad0s4f on /usr (ufs, local, soft-updates) > /dev/ad0s4d on /var (ufs, local, soft-updates) > /dev/ad0s3 on /mnt (ext2fs, local) >=20 > root@plasma# pwd > /mnt > root@plasma# ls > gabi lero lfs.old rootz > ktrace.out lfs lost+found > root@plasma# ls -l > ls: gabi: No such file or directory > ls: ktrace.out: No such file or directory > ls: lero: No such file or directory > ls: lfs: No such file or directory > ls: lfs.old: No such file or directory > ls: lost+found: No such file or directory > ls: rootz: No such file or directory > total 0 >=20 > I checked it on 5.4-STABLE and it's working ok. >=20 > I have used ktrace to see what's going, but i can't say what is, so i > included the output of both "ls" and "ls -l" here: >=20 > http://sp-dhn.com.br/~neh/freebsd/ >=20 I just want to verify that this isn't isolated. I was having the same problem when I still had ext2 drives. --=20 If I write a signature, my emails will appear more personalised. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 08:27:10 2005 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 71D5316A41C for ; Mon, 11 Jul 2005 08:27:10 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89B0043D49 for ; Mon, 11 Jul 2005 08:27:09 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j6B8O4Wd066114 for freebsd-current@freebsd.org.checked; Mon, 11 Jul 2005 12:24:04 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j6B8LagM066077; Mon, 11 Jul 2005 12:21:36 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <42D22C1C.8070908@cronyx.ru> Date: Mon, 11 Jul 2005 12:21:48 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <42C57523.4050302@cronyx.ru> <20050701.121826.56566740.imp@bsdimp.com> <42CAAFCB.2080207@cronyx.ru> <20050705.164135.12222348.imp@bsdimp.com> In-Reply-To: <20050705.164135.12222348.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: BUS infrastructure problem 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, 11 Jul 2005 08:27:10 -0000 Hi, I've found the reason. It was there where I do not expect it. The only function's return value I didn't check was ... ... it was device_set_driver. It returns ENOMEM, all other stuff goes well. More over it seems that at device_probe_child () device_set_driver do not have memory problems, but driver methods table are broken. Something tells me that the call of device_set_driver from device_probe_child is intended for recovering from such case but it doesn't work. Or this is wrong guess? Do you think the case is closed or this is some misbehavior that could be fixed? rik M. Warner Losh wrote: >In message: <42CAAFCB.2080207@cronyx.ru> > Roman Kurakin writes: >: Hi, >: >: M. Warner Losh wrote: >: >: >In message: <42C57523.4050302@cronyx.ru> >: > Roman Kurakin writes: >: >: I observe the followin strange behaviour with current: with some very >: >: high probability after indentify callback I didn't get a probe callback. I >: >: didn't find yet anything that could tell me why I see this. All function >: >: return me that all operations was successful. >: >: >: >: PS. This driver is cx(4) and I am currently try to debug it in async mode >: >: (I get strange panics while its work if I didn't get into situation with >: >: probe()). >: >: >: >: Any ideas? >: > >: >I'll be happy to help you with this. >: > >: > >: The last place I get to is the call of DEVICE_PROBE macro. >: But I do not see the call of my function. >: There is other thing, it seems that probability highly increases >: if the system reboots after panic and needs filesystem check. >: >: This is all information I have now. I use printf as a primary >: debug technic so I need to think how to move farther. >: >: Ideas? > >That sounds really weird. Add a Debugger() call and see if you wind >up in the debugger. > > >Warner >_______________________________________________ >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 Mon Jul 11 03:46:21 2005 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 A51C216A41C for ; Mon, 11 Jul 2005 03:46:21 +0000 (GMT) (envelope-from luckrill@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C96E43D53 for ; Mon, 11 Jul 2005 03:46:21 +0000 (GMT) (envelope-from luckrill@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so1313507wri for ; Sun, 10 Jul 2005 20:46:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:x-accept-language:mime-version:to:subject:content-type:from; b=JQUd4ch+txMcvtwwgsSiH6sNVE7WQ5IXp06gWp43N5ll30OQI2qk7C37cx+CU1Y2UR3EpyUln3nY63lghsPdPN4QzzBPFne0U8qzYXVuv2mjhOGZf0390Crb8T2/6Kr9jZKJ0Sr7/oGWHDYI3Z9iC+hpu4EO8c3Q9rltU0ETt88= Received: by 10.54.19.78 with SMTP id 78mr2151542wrs; Sun, 10 Jul 2005 20:46:20 -0700 (PDT) Received: from ?192.168.1.39? ([159.226.5.250]) by mx.gmail.com with ESMTP id 39sm13902406wrl.2005.07.10.20.46.18; Sun, 10 Jul 2005 20:46:20 -0700 (PDT) Message-ID: <42D1EB8C.7040500@yahoo.com.cn> Date: Mon, 11 Jul 2005 11:46:20 +0800 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050701) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------040009030107090808060901" From: Jiang Zhixiang X-Mailman-Approved-At: Mon, 11 Jul 2005 12:05:46 +0000 Subject: jdk14 cannot work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: luckrill@yahoo.com.cn List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2005 03:46:21 -0000 This is a multi-part message in MIME format. --------------040009030107090808060901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I new install jdk14, but it cannot work, why? My host is: FreeBSD Rill.net 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sat Jul 9 11:06:52 CST 2005 root@Rill.net:/usr/obj/build/src/sys/GENERIC i386 The attachment is runing log for start jedit. please help me and tell me why? -Rill --------------040009030107090808060901 Content-Type: text/plain; name="hs_err_pid70346.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hs_err_pid70346.log" CkFuIHVuZXhwZWN0ZWQgZXhjZXB0aW9uIGhhcyBiZWVuIGRldGVjdGVkIGluIG5hdGl2ZSBj b2RlIG91dHNpZGUgdGhlIFZNLgpVbmV4cGVjdGVkIFNpZ25hbCA6IDExIG9jY3VycmVkIGF0 IFBDPTB4MzJCNjZENEEKRnVuY3Rpb249WHRXaWRnZXRUb0FwcGxpY2F0aW9uQ29udGV4dCsw eDFBCkxpYnJhcnk9L3Vzci9YMTFSNi9saWIvbGliWHQuc28uNgoKQ3VycmVudCBKYXZhIHRo cmVhZDoKCWF0IHN1bi5hd3QubW90aWYuTVRvb2xraXQubG9hZFN5c3RlbUNvbG9ycyhOYXRp dmUgTWV0aG9kKQoJYXQgamF2YS5hd3QuU3lzdGVtQ29sb3IudXBkYXRlU3lzdGVtQ29sb3Jz KFN5c3RlbUNvbG9yLmphdmE6NDE3KQoJYXQgamF2YS5hd3QuU3lzdGVtQ29sb3IuPGNsaW5p dD4oU3lzdGVtQ29sb3IuamF2YTo0MDkpCglhdCBzdW4uYXd0LlgxMUdyYXBoaWNzQ29uZmln LmdldENvbG9yTW9kZWwoWDExR3JhcGhpY3NDb25maWcuamF2YToyMTIpCgktIGxvY2tlZCA8 MHgyYzUwMGUxOD4gKGEgc3VuLmF3dC5YMTFHcmFwaGljc0NvbmZpZykKCWF0IHN1bi5hd3Qu WDExU3VyZmFjZURhdGEuZ2V0U3VyZmFjZVR5cGUoWDExU3VyZmFjZURhdGEuamF2YTozNzQp CglhdCBzdW4uYXd0LlgxMUdyYXBoaWNzQ29uZmlnLmdldFN1cmZhY2VUeXBlKFgxMUdyYXBo aWNzQ29uZmlnLmphdmE6MTE2KQoJLSBsb2NrZWQgPDB4MmM1MDBlMTg+IChhIHN1bi5hd3Qu WDExR3JhcGhpY3NDb25maWcpCglhdCBzdW4uYXd0LlgxMVN1cmZhY2VEYXRhLmNyZWF0ZURh dGEoWDExU3VyZmFjZURhdGEuamF2YToyOTIpCglhdCBzdW4uYXd0Lm1vdGlmLk1Db21wb25l bnRQZWVyLmluaXRpYWxpemUoTUNvbXBvbmVudFBlZXIuamF2YToxOTYpCglhdCBzdW4uYXd0 Lm1vdGlmLk1Db21wb25lbnRQZWVyLmluaXQoTUNvbXBvbmVudFBlZXIuamF2YToyMjgpCglh dCBzdW4uYXd0Lm1vdGlmLk1XaW5kb3dQZWVyLmluaXQoTVdpbmRvd1BlZXIuamF2YTo5MCkK CWF0IHN1bi5hd3QubW90aWYuTUZyYW1lUGVlci48aW5pdD4oTUZyYW1lUGVlci5qYXZhOjU4 KQoJYXQgc3VuLmF3dC5tb3RpZi5NVG9vbGtpdC5jcmVhdGVGcmFtZShNVG9vbGtpdC5qYXZh OjIwOSkKCWF0IGphdmEuYXd0LkZyYW1lLmFkZE5vdGlmeShGcmFtZS5qYXZhOjQ3MikKCS0g bG9ja2VkIDwweDJjNzNmNjc4PiAoYSBqYXZhLmF3dC5Db21wb25lbnQkQVdUVHJlZUxvY2sp CglhdCBqYXZhLmF3dC5XaW5kb3cuYWRkTm90aWZ5KFdpbmRvdy5qYXZhOjQxMykKCS0gbG9j a2VkIDwweDJjNzNmNjc4PiAoYSBqYXZhLmF3dC5Db21wb25lbnQkQVdUVHJlZUxvY2spCglh dCBqYXZhLmF3dC5XaW5kb3cuc2hvdyhXaW5kb3cuamF2YTo0NTkpCglhdCBqYXZhLmF3dC5D b21wb25lbnQuc2hvdyhDb21wb25lbnQuamF2YToxMTMzKQoJYXQgamF2YS5hd3QuQ29tcG9u ZW50LnNldFZpc2libGUoQ29tcG9uZW50LmphdmE6MTA4OCkKCWF0IG9yZy5nanQuc3AuamVk aXQuZ3VpLlNwbGFzaFNjcmVlbi48aW5pdD4oU3BsYXNoU2NyZWVuLmphdmE6NjcpCglhdCBv cmcuZ2p0LnNwLmplZGl0LkdVSVV0aWxpdGllcy5zaG93U3BsYXNoU2NyZWVuKEdVSVV0aWxp dGllcy5qYXZhOjE1MTkpCglhdCBvcmcuZ2p0LnNwLmplZGl0LmpFZGl0Lm1haW4oakVkaXQu amF2YToyOTkpCgpEeW5hbWljIGxpYnJhcmllczoKMHg4MDQ4MDAwIAkvdXNyL2xvY2FsL2pk azEuNC4yL2Jpbi9qYXZhCjB4MjgwN2MwMDAgCS91c3IvbGliL2xpYnB0aHJlYWQuc28uMQow eDI4MGEzMDAwIAkvbGliL2xpYmMuc28uNgoweDI4MThhMDAwIAkvdXNyL2xvY2FsL2pkazEu NC4yL2pyZS9saWIvaTM4Ni9jbGllbnQvbGlianZtLnNvCjB4Mjg1YmYwMDAgCS91c3IvbGli L2xpYnN0ZGMrKy5zby40CjB4Mjg2OTMwMDAgCS9saWIvbGlibS5zby4zCjB4Mjg2YWEwMDAg CS91c3IvbG9jYWwvamRrMS40LjIvanJlL2xpYi9pMzg2L25hdGl2ZV90aHJlYWRzL2xpYmhw aS5zbwoweDI4NmI4MDAwIAkvdXNyL2xvY2FsL2pkazEuNC4yL2pyZS9saWIvaTM4Ni9saWJ2 ZXJpZnkuc28KMHgyODZjZDAwMCAJL3Vzci9sb2NhbC9qZGsxLjQuMi9qcmUvbGliL2kzODYv bGliamF2YS5zbwoweDI4NmViMDAwIAkvdXNyL2xvY2FsL2pkazEuNC4yL2pyZS9saWIvaTM4 Ni9saWJ6aXAuc28KMHgzMjg4NTAwMCAJL3Vzci9sb2NhbC9qZGsxLjQuMi9qcmUvbGliL2kz ODYvbGliYXd0LnNvCjB4MzJhZmQwMDAgCS91c3IvbG9jYWwvamRrMS40LjIvanJlL2xpYi9p Mzg2L2xpYm1saWJfaW1hZ2Uuc28KMHgzMmI0OTAwMCAJL3Vzci9YMTFSNi9saWIvbGliWHAu c28uNgoweDMyYjUxMDAwIAkvdXNyL1gxMVI2L2xpYi9saWJYdC5zby42CjB4MzJiOWIwMDAg CS91c3IvWDExUjYvbGliL2xpYlhleHQuc28uNgoweDMyYmE4MDAwIAkvdXNyL1gxMVI2L2xp Yi9saWJYdHN0LnNvLjYKMHgzMmJhZDAwMCAJL3Vzci9YMTFSNi9saWIvbGliWG11LnNvLjYK MHgzMmJjMTAwMCAJL3Vzci9YMTFSNi9saWIvbGliWDExLnNvLjYKMHgzMmM4MjAwMCAJL3Vz ci9YMTFSNi9saWIvbGliU00uc28uNgoweDMyYzhhMDAwIAkvdXNyL1gxMVI2L2xpYi9saWJJ Q0Uuc28uNgoweDMyY2EwMDAwIAkvdXNyL2xvY2FsL2pkazEuNC4yL2pyZS9saWIvaTM4Ni9s aWJmb250bWFuYWdlci5zbwoweDJjNDdlMDAwIAkvdXNyL1gxMVI2L2xpYi9YMTEvbG9jYWxl L2xpYi9jb21tb24veGxvY2FsZS5zby4yCjB4MzJkNzcwMDAgCS91c3IvWDExUjYvbGliL1gx MS9sb2NhbGUvbGliL2NvbW1vbi94bGliaTE4bi5zby4yCjB4MzJkN2MwMDAgCS91c3IvWDEx UjYvbGliL2xpYlhjdXJzb3Iuc28uMQoweDMyZDg1MDAwIAkvdXNyL1gxMVI2L2xpYi9saWJY cmVuZGVyLnNvLjEKMHgzMmQ4ZDAwMCAJL3Vzci9YMTFSNi9saWIvWDExL2xvY2FsZS9saWIv Y29tbW9uL3hpbWNwLnNvLjIKMHgzMmRhODAwMCAJL3Vzci9YMTFSNi9saWIvWDExL2xvY2Fs ZS9saWIvY29tbW9uL3hvbUdlbmVyaWMuc28uMgoweDI4MDRlMDAwIAkvbGliZXhlYy9sZC1l bGYuc28uMQoKSGVhcCBhdCBWTSBBYm9ydDoKSGVhcAogZGVmIG5ldyBnZW5lcmF0aW9uICAg dG90YWwgNTc2SywgdXNlZCA0NThLIFsweDJjNDgwMDAwLCAweDJjNTIwMDAwLCAweDJjNmYw MDAwKQogIGVkZW4gc3BhY2UgNTEySywgIDc3JSB1c2VkIFsweDJjNDgwMDAwLCAweDJjNGUy YjQ4LCAweDJjNTAwMDAwKQogIGZyb20gc3BhY2UgNjRLLCAxMDAlIHVzZWQgWzB4MmM1MDAw MDAsIDB4MmM1MTAwMDAsIDB4MmM1MTAwMDApCiAgdG8gICBzcGFjZSA2NEssICAgMCUgdXNl ZCBbMHgyYzUxMDAwMCwgMHgyYzUxMDAwMCwgMHgyYzUyMDAwMCkKIHRlbnVyZWQgZ2VuZXJh dGlvbiAgIHRvdGFsIDE0MDhLLCB1c2VkIDY3MEsgWzB4MmM2ZjAwMDAsIDB4MmM4NTAwMDAs IDB4MmU0ODAwMDApCiAgIHRoZSBzcGFjZSAxNDA4SywgIDQ3JSB1c2VkIFsweDJjNmYwMDAw LCAweDJjNzk3OTc4LCAweDJjNzk3YTAwLCAweDJjODUwMDAwKQogY29tcGFjdGluZyBwZXJt IGdlbiAgdG90YWwgNDYwOEssIHVzZWQgNDQ0MUsgWzB4MmU0ODAwMDAsIDB4MmU5MDAwMDAs IDB4MzI0ODAwMDApCiAgIHRoZSBzcGFjZSA0NjA4SywgIDk2JSB1c2VkIFsweDJlNDgwMDAw LCAweDJlOGQ2NzQwLCAweDJlOGQ2ODAwLCAweDJlOTAwMDAwKQoKTG9jYWwgVGltZSA9IE1v biBKdWwgMTEgMTE6MTk6MzYgMjAwNQpFbGFwc2VkIFRpbWUgPSA3CiMKIyBUaGUgZXhjZXB0 aW9uIGFib3ZlIHdhcyBkZXRlY3RlZCBpbiBuYXRpdmUgY29kZSBvdXRzaWRlIHRoZSBWTQoj CiMgSmF2YSBWTTogSmF2YSBIb3RTcG90KFRNKSBDbGllbnQgVk0gKDEuNC4yLXA3LXJvb3Rf MTBfanVsXzIwMDVfMTFfNDggbWl4ZWQgbW9kZSkKIwo= --------------040009030107090808060901-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 12:22:07 2005 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 985B316A41C; Mon, 11 Jul 2005 12:22:07 +0000 (GMT) (envelope-from current@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFBB343D49; Mon, 11 Jul 2005 12:22:06 +0000 (GMT) (envelope-from current@deadcafe.de) Received: from dialin.t-online.de (p54A5DBA1.dip.t-dialin.net [84.165.219.161]) by deadcafe.de (8.13.4/8.13.4/Rock) with ESMTP id j6BCM1Px073215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2005 14:22:04 +0200 (CEST) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4/8.13.4/Rock) with ESMTP id j6BCLtkI059580; Mon, 11 Jul 2005 14:21:55 +0200 (CEST) Message-ID: <42D26463.507@deadcafe.de> Date: Mon, 11 Jul 2005 14:21:55 +0200 From: Daniel Rock User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Paul Richards References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Current amd64, "nve0: device timeout" with nForce4 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, 11 Jul 2005 12:22:07 -0000 Paul Richards schrieb: > Hi, > With CURRENT (checked out earlier this evening) on amd64 I cannot get > my nForce4 ethernet adaptor to work. The module automatically loads > but I get messages of the form "nve0: device timeout(..)" when I > attempt to use the interface. > > This is exactly the same problem that RELEASE 5.4 had using the nvlan > port on my system. I upgraded to current as I was told that the > integrated nve driver in 6.0 was more up to date than the nvlan port. > > Does anyone have nForce4 ethernet working with any version of FreeBSD > on amd64? Is this something to do with my particular nForce4 chipset > or is the nForce4 ethernet generally unsupported at this time? How much memory do you have? I'm too having trouble with the nve driver under FreeBSD, but only if memory is mapped beyond the 4 GB mark. I have a Tyan S2895 mobo with a memory hole at 2.75 GB for PCI cards. In the BIOS I can decide how to remap this memory: Disabled/Hardware/Software If I choose to set this setting to "Disabled" my nve driver works fine, with any other setting I too get "device timeout"'s. Below are my memory chunks for the different settings: Hardware: real memory = 5637144576 (5376 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000090fff, 589824 bytes (144 pages) 0x0000000000985000 - 0x00000000a616ffff, 2776543232 bytes (677867 pages) 0x0000000100000000 - 0x000000014ffdffff, 1342046208 bytes (327648 pages) avail memory = 4109500416 (3919 MB) Software: real memory = 6442450944 (6144 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000090fff, 589824 bytes (144 pages) 0x0000000000985000 - 0x000000007ff1ffff, 2136584192 bytes (521627 pages) 0x0000000100000000 - 0x0000000174baffff, 1958412288 bytes (478128 pages) avail memory = 4085907456 (3896 MB) Disabled: real memory = 2951872512 (2815 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000090fff, 589824 bytes (144 pages) 0x0000000000983000 - 0x00000000aac56fff, 2855092224 bytes (697044 pages) avail memory = 2846003200 (2714 MB) Details of my nve device: nve0: port 0x1c60-0x1c67 mem 0xb0005000-0xb0005fff irq 21 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb0005000 nve0: Ethernet address 00:e0:81:54:b2:a6 miibus0: on nve0 ukphy0: on miibus0 ukphy0: OUI 0x005043, model 0x000c, rev. 1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: bpf attached nve0: Ethernet address: 00:e0:81:54:b2:a6 nve0: [GIANT-LOCKED] Regards, Daniel From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 12:45:53 2005 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 E020116A421 for ; Mon, 11 Jul 2005 12:45:53 +0000 (GMT) (envelope-from rbyrnes@mailshack.com) Received: from karen.nerdshack.com (karen.nerdshack.com [209.189.235.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DFB43D4C for ; Mon, 11 Jul 2005 12:45:53 +0000 (GMT) (envelope-from rbyrnes@mailshack.com) Received: from dispatchd.nerdshack.com (julie.nerdshack.com [209.189.235.39]) by karen.nerdshack.com (Postfix) with SMTP id 2B27D1E3821; Mon, 11 Jul 2005 07:43:01 -0500 (CDT) Received: from cartman.mailshack.com (dialup-233.105.221.203.acc51-kent-syd.comindico.com.au [203.221.105.233]) by mail.nerdshack.com with ESMTP Mon, 11 Jul 2005 07:43:39 -0500 Message-Id: <6.2.1.2.2.20050711224424.028cf258@mail.nerdshack.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Jul 2005 22:45:40 +1000 To: Brooks Davis From: Rob B In-Reply-To: <20050707164922.GA15353@odin.ac.hmc.edu> References: <42CA4263.9080409@locolomo.org> <6.2.1.2.2.20050705220015.029fa770@mail.nerdshack.com> <20050707164922.GA15353@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: current@freebsd.org Subject: Re: dhclient.conf for ath wireless 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, 11 Jul 2005 12:45:54 -0000 At 02:49 AM 8/07/2005, Brooks Davis wrote: > > Have you tried putting the appropriate ifconfig command line into=20 > > /etc/start_if.ath0. That works for me. > >The correct method is to just add: > >ifconfig_ath0=3D"ssid MYAP mode 11g DHCP" > >to /etc/rc.conf. With exception of devices that load firmware, you >probably do not need /etc/start_if.* these days. I tried that with my wi(4) card and it didn't work. I needed to make a start_if.wi0 file Cheers, Rob -- The Delta-United Ring Formation Theory states that the rings of Saturn are composed entirely of lost airline luggage. This is random quote 1014 of 1268. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:09:07 2005 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 4FB3D16A41F for ; Mon, 11 Jul 2005 15:09:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5C5543D48 for ; Mon, 11 Jul 2005 15:09:06 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 11:23:09 -0400 From: John Baldwin To: Stefan Ehmann Date: Mon, 11 Jul 2005 11:01:28 -0400 User-Agent: KMail/1.8 References: <42C92DC5.3060101@gddsn.org.cn> <200507091517.57736.jhb@FreeBSD.org> <1120939825.937.11.camel@taxman.pepperland> In-Reply-To: <1120939825.937.11.camel@taxman.pepperland> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111101.29623.jhb@FreeBSD.org> Cc: current@FreeBSD.org, Fabian Keil Subject: Re: Suspend 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: Mon, 11 Jul 2005 15:09:07 -0000 On Saturday 09 July 2005 04:10 pm, Stefan Ehmann wrote: > On Sat, 2005-07-09 at 15:17 -0400, John Baldwin wrote: > > I think you just need to remove the extra { after the if statement on > > line 539 at the end of the line. > > This and changing timer0_max_real_count to timer0_real_max_count made it > compilable. > > But this time the system is immediately very slow (not just after > suspend) and I get this strange error message on startup: > > calcru: runtime went backwards from 68378390 usec to 67512958 usec for > pid 11 (idle: cpu0) I had never set timer0_real_max_count. :( One more time: --- //depot/vendor/freebsd/src/sys/amd64/isa/clock.c 2005/07/05 20:15:24 +++ //depot/user/jhb/acpipci/amd64/isa/clock.c 2005/07/11 14:46:07 @@ -101,6 +101,7 @@ #endif u_int timer_freq = TIMER_FREQ; int timer0_max_count; +int timer0_real_max_count; int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ struct mtx clock_lock; #define RTC_LOCK mtx_lock_spin(&clock_lock) @@ -108,7 +109,6 @@ static int beeping = 0; static const u_char daysinmonth[] = {31,28,31,30,31,30,31,31,30,31,30,31}; -static u_int hardclock_max_count; static struct intsrc *i8254_intsrc; static u_int32_t i8254_lastcount; static u_int32_t i8254_offset; @@ -517,21 +517,24 @@ static void set_timer_freq(u_int freq, int intr_freq) { - int new_timer0_max_count; + int new_timer0_real_max_count; i8254_timecounter.tc_frequency = freq; mtx_lock_spin(&clock_lock); timer_freq = freq; - new_timer0_max_count = hardclock_max_count = TIMER_DIV(intr_freq); - if (using_lapic_timer) { + if (using_lapic_timer) + new_timer0_real_max_count = 0x10000; + else + new_timer0_real_max_count = TIMER_DIV(intr_freq); + if (new_timer0_real_max_count != timer0_real_max_count) { + timer0_real_max_count = new_timer0_real_max_count; + if (timer0_real_max_count == 0x10000) + timer0_max_count = 0xffff; + else + timer0_max_count = timer0_real_max_count; outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, 0); - outb(TIMER_CNTR0, 0); - } else if (new_timer0_max_count != timer0_max_count) { - timer0_max_count = new_timer0_max_count; - outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, timer0_max_count & 0xff); - outb(TIMER_CNTR0, timer0_max_count >> 8); + outb(TIMER_CNTR0, timer0_real_max_count & 0xff); + outb(TIMER_CNTR0, timer0_real_max_count >> 8); } mtx_unlock_spin(&clock_lock); } @@ -826,19 +829,8 @@ static unsigned i8254_simple_get_timecount(struct timecounter *tc) { - u_int count; - u_int high, low; - mtx_lock_spin(&clock_lock); - - /* Select timer0 and latch counter value. */ - outb(TIMER_MODE, TIMER_SEL0 | TIMER_LATCH); - - low = inb(TIMER_CNTR0); - high = inb(TIMER_CNTR0); - count = 0xffff - ((high << 8) | low); - mtx_unlock_spin(&clock_lock); - return (count); + return (timer0_max_count - getit()); } static unsigned --- //depot/vendor/freebsd/src/sys/i386/isa/clock.c 2005/07/05 20:15:24 +++ //depot/user/jhb/acpipci/i386/isa/clock.c 2005/07/11 14:46:07 @@ -110,6 +110,7 @@ #endif u_int timer_freq = TIMER_FREQ; int timer0_max_count; +int timer0_real_max_count; int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ struct mtx clock_lock; #define RTC_LOCK mtx_lock_spin(&clock_lock) @@ -117,7 +118,6 @@ static int beeping = 0; static const u_char daysinmonth[] = {31,28,31,30,31,30,31,31,30,31,30,31}; -static u_int hardclock_max_count; static struct intsrc *i8254_intsrc; static u_int32_t i8254_lastcount; static u_int32_t i8254_offset; @@ -531,21 +531,24 @@ static void set_timer_freq(u_int freq, int intr_freq) { - int new_timer0_max_count; + int new_timer0_real_max_count; i8254_timecounter.tc_frequency = freq; mtx_lock_spin(&clock_lock); timer_freq = freq; - new_timer0_max_count = hardclock_max_count = TIMER_DIV(intr_freq); - if (using_lapic_timer) { + if (using_lapic_timer) + new_timer0_real_max_count = 0x10000; + else + new_timer0_real_max_count = TIMER_DIV(intr_freq); + if (new_timer0_real_max_count != timer0_real_max_count) { + timer0_real_max_count = new_timer0_real_max_count; + if (timer0_real_max_count == 0x10000) + timer0_max_count = 0xffff; + else + timer0_max_count = timer0_real_max_count; outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, 0); - outb(TIMER_CNTR0, 0); - } else if (new_timer0_max_count != timer0_max_count) { - timer0_max_count = new_timer0_max_count; - outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, timer0_max_count & 0xff); - outb(TIMER_CNTR0, timer0_max_count >> 8); + outb(TIMER_CNTR0, timer0_real_max_count & 0xff); + outb(TIMER_CNTR0, timer0_real_max_count >> 8); } mtx_unlock_spin(&clock_lock); } @@ -554,7 +557,11 @@ i8254_restore(void) { - set_timer_freq(timer_freq, hz); + mtx_lock_spin(&clock_lock); + outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); + outb(TIMER_CNTR0, timer0_real_max_count & 0xff); + outb(TIMER_CNTR0, timer0_real_max_count >> 8); + mtx_unlock_spin(&clock_lock); } static void @@ -876,19 +883,8 @@ static unsigned i8254_simple_get_timecount(struct timecounter *tc) { - u_int count; - u_int high, low; - mtx_lock_spin(&clock_lock); - - /* Select timer0 and latch counter value. */ - outb(TIMER_MODE, TIMER_SEL0 | TIMER_LATCH); - - low = inb(TIMER_CNTR0); - high = inb(TIMER_CNTR0); - count = 0xffff - ((high << 8) | low); - mtx_unlock_spin(&clock_lock); - return (count); + return (timer0_max_count - getit()); } static unsigned --- //depot/vendor/freebsd/src/sys/pc98/cbus/clock.c 2005/07/05 20:15:24 +++ //depot/user/jhb/acpipci/pc98/cbus/clock.c 2005/07/11 14:46:07 @@ -109,12 +109,12 @@ #endif u_int timer_freq = TIMER_FREQ; int timer0_max_count; +int timer0_real_max_count; int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ struct mtx clock_lock; static int beeping = 0; static const u_char daysinmonth[] = {31,28,31,30,31,30,31,31,30,31,30,31}; -static u_int hardclock_max_count; static struct intsrc *i8254_intsrc; static u_int32_t i8254_lastcount; static u_int32_t i8254_offset; @@ -472,21 +472,24 @@ static void set_timer_freq(u_int freq, int intr_freq) { - int new_timer0_max_count; + int new_timer0_real_max_count; i8254_timecounter.tc_frequency = freq; mtx_lock_spin(&clock_lock); timer_freq = freq; - new_timer0_max_count = hardclock_max_count = TIMER_DIV(intr_freq); - if (using_lapic_timer) { + if (using_lapic_timer) + new_timer0_real_max_count = 0x10000; + else + new_timer0_real_max_count = TIMER_DIV(intr_freq); + if (new_timer0_real_max_count != timer0_real_max_count) { + timer0_real_max_count = new_timer0_real_max_count; + if (timer0_real_max_count == 0x10000) + timer0_max_count = 0xffff; + else + timer0_max_count = timer0_real_max_count; outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, 0); - outb(TIMER_CNTR0, 0); - } else if (new_timer0_max_count != timer0_max_count) { - timer0_max_count = new_timer0_max_count; - outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); - outb(TIMER_CNTR0, timer0_max_count & 0xff); - outb(TIMER_CNTR0, timer0_max_count >> 8); + outb(TIMER_CNTR0, timer0_real_max_count & 0xff); + outb(TIMER_CNTR0, timer0_real_max_count >> 8); } mtx_unlock_spin(&clock_lock); } @@ -495,7 +498,11 @@ i8254_restore(void) { - set_timer_freq(timer_freq, hz); + mtx_lock_spin(&clock_lock); + outb(TIMER_MODE, TIMER_SEL0 | TIMER_RATEGEN | TIMER_16BIT); + outb(TIMER_CNTR0, timer0_real_max_count & 0xff); + outb(TIMER_CNTR0, timer0_real_max_count >> 8); + mtx_unlock_spin(&clock_lock); } @@ -815,19 +822,8 @@ static unsigned i8254_simple_get_timecount(struct timecounter *tc) { - u_int count; - u_int high, low; - mtx_lock_spin(&clock_lock); - - /* Select timer0 and latch counter value. */ - outb(TIMER_MODE, TIMER_SEL0 | TIMER_LATCH); - - low = inb(TIMER_CNTR0); - high = inb(TIMER_CNTR0); - count = 0xffff - ((high << 8) | low); - mtx_unlock_spin(&clock_lock); - return (count); + return (timer0_max_count - getit()); } static unsigned -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:09:07 2005 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 AF80116A41C; Mon, 11 Jul 2005 15:09:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1072743D4C; Mon, 11 Jul 2005 15:09:06 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 11:23:09 -0400 From: John Baldwin To: "Wilkinson, Alex" Date: Mon, 11 Jul 2005 10:44:51 -0400 User-Agent: KMail/1.8 References: <200507090932.12973.jhb@FreeBSD.org> <20514.1120916772@phk.freebsd.dk> <20050710072752.GA39156@squash.dsto.defence.gov.au> In-Reply-To: <20050710072752.GA39156@squash.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111044.52693.jhb@FreeBSD.org> Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 11 Jul 2005 15:09:07 -0000 On Sunday 10 July 2005 03:27 am, Wilkinson, Alex wrote: > 0n Sat, Jul 09, 2005 at 03:46:12PM +0200, Poul-Henning Kamp wrote: > >In message <200507090932.12973.jhb@FreeBSD.org>, John Baldwin writes: > >>On Tuesday 05 July 2005 04:44 pm, Poul-Henning Kamp wrote: > >>> This is an attempt to fix an boot0cfg/fdisk issue which I have > >>> overlooked. > >>> > >>> The patch adds a g_ctl method to geom_mbr and makes boot0cfg and > >>> fdisk use it to modify the MBR if possible. > >>> > >>> Please test and report ASAP in order to get this solution into > >>> RELENG_6 > >> > >>Only thing I noted is that it seems that you changed boot0 to always > >> only write 512 bytes which means it will break trying to use > >> boot0cfg to install boot0ext (which is 2 sectors). Perhaps you > >> should check the filesize of the boot you are writing and if it's > > >> 512, write the other data with a write(2) after the g_ctl()? > >> Perhaps I don't see quite understand what your g_ctl() is doing > >> though. > > > >Damn, didn't think of that... > > what is boot0ext ? It's a 2-sector variant of boot0 that includes extra logic to choose between CHS and LBA BIOS calls and a longer table of filesystem/OS names. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:09:07 2005 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 AF80116A41C; Mon, 11 Jul 2005 15:09:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1072743D4C; Mon, 11 Jul 2005 15:09:06 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 11:23:09 -0400 From: John Baldwin To: "Wilkinson, Alex" Date: Mon, 11 Jul 2005 10:44:51 -0400 User-Agent: KMail/1.8 References: <200507090932.12973.jhb@FreeBSD.org> <20514.1120916772@phk.freebsd.dk> <20050710072752.GA39156@squash.dsto.defence.gov.au> In-Reply-To: <20050710072752.GA39156@squash.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111044.52693.jhb@FreeBSD.org> Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 11 Jul 2005 15:09:07 -0000 On Sunday 10 July 2005 03:27 am, Wilkinson, Alex wrote: > 0n Sat, Jul 09, 2005 at 03:46:12PM +0200, Poul-Henning Kamp wrote: > >In message <200507090932.12973.jhb@FreeBSD.org>, John Baldwin writes: > >>On Tuesday 05 July 2005 04:44 pm, Poul-Henning Kamp wrote: > >>> This is an attempt to fix an boot0cfg/fdisk issue which I have > >>> overlooked. > >>> > >>> The patch adds a g_ctl method to geom_mbr and makes boot0cfg and > >>> fdisk use it to modify the MBR if possible. > >>> > >>> Please test and report ASAP in order to get this solution into > >>> RELENG_6 > >> > >>Only thing I noted is that it seems that you changed boot0 to always > >> only write 512 bytes which means it will break trying to use > >> boot0cfg to install boot0ext (which is 2 sectors). Perhaps you > >> should check the filesize of the boot you are writing and if it's > > >> 512, write the other data with a write(2) after the g_ctl()? > >> Perhaps I don't see quite understand what your g_ctl() is doing > >> though. > > > >Damn, didn't think of that... > > what is boot0ext ? It's a 2-sector variant of boot0 that includes extra logic to choose between CHS and LBA BIOS calls and a longer table of filesystem/OS names. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:15:56 2005 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 C30EE16A41C for ; Mon, 11 Jul 2005 15:15:56 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D4B243D49 for ; Mon, 11 Jul 2005 15:15:56 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id for ; Mon, 11 Jul 2005 10:16:39 -0500 Message-Id: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 10:15:47 -0500 To: freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <20050711120017.35E1A16A420@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 15:15:56 -0000 The architecture / driver manual has this item: "That means that absolutely every driver, even the ones not supporting any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table to return failure on unknown PnP devices." (http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&q=freebsd+architect+isa+driver) However in mss.c, routine mss_probe we have in the non pnp device detection routine if (isa_get_logicalid(dev)) return ENXIO; which causes the acpi driver to fail to attach multiple times, and to ratchet up x in the pcmx device before giving up. Often this leads to the isa routine not calling the pnp version of the probe routine and the whole pcm load fails or loads the first and only sound driver on a pcm number like 3 or 6. Booting without ACPI gives normal results. The fix in mss.c is: static struct isa_pnp_id mss_ids[] = { {0} }; static int mss_probe(device_t dev) { u_char tmp, tmpx; int flags, irq, drq, result = ENXIO, setres = 0; struct mss_info *mss; result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); if (result!=ENOENT) return ENXIO; /* only continue if the device is not pnp */ /* old way- not so good for ACPI: if (isa_get_logicalid(dev)) return ENXIO; */ Sincerely, Harry Coin From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:42:20 2005 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 AD9E016A41C for ; Mon, 11 Jul 2005 15:42:20 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D26443D48 for ; Mon, 11 Jul 2005 15:42:19 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd26.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Drztq-0005K1-02; Mon, 11 Jul 2005 17:08:50 +0200 Received: from Andro-Beta.Leidinger.net (ZY7s6wZEYe4hzgFLZphJVzNwg3YNAV8ywX6ZBOeRC0aFWcccLQn7oF@[84.165.228.193]) by fwd26.sul.t-online.de with esmtp id 1DrztQ-1ZcMS00; Mon, 11 Jul 2005 17:08:24 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6BF8NjU070594; Mon, 11 Jul 2005 17:08:23 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 11 Jul 2005 17:08:23 +0200 From: Alexander Leidinger To: Rob B Message-ID: <20050711170823.0bae2054@Magellan.Leidinger.net> In-Reply-To: <6.2.1.2.2.20050711224424.028cf258@mail.nerdshack.com> References: <42CA4263.9080409@locolomo.org> <6.2.1.2.2.20050705220015.029fa770@mail.nerdshack.com> <20050707164922.GA15353@odin.ac.hmc.edu> <6.2.1.2.2.20050711224424.028cf258@mail.nerdshack.com> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: ZY7s6wZEYe4hzgFLZphJVzNwg3YNAV8ywX6ZBOeRC0aFWcccLQn7oF@t-dialin.net X-TOI-MSGID: 414179cb-4ba9-4470-9034-11385c56b76a Cc: current@freebsd.org Subject: Re: dhclient.conf for ath wireless 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, 11 Jul 2005 15:42:20 -0000 On Mon, 11 Jul 2005 22:45:40 +1000 Rob B wrote: > At 02:49 AM 8/07/2005, Brooks Davis wrote: > > > Have you tried putting the appropriate ifconfig command line into=20 > > > /etc/start_if.ath0. That works for me. > > > >The correct method is to just add: > > > >ifconfig_ath0=3D"ssid MYAP mode 11g DHCP" > > > >to /etc/rc.conf. With exception of devices that load firmware, you > >probably do not need /etc/start_if.* these days. > > I tried that with my wi(4) card and it didn't work. I needed to make a > start_if.wi0 file I think something is wrong with the wlan_wep module or with the wi driver. I have a strange script on my -current laptop which I run by hand: ---snip--- ifconfig wi0 inet 192... wepmode on weptxkey 1 ssid ID kldload wlan_wep ifconfig wi0 wepkey 1:xxxx wicontrol -L route add default ... ifconfig wi0 wepmode on wicontrol -L ---snip--- If I don't do it this way (e.g. removing the setup of the first ifconfig line to the second ifconfig line, or adding the wlan_wep module to loader.conf), it will not find my accesspoint (FreeBSD 4.11, wi0 in host-ap mode). Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:51:09 2005 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 2141016A41C for ; Mon, 11 Jul 2005 15:51:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C8043D5D for ; Mon, 11 Jul 2005 15:51:08 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 12:05:12 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Jul 2005 11:45:20 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111145.21467.jhb@FreeBSD.org> Cc: Harry Coin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 15:51:09 -0000 On Monday 11 July 2005 11:15 am, Harry Coin wrote: > The architecture / driver manual has this item: > > "That means that absolutely every driver, even the ones not supporting any > PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table > to return failure on unknown PnP > devices." > (http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&q=freebsd+archi >tect+isa+driver) > > However in mss.c, routine mss_probe we have in the non pnp device detection > routine > > if (isa_get_logicalid(dev)) return ENXIO; > > which causes the acpi driver to fail to attach multiple times, and to > ratchet up x in the pcmx device before giving up. Often this leads to the > isa routine not calling the pnp version of the probe routine and the whole > pcm load fails or loads the first and only sound driver on a pcm number > like 3 or 6. Booting without ACPI gives normal results. > > The fix in mss.c is: > > static struct isa_pnp_id mss_ids[] = { > {0} > }; > > static int > mss_probe(device_t dev) > { > u_char tmp, tmpx; > int flags, irq, drq, result = ENXIO, setres = 0; > struct mss_info *mss; > result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); > if (result!=ENOENT) return ENXIO; /* only continue if the device > is not pnp */ > /* old way- not so good for ACPI: if (isa_get_logicalid(dev)) > return ENXIO; */ > > Sincerely, > > Harry Coin If this is broken then there are a lot of drivers that need fixing. It sounds like ACPI needs fixing instead. I don't see why pcm's unit number would go up, however, as a device reverts back to 'unknown' with a unit of -1 when a probe() function fails. Can you provide more details such as a verbose dmesg for both the ACPI and non-ACPI cases without your change? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:19:38 2005 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 C175916A41C for ; Mon, 11 Jul 2005 16:19:38 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D23F43D46 for ; Mon, 11 Jul 2005 16:19:37 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ds0zd-0002bx-AT for freebsd-current@freebsd.org; Mon, 11 Jul 2005 18:18:53 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 18:18:53 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 18:18:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Mon, 11 Jul 2005 09:17:37 -0700 Lines: 47 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.9.0 Sender: news Subject: is there a way not to believe the bios' IRQ prog and use the $PIR? 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, 11 Jul 2005 16:19:38 -0000 Hi, I believe since the following commit, I have had serious problems with interrupts on one class of machines (TYAN S1867 - thunder 2500): http://article.gmane.org/gmane.os.freebsd.devel.cvs.src/46247/ jhb 2005-04-14 18:25:09 UTC FreeBSD src repository Modified files: sys/i386/pci pci_pir.c Log: Trust the settings programmed by the BIOS over what the $PIR says. Specifically, if the BIOS has programmed an IRQ for a device that doesn't match the list of valid IRQs for the link, use it anyway as some BIOSes don't correctly list the valid IRQs in the $PIR. Also, allow the user to specify an IRQ that $PIR claims is invalid as an override, but emit a warning in that case. Revision Changes Path 1.117 +48 -18 src/sys/i386/pci/pci_pir.c Unfortunately, I'm quite sure that no more fixes for this older mboard will be forthcoming from the vendor. Under high to moderate load, the layer will simply 'miss' interrupts, leading to file/network traffic corruption and dropped characters on serial consoles. Here's the non -v boot showing the warning entries. pcib2: pcibus 2 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 17 from 1.0.INTA is for link 0x12 $PIR: Using invalid BIOS IRQ 23 from 0.7.INTA is for link 0x18 $PIR: Using invalid BIOS IRQ 16 from 0.3.INTA is for link 0x11 $PIR: Using invalid BIOS IRQ 18 from 0.4.INTA is for link 0x13 $PIR: Using invalid BIOS IRQ 20 from 0.5.INTA is for link 0x15 $PIR: Using invalid BIOS IRQ 22 from 0.6.INTA is for link 0x17 Is there a tunable I'm not aware of that I could revert back to not believing the BIOS and use the $PIR entries? -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 17:19:17 2005 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 DF02416A41F for ; Mon, 11 Jul 2005 17:19:17 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F41F43D45 for ; Mon, 11 Jul 2005 17:19:17 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6BHJFZs020033 for ; Mon, 11 Jul 2005 19:19:15 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6BHJFDD020032 for freebsd-current@freebsd.org; Mon, 11 Jul 2005 13:19:15 -0400 (EDT) (envelope-from cracauer) Date: Mon, 11 Jul 2005 13:19:15 -0400 From: Martin Cracauer To: freebsd-current@freebsd.org Message-ID: <20050711131915.A19863@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: gvinum. A little worse than I thought :-) 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, 11 Jul 2005 17:19:18 -0000 I understand that gvinum doesn't have documentation yet, and I found a note "or basic stuff (like creating concatinated volumes) you can use the vinum documentation and replace 'vinum' with 'gvinum' when you try things." But this is going a bit far: sbin/gvinum(grisu)80# gvinum gvinum -> help [...] info [-v] [-V] List information about volume manager state. [...] gvinum -> info unknown command 'info' gvinum -> dumpconfig unknown command 'dumpconfig' Also, seperate issue, the geom_vinum kernel module is not unloadable but the "stop" command tries to do exactly that, and fails. What the stop command does not do is actually stop or detach anything, so I am stuck with 3 devices captive in a failed raid5 setup attempt until I reboot. gvinum -> stop raid gvinum: cannot unload geom_vinum: Operation not supported gvinum -> stop raid.lp0 gvinum: cannot unload geom_vinum: Operation not supported gvinum -> stop gvinum: cannot unload geom_vinum: Operation not supported The detach command, listed in help, is also only triggering a message that it is unsupported. But have no fear, I just poked a little deeper into Linux raid (raid5) and it was way worse :-) What is a recommended ATA or SATA controller with hardware RAID5 and the capability to run different RAID levels on different parts of the disk these days? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 17:30:43 2005 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 0FDDA16A41C; Mon, 11 Jul 2005 17:30:43 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9463043D46; Mon, 11 Jul 2005 17:30:42 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 11 Jul 2005 12:31:26 -0500 Message-Id: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 12:30:34 -0500 To: John Baldwin ,freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <200507111145.21467.jhb@FreeBSD.org> References: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 17:30:43 -0000 John, The verbose dmesg doesn't tell you enough. What was needed was debug writes in the pnp and non pnp mss.c probe routines that displayed the parent device id and the probed device id. That solved it because there you could see the acpi parent calling the non-pnp isa mss probe routine (mss_probe) which would _accept_ the probe, wrongly, on a few various attempts, only to have the non pnp mss_attach fail for lack of resources. I haven't looked into the newbus logic enough to know for sure but my hunch is that the current mss.c call to detect pnp and so avoid to use the non pnp probe code (isa_get_logicalid) didn't get mapped through the acpi_isa_xxx but instead the isa routine directly-- which returned a zero in the context of an ACPI parent bus-- signaling not-a-pnp device -- while the acpi version would not have done. Hence the directive in the manual to use the ISA_PNP_PROBE even on non-PNP probe routines. The environment is a Dell Optiplex, using the Crystal Semiconductor (CSC) CS4236B chip. There are many unresolved postings for 'attach returns 6' and pcm that popped up -- with no solution posted when acpi was introduced. So this is my cut at it. At least it boots properly with acpi now and loads the driver at pcm0 instead of pcm3. The real problem is one I'm still trying to solve, the mappings for the mixer for the CS423X chip do not map the ADCs properly so there is no way to connect audio on either the line - in or mic ports to the system either for loop-through to line out or digitizing. In the process I've noted the 4236B chip in its (currently unsupported) mode 3 allows for different sample rates for playback and digitizing, and actually implements an input mixer instead of a simple input selector. So I'm struggling to add support for that in the mss.c driver as I don't want the digitizing sample rate to have anything to do with the playback sample rate. I'm still new to *bsd and *nix, but it seems to me that the number of chips supported in the mss.c driver is challengingly high. Harry At 11:45 AM 7/11/2005 -0400, John Baldwin wrote: >On Monday 11 July 2005 11:15 am, Harry Coin wrote: > > The architecture / driver manual has this item: > > > > "That means that absolutely every driver, even the ones not supporting any > > PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table > > to return failure on unknown PnP > > devices." > > (http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&q=freebsd+archi > >tect+isa+driver) > > > > However in mss.c, routine mss_probe we have in the non pnp device detection > > routine > > > > if (isa_get_logicalid(dev)) return ENXIO; > > > > which causes the acpi driver to fail to attach multiple times, and to > > ratchet up x in the pcmx device before giving up. Often this leads to the > > isa routine not calling the pnp version of the probe routine and the whole > > pcm load fails or loads the first and only sound driver on a pcm number > > like 3 or 6. Booting without ACPI gives normal results. > > > > The fix in mss.c is: > > > > static struct isa_pnp_id mss_ids[] = { > > {0} > > }; > > > > static int > > mss_probe(device_t dev) > > { > > u_char tmp, tmpx; > > int flags, irq, drq, result = ENXIO, setres = 0; > > struct mss_info *mss; > > result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); > > if (result!=ENOENT) return ENXIO; /* only continue if the device > > is not pnp */ > > /* old way- not so good for ACPI: if (isa_get_logicalid(dev)) > > return ENXIO; */ > > > > Sincerely, > > > > Harry Coin > >If this is broken then there are a lot of drivers that need fixing. It >sounds >like ACPI needs fixing instead. I don't see why pcm's unit number would go >up, however, as a device reverts back to 'unknown' with a unit of -1 when a >probe() function fails. Can you provide more details such as a verbose dmesg >for both the ACPI and non-ACPI cases without your change? > >-- >John Baldwin <>< http://www.FreeBSD.org/~jhb/ >"Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 17:44:48 2005 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 34FA816A41C for ; Mon, 11 Jul 2005 17:44:48 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98AE543D46 for ; Mon, 11 Jul 2005 17:44:47 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from av.mx0.thekeelecentre.com (av.mx0.thekeelecentre.com [217.206.238.166]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 23C56429E; Mon, 11 Jul 2005 18:44:46 +0100 (BST) Received: from mx0.thekeelecentre.com ([217.206.238.167]) by av.mx0.thekeelecentre.com (av.mx0.thekeelecentre.com [217.206.238.166]) (amavisd-new, port 10024) with ESMTP id 47385-09; Mon, 11 Jul 2005 18:44:45 +0100 (BST) Received: from [217.206.238.190] (host-190.thekeelecentre.com [217.206.238.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTP id D0F01412C; Mon, 11 Jul 2005 18:44:27 +0100 (BST) Message-ID: <42D2B012.9040208@thekeelecentre.com> Date: Mon, 11 Jul 2005 18:44:50 +0100 From: Richard Tector User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Martin Cracauer References: <20050711131915.A19863@cons.org> In-Reply-To: <20050711131915.A19863@cons.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Cc: freebsd-current@freebsd.org Subject: Re: gvinum. A little worse than I thought :-) 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, 11 Jul 2005 17:44:48 -0000 Martin Cracauer wrote: >What is a recommended ATA or SATA controller with hardware RAID5 and >the capability to run different RAID levels on different parts of the >disk these days? > >Martin > > I've had good results with both Areca 8 and 16 port cards (arcmsr driver) on -CURRENT and a couple of Adaptec 2410s on 5.x (aac driver). All SATA, though the Areca did seem to perform quite a bit better (+15-20MB/s on writes) during a bunch of quick dd tests I did using a month old -CURRENT. I haven't used any 3ware cards myself but I've heard good things. With the Adaptec's it's fairly trivial to run say 2 seperate Raid5 sets across the disks or mirror 4 the first 5GB of each of 4 disks and use the rest of the space in RAID5, etc. I haven't tried this with the Areca's but brielfy looking at the documentation it seems possible. I hope that's of some help. Regards, Richard Tector From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:04:48 2005 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 A816C16A41C for ; Mon, 11 Jul 2005 18:04:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D7143D48 for ; Mon, 11 Jul 2005 18:04:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 14:18:51 -0400 From: John Baldwin To: Harry Coin Date: Mon, 11 Jul 2005 13:58:46 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111358.50262.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 18:04:48 -0000 On Monday 11 July 2005 01:30 pm, Harry Coin wrote: > John, > > The verbose dmesg doesn't tell you enough. What was needed was debug > writes in the pnp and non pnp mss.c probe routines that displayed the > parent device id and the probed device id. That solved it because there > you could see the acpi parent calling the non-pnp isa mss probe routine > (mss_probe) which would _accept_ the probe, wrongly, on a few various > attempts, only to have the non pnp mss_attach fail for lack of resources. Well, that would be helpful to see as well. :) It would be helpful to dump the name of the parent device via device_get_nameunit(device_get_parent(dev)) if you aren't already. > I haven't looked into the newbus logic enough to know for sure but my hunch > is that the current mss.c call to detect pnp and so avoid to use the non > pnp probe code (isa_get_logicalid) didn't get mapped through the > acpi_isa_xxx but instead the isa routine directly-- which returned a zero > in the context of an ACPI parent bus-- signaling not-a-pnp device -- while > the acpi version would not have done. Hence the directive in the manual to > use the ISA_PNP_PROBE even on non-PNP probe routines. Well, isa_get_logicalid() just asks the parent device for the ISA logical ID IVAR which maps to a call to bus_read_ivar(). For the non-ACPI case, it is implemented by returning the id read by the PnP code in in isa_read_ivar() in sys/isa/isa_common.c. However, for devices that are children of acpi0, they call acpi_read_ivar() which does end up calling acpi_isa_get_logicalid(): static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) { ... case ISA_IVAR_LOGICALID: *(int *)result = acpi_isa_get_logicalid(child); break; ... return (0); } So, you see, isa_get_logicalid() should work fine, and it's actually something that many ISA device drivers use to avoid probing PnP devices, so the root problem needs to be fixed if acpi_isa_get_logicalid() has a bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:05:21 2005 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 8F63216A41C for ; Mon, 11 Jul 2005 18:05:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA2F43D49 for ; Mon, 11 Jul 2005 18:05:20 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 14:18:50 -0400 From: John Baldwin To: Mike Tancsa Date: Mon, 11 Jul 2005 13:27:44 -0400 User-Agent: KMail/1.8 References: <70e8236f05070208212e36c375@mail.gmail.com> <200507081006.43609.jhb@FreeBSD.org> <6.2.1.2.0.20050708110446.07de5768@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050708110446.07de5768@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111327.46165.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 11 Jul 2005 18:05:21 -0000 On Friday 08 July 2005 11:47 am, Mike Tancsa wrote: > At 10:06 AM 08/07/2005, John Baldwin wrote: > >On Thursday 07 July 2005 10:09 pm, Mike Tancsa wrote: > > > At 04:58 PM 07/07/2005, John Baldwin wrote: > > > >Crud, it's off in the weeds. :( Can you do a boot -v and get the > > > > lines after 'pcib3:'? > > > > > > Here you go > > > >Ok, I see why it is badly confused in the non-APIC and non-ACPI case > > though I don't know why it is panicing. (FWIW, it is trying to route all > > interrupts to IRQ 14 because your $PIR is all busted *sigh*). BIOS > > writers suck. > > Unfortunately, this is the latest version of the BIOS from Dell. Windows uses ACPI, so I bet the $PIR stuff isn't QA'd anymore. > >Anyway, I still need a simple matrix of what works and what doesn't work > >first (if I got one earlier I lost it): > > > >ACPI/APIC - amr0 gets no interrupts, hangs after boot > > yes, it hangs either with amr or perhaps ata. yesterday I was trying just > a netboot and it seemed to work if I pulled the card and did not have the > ata code in the driver, although I had not setup the fstab to properly > work, but the fact that I was complaining about mounting root implies it > got farther along. If you feel this is worth checking out, I could pull > the amr card again, and try and properly netboot a kernel and mount root > via nfs on 6.x. > > On RELENG_5 it sometimes works if I disable ata in the kernel. I attached > the boot-v from releng5. 6.x hangs (also attached) Hummm, so does it work with an ata(4) disk if you pull the amr card or disable the amr driver in your kernel? > >ACPI/no-APIC - amr0 gets no interrupts, hangs after boot? > > Panic. This case should be in the last email I sent. > OK set hint.apic.0.disabled=1 > OK load acpi.ko > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xba9f > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc00fd141 > stack pointer = 0x10:0xc0c2094c > frame pointer = 0x10:0xc0c209b8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at 0xc00fd141: cmpb %cs:0xba9f,%bh > db> trace > Tracing pid 0 tid 0 td 0xc07d1c60 > kernbase(e0b,c07029d1,c00fc860,c00fc86b,c0c209f8) at 0xc00fd141 > db> Hmm, so no-APIC always gets this BIOS panic, in both the ACPI and non-ACPI cases? And is that the same on 5.x? > >no-ACPI/APIC - ??? > > RELENG_5, all is happy. 6.x hang. Ok. Very odd in that the code there is almost identical. There is one diff you can try reverting (use patch -R) and see if it changes anything: Index: mptable.c =================================================================== RCS file: /usr/cvs/src/sys/i386/i386/mptable.c,v retrieving revision 1.235.2.4 retrieving revision 1.241 diff -u -r1.235.2.4 -r1.241 --- mptable.c 25 Mar 2005 21:10:07 -0000 1.235.2.4 +++ mptable.c 14 Apr 2005 17:59:58 -0000 1.241 @@ -353,7 +353,6 @@ busses[i].bus_type = NOBUS; /* Second, we run through adding I/O APIC's and busses. */ - ioapic_enable_mixed_mode(); mptable_parse_apics_and_busses(); /* Third, we run through the table tweaking interrupt sources. */ There are also some changes to the amr(4) driver (minor though) in 6.x that you could try reverting perhaps. ata(4) has had a lot of changes in 6.x. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:38:58 2005 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 5FF0716A41C for ; Mon, 11 Jul 2005 18:38:58 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 047C643D45 for ; Mon, 11 Jul 2005 18:38:57 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 14:53:01 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Jul 2005 14:38:07 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200507111438.08844.jhb@FreeBSD.org> Cc: othermark Subject: Re: is there a way not to believe the bios' IRQ prog and use the $PIR? 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, 11 Jul 2005 18:38:58 -0000 On Monday 11 July 2005 12:17 pm, othermark wrote: > Hi, > > I believe since the following commit, I have had serious problems with > interrupts on one class of machines (TYAN S1867 - thunder 2500): > > http://article.gmane.org/gmane.os.freebsd.devel.cvs.src/46247/ > > jhb 2005-04-14 18:25:09 UTC > > FreeBSD src repository > > Modified files: > sys/i386/pci pci_pir.c > Log: > Trust the settings programmed by the BIOS over what the $PIR says. > Specifically, if the BIOS has programmed an IRQ for a device that doesn't > match the list of valid IRQs for the link, use it anyway as some BIOSes > don't correctly list the valid IRQs in the $PIR. Also, allow the user > to specify an IRQ that $PIR claims is invalid as an override, but emit a > warning in that case. > > Revision Changes Path > 1.117 +48 -18 src/sys/i386/pci/pci_pir.c > > Unfortunately, I'm quite sure that no more fixes for this older > mboard will be forthcoming from the vendor. Under high to moderate > load, the layer will simply 'miss' interrupts, leading to file/network > traffic corruption and dropped characters on serial consoles. > > Here's the non -v boot showing the warning entries. > > pcib2: pcibus 2 on motherboard > pir0: on motherboard > $PIR: Using invalid BIOS IRQ 17 from 1.0.INTA is for link 0x12 > $PIR: Using invalid BIOS IRQ 23 from 0.7.INTA is for link 0x18 > $PIR: Using invalid BIOS IRQ 16 from 0.3.INTA is for link 0x11 > $PIR: Using invalid BIOS IRQ 18 from 0.4.INTA is for link 0x13 > $PIR: Using invalid BIOS IRQ 20 from 0.5.INTA is for link 0x15 > $PIR: Using invalid BIOS IRQ 22 from 0.6.INTA is for link 0x17 > > Is there a tunable I'm not aware of that I could revert back to > not believing the BIOS and use the $PIR entries? You can override the IRQs for any link device by setting hw.pci.link.0x12.irq=XX to set link 0x12 to irq XX for example. You could also modify $PIR to never trust a BIOS value > 16: --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2005/04/14 18:25:24 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2005/07/11 18:13:16 @@ -327,6 +327,15 @@ if (irq == PCI_INVALID_IRQ || irq == pci_link->pl_irq) return; + /* Don't trust any BIOS IRQs greater than 15. */ + if (irq >= NUM_ISA_INTERRUPTS) { + printf( + "$PIR: Ignoring invalid BIOS IRQ %d from %d.%d.INT%c for link %#x\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id); + return; + } + /* * If we don't have an IRQ for this link yet, then we trust the * BIOS, even if it seems invalid from the $PIR entries. @@ -334,7 +343,7 @@ if (pci_link->pl_irq == PCI_INVALID_IRQ) { if (!pci_pir_valid_irq(pci_link, irq)) printf( - "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c is for link %#x\n", + "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', pci_link->pl_id); pci_link->pl_irq = irq; -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:04:05 2005 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 4CEBE16A41C; Mon, 11 Jul 2005 19:04:05 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id B557743D4C; Mon, 11 Jul 2005 19:04:04 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 11 Jul 2005 14:04:48 -0500 Message-Id: <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 14:03:56 -0500 To: John Baldwin From: Harry Coin In-Reply-To: <200507111358.50262.jhb@FreeBSD.org> References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 19:04:05 -0000 John, Here are the results you asked for. You will seein the acpi boot the isa_get_logicalid(dev) returns 0 for a probe call to the non-pnp routine mss_probe dmesg excerpt ... mss_probe: bus acpi0 is probing device pcm0 mss_probe: isa_get_logicalid() returned 0! mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm0: port 0x530-0x537 on acpi0 device_attach: pcm0 attach returned 6 mss_probe: bus acpi0 is probing device pcm1 ... Here are the changes I made for debugging output to the two probe routines in mss.c static int mss_probe(device_t dev) { u_char tmp, tmpx; int flags, irq, drq, result = ENXIO, setres = 0; struct mss_info *mss; printf("mss_probe: bus %s is probing device %s\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev)); // result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); // if (result!=ENOENT) return ENXIO; /* only continue if the device is not pnp */ /* old way- not so good for ACPI: */ if (isa_get_logicalid(dev)) return ENXIO; printf("mss_probe: isa_get_logicalid() returned 0!\n"); .... and static int pnpmss_probe(device_t dev) { u_int32_t lid, vid; int result; lid = isa_get_logicalid(dev); vid = isa_get_vendorid(dev); printf("pnpmss_probe: bus %s is probing device %s lid %lxh, vid %lxh\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev),lid,vid); if (lid == 0x01000000 && vid != 0x0100a90d) /* CMI0001 */ return ENXIO; result = ISA_PNP_PROBE(device_get_parent(dev), dev, pnpmss_ids); if (result == 0) { if ((lid == 0x630e) && ((vid&0xff000000) == 0x35000000)) { device_set_desc(dev, "CS4236B"); } } printf("pnpmss_probe result %d\n",result); return result; } Here is the verbose dmesg with acpi on in the bios. I appended to it a cat /dev/sndstat. Note it has loaded the sound driver as pcm3 Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #21: Sun May 29 15:06:21 CDT 2005 root@server1.quietfountain.com:/usr/obj/usr/src/sys/DISKLESS Preloaded elf kernel "/boot/kernel/kernel" at 0xc07af000. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc07af1a4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07af250. Calibrating clock(s) ... i8254 clock: 1193157 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 331109954 Hz CPU: Pentium II/Pentium II Xeon/Celeron (331.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ff real memory = 134209536 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x0000000007d8dfff, 123113472 bytes (30057 pages) avail memory = 125865984 (120 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xcf4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: mem: Pentium Pro MTRR support enabled null: io: random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fcaf0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 A 0x64 14 embedded 0 7 B 0x65 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 D 0x61 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 ACPI timer: 0/6 0/4 0/5 0/6 0/6 0/4 0/6 0/6 0/6 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 mss_probe: bus acpi0 is probing device pcm0 mss_probe: isa_get_logicalid() returned 0! mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm0: port 0x530-0x537 on acpi0 device_attach: pcm0 attach returned 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid 30ad041h, vid ffffffffh pnpmss_probe result 6 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.1.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.7.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.17.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.14.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.14.1 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.3 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.0 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.13.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.13.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x010f, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 5, priority 38295): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKA (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKB (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKC (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 pcib0: slot 7 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000850, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base fa000000, size 12, enabled map[14]: type 4, range 32, base 0000dcc0, size 5, enabled map[18]: type 1, range 32, base ff000000, size 20, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKB (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKC (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 pcib0: slot 14 INTA routed to irq 10 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x1229, revid=0x05 bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x1011, dev=0x0024, revid=0x03 bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfc000000-0xfeffffff pcib1: prefetched decode 0xf9000000-0xf9ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfd000000-0xfdffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base fcfff000, size 12, enabled pcib1: device (null) requested decoded memory range 0xfcfff000-0xfcffffff found-> vendor=0x1002, dev=0x4744, revid=0x5c bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=00 ostat1=ff ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) fxp0: port 0xdcc0-0xdcdf mem 0xff000000-0xff0fffff,0xfa000000-0xfa000fff irq 10 at device 14.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfa000000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000a 0005 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:a0:c9:af:3e:51 fxp0: [MPSAFE] pcib2: at device 15.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.1 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.9.2 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.9.3 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.10.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.1 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.2 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.10.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.0 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.11.1 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.11.2 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.3 pci2: on pcib2 pci2: physical bus=2 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm1 mss_probe: isa_get_logicalid() returned 0! mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm1: port 0x530-0x537 on acpi0 device_attach: pcm1 attach returned 6 mss_probe: bus acpi0 is probing device pcm2 mss_probe: isa_get_logicalid() returned 0! mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm2: port 0x530-0x537 on acpi0 device_attach: pcm2 attach returned 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid 8d041h, vid ffffffffh pnpmss_probe result 6 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 mss_probe: bus acpi0 is probing device pcm0 mss_probe: isa_get_logicalid() returned 0! mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm0: port 0x530-0x537 on acpi0 device_attach: pcm0 attach returned 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm1 mss_probe: isa_get_logicalid() returned 0! mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm1: port 0x530-0x537 on acpi0 device_attach: pcm1 attach returned 6 mss_probe: bus acpi0 is probing device pcm2 mss_probe: isa_get_logicalid() returned 0! mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm2: port 0x530-0x537 on acpi0 device_attach: pcm2 attach returned 6 mss_probe: bus acpi0 is probing device pcm3 pnpmss_probe: bus acpi0 is probing device pcm3 lid 8d041h, vid ffffffffh pnpmss_probe result 6 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 CSC0000: start dependent (0) CSC0000: adding dma mask 0xa CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x2a0 CSC0000: adding io range 0x534-0x60b, size=0x4, align=0xd4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x24f, size=0x10, align=0x20 CSC0000: start dependent (1) CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x3f3, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x26f, size=0x10, align=0x10 CSC0000: end dependent CSC000f: start dependent (0) CSC000f: adding io range 0x3a0-0x3ff, size=0x8, align=0x8 CSC000f: end dependent CSC0010: adding io range 0xf00-0xfef, size=0x8, align=0x8 CSC0003: start dependent (0) CSC0003: adding io range 0x330-0x3f1, size=0x2, align=0x8 CSC0003: end dependent sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm3 pnpmss_probe: bus isa0 is probing device pcm3 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm3: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh pcm3: [GIANT-LOCKED] pcm3: sndbuf_setmap ff4000, 1000; 0xcc14e000 -> ff4000 pcm3: sndbuf_setmap ff3000, 1000; 0xcc14f000 -> ff3000 mss_probe: bus isa0 is probing device pcm4 pnpmss_probe: bus isa0 is probing device pcm4 lid f00630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x3a0-0x3a7 on isa0 mss_probe: bus isa0 is probing device pcm4 pnpmss_probe: bus isa0 is probing device pcm4 lid 1000630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0xf00-0xf07 on isa0 mss_probe: bus isa0 is probing device pcm4 pnpmss_probe: bus isa0 is probing device pcm4 lid 300630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x330-0x331 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 331109954 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ... Linux ELF exec handler installed /dev/sndstat contains: FreeBSD Audio Driver (newpcm) Installed devices: pcm3: at io 0x534 irq 5 drq 1:0 bufsz 4096 (1p/1r/0v channels duplex) Here follows the same info but with ACPI disabled in the BIOS Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #21: Sun May 29 15:06:21 CDT 2005 root@server1.quietfountain.com:/usr/obj/usr/src/sys/DISKLESS Preloaded elf kernel "/boot/kernel/kernel" at 0xc0758000. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc075817c. Calibrating clock(s) ... i8254 clock: 1193160 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 331109196 Hz CPU: Pentium II/Pentium II Xeon/Celeron (331.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ff real memory = 134217728 (128 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x0000000007d8ffff, 123121664 bytes (30059 pages) avail memory = 125890560 (120 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xcf4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: random: mem: Pentium Pro MTRR support enabled null: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80000064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fcaf0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 A 0x64 14 embedded 0 7 B 0x65 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 D 0x61 3 4 5 6 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x64 255 N 1 14 0x65 255 N 1 15 0x63 255 N 8 3 4 5 6 7 9 10 11 12 14 15 0x60 255 N 6 3 4 5 6 7 9 10 11 12 14 15 0x61 255 N 6 3 4 5 6 7 9 10 11 12 14 15 0x62 255 N 6 3 4 5 6 7 9 10 11 12 14 15 $PIR: Found matching pin for 0.7.INTD at func 2: 11 $PIR: Found matching pin for 0.14.INTA at func 0: 10 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x64 14 N 1 14 0x65 15 N 1 15 0x63 11 Y 8 3 4 5 6 7 9 10 11 12 14 15 0x60 255 N 6 3 4 5 6 7 9 10 11 12 14 15 0x61 255 N 6 3 4 5 6 7 9 10 11 12 14 15 0x62 10 Y 6 3 4 5 6 7 9 10 11 12 14 15 $PIR: IRQs used by BIOS: 10 11 14 15 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 0 0 0 0 0 6 8 0 0 1 1 ] pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x010f, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000dce0, size 5, enabled $PIR: 0:7 INTD routed to irq 11 found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000850, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base fa000000, size 12, enabled map[14]: type 4, range 32, base 0000dcc0, size 5, enabled map[18]: type 1, range 32, base ff000000, size 20, enabled $PIR: 0:14 INTA routed to irq 10 found-> vendor=0x8086, dev=0x1229, revid=0x05 bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x1011, dev=0x0024, revid=0x03 bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfc000000-0xfeffffff pcib1: prefetched decode 0xf9000000-0xf9ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfd000000-0xfdffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base fcfff000, size 12, enabled pcib1: device (null) requested decoded memory range 0xfcfff000-0xfcffffff found-> vendor=0x1002, dev=0x4744, revid=0x5c bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=00 ostat1=ff ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) fxp0: port 0xdcc0-0xdcdf mem 0xff000000-0xff0fffff,0xfa000000-0xfa000fff irq 10 at device 14.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfa000000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000a 0005 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:a0:c9:af:3e:51 fxp0: [MPSAFE] pcib2: at device 15.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 CSC0000: start dependent (0) CSC0000: adding dma mask 0xa CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x2a0 CSC0000: adding io range 0x534-0x60b, size=0x4, align=0xd4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x24f, size=0x10, align=0x20 CSC0000: start dependent (1) CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x3f3, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x26f, size=0x10, align=0x10 CSC0000: end dependent CSC000f: start dependent (0) CSC000f: adding io range 0x3a0-0x3ff, size=0x8, align=0x8 CSC000f: end dependent CSC0010: adding io range 0xf00-0xfef, size=0x8, align=0x8 CSC0003: start dependent (0) CSC0003: adding io range 0x330-0x3f1, size=0x2, align=0x8 CSC0003: end dependent pnpbios: 14 devices, largest 248 bytes PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0x100000-0x7ffffff, size=0x7f00000 PNP0c01: adding fixed memory32 range 0xffe00000-0xffffffff, size=0x200000 PNP0c01: adding fixed memory32 range 0xf0000-0xfffff, size=0x10000 PNP0c01: adding io range 0x800-0x83f, size=0x40, align=0x1 PNP0c01: adding io range 0x850-0x85f, size=0x10, align=0x1 PNP0c01: adding io range 0x62-0x63, size=0x2, align=0x1 PNP0c01: adding io range 0x65-0x6f, size=0xb, align=0x1 PNP0c01: adding io range 0xe0-0xef, size=0x10, align=0x1 pnpbios: handle 0 device ID PNP0c01 (010cd041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0x8 pnpbios: handle 1 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0x8 pnpbios: handle 2 device ID PNP0501 (0105d041) PNP0401: adding irq mask 0x80 PNP0401: adding io range 0x378-0x37f, size=0x8, align=0x8 PNP0401: adding io range 0x778-0x77b, size=0x4, align=0x8 pnpbios: handle 3 device ID PNP0401 (0104d041) PNP0700: adding irq mask 0x40 PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0x8 PNP0700: adding dma mask 0x4 pnpbios: handle 4 device ID PNP0700 (0007d041) PNP0f13: adding irq mask 0x1000 pnpbios: handle 5 device ID PNP0f13 (130fd041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0x1 pnpbios: handle 6 device ID PNP0a03 (030ad041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x5f, size=0x20, align=0x1 pnpbios: handle 9 device ID PNP0100 (0001d041) PNP0200: adding io range 0x80-0x9f, size=0x20, align=0x1 PNP0200: adding io range 0-0x1f, size=0x20, align=0x1 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0x1 PNP0200: adding dma mask 0x10 pnpbios: handle 10 device ID PNP0200 (0002d041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0x1 PNP0303: adding io range 0x64-0x64, size=0x1, align=0x1 pnpbios: handle 11 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 pnpbios: handle 12 device ID PNP0800 (0008d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x7f, size=0x10, align=0x1 pnpbios: handle 13 device ID PNP0b00 (000bd041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0x1 pnpbios: handle 14 device ID PNP0c04 (040cd041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: ic_type 90 part_id 73 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: ic_type 90 part_id 73 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x21 0x31 0x21 0x21 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x21 0x29 0x21 0x21 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm0 pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm0: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap ff4000, 1000; 0xcc14a000 -> ff4000 pcm0: sndbuf_setmap ff3000, 1000; 0xcc14b000 -> ff3000 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid f00630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x3a0-0x3a7 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 1000630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0xf00-0xf07 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 300630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x330-0x331 on isa0 unknown: can't assign resources (port) unknown: at port 0x850-0x85f,0x800-0x83f iomem 0xf0000-0xfffff,0xffe00000-0xffffffff,0x100000-0x7ffffff,0-0x9ffff on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: can't assign resources (port) unknown: at port 0x3f0-0x3f5 on isa0 unknown: can't assign resources (irq) unknown: at irq 12 on isa0 unknown: can't assign resources (port) unknown: at port 0x60 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 8d041h, vid 8d041h pnpmss_probe result 6 unknown: failed to probe at port 0x61 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 331109196 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ...DHCP stuff deleted Linux ELF exec handler installed cat of /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0x534 irq 5 drq 1:0 bufsz 4096 (1p/1r/0v channels duplex default) Hope this helps Harry At 01:58 PM 7/11/2005 -0400, John Baldwin wrote: >On Monday 11 July 2005 01:30 pm, Harry Coin wrote: > > John, > > > > The verbose dmesg doesn't tell you enough. What was needed was debug > > writes in the pnp and non pnp mss.c probe routines that displayed the > > parent device id and the probed device id. That solved it because there > > you could see the acpi parent calling the non-pnp isa mss probe routine > > (mss_probe) which would _accept_ the probe, wrongly, on a few various > > attempts, only to have the non pnp mss_attach fail for lack of resources. > >Well, that would be helpful to see as well. :) It would be helpful to dump >the name of the parent device via device_get_nameunit(device_get_parent(dev)) >if you aren't already. > > > I haven't looked into the newbus logic enough to know for sure but my hunch > > is that the current mss.c call to detect pnp and so avoid to use the non > > pnp probe code (isa_get_logicalid) didn't get mapped through the > > acpi_isa_xxx but instead the isa routine directly-- which returned a zero > > in the context of an ACPI parent bus-- signaling not-a-pnp device -- while > > the acpi version would not have done. Hence the directive in the manual to > > use the ISA_PNP_PROBE even on non-PNP probe routines. > >Well, isa_get_logicalid() just asks the parent device for the ISA logical ID >IVAR which maps to a call to bus_read_ivar(). For the non-ACPI case, it is >implemented by returning the id read by the PnP code in in isa_read_ivar() in >sys/isa/isa_common.c. However, for devices that are children of acpi0, they >call acpi_read_ivar() which does end up calling acpi_isa_get_logicalid(): > >static int >acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) >{ > ... > case ISA_IVAR_LOGICALID: > *(int *)result = acpi_isa_get_logicalid(child); > break; > ... > return (0); >} > >So, you see, isa_get_logicalid() should work fine, and it's actually >something >that many ISA device drivers use to avoid probing PnP devices, so the root >problem needs to be fixed if acpi_isa_get_logicalid() has a bug. > >-- >John Baldwin <>< http://www.FreeBSD.org/~jhb/ >"Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:16:33 2005 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 A81ED16A41C for ; Mon, 11 Jul 2005 19:16:33 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id ACC4943D49 for ; Mon, 11 Jul 2005 19:16:32 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 11 Jul 2005 19:16:31 -0000 Received: from h081217095100.dyn.cm.kabsi.at (EHLO localhost.localdomain) [81.217.95.100] by mail.gmx.net (mp034) with SMTP; 11 Jul 2005 21:16:31 +0200 X-Authenticated: #16703784 From: Stefan Ehmann To: John Baldwin In-Reply-To: <200507111101.29623.jhb@FreeBSD.org> References: <42C92DC5.3060101@gddsn.org.cn> <200507091517.57736.jhb@FreeBSD.org> <1120939825.937.11.camel@taxman.pepperland> <200507111101.29623.jhb@FreeBSD.org> Content-Type: text/plain Date: Mon, 11 Jul 2005 21:16:34 +0200 Message-Id: <1121109394.1330.0.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: current@FreeBSD.org, Fabian Keil Subject: Re: Suspend 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: Mon, 11 Jul 2005 19:16:33 -0000 On Mon, 2005-07-11 at 11:01 -0400, John Baldwin wrote: > On Saturday 09 July 2005 04:10 pm, Stefan Ehmann wrote: > > On Sat, 2005-07-09 at 15:17 -0400, John Baldwin wrote: > > > I think you just need to remove the extra { after the if statement on > > > line 539 at the end of the line. > > > > This and changing timer0_max_real_count to timer0_real_max_count made it > > compilable. > > > > But this time the system is immediately very slow (not just after > > suspend) and I get this strange error message on startup: > > > > calcru: runtime went backwards from 68378390 usec to 67512958 usec for > > pid 11 (idle: cpu0) > > I had never set timer0_real_max_count. :( One more time: This new patch fixes the problem for me. Thanks From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:18:39 2005 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 77BF416A41F; Mon, 11 Jul 2005 19:18:39 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4375E43D5C; Mon, 11 Jul 2005 19:18:38 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 11 Jul 2005 14:19:21 -0500 Message-Id: <4.3.2.7.2.20050711141405.01ea43b8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 14:18:30 -0500 To: John Baldwin From: Harry Coin In-Reply-To: <200507111358.50262.jhb@FreeBSD.org> References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 19:18:39 -0000 John, P.S. Here's the verbose dmesg with acpi on in the bios, but with the mss_probe routine (non pnp) using the method described in the architecture manual. Here you will see the acpi calls rejected by the mss_probe routine, and the pnpbios call accepted. The driver loads properly as pcm0 with acpi enabled. (now, the line in and mic in functions are completely broken for the CS4236B in mode 2 and were previously, so there is still a problem there.) Harry Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #21: Sun May 29 15:06:21 CDT 2005 root@server1.quietfountain.com:/usr/obj/usr/src/sys/DISKLESS Preloaded elf kernel "/boot/kernel/kernel" at 0xc07af000. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc07af1a4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07af250. Calibrating clock(s) ... i8254 clock: 1193160 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 331109194 Hz CPU: Pentium II/Pentium II Xeon/Celeron (331.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ff real memory = 134209536 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x0000000007d8dfff, 123113472 bytes (30057 pages) avail memory = 125865984 (120 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xcf4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: mem: Pentium Pro MTRR support enabled null: io: random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fcaf0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 A 0x64 14 embedded 0 7 B 0x65 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 D 0x61 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 ACPI timer: 0/4 0/16777211 0/16777211 0/4 0/4 0/4 0/4 0/4 0/16777212 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 cpu0: on acpi0 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 30ad041h, vid ffffffffh pnpmss_probe result 6 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.1.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.7.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.17.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.14.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.14.1 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.3 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.0 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.13.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.13.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x010f, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 5, priority 38295): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKA (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKB (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKC (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 pcib0: slot 7 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000850, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base fa000000, size 12, enabled map[14]: type 4, range 32, base 0000dcc0, size 5, enabled map[18]: type 1, range 32, base ff000000, size 20, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKB (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKC (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 pcib0: slot 14 INTA routed to irq 10 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x1229, revid=0x05 bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x1011, dev=0x0024, revid=0x03 bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfc000000-0xfeffffff pcib1: prefetched decode 0xf9000000-0xf9ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfd000000-0xfdffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base fcfff000, size 12, enabled pcib1: device (null) requested decoded memory range 0xfcfff000-0xfcffffff found-> vendor=0x1002, dev=0x4744, revid=0x5c bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=00 ostat1=ff ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) fxp0: port 0xdcc0-0xdcdf mem 0xff000000-0xff0fffff,0xfa000000-0xfa000fff irq 10 at device 14.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfa000000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000a 0005 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:a0:c9:af:3e:51 fxp0: [MPSAFE] pcib2: at device 15.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.1 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.9.2 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.9.3 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.10.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.1 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.2 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.10.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.0 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.11.1 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.11.2 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.3 pci2: on pcib2 pci2: physical bus=2 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 acpi_tz0: on acpi0 acpi_tz0: _PSV value is absurd, ignored (-273.-2C) mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 8d041h, vid ffffffffh pnpmss_probe result 6 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 8d041h, vid ffffffffh pnpmss_probe result 6 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 CSC0000: start dependent (0) CSC0000: adding dma mask 0xa CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x2a0 CSC0000: adding io range 0x534-0x60b, size=0x4, align=0xd4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x24f, size=0x10, align=0x20 CSC0000: start dependent (1) CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x3f3, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x26f, size=0x10, align=0x10 CSC0000: end dependent CSC000f: start dependent (0) CSC000f: adding io range 0x3a0-0x3ff, size=0x8, align=0x8 CSC000f: end dependent CSC0010: adding io range 0xf00-0xfef, size=0x8, align=0x8 CSC0003: start dependent (0) CSC0003: adding io range 0x330-0x3f1, size=0x2, align=0x8 CSC0003: end dependent sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm0 pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm0: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap ff4000, 1000; 0xcc14e000 -> ff4000 pcm0: sndbuf_setmap ff3000, 1000; 0xcc14f000 -> ff3000 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid f00630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x3a0-0x3a7 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 1000630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0xf00-0xf07 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 300630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x330-0x331 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 331109194 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ...DHCP stuff deleted... start_init: trying /sbin/init splash: image decoder found: green_saver Linux ELF exec handler installed FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0x534 irq 5 drq 1:0 bufsz 4096 (1p/1r/0v channels duplex default) Harry From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:22:42 2005 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 DD02C16A41C; Mon, 11 Jul 2005 19:22:42 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A9743D4C; Mon, 11 Jul 2005 19:22:41 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 11 Jul 2005 14:23:07 -0500 Message-Id: <4.3.2.7.2.20050711142120.01edd3f0@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 14:22:15 -0500 To: John Baldwin From: Harry Coin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 19:22:43 -0000 John, P.P.S. The code in mss.c that gave rise to the working acpi boot in the P.S. (per the manual requirement) is static struct isa_pnp_id mss_ids[] = { {0} }; static int mss_probe(device_t dev) { u_char tmp, tmpx; int flags, irq, drq, result = ENXIO, setres = 0; struct mss_info *mss; printf("mss_probe: bus %s is probing device %s\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev)); result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); if (result!=ENOENT) return ENXIO; /* only continue if the device is not pnp */ /* old way- not so good for ACPI: */ //if (isa_get_logicalid(dev)) return ENXIO; printf("mss_probe: non pnp audio chip detected.\n"); From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:58:31 2005 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 AD30C16A423 for ; Mon, 11 Jul 2005 19:58:31 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D683943D48 for ; Mon, 11 Jul 2005 19:58:30 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ds4Oj-0001WF-Ns for freebsd-current@freebsd.org; Mon, 11 Jul 2005 21:57:01 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 21:57:01 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 21:57:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Mon, 11 Jul 2005 12:55:54 -0700 Lines: 61 Message-ID: References: <200507111438.08844.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.9.0 Sender: news Subject: Re: is there a way not to believe the bios' IRQ prog and use the $PIR? 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, 11 Jul 2005 19:58:31 -0000 John Baldwin wrote: > On Monday 11 July 2005 12:17 pm, othermark wrote: >> Hi, >> >> I believe since the following commit, I have had serious problems with >> interrupts on one class of machines (TYAN S1867 - thunder 2500): >> >> http://article.gmane.org/gmane.os.freebsd.devel.cvs.src/46247/ >> >> Is there a tunable I'm not aware of that I could revert back to >> not believing the BIOS and use the $PIR entries? > > You can override the IRQs for any link device by setting > hw.pci.link.0x12.irq=XX to set link 0x12 to irq XX for example. You could > also modify $PIR to never trust a BIOS value > 16: > > --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2005/04/14 18:25:24 > +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2005/07/11 18:13:16 > @@ -327,6 +327,15 @@ > if (irq == PCI_INVALID_IRQ || irq == pci_link->pl_irq) > return; > > + /* Don't trust any BIOS IRQs greater than 15. */ > + if (irq >= NUM_ISA_INTERRUPTS) { > + printf( > + "$PIR: Ignoring invalid BIOS IRQ %d from %d.%d.INT%c for link %#x\n", > + irq, entry->pe_bus, entry->pe_device, pin + 'A', > + pci_link->pl_id); > + return; > + } > + > /* > * If we don't have an IRQ for this link yet, then we trust the > * BIOS, even if it seems invalid from the $PIR entries. > @@ -334,7 +343,7 @@ > if (pci_link->pl_irq == PCI_INVALID_IRQ) { > if (!pci_pir_valid_irq(pci_link, irq)) > printf( > - "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c is for link %#x\n", > + "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c for link %#x\n", > irq, entry->pe_bus, entry->pe_device, pin + 'A', > pci_link->pl_id); > pci_link->pl_irq = irq; > At first blush this seems to do the trick! My log used to be flooded with the following on this machine, but now under simultaneous load with that patch I get none: Jul 11 18:44:59 consrv kernel: sio17: 171 more interrupt-level buffer overflows(total 5881) Jul 11 18:45:30 consrv kernel: sio17: 26 more interrupt-level buffer overflows (total 5907) Jul 11 18:46:00 consrv kernel: sio17: 48 more interrupt-level buffer overflows (total 5955) -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:24:31 2005 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 8E34416A41C for ; Mon, 11 Jul 2005 20:24:31 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id D544D43D5E for ; Mon, 11 Jul 2005 20:24:28 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd31.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1Ds4pH-0002mX-00; Mon, 11 Jul 2005 22:24:27 +0200 Received: from fw.reifenberger.com (SyFKrMZloeezTQl2uYv3f7Ib7SLaAZK3HXJWHIODpD2SRpmOuIZqZN@[84.152.86.36]) by fwd31.sul.t-online.de with esmtp id 1Ds4p2-2L8WRc0; Mon, 11 Jul 2005 22:24:12 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j6BKNdF8075103; Mon, 11 Jul 2005 22:23:40 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Mon, 11 Jul 2005 22:23:39 +0200 (CEST) From: Michael Reifenberger To: Martin Cracauer In-Reply-To: <20050711131915.A19863@cons.org> Message-ID: <20050711214244.Y74952@fw.reifenberger.com> References: <20050711131915.A19863@cons.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: SyFKrMZloeezTQl2uYv3f7Ib7SLaAZK3HXJWHIODpD2SRpmOuIZqZN@t-dialin.net X-TOI-MSGID: 6789e388-6a11-4fad-8b16-e1b15a5b5927 Cc: freebsd-current@freebsd.org Subject: Re: gvinum. A little worse than I thought :-) 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, 11 Jul 2005 20:24:31 -0000 On Mon, 11 Jul 2005, Martin Cracauer wrote: > Date: Mon, 11 Jul 2005 13:19:15 -0400 > From: Martin Cracauer > To: freebsd-current@freebsd.org > Subject: gvinum. A little worse than I thought :-) > ... > What is a recommended ATA or SATA controller with hardware RAID5 and > the capability to run different RAID levels on different parts of the > disk these days? > For those who don't want to bother with SW-raid at all sould have a look at: http://www.areca.com.tw/products/html/scsi-sata-sub.htm http://www.areca.com.tw/products/html/ide-ide.htm or http://www.areca.com.tw/products/html/scsi-ide-sub.htm I have the last one which works flawlessly for me. One can configure them via sio(4) or with an extra I2C control panel. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:28:18 2005 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 5A37616A423 for ; Mon, 11 Jul 2005 20:28:18 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 840A443D48 for ; Mon, 11 Jul 2005 20:28:17 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 16:42:20 -0400 From: John Baldwin To: Harry Coin Date: Mon, 11 Jul 2005 16:26:23 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111626.25124.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 20:28:18 -0000 On Monday 11 July 2005 03:03 pm, Harry Coin wrote: > John, > > Here are the results you asked for. You will seein the acpi boot the > isa_get_logicalid(dev) returns 0 for a probe call to the non-pnp routine > mss_probe > > dmesg excerpt ... > mss_probe: bus acpi0 is probing device pcm0 > mss_probe: isa_get_logicalid() returned 0! > mss_probe: no address given, try 0x530 > mss_detect - chip revision 0x0a > mss_detect() - Detected CS4236 > pcm0: port 0x530-0x537 on acpi0 > device_attach: pcm0 attach returned 6 > mss_probe: bus acpi0 is probing device pcm1 > ... > > Here are the changes I made for debugging output to the two probe routines > in mss.c > > static int > mss_probe(device_t dev) > { > u_char tmp, tmpx; > int flags, irq, drq, result = ENXIO, setres = 0; > struct mss_info *mss; > printf("mss_probe: bus %s is probing device > %s\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev)) >; // result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); // > if (result!=ENOENT) return ENXIO; /* only continue if the device is not > pnp */ > /* old way- not so good for ACPI: */ > if (isa_get_logicalid(dev)) return ENXIO; > printf("mss_probe: isa_get_logicalid() returned 0!\n"); > .... Ok, let's do this one step at a time. I'll give you a patch for mss.c to try to get some more information. It also looks like your soundcard creates 4 different devices (Game, MPU, etc.) so it may be that mss is not handling your card correctly when it sees all the devices. Also, can you upload your acpidump somewhere and provide a URL? I'm curious if you have ACPI devices like thermal zones that don't have _HID's and only have _CIDs. In fact, here's a patch to fix acpi_get_logicalid() in that case. Give this a try first and let me know if it fixes it. Index: acpi.c =================================================================== RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.214 diff -u -r1.214 acpi.c --- acpi.c 3 Jun 2005 20:12:12 -0000 1.214 +++ acpi.c 11 Jul 2005 20:23:14 -0000 @@ -1138,6 +1138,7 @@ ACPI_HANDLE h; ACPI_STATUS error; u_int32_t pnpid; + int i; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -1153,8 +1154,24 @@ goto out; devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; - if ((devinfo->Valid & ACPI_VALID_HID) != 0) + if ((devinfo->Valid & ACPI_VALID_HID) != 0) { pnpid = PNP_EISAID(devinfo->HardwareId.Value); + goto out; + } + + /* + * If we don't have a HID but do have at least one CID, return the first + * CID. This is so that ISA drivers that use isa_get_logicalid() to + * determine if a device is a PnP device or not will work correctly. + */ + if ((devinfo->Valid & ACPI_VALID_CID) != 0) { + for (i = 0; i < devinfo->CompatibilityId.Count; i++) { + if (strncmp(devinfo->CompatibilityId.Id[i].Value, "PNP", 3) != 0) + continue; + pnpid = PNP_EISAID(devinfo->CompatibilityId.Id[i].Value); + goto out; + } + } out: if (buf.Pointer != NULL) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:44:44 2005 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 7783C16A41C for ; Mon, 11 Jul 2005 20:44:44 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31C1E43D49 for ; Mon, 11 Jul 2005 20:44:44 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j6BKicbk046767; Mon, 11 Jul 2005 13:44:40 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200507112044.j6BKicbk046767@gate.bitblocks.com> To: Brooks Davis In-reply-to: Your message of "Tue, 05 Jul 2005 15:42:09 PDT." <20050705224209.GC28034@odin.ac.hmc.edu> Date: Mon, 11 Jul 2005 13:44:38 -0700 From: Bakul Shah Cc: Sam Leffler , freebsd-current@freebsd.org Subject: Re: minor WPA problem on a Thinkpad R40 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, 11 Jul 2005 20:44:44 -0000 > > IMO wpa_supplicant should exit when the interface goes down/away but it > > does not. I sent mail to Jouni about this but he hasn't responded yet. > > > I was going to check if there was a way to make it work this way. Not > > sure why it works this way except to avoid recalculating various crypto > > state or perhaps to avoid linux hotplug issues. If it matters may be the state can be saved? On restart wpa_supplicant can use it as a hint. The problem seems to be generic in that suspend/resume needs to save more state than shutdown/boot (or may be, the only difference between the two is state saving). > I've we're going to do that, I think we may want either a new target in > /etc/rc.d/netif or a new /etc/rc.d/linkstate script. That's probably > the right way to go though. You mean targets like suspend/resume? Not sure if you guys need me to test anything.... Thanks for looking into this! From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:21:08 2005 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 CA73E16A41C; Mon, 11 Jul 2005 21:21:08 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517BF43D48; Mon, 11 Jul 2005 21:21:08 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 11 Jul 2005 16:21:51 -0500 Message-Id: <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 16:20:49 -0500 To: John Baldwin From: Harry Coin In-Reply-To: <200507111626.25124.jhb@FreeBSD.org> References: <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org, Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 21:21:08 -0000 John, 1) Indeed the mss driver just ignores the further logical devices the chip offers -- which is most likely the right thing to do. Logical device 0 is the WSS codec, Synthesizer, and alternate Sound Blaster pro interface. Handled by MSS.c Logical device 1 is a game port. 2 is a 'master chip control' device (defaults all are ok I think). 3 is an MPU-401 midi, 4 (not enabled) is a CD Rom controller, 5 (not enabled) is a modem. The data sheet for the CS4236B is available online. I'll send it as a private attachment in an email. To be tidy, the mss.c controller should 'talk to' a device for the 'master chip controller' to be sure sound related bits are set the way WSS needs them to be set. The power up defaults are ok so far as I can tell. I'm not sure where to read to understand how to program a 'multifunction' chip when several of the on chip logical devices have dependencies on a 'separate' chip control device. To be very tidy, the device for the master chip controller should be up and running before the attach routines of any of its subordinate functions is called, those routines would then send setup commands to the master chip control device. Don't have a clue how to get that done. 2) Be advised that the mss driver as shipped with ACPI turned off puts internally generated sounds to the line-out port with no problems. (line in and mic in are not processed, but that's another story). 3) Give me a clue or a doc ref about how to apply the RCS / diff patch you sent me. 4) See http://www.n4comm.com/gxa.acpidump and http://www.n4comm.com/gxa.dsdt per your request At 04:26 PM 7/11/2005 -0400, John Baldwin wrote: >On Monday 11 July 2005 03:03 pm, Harry Coin wrote: > > John, > > > > Here are the results you asked for. You will seein the acpi boot the > > isa_get_logicalid(dev) returns 0 for a probe call to the non-pnp routine > > mss_probe > > > > dmesg excerpt ... > > mss_probe: bus acpi0 is probing device pcm0 > > mss_probe: isa_get_logicalid() returned 0! > > mss_probe: no address given, try 0x530 > > mss_detect - chip revision 0x0a > > mss_detect() - Detected CS4236 > > pcm0: port 0x530-0x537 on acpi0 > > device_attach: pcm0 attach returned 6 > > mss_probe: bus acpi0 is probing device pcm1 > > ... > > > > Here are the changes I made for debugging output to the two probe routines > > in mss.c > > > > static int > > mss_probe(device_t dev) > > { > > u_char tmp, tmpx; > > int flags, irq, drq, result = ENXIO, setres = 0; > > struct mss_info *mss; > > printf("mss_probe: bus %s is probing device > > %s\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev)) > >; // result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids); // > > if (result!=ENOENT) return ENXIO; /* only continue if the device is not > > pnp */ > > /* old way- not so good for ACPI: */ > > if (isa_get_logicalid(dev)) return ENXIO; > > printf("mss_probe: isa_get_logicalid() returned 0!\n"); > > .... > >Ok, let's do this one step at a time. I'll give you a patch for mss.c to try >to get some more information. It also looks like your soundcard creates 4 >different devices (Game, MPU, etc.) so it may be that mss is not handling >your card correctly when it sees all the devices. > >Also, can you upload your acpidump somewhere and provide a URL? I'm curious >if you have ACPI devices like thermal zones that don't have _HID's and only >have _CIDs. In fact, here's a patch to fix acpi_get_logicalid() in that >case. Give this a try first and let me know if it fixes it. > >Index: acpi.c >=================================================================== >RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v >retrieving revision 1.214 >diff -u -r1.214 acpi.c >--- acpi.c 3 Jun 2005 20:12:12 -0000 1.214 >+++ acpi.c 11 Jul 2005 20:23:14 -0000 >@@ -1138,6 +1138,7 @@ > ACPI_HANDLE h; > ACPI_STATUS error; > u_int32_t pnpid; >+ int i; > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > >@@ -1153,8 +1154,24 @@ > goto out; > devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; > >- if ((devinfo->Valid & ACPI_VALID_HID) != 0) >+ if ((devinfo->Valid & ACPI_VALID_HID) != 0) { > pnpid = PNP_EISAID(devinfo->HardwareId.Value); >+ goto out; >+ } >+ >+ /* >+ * If we don't have a HID but do have at least one CID, return the first >+ * CID. This is so that ISA drivers that use isa_get_logicalid() to >+ * determine if a device is a PnP device or not will work correctly. >+ */ >+ if ((devinfo->Valid & ACPI_VALID_CID) != 0) { >+ for (i = 0; i < devinfo->CompatibilityId.Count; i++) { >+ if (strncmp(devinfo->CompatibilityId.Id[i].Value, "PNP", 3) != 0) >+ continue; >+ pnpid = PNP_EISAID(devinfo->CompatibilityId.Id[i].Value); >+ goto out; >+ } >+ } > > out: > if (buf.Pointer != NULL) > > >-- >John Baldwin <>< http://www.FreeBSD.org/~jhb/ >"Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:35:20 2005 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 DA73A16A41C for ; Mon, 11 Jul 2005 21:35:20 +0000 (GMT) (envelope-from ben@bjencks.net) Received: from bjencks.net (sub20-225.member.dsl-only.net [63.105.20.225]) by mx1.FreeBSD.org (Postfix) with SMTP id 25D0443D48 for ; Mon, 11 Jul 2005 21:35:19 +0000 (GMT) (envelope-from ben@bjencks.net) Received: (qmail 39119 invoked from network); 11 Jul 2005 21:35:19 -0000 Received: from unknown (HELO wagner.bjencks.net) (10.11.55.30) by bjencks.net with SMTP; 11 Jul 2005 21:35:19 -0000 Received: (from brj@localhost) by wagner.bjencks.net (8.13.4/8.13.4/Submit) id j6BLZGJo001315; Mon, 11 Jul 2005 14:35:16 -0700 (PDT) (envelope-from ben@bjencks.net) X-Authentication-Warning: wagner.bjencks.net: brj set sender to ben@bjencks.net using -f To: current@FreeBSD.org References: <42C92DC5.3060101@gddsn.org.cn> <200507091517.57736.jhb@FreeBSD.org> <1120939825.937.11.camel@taxman.pepperland> <200507111101.29623.jhb@FreeBSD.org> <1121109394.1330.0.camel@taxman.pepperland> From: Ben Jencks Date: Mon, 11 Jul 2005 14:35:13 -0700 In-Reply-To: <1121109394.1330.0.camel@taxman.pepperland> (Stefan Ehmann's message of "Mon, 11 Jul 2005 21:16:34 +0200") Message-ID: <86r7e5uium.fsf@wagner.bjencks.net> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Suspend 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: Mon, 11 Jul 2005 21:35:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Ehmann writes: > On Mon, 2005-07-11 at 11:01 -0400, John Baldwin wrote: >> On Saturday 09 July 2005 04:10 pm, Stefan Ehmann wrote: >> > On Sat, 2005-07-09 at 15:17 -0400, John Baldwin wrote: >> > > I think you just need to remove the extra { after the if statement on >> > > line 539 at the end of the line. >> > >> > This and changing timer0_max_real_count to timer0_real_max_count made it >> > compilable. >> > >> > But this time the system is immediately very slow (not just after >> > suspend) and I get this strange error message on startup: >> > >> > calcru: runtime went backwards from 68378390 usec to 67512958 usec for >> > pid 11 (idle: cpu0) >> >> I had never set timer0_real_max_count. :( One more time: > > This new patch fixes the problem for me. On a T43p, I had the same problem with the slowdown after resume. This patch fixes it for me as well. Thanks, - -- Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0uYUpt3yYclAKVsRArnpAJsFBMgKkGVXiMhnVAzdnw6x4U2AtQCeOkrJ jErii8PcLAzJqI0gSULZnk4= =/Ur+ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:03:13 2005 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 F1E6716A41C for ; Mon, 11 Jul 2005 22:03:13 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5120243D46 for ; Mon, 11 Jul 2005 22:03:12 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6BM3CPh025217 for ; Tue, 12 Jul 2005 00:03:12 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6BM3BFd025216 for freebsd-current@freebsd.org; Mon, 11 Jul 2005 18:03:11 -0400 (EDT) (envelope-from cracauer) Date: Mon, 11 Jul 2005 18:03:11 -0400 From: Martin Cracauer To: freebsd-current@freebsd.org Message-ID: <20050711180311.A23623@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: 6-current: udf broken, "locking against myself" 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, 11 Jul 2005 22:03:14 -0000 Further testing 6-current. Seems like the udf filesystem is hosed, I cannot even use a minimal one. Mounting a udf (data) filesystem works, but the first attempt to use it results in "panic: lockmgr: locking against myself". I put an minimal testing image on: http://wavehh.dyndns.org/tmp/ll.udf.gz It has been created with `mkisofs -udf dir` # no other options to mkisofs Reproduce error: $ mdconfig -a -t vnode -f ll.udf md4 $ mount_udf /dev/md4 /mnt/tmp # works $ cd /mnt/tmp # still works $ ls # panic This is a single-processor i386 machine with a single-processor kernel. Info on this machine (dmesg, pciconf, kernel config etc.) is on http://www.cons.org/cracauer/machines/grisu/ A quick check on a 2-processor box with SMP support shows the same panic. Here are the symboled parts of the backtrace: #23 0xc05888e0 in kdb_enter (msg=0x0) at cpufunc.h:60 #24 0xc056a4f5 in panic (fmt=0xc077896e "lockmgr: locking against myself") at ../../../kern/kern_shutdown.c:537 #25 0xc055baad in lockmgr (lkp=0xc2e27168, flags=12290, interlkp=0x80, td=0xc2d6b600) at ../../../kern/kern_lock.c:329 #26 0xc05ca1cf in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:258 #27 0xc074e364 in VOP_LOCK_APV (vop=0xc07b7500, a=0xf7cd8994) at vnode_if.c:1642 #28 0xc05e481c in vn_lock (vp=0xc2e27110, flags=4098, td=0xc2d6b600) at vnode_if.h:844 [addresses without symbols] #56 0xc074d40e in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at vnode_if.c:150 vnode_if.c:1642 is generated, it looks like this in this kernel (line marked in # comment). int VOP_LOCK_APV(struct vop_vector *vop, struct vop_lock_args *a) { int rc; VNASSERT(a->a_gen.a_desc == &vop_lock_desc, a->a_vp, ("Wrong a_desc in vop_lock(%p, %p)", a->a_vp, a)); while(vop != NULL && \ vop->vop_lock == NULL && vop->vop_bypass == NULL) vop = vop->vop_default; VNASSERT(vop != NULL, a->a_vp, ("No vop_lock(%p, %p)", a->a_vp, a)); vop_lock_pre(a); if (vop->vop_lock != NULL) rc = vop->vop_lock(a); # this is the panic line 1642 else rc = vop->vop_bypass(&a->a_gen); CTR3(KTR_VOP, "VOP_LOCK(vp 0x%lX, flags %ld, td 0x%lX)", a->a_vp, a->a_flags, a->a_td); if (rc == 0) { } else { } vop_lock_post(a, rc); return (rc); } Now, since I don't have anything useful in the backtrace, how do I go about debugging an error like this? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:09:09 2005 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 42A7916A41C for ; Mon, 11 Jul 2005 22:09:09 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC31243D55 for ; Mon, 11 Jul 2005 22:09:08 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so925941wra for ; Mon, 11 Jul 2005 15:09:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dp5xPdL3Zt7rwqgiglkvjCCd0d+DFekYOVt26VBVOgjzNHETrmsyBwljYOzvoC0MZ0ZDiGiXERxU0rCFsBdn7pM4Ds86WZjmTtO9asYQGcVPpxQ+z9KTVo2VJcqADOe/BBLQW23K/mSHMyQ8T6gA8mqVv8dR2vDa1M98AkKHwSc= Received: by 10.54.36.67 with SMTP id j67mr4392443wrj; Mon, 11 Jul 2005 15:08:14 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Mon, 11 Jul 2005 15:08:14 -0700 (PDT) Message-ID: Date: Mon, 11 Jul 2005 17:08:14 -0500 From: Sam Pierson To: FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Trouble with wi in Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2005 22:09:09 -0000 Hey all, I just got a SMC2532W-B, which supposedly uses the prism3 chipset (according to my friend who bought the exact same card). It works under OpenBSD and linux. When I insert the card, I get the following message: pccard1: (manufacturer=3D0xd601, product=3D0x0010) at functi= on 0 pccard1: CIS info: SMC, SMC2532W-B EliteConnect Wireless Adapter, I have already compiled in wi and wlan to my kernel. There was one post somewhere on the net about this card turning to an alternate chipset, but I couldn't find any verification of this, and SMC techs said that this = card would either be prism2.5 or prism3. =20 Any ideas on how I can make this work? -Sam From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:26:13 2005 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 C48DA16A41C for ; Mon, 11 Jul 2005 22:26:13 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D28843D60 for ; Mon, 11 Jul 2005 22:26:08 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1005477wri for ; Mon, 11 Jul 2005 15:26:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iI+MkojmVg9sW0lzLBbGPbeVTeU7MuUMiood9E2fMOdtRTDplFpnd2x4hNYhw4z32bwHR7kXOeMGJpxfe+lfYp1SyBYIBylLZ9VvwNk6xTsGCuovCV0jubKnXTt1ni6Ou9Wkld7x7jAtRfgYPb7DK8h3bdZaTApr5jUqwZim/Ww= Received: by 10.54.29.10 with SMTP id c10mr4193693wrc; Mon, 11 Jul 2005 15:25:18 -0700 (PDT) Received: by 10.54.29.26 with HTTP; Mon, 11 Jul 2005 15:25:17 -0700 (PDT) Message-ID: <790a9fff05071115253ea23741@mail.gmail.com> Date: Mon, 11 Jul 2005 17:25:17 -0500 From: Scot Hetzel To: Harry Coin In-Reply-To: <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> Cc: freebsd-current@freebsd.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2005 22:26:13 -0000 On 7/11/05, Harry Coin wrote: > 3) Give me a clue or a doc ref about how to apply the RCS / diff patch yo= u > sent me. >=20 Save the patch in the email, then do the following: cd src/sys/dev/acpica patch < /path/to/patch/acpica.patch Scot From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:32:00 2005 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 B14ED16A41C; Mon, 11 Jul 2005 22:32:00 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264D843D4C; Mon, 11 Jul 2005 22:32:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-184-89.dsl.snfc21.pacbell.net [64.171.184.89]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6BMVwo5028129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 15:31:59 -0700 Message-ID: <42D2F177.3070101@root.org> Date: Mon, 11 Jul 2005 15:23:51 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> In-Reply-To: <200507111626.25124.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Harry Coin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 11 Jul 2005 22:32:00 -0000 John Baldwin wrote: > Also, can you upload your acpidump somewhere and provide a URL? I'm curious > if you have ACPI devices like thermal zones that don't have _HID's and only > have _CIDs. In fact, here's a patch to fix acpi_get_logicalid() in that > case. Give this a try first and let me know if it fixes it. I would rather you directly call acpi_isa_get_compatid() rather than duplicating its logic here. There's no guarantee that the first CID will match the single ID passed in. -Nate > Index: acpi.c > =================================================================== > RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.214 > diff -u -r1.214 acpi.c > --- acpi.c 3 Jun 2005 20:12:12 -0000 1.214 > +++ acpi.c 11 Jul 2005 20:23:14 -0000 > @@ -1138,6 +1138,7 @@ > ACPI_HANDLE h; > ACPI_STATUS error; > u_int32_t pnpid; > + int i; > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > > @@ -1153,8 +1154,24 @@ > goto out; > devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; > > - if ((devinfo->Valid & ACPI_VALID_HID) != 0) > + if ((devinfo->Valid & ACPI_VALID_HID) != 0) { > pnpid = PNP_EISAID(devinfo->HardwareId.Value); > + goto out; > + } > + > + /* > + * If we don't have a HID but do have at least one CID, return the first > + * CID. This is so that ISA drivers that use isa_get_logicalid() to > + * determine if a device is a PnP device or not will work correctly. > + */ > + if ((devinfo->Valid & ACPI_VALID_CID) != 0) { > + for (i = 0; i < devinfo->CompatibilityId.Count; i++) { > + if (strncmp(devinfo->CompatibilityId.Id[i].Value, "PNP", 3) != 0) > + continue; > + pnpid = PNP_EISAID(devinfo->CompatibilityId.Id[i].Value); > + goto out; > + } > + } > > out: > if (buf.Pointer != NULL) > > -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 02:49:16 2005 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 BD83F16A41C for ; Tue, 12 Jul 2005 02:49:16 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD5F43D53 for ; Tue, 12 Jul 2005 02:49:16 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j6C2nCQn076391; Mon, 11 Jul 2005 22:49:12 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j6C2nCCu076388; Mon, 11 Jul 2005 22:49:12 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Mon, 11 Jul 2005 22:49:12 -0400 (EDT) From: Andre Guibert de Bruet To: Nicolas Blais In-Reply-To: <200507091406.35280.nb_root@videotron.ca> Message-ID: <20050711224548.C80892@lexi.siliconlandmark.com> References: <200507091406.35280.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.539, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: No mouse with vidcontrol to 1024x768 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, 12 Jul 2005 02:49:16 -0000 On Sat, 9 Jul 2005, Nicolas Blais wrote: > When I try to switch console resolution to any 24-bit color depth, such as > vidcontrol -m on MODE_280, it switches perfectly to a beautiful shell and > nice fonts but I loose my mouse cursor. I can still select text (guessing > from where my mouse used to be) and passing my mouse over text distorts it a > bit. If I switch to 16-bit depth my mouse appears and everything is fine. > This is all resolutions. > > MODE_280 is 1024x768@24bpp while MODE_279 is 1024x768@16bpp. > > I have a : > drm0: port 0xe000-0xe0ff mem > 0xe8000000-0xefffffff,0xfbe00000-0xfbe0ffff irq 11 at device 0.0 on pci1 > > With enough power to draw a cursor :) I am seeing the same behavior with: none5@pci8:12:0: class=0x030000 card=0x34398086 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class = display subclass = VGA FreeBSD bling.properkernel.com 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Mon Jul 4 02:45:50 EDT 2005 root@bling.properkernel.com:/usr/obj/usr/src/sys/BLING i386 For some weird reason, when using a mode that does draw the cursor, it doesn't honor my request to use a block cursor. My custom kernel is a dumbed down version of generic with the following: options SC_ALT_MOUSE_IMAGE options SC_CUT_SPACES2TABS options SC_HISTORY_SIZE=4096 options SC_PIXEL_MODE options VESA options VGA_WIDTH90 Cheers, Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 02:51:58 2005 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 866B616A41C for ; Tue, 12 Jul 2005 02:51:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29CF143D46 for ; Tue, 12 Jul 2005 02:51:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6C2vPpF060680; Mon, 11 Jul 2005 20:57:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D33043.4030700@samsco.org> Date: Mon, 11 Jul 2005 20:51:47 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Cracauer References: <20050711180311.A23623@cons.org> In-Reply-To: <20050711180311.A23623@cons.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: 6-current: udf broken, "locking against myself" 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, 12 Jul 2005 02:51:58 -0000 This should have been fixed by a commit a couple of days ago. How old are your sources? Scott Martin Cracauer wrote: > Further testing 6-current. Seems like the udf filesystem is hosed, I > cannot even use a minimal one. > > Mounting a udf (data) filesystem works, but the first attempt to use it > results in > "panic: lockmgr: locking against myself". > > I put an minimal testing image on: > http://wavehh.dyndns.org/tmp/ll.udf.gz > > It has been created with `mkisofs -udf dir` # no other options to mkisofs > > Reproduce error: > $ mdconfig -a -t vnode -f ll.udf > md4 > $ mount_udf /dev/md4 /mnt/tmp # works > $ cd /mnt/tmp # still works > $ ls # panic > > This is a single-processor i386 machine with a single-processor > kernel. Info on this machine (dmesg, pciconf, kernel config etc.) is > on http://www.cons.org/cracauer/machines/grisu/ > > A quick check on a 2-processor box with SMP support shows the same > panic. > > Here are the symboled parts of the backtrace: > #23 0xc05888e0 in kdb_enter (msg=0x0) at cpufunc.h:60 > #24 0xc056a4f5 in panic (fmt=0xc077896e "lockmgr: locking against myself") > at ../../../kern/kern_shutdown.c:537 > #25 0xc055baad in lockmgr (lkp=0xc2e27168, flags=12290, interlkp=0x80, > td=0xc2d6b600) at ../../../kern/kern_lock.c:329 > #26 0xc05ca1cf in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:258 > #27 0xc074e364 in VOP_LOCK_APV (vop=0xc07b7500, a=0xf7cd8994) > at vnode_if.c:1642 > #28 0xc05e481c in vn_lock (vp=0xc2e27110, flags=4098, td=0xc2d6b600) > at vnode_if.h:844 > [addresses without symbols] > #56 0xc074d40e in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at vnode_if.c:150 > > vnode_if.c:1642 is generated, it looks like this in this kernel (line > marked in # comment). > > int > VOP_LOCK_APV(struct vop_vector *vop, struct vop_lock_args *a) > { > int rc; > > VNASSERT(a->a_gen.a_desc == &vop_lock_desc, a->a_vp, > ("Wrong a_desc in vop_lock(%p, %p)", a->a_vp, a)); > while(vop != NULL && \ > vop->vop_lock == NULL && vop->vop_bypass == NULL) > vop = vop->vop_default; > VNASSERT(vop != NULL, a->a_vp, ("No vop_lock(%p, %p)", a->a_vp, a)); > vop_lock_pre(a); > if (vop->vop_lock != NULL) > rc = vop->vop_lock(a); # this is the panic line 1642 > else > rc = vop->vop_bypass(&a->a_gen); > CTR3(KTR_VOP, > "VOP_LOCK(vp 0x%lX, flags %ld, td 0x%lX)", > a->a_vp, a->a_flags, a->a_td); > if (rc == 0) { > } else { > } > vop_lock_post(a, rc); > return (rc); > } > > Now, since I don't have anything useful in the backtrace, how do I go > about debugging an error like this? > > Martin From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 03:50:27 2005 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 172F816A41C for ; Tue, 12 Jul 2005 03:50:27 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: from web31802.mail.mud.yahoo.com (web31802.mail.mud.yahoo.com [68.142.207.65]) by mx1.FreeBSD.org (Postfix) with SMTP id ADB6143D45 for ; Tue, 12 Jul 2005 03:50:26 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 26409 invoked by uid 60001); 12 Jul 2005 03:50:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KNzG9a/9aNio0RcEU2d40vdbKw8drjoGF5rzEB6PSbwZzQ4hA2gjkoVJThTQHXr7orXt7ndYUPaBlb1V8nJxfSS0/K1ZVIOQ6CU9mQQvyVcrt41y+y8VrOLgRS1MUAGiEvaWKRqS0sNm8Dr7AlAvRsrg2FQ5KTByQz0hGzMEFuQ= ; Message-ID: <20050712035026.26407.qmail@web31802.mail.mud.yahoo.com> Received: from [64.168.22.169] by web31802.mail.mud.yahoo.com via HTTP; Mon, 11 Jul 2005 20:50:25 PDT Date: Mon, 11 Jul 2005 20:50:25 -0700 (PDT) From: Mohan Srinivasan To: Oliver Lehmann In-Reply-To: <20050709082801.18f15374.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: problems with soft-nfs when the server goes down 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, 12 Jul 2005 03:50:27 -0000 If you can't get a core, can you save the tcpump output to a file and send me the file ? Make sure you specify -s1500 (so the entire NFS header gets captured). thanks mohan --- Oliver Lehmann wrote: > Mohan Srinivasan wrote: > > > FYI - > > > > I am not able to reproduce the problem in my setup (at least > > not easily). So a tcpdump and core would be very helpful. > > > 08:09:01.610027 IP curry.salatschuessel.net.1660761846 > 10.0.1.251.nfs: 112 read [|nfs] > 08:09:16.978803 IP curry.salatschuessel.net.1660761846 > 10.0.1.251.nfs: 112 read [|nfs] > 08:09:32.357595 IP curry.salatschuessel.net.1660761847 > 10.0.1.251.nfs: 112 read [|nfs] > 08:09:47.726377 IP curry.salatschuessel.net.1660761847 > 10.0.1.251.nfs: 112 read [|nfs] > 08:10:03.105170 IP curry.salatschuessel.net.1660761847 > 10.0.1.251.nfs: 112 read [|nfs] > 08:10:03.184644 IP 10.0.1.251.nfs > curry.salatschuessel.net.1660761847: reply ok 1472 read > 08:10:03.184752 IP 10.0.1.251 > curry.salatschuessel.net: udp > 08:10:03.184988 IP 10.0.1.251 > curry.salatschuessel.net: udp > 08:10:03.185112 IP 10.0.1.251 > curry.salatschuessel.net: udp > 08:10:03.185239 IP 10.0.1.251 > curry.salatschuessel.net: udp > 08:10:03.185312 IP 10.0.1.251 > curry.salatschuessel.net: udp > > > on 08:10 the server was back online. But beep-media-player was still stucked. > I ran a ktrace then on the pid of beep-media-player: > > 1781 beep-media-player CALL ioctl(0x9,SNDCTL_DSP_GETOSPACE,0xbf1f6ee0) > 1781 beep-media-player RET ioctl 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL ioctl(0x9,SNDCTL_DSP_GETOSPACE,0xbf1f6ee0) > 1781 beep-media-player RET ioctl 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL ioctl(0x9,SNDCTL_DSP_GETOSPACE,0xbf1f6ee0) > 1781 beep-media-player RET ioctl 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL ioctl(0x9,SNDCTL_DSP_GETOSPACE,0xbf1f6ee0) > 1781 beep-media-player RET ioctl 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL select(0x8,0xbf8fdef0,0,0,0xbf8fde38) > 1781 beep-media-player RET fork 0 > 1781 beep-media-player CALL kse_release(0x80c1f44) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > 1781 beep-media-player CALL ioctl(0x9,SNDCTL_DSP_GETOSPACE,0xbf1f6ee0) > 1781 beep-media-player RET ioctl 0 > 1781 beep-media-player CALL kse_release(0x80c1f4c) > 1781 beep-media-player RET kse_release 0 > > all the time repeating that. The nfs mount itself is working I can > ls /mnt/tmp for example > > When I try mpg123, > > 08:20:18.339812 IP curry.salatschuessel.net.596824881 > 10.0.1.251.nfs: 112 read [|nfs] > 08:20:22.189524 IP curry.salatschuessel.net.596824881 > 10.0.1.251.nfs: 112 read [|nfs] > 08:20:29.878921 IP curry.salatschuessel.net.596824881 > 10.0.1.251.nfs: 112 read [|nfs] > 08:20:45.247753 IP curry.salatschuessel.net.596824881 > 10.0.1.251.nfs: 112 read [|nfs] > 08:21:00.616563 IP curry.salatschuessel.net.596824881 > 10.0.1.251.nfs: 112 read [|nfs] > 08:23:09.367970 IP curry.salatschuessel.net.596824882 > 10.0.1.251.nfs: 104 access [|nfs] > 08:23:09.368508 IP 10.0.1.251.nfs > curry.salatschuessel.net.596824882: reply ok 120 access c > 001c > > And all I get with ktrace out is > > 569 mpg123 RET write 16384/0x4000 > > as the last line, and after that nothing more. > > I'm not sure how to get a coredump out of these locked processes. > > -- > Oliver Lehmann > http://www.pofo.de/ > http://wishlist.ans-netz.de/ > _______________________________________________ > 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 Tue Jul 12 04:49:51 2005 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 CE4D016A41C; Tue, 12 Jul 2005 04:49:51 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45DB243D45; Tue, 12 Jul 2005 04:49:51 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C4nXNS089264; Tue, 12 Jul 2005 00:49:33 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C4nnpR030807; Tue, 12 Jul 2005 00:49:49 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C4nlJq090466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2005 00:49:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Jul 2005 00:51:19 -0400 To: John Baldwin From: Mike Tancsa In-Reply-To: <200507111327.46165.jhb@FreeBSD.org> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507081006.43609.jhb@FreeBSD.org> <6.2.1.2.0.20050708110446.07de5768@64.7.153.2> <200507111327.46165.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 12 Jul 2005 04:49:52 -0000 At 01:27 PM 11/07/2005, John Baldwin wrote: >Ok. Very odd in that the code there is almost identical. There is one diff >you can try reverting (use patch -R) and see if it changes anything: > >Index: mptable.c >=================================================================== >RCS file: /usr/cvs/src/sys/i386/i386/mptable.c,v >retrieving revision 1.235.2.4 >retrieving revision 1.241 >diff -u -r1.235.2.4 -r1.241 >--- mptable.c 25 Mar 2005 21:10:07 -0000 1.235.2.4 >+++ mptable.c 14 Apr 2005 17:59:58 -0000 1.241 >@@ -353,7 +353,6 @@ > busses[i].bus_type = NOBUS; > > /* Second, we run through adding I/O APIC's and busses. */ >- ioapic_enable_mixed_mode(); > mptable_parse_apics_and_busses(); > > /* Third, we run through the table tweaking interrupt sources. */ cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/i386/i386/mptable.c /usr/src/sys/i386/i386/mptable.c: In function `mptable_setup_io': /usr/src/sys/i386/i386/mptable.c:356: warning: implicit declaration of function `ioapic_enable_mixed_mode' /usr/src/sys/i386/i386/mptable.c:356: warning: nested extern declaration of `ioapic_enable_mixed_mode' *** Error code 1 Stop in /usr/obj/usr/src/sys/current. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Looking at the commit logs, this has been removed from a number of files. I am not sure if I imported all the necessary files or not but I pulled in Version 1.19 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/io_apic.c 1.11 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/apicvar.h With those changes, no luck with ATA compiled into the kernel :( BUT! With ata compiled out, I can now boot a current kernel using PIC and APIC! This is with a newer AMR card, but I dont think that is the issue. I will put back the old one once back at the office tomorrow just to be sure as the generic current kernel still hangs on it. OK unload OK load /boot/mix/kernel /boot/mix/kernel text=0x2142d4 data=0x2c550+0x71354 syms=[0x4+0x33050+0x4+0x40317] OK load /boot/mix/acpi.ko /boot/mix/acpi.ko text=0x41e40 data=0x20e0+0x10b0 syms=[0x4+0x7740+0x4+0x9ead] OK boot GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #2: Tue Jul 12 00:20:43 EDT 2005 mdtancsa@freebsd-current.sentex.ca:/usr/src/sys/i386/compile/mike WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2101010432 (2003 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: irq 11 on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: irq 14 on acpi0 pci_link9: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pci0: at device 2.3 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: on acpi0 pci2: on pcib2 pcib3: on acpi0 pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounter "TSC" frequency 500020005 Hz quality 800 Timecounters tick every 1.000 msec amrd0: on amr0 amrd0: 34732MB (71131136 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device Trying to mount root from ufs:/dev/amrd0s1a Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/amrd0s1b as swap device Starting file system checks: /dev/amrd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1a: clean, 218641 free (649 frags, 27249 blocks, 0.3% fragmentation) /dev/amrd0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1e: clean, 506479 free (39 frags, 63305 blocks, 0.0% fragmentation) /dev/amrd0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1f: clean, 11219339 free (36099 frags, 1397905 blocks, 0.3% fragmentation) /dev/amrd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1d: clean, 2528841 free (377 frags, 316058 blocks, 0.0% fragmentation) Setting hostname: hippo.sentex.ca. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 Starting dhclient. em0: link state changed to UP em0: flags=8843 mtu 1500m 0 options=b link state changed to DOWN inet6 fe80::20e:cff:fe5d:f8ca%em0 prefixlen 64 scopeid 0x1 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:0e:0c:5d:f8:ca media: Ethernet autoselect status: no carrier Additional routing options: IP gateway=YES. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Recovering vi editor sessions:. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Tue Jul 12 04:24:50 EDT 2005 FreeBSD/i386 (hippo.sentex.ca) (ttyd0) and without acpi OK unload OK load /boot/mix/kernel /boot/mix/kernel text=0x21c7a4 data=0x2d1f0+0x773f4 syms=[0x4+0x34670+0x4+0x41e84] OK set hint.acpi.0.disabled=1 OK boot GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #3: Tue Jul 12 00:38:37 EDT 2005 mdtancsa@freebsd-current.sentex.ca:/usr/src/sys/i386/compile/mike WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2100973568 (2003 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 4 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard cpu2 on motherboard cpu3 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) piix0: port 0x850-0x85f at device 2.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: pcibus 2 on motherboard pci2: on pcib2 pcib3: pcibus 3 on motherboard pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xccfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) ppc1: parallel port not found. unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 1.000 msec amrd0: on amr0 amrd0: 34732MB (71131136 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/amrd0s1a Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/amrd0s1b as swap device Starting file system checks: /dev/amrd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1a: clean, 218641 free (649 frags, 27249 blocks, 0.3% fragmentation) /dev/amrd0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1e: clean, 506479 free (39 frags, 63305 blocks, 0.0% fragmentation) /dev/amrd0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1f: clean, 11219339 free (36099 frags, 1397905 blocks, 0.3% fragmentation) /dev/amrd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1d: clean, 2528832 free (384 frags, 316056 blocks, 0.0% fragmentation) Setting hostname: hippo.sentex.ca. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 Starting dhclient. em0: link state changed to UP em0: flags=8843 mtu 1500 options=b inet6 fe80::20e:cff:fe5d:f8ca%em0 prefixlen 64 scopeid 0x1 inet 192.168.5.107 netmask 0xffffff00 broadcast 192.168.5.255 ether 00:0e:0c:5d:f8:ca media: Ethernet autoselect status: no carrier Additional routing options: IP gateway=YES. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Recovering vi editor sessions:. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Tue Jul 12 04:47:06 EDT 2005 FreeBSD/i386 (hippo.sentex.ca) (ttyd0) And with ACPI and APIC OK unload OK load /boot/mix/kernel /boot/mix/kernel text=0x21c7a4 data=0x2d1f0+0x773f4 syms=[0x4+0x34670+0x4+0x41e84] OK load /boot/mix/acpi.ko /boot/mix/acpi.ko text=0x41e40 data=0x20e0+0x10b0 syms=[0x4+0x7740+0x4+0x9ead] OK boot GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #3: Tue Jul 12 00:38:37 EDT 2005 mdtancsa@freebsd-current.sentex.ca:/usr/src/sys/i386/compile/mike WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2100957184 (2003 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: irq 11 on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: irq 14 on acpi0 pci_link9: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pci0: at device 2.3 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: on acpi0 pci2: on pcib2 pcib3: on acpi0 pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xccfff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec amrd0: on amr0 amrd0: 34732MB (71131136 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/amrd0s1a Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/amrd0s1b as swap device Starting file system checks: /dev/amrd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1a: clean, 218641 free (649 frags, 27249 blocks, 0.3% fragmentation) /dev/amrd0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1e: clean, 506479 free (39 frags, 63305 blocks, 0.0% fragmentation) /dev/amrd0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1f: clean, 11219339 free (36099 frags, 1397905 blocks, 0.3% fragmentation) /dev/amrd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1d: clean, 2528836 free (388 frags, 316056 blocks, 0.0% fragmentation) Setting hostname: hippo.sentex.ca. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 Starting dhclient. em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP em0: flags=8843 mtu 1500 options=b inet6 fe80::20e:cff:fe5d:f8ca%em0 prefixlen 64 scopeid 0x1 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:0e:0c:5d:f8:ca media: Ethernet autoselect status: no carrier Additional routing options: IP gateway=YES. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Recovering vi editor sessions:. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Tue Jul 12 04:42:09 EDT 2005 FreeBSD/i386 (hippo.sentex.ca) (ttyd0) login: From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 05:06:33 2005 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 CFAEB16A41C; Tue, 12 Jul 2005 05:06:33 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E14C43D48; Tue, 12 Jul 2005 05:06:33 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C56F5e089577; Tue, 12 Jul 2005 01:06:15 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C56WUN033561; Tue, 12 Jul 2005 01:06:32 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6C56Tv7090508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2005 01:06:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050712010048.034acf10@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Jul 2005 01:08:01 -0400 To: John Baldwin From: Mike Tancsa In-Reply-To: <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507081006.43609.jhb@FreeBSD.org> <6.2.1.2.0.20050708110446.07de5768@64.7.153.2> <200507111327.46165.jhb@FreeBSD.org> <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: freebsd-current@freebsd.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 12 Jul 2005 05:06:33 -0000 At 12:51 AM 12/07/2005, Mike Tancsa wrote: >With those changes, no luck with ATA compiled into the kernel :( > >BUT! With ata compiled out, I can now boot a current kernel using PIC and Here is the boot with ata and atadisk compiled in. Notice the em nic is trashed as well OK unload OK load /boot/mix/ata/kernel /boot/mix/ata/kernel text=0x232e34 data=0x2ea50+0x77454 syms=[0x4+0x35af0+0x4+0x43762] OK load /boot/mix/ata/acpi.ko /boot/mix/ata/acpi.ko text=0x41e40 data=0x20e0+0x10b0 syms=[0x4+0x7740+0x4+0x9ead] OK boot GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #4: Tue Jul 12 00:53:26 EDT 2005 mdtancsa@freebsd-current.sentex.ca:/usr/src/sys/i386/compile/mike WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2100953088 (2003 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: irq 11 on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: irq 14 on acpi0 pci_link9: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 2.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 2.2 (no driver attached) pci0: at device 2.3 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: on acpi0 pci2: on pcib2 pcib3: on acpi0 pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Hardware Initialization Failedem0: Unable to initialize the hardware device_attach: em0 attach returned 5 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm: keyboard controller failed. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounters tick every 1.000 msec Memory modified after free 0xc3167000(2044) val=c317c0f0 @ 0xc31671b0 panic: Most recently used by bus-sc cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2c: leave db> trace Tracing pid 0 tid 0 td 0xc0667940 kdb_enter(c061356f,100,c0667940,7fc,c31677fc) at kdb_enter+0x2c panic(c0626098,c0615041,c0626069,c3167000,7fc) at panic+0x17f mtrash_ctor(c3167000,800,0,2) at mtrash_ctor+0x5f uma_zalloc_arg(c0c5adc0,0,2) at uma_zalloc_arg+0x24f malloc(800,c064d9e0,2,c064efe0,c0820d5c) at malloc+0x6b hashinit(200,c064d9e0,c06b9200,c064efe0,c0820d6c) at hashinit+0x2e ip_init(c0655170,c30887bc,c0820d88,c049a063,c064efa0) at ip_init+0x2c net_add_domain(c064efa0,c3088820,81ec00,81e000,828000) at net_add_domain+0x6b mi_startup() at mi_startup+0xb3 begin() at begin+0x2c db> show intrcnt irq1: atkbd0 2 irq0: clk 199 irq6: fdc0 2 lapic3: timer 4687 db> With ACPI not loaded, the box goes into some strange suspend mode. Sending a break from the serial console does not let me enter the debugger and the video is turned off. ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 07:26:20 2005 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 D10ED16A41C for ; Tue, 12 Jul 2005 07:26:20 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: from office.suresupport.com (office.suresupport.com [213.145.98.15]) by mx1.FreeBSD.org (Postfix) with SMTP id E3B1343D4C for ; Tue, 12 Jul 2005 07:26:19 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 96954 invoked by uid 1026); 12 Jul 2005 07:27:41 -0000 Received: from 213.145.98.14 by office.suresupport.com (envelope-from , uid 1004) with qmail-scanner-1.23 (f-prot: 4.4.2/3.14.11. Clear:RC:1(213.145.98.14):. Processed in 0.096107 secs); 12 Jul 2005 07:27:41 -0000 Received: from unknown (HELO 14.98.145.213.in-addr.arpa) (213.145.98.14) by office.suresupport.com with SMTP; 12 Jul 2005 07:27:40 -0000 From: Niki Denev To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 10:26:16 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121026.16664.nike_d@cytexbg.com> Subject: add a few informative printfs to if_bridge.c? 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, 12 Jul 2005 07:26:20 -0000 Hello all, I've had some problems adding one if_ral interface to if_bridge device. I've tracked down the problem to the MTU on my PCI if_ral interface which is set to 2290 ( i think that hostapd did this ). So, i have a proposition to add some informative printfs to if_bridge code, because returning "Invalid argument" is not so self explanatory, especially in the wrong MTU case. I think that most of the returns in bridge_ioctl_add(), could benefit from additional printf with more information. What do you think? --niki From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 08:20:44 2005 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 E33B016A41C; Tue, 12 Jul 2005 08:20:44 +0000 (GMT) (envelope-from marks@ripe.net) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D15743D45; Tue, 12 Jul 2005 08:20:44 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 4008) id 58B5B24996; Tue, 12 Jul 2005 10:20:43 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 765DE23F12; Tue, 12 Jul 2005 10:20:42 +0200 (CEST) Received: from laptop.santcroos.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j6C8Kgmq007937; Tue, 12 Jul 2005 10:20:42 +0200 Received: (nullmailer pid 21606 invoked by uid 1001); Tue, 12 Jul 2005 08:20:42 -0000 Date: Tue, 12 Jul 2005 10:20:42 +0200 From: Mark Santcroos To: John Baldwin Message-ID: <20050712082042.GA21580@laptop.santcroos.net> References: <42C92DC5.3060101@gddsn.org.cn> <200507091517.57736.jhb@FreeBSD.org> <1120939825.937.11.camel@taxman.pepperland> <200507111101.29623.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507111101.29623.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.001576 / -5.9 X-RIPE-Signature: 37dfc4e0d9ed17d5dfd28d4af64a3cb3 Cc: current@FreeBSD.org Subject: Re: Suspend 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: Tue, 12 Jul 2005 08:20:45 -0000 Hi John, On Mon, Jul 11, 2005 at 11:01:28AM -0400, John Baldwin wrote: > I had never set timer0_real_max_count. :( One more time: This fixes it for me. Thanks! Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:32:05 2005 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 9517516A41C for ; Mon, 11 Jul 2005 19:32:05 +0000 (GMT) (envelope-from admin@sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id E06A143D46 for ; Mon, 11 Jul 2005 19:32:04 +0000 (GMT) (envelope-from admin@sbb.co.yu) Received: from zexi.sbb.co.yu ([192.168.1.115]) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j6BJW1BK053298; Mon, 11 Jul 2005 21:32:01 +0200 (CEST) From: admin@sbb.co.yu To: freebsd-current@freebsd.org Date: Mon, 11 Jul 2005 21:35:10 +0200 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507112135.10703.admin@sbb.co.yu> X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: admin@sbb.co.yu X-Mailman-Approved-At: Tue, 12 Jul 2005 12:06:32 +0000 Cc: admin@sbb.co.yu Subject: panic in freebsd 6.0 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: Mon, 11 Jul 2005 19:32:05 -0000 db> trace Tracing pid 409 tid 100102 td 0xc5c8aa80 m_tag_delete(c8a5d900,33203037) at m_tag_delete+0x40 m_tag_delete_chain(c8a5d900,0) at m_tag_delete_chain+0x3b mb_dtor_mbuf(c8a5d900,100,0) at mb_dtor_mbuf+0x15 uma_zfree_arg(c104a9a0,c8a5d900,0) at uma_zfree_arg+0x24 m_freem(c8a5d900) at m_freem+0x36 arpresolve(c5912000,c5e3fce4,c9839100,c5e529b0,ec072aa4) at arpresolve+0x1f4 ether_output(c5912000,c9839100,c5e529b0,c5e3fce4,c5c55900) at ether_output+0x66 ip_output(c9839100,0,ec072afc,0,0) at ip_output+0x6fc udp_output(c5d9c7bc,c9839100,c741d620,0,c5c8aa80) at udp_output+0x4a7 udp_send(c5eff2c8,0,c9839100,c741d620,0) at udp_send+0x1a sosend(c5eff2c8,c741d620,ec072c38,c9839100,0) at sosend+0x5e3 kern_sendit(c5c8aa80,1c,ec072cb4,0,0) at kern_sendit+0x104 sendit(c5c8aa80,1c,ec072cb4,0,c5c1e590) at sendit+0x163 sendmsg(c5c8aa80,ec072d04,3,4628,286) at sendmsg+0x5a syscall(bfbf003b,bfbf003b,bfbf003b,1,8a40a2c) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x882f949b, esp = 0xbfbfe41c, ebp = 0xbfbfe598 --- db> From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 19:50:29 2005 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 AB4D716A41C for ; Mon, 11 Jul 2005 19:50:29 +0000 (GMT) (envelope-from zexi@sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1248E43D45 for ; Mon, 11 Jul 2005 19:50:28 +0000 (GMT) (envelope-from zexi@sbb.co.yu) Received: from zexi.sbb.co.yu ([192.168.1.115]) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j6BJoQpo061326 for ; Mon, 11 Jul 2005 21:50:26 +0200 (CEST) From: Zvezdan Babic To: freebsd-current@freebsd.org Date: Mon, 11 Jul 2005 21:53:35 +0200 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507112153.35585.zexi@sbb.co.yu> X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: zexi@sbb.co.yu X-Mailman-Approved-At: Tue, 12 Jul 2005 12:06:32 +0000 Subject: panic in freebsd 6.0 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: Mon, 11 Jul 2005 19:50:29 -0000 one more time db> Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual address = 0x33203037 fault code = supervisor read, page not present instruction pointer = 0x20:0xc068103c stack pointer = 0x28:0xec0729f4 frame pointer = 0x28:0xec0729f4 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 = 409 (named) [thread pid 409 tid 100102 ] Stopped at m_tag_delete+0x40: movl 0(%eax),%eax db> db> trace Tracing pid 409 tid 100102 td 0xc5c8aa80 m_tag_delete(c8a5d900,33203037) at m_tag_delete+0x40 m_tag_delete_chain(c8a5d900,0) at m_tag_delete_chain+0x3b mb_dtor_mbuf(c8a5d900,100,0) at mb_dtor_mbuf+0x15 uma_zfree_arg(c104a9a0,c8a5d900,0) at uma_zfree_arg+0x24 m_freem(c8a5d900) at m_freem+0x36 arpresolve(c5912000,c5e3fce4,c9839100,c5e529b0,ec072aa4) at arpresolve+0x1f4 ether_output(c5912000,c9839100,c5e529b0,c5e3fce4,c5c55900) at ether_output+0x66 ip_output(c9839100,0,ec072afc,0,0) at ip_output+0x6fc udp_output(c5d9c7bc,c9839100,c741d620,0,c5c8aa80) at udp_output+0x4a7 udp_send(c5eff2c8,0,c9839100,c741d620,0) at udp_send+0x1a sosend(c5eff2c8,c741d620,ec072c38,c9839100,0) at sosend+0x5e3 kern_sendit(c5c8aa80,1c,ec072cb4,0,0) at kern_sendit+0x104 sendit(c5c8aa80,1c,ec072cb4,0,c5c1e590) at sendit+0x163 sendmsg(c5c8aa80,ec072d04,3,4628,286) at sendmsg+0x5a syscall(bfbf003b,bfbf003b,bfbf003b,1,8a40a2c) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x882f949b, esp = 0xbfbfe41c, ebp = 0xbfbfe598 --- db> Sorry for inconvinience best regards Zvezdan Babic From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:54:07 2005 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 1EB6D16A41C for ; Mon, 11 Jul 2005 21:54:07 +0000 (GMT) (envelope-from ggajic@sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72B6A43D4C for ; Mon, 11 Jul 2005 21:54:05 +0000 (GMT) (envelope-from ggajic@sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j6BLs3Vw010010 for ; Mon, 11 Jul 2005 23:54:03 +0200 (CEST) Date: Mon, 11 Jul 2005 23:54:03 +0200 (CEST) From: Goran Gajic To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@sbb.co.yu X-Mailman-Approved-At: Tue, 12 Jul 2005 12:06:32 +0000 Subject: panic with 7.0-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: Mon, 11 Jul 2005 21:54:07 -0000 I've just cvsup-ed my system this evening. First network cards stoped responding. After that I did ifconfig em0 down and ifconfig em0 up and also ifconfig fxp0 down and ifconfig fxp0 up and when I have rebooted system this is what I got: Yanic: duentmaocuhn tw iotfh /adcetvi vfea irleeqdu e(sBtUsS p)c uid = 3 KDB: enter: panic [thread pid 2 tid 100055 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 2 tid 100055 td 0xc5809d80 kdb_enter(c087179e) at kdb_enter+0x2b panic(c086cd9b,c5b8bc40,e9af1cec,c061b30e,c5b8bc40) at panic+0x127 g_detach(c5b8bc40) at g_detach+0x82 g_wither_washer(e9af1d0c,c0619d21,258,190,c0619cb4) at g_wither_washer+0xde g_run_events(258,190,c0619cb4,c5808c48,e9af1d24) at g_run_events+0x49 g_event_procbody(0,e9af1d38,0,c0619cb4,0) at g_event_procbody+0x6d fork_exit(c0619cb4,0,e9af1d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe9af1d6c, ebp = 0 --- db> re cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 3 This SMP machine.. with HTT enabled.. Regards, gg. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:58:30 2005 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 15E4116A41C for ; Mon, 11 Jul 2005 21:58:30 +0000 (GMT) (envelope-from vangyzen@isds.duke.edu) Received: from when.isds.duke.edu (when.isds.duke.edu [152.3.22.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95DC43D46 for ; Mon, 11 Jul 2005 21:58:29 +0000 (GMT) (envelope-from vangyzen@isds.duke.edu) Received: from xavier.isds.duke.edu (xavier.isds.duke.edu [152.3.22.33]) by when.isds.duke.edu (Postfix) with ESMTP id 130B41EB127 for ; Mon, 11 Jul 2005 17:58:29 -0400 (EDT) Received: by xavier.isds.duke.edu (Postfix, from userid 3604) id E0D1C3E0211; Mon, 11 Jul 2005 17:58:28 -0400 (EDT) Date: Mon, 11 Jul 2005 17:58:28 -0400 From: Eric van Gyzen To: freebsd-current@freebsd.org Message-ID: <20050711215828.GA6481@xavier.isds.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Tue, 12 Jul 2005 12:06:32 +0000 Subject: SNAP005 as a VMware 5 guest 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, 11 Jul 2005 21:58:30 -0000 I tried to install FreeBSD 6-CURRENT i386 from the SNAP005 ISO image as a guest under VMware Workstation 5 and got the following panic: panic: Duplicate free of item 0xc1d9e000 from zone 0xc144adc0(g_bio) cpuid = 0 KDB: enter: panic [thread pid 3 tid 100034 ] Stopped at kdb_enter+0x2b: nop db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd ..... 3 c1985c48 0 0 0 0000204 [CPU 0] g_up It has happened several times while extracting the base distribution set. I verified the MD5 sum of the ISO image. VMware is running on a Windows XP host. SoftUpdates was enabled. Today is Monday. ;) I don't have much experience debugging the kernel, but I'm willing to help if you're interested. Cheers, Eric From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:50:19 2005 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 E396016A421 for ; Mon, 11 Jul 2005 22:50:19 +0000 (GMT) (envelope-from bryanv@daemoninthecloset.org) Received: from ms-smtp-03.rdc-kc.rr.com (ms-smtp-03.rdc-kc.rr.com [24.94.166.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A4543D60 for ; Mon, 11 Jul 2005 22:50:11 +0000 (GMT) (envelope-from bryanv@daemoninthecloset.org) Received: from misery.daemoninthecloset.org (rrcs-67-52-233-243.west.biz.rr.com [67.52.233.243]) by ms-smtp-03.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id j6BMo7gu015350 for ; Mon, 11 Jul 2005 17:50:08 -0500 (CDT) Received: from localhost (misery.daemoninthecloset.org [192.168.1.25]) by misery.daemoninthecloset.org (Postfix) with ESMTP id 54E6784504 for ; Mon, 11 Jul 2005 17:50:07 -0500 (CDT) Received: from misery.daemoninthecloset.org ([192.168.1.25]) by localhost (misery.daemoninthecloset.org [192.168.1.25]) (amavisd-new, port 10024) with ESMTP id 44012-03 for ; Mon, 11 Jul 2005 17:50:05 -0500 (CDT) Received: from agonize.daemoninthecloset.org (agonize.daemoninthecloset.org [192.168.1.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by misery.daemoninthecloset.org (Postfix) with ESMTP id 0703E8440B for ; Mon, 11 Jul 2005 17:50:04 -0500 (CDT) Date: Mon, 11 Jul 2005 17:50:04 -0500 From: Bryan V To: freebsd-current@freebsd.org Message-Id: <20050711175004.63f787dc.bryanv@daemoninthecloset.org> In-Reply-To: <42D26463.507@deadcafe.de> References: <42D26463.507@deadcafe.de> X-Mailer: Sylpheed version 2.0.0beta5 (GTK+ 2.7.2; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Mailman-Approved-At: Tue, 12 Jul 2005 12:06:32 +0000 Subject: Re: Current amd64, "nve0: device timeout" with nForce4 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, 11 Jul 2005 22:50:22 -0000 On Mon, 11 Jul 2005 14:21:55 +0200 Daniel Rock wrote: > Paul Richards schrieb: > > Hi, > > With CURRENT (checked out earlier this evening) on amd64 I cannot get > > my nForce4 ethernet adaptor to work. The module automatically loads > > but I get messages of the form "nve0: device timeout(..)" when I > > attempt to use the interface. > > > > This is exactly the same problem that RELEASE 5.4 had using the nvlan > > port on my system. I upgraded to current as I was told that the > > integrated nve driver in 6.0 was more up to date than the nvlan port. > > > > Does anyone have nForce4 ethernet working with any version of FreeBSD > > on amd64? Is this something to do with my particular nForce4 chipset > > or is the nForce4 ethernet generally unsupported at this time? > > How much memory do you have? > > I'm too having trouble with the nve driver under FreeBSD, but only if memory > is mapped beyond the 4 GB mark. > > I have a Tyan S2895 mobo with a memory hole at 2.75 GB for PCI cards. In the > BIOS I can decide how to remap this memory: Disabled/Hardware/Software > > If I choose to set this setting to "Disabled" my nve driver works fine, with > any other setting I too get "device timeout"'s. > I have a similar timeouts under current with an NForce2 (Abit NF7) with 1GB of memory. My timeouts usually happen under heavy usage however. nve0: port 0xc000-0xc007 mem 0xe1004000-0xe1004fff irq 10 at device 4.0 on pci0 nve0: Ethernet address 00:50:8d:fb:18:a2 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:50:8d:fb:18:a2 nve0: [GIANT-LOCKED] Bryan From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 12:10:40 2005 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 6CD1516A41C; Tue, 12 Jul 2005 12:10:40 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147EC43D48; Tue, 12 Jul 2005 12:10:40 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id A4FF5C12A; Tue, 12 Jul 2005 14:10:36 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id BADB5405B; Tue, 12 Jul 2005 14:10:36 +0200 (CEST) Date: Tue, 12 Jul 2005 14:10:36 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20050712121036.GM39292@obiwan.tataz.chchile.org> References: <200507090932.12973.jhb@FreeBSD.org> <20514.1120916772@phk.freebsd.dk> <20050710072752.GA39156@squash.dsto.defence.gov.au> <200507111044.52693.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507111044.52693.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 12 Jul 2005 12:10:40 -0000 Hi John, > > what is boot0ext ? > > It's a 2-sector variant of boot0 that includes extra logic to choose between > CHS and LBA BIOS calls and a longer table of filesystem/OS names. Are there some drawbacks that would prevent an i386 user from using it ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 13:00:11 2005 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 7B07516A41C for ; Tue, 12 Jul 2005 13:00:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A12543D5C for ; Tue, 12 Jul 2005 13:00:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 1D65F1FFDD8; Tue, 12 Jul 2005 15:00:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id B414D1FF90C; Tue, 12 Jul 2005 15:00:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id B332E157B9; Tue, 12 Jul 2005 12:58:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id A529415583; Tue, 12 Jul 2005 12:58:37 +0000 (UTC) Date: Tue, 12 Jul 2005 12:58:37 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Bryan V In-Reply-To: <20050711175004.63f787dc.bryanv@daemoninthecloset.org> Message-ID: References: <42D26463.507@deadcafe.de> <20050711175004.63f787dc.bryanv@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: Current amd64, "nve0: device timeout" with nForce4 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, 12 Jul 2005 13:00:11 -0000 On Mon, 11 Jul 2005, Bryan V wrote: > On Mon, 11 Jul 2005 14:21:55 +0200 > Daniel Rock wrote: > > > Paul Richards schrieb: > > > Hi, > > > With CURRENT (checked out earlier this evening) on amd64 I cannot get > > > my nForce4 ethernet adaptor to work. The module automatically loads > > > but I get messages of the form "nve0: device timeout(..)" when I > > > attempt to use the interface. > > > > > > This is exactly the same problem that RELEASE 5.4 had using the nvlan > > > port on my system. I upgraded to current as I was told that the > > > integrated nve driver in 6.0 was more up to date than the nvlan port. > > > > > > Does anyone have nForce4 ethernet working with any version of FreeBSD > > > on amd64? Is this something to do with my particular nForce4 chipset > > > or is the nForce4 ethernet generally unsupported at this time? > > > > How much memory do you have? > > > > I'm too having trouble with the nve driver under FreeBSD, but only if memory > > is mapped beyond the 4 GB mark. > > > > I have a Tyan S2895 mobo with a memory hole at 2.75 GB for PCI cards. In the > > BIOS I can decide how to remap this memory: Disabled/Hardware/Software > > > > If I choose to set this setting to "Disabled" my nve driver works fine, with > > any other setting I too get "device timeout"'s. I tried that with my 4GB amd64 machine but it hadn't helped. > I have a similar timeouts under current with an NForce2 (Abit NF7) with 1GB of memory. My timeouts usually happen under heavy usage however. it's an nf4 MCP8 here and I cannot even get it up and working. tx ring fills but packet don't get send. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 13:12:29 2005 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 C31BA16A41C for ; Tue, 12 Jul 2005 13:12:29 +0000 (GMT) (envelope-from current@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id E04F243D4C for ; Tue, 12 Jul 2005 13:12:28 +0000 (GMT) (envelope-from current@deadcafe.de) Received: from dialin.t-online.de (p54A5CA1E.dip.t-dialin.net [84.165.202.30]) by deadcafe.de (8.13.4/8.13.4/Rock) with ESMTP id j6CDCOZr077319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jul 2005 15:12:26 +0200 (CEST) X-Envelope-To: Received: from [172.23.7.123] (nx7000-wlan.rock.net [172.23.7.123]) by dialin.t-online.de (8.13.4/8.13.4/Rock) with ESMTP id j6CDCIBr048957 for ; Tue, 12 Jul 2005 15:12:18 +0200 (CEST) Message-ID: <42D3C1B4.8060709@deadcafe.de> Date: Tue, 12 Jul 2005 15:12:20 +0200 From: Daniel Rock User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <42D26463.507@deadcafe.de> <20050711175004.63f787dc.bryanv@daemoninthecloset.org> In-Reply-To: <20050711175004.63f787dc.bryanv@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Subject: Re: Current amd64, "nve0: device timeout" with nForce4 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, 12 Jul 2005 13:12:29 -0000 >>How much memory do you have? >> >>I'm too having trouble with the nve driver under FreeBSD, but only if memory >>is mapped beyond the 4 GB mark. >> >>I have a Tyan S2895 mobo with a memory hole at 2.75 GB for PCI cards. In the >>BIOS I can decide how to remap this memory: Disabled/Hardware/Software >> >>If I choose to set this setting to "Disabled" my nve driver works fine, with >>any other setting I too get "device timeout"'s. >> > > > I have a similar timeouts under current with an NForce2 (Abit NF7) with 1GB of memory. My timeouts usually happen under heavy usage however. > > nve0: port 0xc000-0xc007 mem 0xe1004000-0xe1004fff irq 10 at device 4.0 on pci0 > nve0: Ethernet address 00:50:8d:fb:18:a2 > miibus0: on nve0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > nve0: Ethernet address: 00:50:8d:fb:18:a2 > nve0: [GIANT-LOCKED] To clarify myself (after longer testing): Without the memory clipping at 4 GB the nve driver doesn't work at all. I just receive a message nve0: device timeout(n) with n any positive number (5..11 so far). With options MAXMEM=4194303 in my kernel config file the nve driver works mostly. Yesterday I was able to transfer ~500MB without any error. Then suddenly network traffic stops after nve0: device timeout(-1) Only solution was a reboot (I may try compiling the nve driver as a module and see if unloading/reloading of the module also helps). Today I'm getting tons of messages nve0: device timeout(4) (68 of these messages for ~260MB traffic) but after 2 seconds the link works again. Daniel From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 13:19:18 2005 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 CB24016A41F for ; Tue, 12 Jul 2005 13:19:18 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D130743D53 for ; Tue, 12 Jul 2005 13:19:17 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 81693 invoked by uid 1005); 12 Jul 2005 13:19:17 -0000 Received: from rainer@ultra-secure.de by bsd.ultra-secure.de by uid 89 with qmail-scanner-1.22 (clamdscan: 0.85. spamassassin: 2.64. Clear:RC:1(213.196.191.65):. Processed in 0.028301 secs); 12 Jul 2005 13:19:17 -0000 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2005 13:19:16 -0000 Message-ID: <42D3C350.4060308@ultra-secure.de> Date: Tue, 12 Jul 2005 15:19:12 +0200 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric van Gyzen References: <20050711215828.GA6481@xavier.isds.duke.edu> In-Reply-To: <20050711215828.GA6481@xavier.isds.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: SNAP005 as a VMware 5 guest 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, 12 Jul 2005 13:19:18 -0000 Eric van Gyzen wrote: >I tried to install FreeBSD 6-CURRENT i386 from the SNAP005 ISO image >as a guest under VMware Workstation 5 and got the following panic: > > panic: Duplicate free of item 0xc1d9e000 from zone 0xc144adc0(g_bio) > > cpuid = 0 > KDB: enter: panic > [thread pid 3 tid 100034 ] > Stopped at kdb_enter+0x2b: nop > db> ps > pid proc uid ppid pgrp flag stat wmesg wchan cmd > ..... > 3 c1985c48 0 0 0 0000204 [CPU 0] g_up > >It has happened several times while extracting the base distribution set. >I verified the MD5 sum of the ISO image. VMware is running on a Windows XP >host. SoftUpdates was enabled. Today is Monday. ;) > > > It also happens on my SuSE9.2-host. I got a "Bio already on queue bp=0xc23054a4 cpuid = 0 KDB: enter: panic [thread pid 40 tid 100029 ] Stopped at kdb_enter+0x2b: nop" -error, at about 16% into the base-set. I could give a screenshot ;-) Rainer From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 16:57:07 2005 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 516F616A41C for ; Tue, 12 Jul 2005 16:57:07 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE18A43D46 for ; Tue, 12 Jul 2005 16:57:06 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6CGv2ul045512; Tue, 12 Jul 2005 18:57:02 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6CGux9i045511; Tue, 12 Jul 2005 12:56:59 -0400 (EDT) (envelope-from cracauer) Date: Tue, 12 Jul 2005 12:56:59 -0400 From: Martin Cracauer To: Scott Long Message-ID: <20050712125659.A45450@cons.org> References: <20050711180311.A23623@cons.org> <42D33043.4030700@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <42D33043.4030700@samsco.org>; from scottl@samsco.org on Mon, Jul 11, 2005 at 08:51:47PM -0600 Cc: Martin Cracauer , freebsd-current@freebsd.org Subject: Re: 6-current: udf broken, "locking against myself" (not anymore) 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, 12 Jul 2005 16:57:07 -0000 Scott Long wrote on Mon, Jul 11, 2005 at 08:51:47PM -0600: > This should have been fixed by a commit a couple of days ago. How old > are your sources? My sources were end of last week's and yes it is fixed to today's. You guys are quick. Sorry for the noise, but I suppose better this way round that the other :-) Thanks Martin > Scott > > Martin Cracauer wrote: > > Further testing 6-current. Seems like the udf filesystem is hosed, I > > cannot even use a minimal one. [...] -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 17:01:24 2005 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 8A92E16A41C for ; Tue, 12 Jul 2005 17:01:24 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24D4E43D45 for ; Tue, 12 Jul 2005 17:01:19 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6CH6in1064849; Tue, 12 Jul 2005 11:06:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D3F75B.8090302@samsco.org> Date: Tue, 12 Jul 2005 11:01:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Cracauer References: <20050711180311.A23623@cons.org> <42D33043.4030700@samsco.org> <20050712125659.A45450@cons.org> In-Reply-To: <20050712125659.A45450@cons.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: 6-current: udf broken, "locking against myself" (not anymore) 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, 12 Jul 2005 17:01:24 -0000 Martin Cracauer wrote: > Scott Long wrote on Mon, Jul 11, 2005 at 08:51:47PM -0600: > >>This should have been fixed by a commit a couple of days ago. How old >>are your sources? > > > My sources were end of last week's and yes it is fixed to today's. > You guys are quick. > > Sorry for the noise, but I suppose better this way round that the > other :-) > > Thanks > Martin > Bug reports are always welcomed. It was actually broken a month or two ago, but many thanks to Seigo Tanimura for tracking it down and fixing it. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 17:29:45 2005 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 70A8C16A41C for ; Tue, 12 Jul 2005 17:29:45 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1801143D45 for ; Tue, 12 Jul 2005 17:29:45 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 38847BA22; Tue, 12 Jul 2005 21:29:43 +0400 (MSD) Date: Tue, 12 Jul 2005 21:29:43 +0400 From: "Eygene A. Ryabinkin" To: current@freebsd.org Message-ID: <20050712172943.GA744@rea.mbslab.kiae.ru> References: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050709102616.5b601c14.sebastian.ssmoller@gmx.net> User-Agent: Mutt/1.5.9i Cc: Subject: Re: Fw: Re: Massive sound changes / fix (24/32bit pcm support, new sampling rate converter, various fixes) 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, 12 Jul 2005 17:29:45 -0000 > > After sometimes, I've decided to release this (massive 4k lines) diff > > to our sound driver. This need proper review and confirmation, before > > it can be committed. Great job! Works fine for me at 5.4-STABLE, improves sound quality well. I am using emu10kx driver on Audigy2 ZX [SB0350]. -- rea From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 17:36:34 2005 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 F287C16A41C; Tue, 12 Jul 2005 17:36:33 +0000 (GMT) (envelope-from tim-lists@bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [84.234.16.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 987AD43D46; Tue, 12 Jul 2005 17:36:33 +0000 (GMT) (envelope-from tim-lists@bishnet.net) Received: from inferno.sixth.bishnet.net ([82.68.45.195] helo=localhost.localdomain) by carrick.bishnet.net with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.51 (FreeBSD)) id 1DsOgB-000Ge8-BF; Tue, 12 Jul 2005 18:36:23 +0100 From: Tim Bishop To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 12 Jul 2005 18:36:21 +0100 Message-Id: <1121189781.65846.3.camel@inferno.sixth.bishnet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.3, required 5, autolearn=not spam, AWL 1.30, BAYES_00 -2.60, SPF_PASS -0.00) X-Bishnet-MailScanner-From: tim-lists@bishnet.net Cc: Subject: ataraid - RAID5 in RELENG_6? 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, 12 Jul 2005 17:36:34 -0000 I'm having a fiddle with RELENG_6 and while setting up a RAID1 system disk I noticed that atacontrol now lets you create a RAID5 device. I gave it a whirl and it seemed to work - I have a device I can "use". But is this working properly? I don't have a hardware raid card, just a plain old SATA card. Having searched the archives I noticed that S=F8ren said it wasn't handling parity. Maybe this was fixed? Anyway - the bottom line is this. Can I create an entirely software RAID5 setup using ataraid? I'm personally not finding gvinum to be that polished... Cheers, Tim. --=20 Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:31:12 2005 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 4EC3016A41C for ; Tue, 12 Jul 2005 18:31:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3CCF43D49 for ; Tue, 12 Jul 2005 18:31:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 14:45:16 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 10:24:49 -0400 User-Agent: KMail/1.8 References: <70e8236f05070208212e36c375@mail.gmail.com> <200507111327.46165.jhb@FreeBSD.org> <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121024.50273.jhb@FreeBSD.org> Cc: Mike Tancsa Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 12 Jul 2005 18:31:12 -0000 On Tuesday 12 July 2005 12:51 am, Mike Tancsa wrote: > At 01:27 PM 11/07/2005, John Baldwin wrote: > >Ok. Very odd in that the code there is almost identical. There is one > > diff you can try reverting (use patch -R) and see if it changes anything: > > > >Index: mptable.c > >=================================================================== > >RCS file: /usr/cvs/src/sys/i386/i386/mptable.c,v > >retrieving revision 1.235.2.4 > >retrieving revision 1.241 > >diff -u -r1.235.2.4 -r1.241 > >--- mptable.c 25 Mar 2005 21:10:07 -0000 1.235.2.4 > >+++ mptable.c 14 Apr 2005 17:59:58 -0000 1.241 > >@@ -353,7 +353,6 @@ > > busses[i].bus_type = NOBUS; > > > > /* Second, we run through adding I/O APIC's and busses. */ > >- ioapic_enable_mixed_mode(); > > mptable_parse_apics_and_busses(); > > > > /* Third, we run through the table tweaking interrupt sources. */ > > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath > -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -ffreestanding -Werror /usr/src/sys/i386/i386/mptable.c > /usr/src/sys/i386/i386/mptable.c: In function `mptable_setup_io': > /usr/src/sys/i386/i386/mptable.c:356: warning: implicit declaration of > function `ioapic_enable_mixed_mode' > /usr/src/sys/i386/i386/mptable.c:356: warning: nested extern declaration of > `ioapic_enable_mixed_mode' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/current. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Looking at the commit logs, this has been removed from a number of > files. I am not sure if I imported all the necessary files or not but I > pulled in > > Version 1.19 of > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/io_apic.c > > 1.11 of > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/apicvar.h > > With those changes, no luck with ATA compiled into the kernel :( > > BUT! With ata compiled out, I can now boot a current kernel using PIC and > APIC! This is with a newer AMR card, but I dont think that is the issue. I > will put back the old one once back at the office tomorrow just to be sure > as the generic current kernel still hangs on it. Argh ok. Can you try compiling a 5.x kernel with 'options NO_MIXED_MODE' and see if it hangs as well? ACPI specifically forbids using mixed mode. :( -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:31:12 2005 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 C0C6B16A41C for ; Tue, 12 Jul 2005 18:31:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E79C43D4C for ; Tue, 12 Jul 2005 18:31:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 14:45:16 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 10:19:55 -0400 User-Agent: KMail/1.8 References: <200507090932.12973.jhb@FreeBSD.org> <200507111044.52693.jhb@FreeBSD.org> <20050712121036.GM39292@obiwan.tataz.chchile.org> In-Reply-To: <20050712121036.GM39292@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121019.56737.jhb@FreeBSD.org> Cc: Jeremie Le Hen , "Wilkinson, Alex" Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix 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, 12 Jul 2005 18:31:12 -0000 On Tuesday 12 July 2005 08:10 am, Jeremie Le Hen wrote: > Hi John, > > > > what is boot0ext ? > > > > It's a 2-sector variant of boot0 that includes extra logic to choose > > between CHS and LBA BIOS calls and a longer table of filesystem/OS names. > > Are there some drawbacks that would prevent an i386 user from using it ? It used to be the default boot0 a few years ago, but there were a few machines that it would hang on that I don't think were ever worked around/fixed, so it was reverted. It should work on most x86 machines just fine however. You should be able to use boot0cfg to install it still. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:31:13 2005 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 E18F816A41F for ; Tue, 12 Jul 2005 18:31:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302F443D53 for ; Tue, 12 Jul 2005 18:31:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 14:45:17 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 10:27:12 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> <42D2F177.3070101@root.org> In-Reply-To: <42D2F177.3070101@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121027.14113.jhb@FreeBSD.org> Cc: Harry Coin , Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 18:31:13 -0000 On Monday 11 July 2005 06:23 pm, Nate Lawson wrote: > John Baldwin wrote: > > Also, can you upload your acpidump somewhere and provide a URL? I'm > > curious if you have ACPI devices like thermal zones that don't have > > _HID's and only have _CIDs. In fact, here's a patch to fix > > acpi_get_logicalid() in that case. Give this a try first and let me know > > if it fixes it. > > I would rather you directly call acpi_isa_get_compatid() rather than > duplicating its logic here. There's no guarantee that the first CID > will match the single ID passed in. There is no passed in ID. For the common use of this function in almost all ISA drivers, it just needs to return != 0 for PNP devices. > -Nate > > > Index: acpi.c > > =================================================================== > > RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v > > retrieving revision 1.214 > > diff -u -r1.214 acpi.c > > --- acpi.c 3 Jun 2005 20:12:12 -0000 1.214 > > +++ acpi.c 11 Jul 2005 20:23:14 -0000 > > @@ -1138,6 +1138,7 @@ > > ACPI_HANDLE h; > > ACPI_STATUS error; > > u_int32_t pnpid; > > + int i; > > > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > > > > @@ -1153,8 +1154,24 @@ > > goto out; > > devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; > > > > - if ((devinfo->Valid & ACPI_VALID_HID) != 0) > > + if ((devinfo->Valid & ACPI_VALID_HID) != 0) { > > pnpid = PNP_EISAID(devinfo->HardwareId.Value); > > + goto out; > > + } > > + > > + /* > > + * If we don't have a HID but do have at least one CID, return the > > first + * CID. This is so that ISA drivers that use > > isa_get_logicalid() to + * determine if a device is a PnP device or > > not will work correctly. + */ > > + if ((devinfo->Valid & ACPI_VALID_CID) != 0) { > > + for (i = 0; i < devinfo->CompatibilityId.Count; i++) { > > + if (strncmp(devinfo->CompatibilityId.Id[i].Value, "PNP", 3) != 0) > > + continue; > > + pnpid = PNP_EISAID(devinfo->CompatibilityId.Id[i].Value); > > + goto out; > > + } > > + } > > > > out: > > if (buf.Pointer != NULL) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:31:44 2005 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 9A79916A4C6 for ; Tue, 12 Jul 2005 18:31:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2476E43D45 for ; Tue, 12 Jul 2005 18:31:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 14:45:17 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 10:44:00 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121044.01574.jhb@FreeBSD.org> Cc: Harry Coin , Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 18:31:44 -0000 On Monday 11 July 2005 05:20 pm, Harry Coin wrote: > John, > > 1) Indeed the mss driver just ignores the further logical devices the chip > offers -- which is most likely the right thing to do. > Logical device 0 is the WSS codec, Synthesizer, and alternate Sound Blaster > pro interface. Handled by MSS.c > Logical device 1 is a game port. 2 is a 'master chip control' device > (defaults all are ok I think). 3 is an MPU-401 midi, 4 (not enabled) is a > CD Rom controller, 5 (not enabled) is a modem. The data sheet for the > CS4236B is available online. I'll send it as a private attachment in an > email. > > 3) Give me a clue or a doc ref about how to apply the RCS / diff patch you > sent me. There's a 'patch' command to apply patches, but after looking at your acpidump, it wouldn't fix the problem anyway. Now, when ACPI is enabled, the pnpmss driver doesn't probe the device IIRC? It may be that when ACPI is being used, support for ISA PnP cards is just completely broken and mss(4)'s hacks in its non-PnP attachment happent to sort of work by accident. In fact, this device really shouldn't be attaching to ACPI at all. All ACPI devices have PNP IDs. Can you try this patch instad of the earlier one? Index: mss.c =================================================================== RCS file: /usr/cvs/src/sys/dev/sound/isa/mss.c,v retrieving revision 1.95 diff -u -r1.95 mss.c --- mss.c 27 Feb 2005 23:32:21 -0000 1.95 +++ mss.c 12 Jul 2005 14:34:55 -0000 @@ -1883,7 +1883,6 @@ }; DRIVER_MODULE(snd_mss, isa, mss_driver, pcm_devclass, 0, 0); -DRIVER_MODULE(snd_mss, acpi, mss_driver, pcm_devclass, 0, 0); MODULE_DEPEND(snd_mss, sound, SOUND_MINVER, SOUND_PREFVER, SOUND_MAXVER); MODULE_VERSION(snd_mss, 1); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 19:19:14 2005 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 8B81016A41C; Tue, 12 Jul 2005 19:19:14 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BEFC43D46; Tue, 12 Jul 2005 19:19:13 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Tue, 12 Jul 2005 14:19:57 -0500 Message-Id: <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jul 2005 14:19:06 -0500 To: John Baldwin ,freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <200507121044.01574.jhb@FreeBSD.org> References: <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> <4.3.2.7.2.20050711135352.01edd3f0@mail.qconline.com> <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 19:19:14 -0000 At 10:44 AM 7/12/2005 -0400, John Baldwin wrote: >Now, when ACPI is enabled, the >pnpmss driver doesn't probe the device IIRC? Both the mss_probe and pnpmss_probe routine are called in the ACPI case and in the ACPI disabled case. Let me help by providing proof from some edited short form commented dmesg excerpts from upstream postings using unmodified-except-for-debug-writes mss.c: In the case ACPI is enabled, you get: ... atpic: Programming IRQ9 as level/low mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find device pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find device pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 ACPI timer: 0/6 0/4 0/5 0/6 0/6 0/4 0/6 0/6 0/6 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 mss_probe: bus acpi0 is probing device pcm0 mss_probe: isa_get_logicalid() returned 0! -- non pnp probe FINDS the device, wrongly. Using the ISA_PNP_PROBE does the right thing here. mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm0: port 0x530-0x537 on acpi0 device_attach: pcm0 attach returned 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid 30ad041h, vid ffffffffh pnpmss_probe result 6 pcib0: port 0xcf8-0xcff on acpi0 ... isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm3 pnpmss_probe: bus isa0 is probing device pcm3 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm3: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh ... In the case ACPI is not enabled, you get: ..isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm0 pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm0: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh .. Note that in the non-ACPI case, the non-pnp probe routine, mss_probe, when called by isa0 does the right thing and fails to accept the pnp device. The pnp probe routine correctly probes the device in this case. The question I can't get out of my head is this: When I change the mss.c code to use the routine the manual says non-PNP devices are supposed to use: ISA_PNP_PROBE -- all bootup operations are correct in both the ACPI and non ACPI case. Why doesn't that count as 'fixed, update mss.c and lets move on?'. Clearly the present code uses another function that doesn't work in the ACPI case. Shouldn't the investigation focus on what ISA_PNP_PROBE knows that the other call doesn't? ISA_PNP_PROBE in mss_probe works and matches the docs, the isa_get_whatziz doesn't work and is not accepted as correct practice in the docs. Maybe the doc writer has the answer. At any rate I don't get why this further investigation when an apparently 'canonical' practice works. That, or the architecture manual needs changing to mention this other way to avoid wrongful probing by non-PNP isa drivers when called by ACPI or isa0. If you still want me to try a test I'm game, let me know. It would encourage me to do so with the insight provided by some comments on the above though. Harry From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 19:28:06 2005 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 DDBC416A41C; Tue, 12 Jul 2005 19:28:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F3E43D45; Tue, 12 Jul 2005 19:28:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6CJXTJk065550; Tue, 12 Jul 2005 13:33:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D419C2.6040606@samsco.org> Date: Tue, 12 Jul 2005 13:28:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> In-Reply-To: <20050708155827.A10658@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 12 Jul 2005 19:28:06 -0000 Luigi Rizzo wrote: > scott, i probably did not provide enough context... > > To reassure you, I dont intend to change the status quo - the > queue is owned by the driver, and the locking scheme remains the same. > > What we are trying to do is abstract the disk scheduler API so that > if a user, or a subsystem, or a piece of hardware, could benefit > from a different scheduler than the default, it can be easily plugged in. > > In RELENG_4 and RELENG_5 most drivers use bioq_disksort(), which > optimizes for throughput, but may not be ideal when apps have > even soft real-time requirements (e.g. media players), plus > there are different approaches (e.g. the anticipatory scheduling > that someone referenced) that could prove more effective. Stuff > like RAID drivers might have different request ordering > requirements. Even the ATA driver in HEAD uses a different > scheduler than bioq_disksort, but for lack of a proper API > that's hardwired in the driver. > And then as you say, the hardware might have an intelligent > controller so it might be worthwhile disabling sorting - but > then, the same driver e.g. SCSI or ATA might talk to differently > 'smart' hardware and so having configurable per-device schedulers > might be useful. > > Now, if one sees the disk scheduler as a boot-time option, then > the bioq_*() functions are all one needs - the API calls assume > that the subsystem is already locked so nobody except the driver > needs to know about the lock. > > However, if one wants to be able to switch schedulers at runtime > (e.g. through a sysctl), then at the time of a switch you may need to > move requests from the old scheduler to the new one, and in the > process you have to lock each queue before playing with it. > > So the issue is _not_ changing the locking scheme, but just making > the sysctl handler aware of the address (and maybe type) of the lock. > > Here are the two ways that I suggested - 1) put the lock in the queue > so its address is implicitly known, or 2) pass it as an additional > argument to bioq_init(). Either way, when the sysctl handler needs > to play with the bioq outside the normal requests issued by > the driver, it knows which lock to grab. > > I am totally with you when say that a single lock covering not > just the bioq is more efficient - this seems to push towards > method #2, which overall is more flexible. > > cheers > luigi > Ah, now I understand. The downside to exporting the lock is that it opens the possibility of a layer outside of the driver holding the lock long enough to do undesirable things like delay interrupt processing. Also, allowing an outside layer to peek at the bioq contents breaks the assumption that most drivers have that they own the queue and can handle it as they see fit. It's often times desirable to look at the head of the bioq but not dequeue the bio object until you know for sure that it'll be delivered to the hardware. Also, what about in-flight bio's? It's up to the driver to decide whether to complete or requeue bio's that might have been defered due to lack of resources or a transient errors. How will the action of re-ordering the queue from an outside layer handle this? And finally, if you do export a lock from the driver, you cannot assume that it'll be a sleep mutex. You'll need to handle the possibility of a spinlock, sx lock, semaphore, etc. An alternate approach that I would suggest is to have the disk scheduler freeze the block layer from delivering any new bio's while waiting for all of the outstanding bio's to complete, then flip the scheduler algorithm and allow i/o delivery to resume. That way there is no need to play with driver locks, no need to rummage around in resources that are private to the driver, and no need to worry about in-flight bio's. It also removes the need to touch every driver with an API change. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 19:50:21 2005 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 6B60716A41C for ; Tue, 12 Jul 2005 19:50:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A12643D45 for ; Tue, 12 Jul 2005 19:50:20 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 16:04:26 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 15:50:30 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121550.31852.jhb@FreeBSD.org> Cc: Harry Coin , Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 19:50:21 -0000 On Tuesday 12 July 2005 03:19 pm, Harry Coin wrote: > At 10:44 AM 7/12/2005 -0400, John Baldwin wrote: > >Now, when ACPI is enabled, the > >pnpmss driver doesn't probe the device IIRC? > > Both the mss_probe and pnpmss_probe routine are called in the ACPI case and > in the ACPI disabled case. Let me help by providing proof from some > edited short form commented dmesg excerpts from upstream postings using > unmodified-except-for-debug-writes mss.c: I understand that. My last patch (which you apparently didn't test), makes the non-pnp mss probe not be used by ACPI ever. > The question I can't get out of my head is this: When I change the mss.c > code to use the routine the manual says non-PNP devices are supposed to > use: ISA_PNP_PROBE -- all bootup operations are correct in both the ACPI > and non ACPI case. > > Why doesn't that count as 'fixed, update mss.c and lets move on?'. Because there are 20-30 _other_ drivers that use isa_get_logicalid(), and if there's a bug in isa_get_logicalid() then it's going to break _all_ those drivers, and I'd rather fix ACPI than have to wade through a whole bunch of different drivers. Also, having to use an empty PNP_PROBE list is a rather lame solution. > Clearly the present code uses another function that doesn't work in the > ACPI case. Shouldn't the investigation focus on what ISA_PNP_PROBE knows > that the other call doesn't? ISA_PNP_PROBE in mss_probe works and matches > the docs, the isa_get_whatziz doesn't work and is not accepted as correct > practice in the docs. Maybe the doc writer has the answer. At any > rate I don't get why this further investigation when an apparently > 'canonical' practice works. That, or the architecture manual needs > changing to mention this other way to avoid wrongful probing by non-PNP isa > drivers when called by ACPI or isa0. The problem is that ISA_PNP_PROBE() just uses isa_get_logicalid() (basically). Here's what the two functions look like in ACPI: /* Probe _HID and _CID for compatible ISA PNP ids. */ static uint32_t acpi_isa_get_logicalid(device_t dev) { ACPI_DEVICE_INFO *devinfo; ACPI_BUFFER buf; ACPI_HANDLE h; ACPI_STATUS error; u_int32_t pnpid; int i; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); pnpid = 0; buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; /* Fetch and validate the HID. */ if ((h = acpi_get_handle(dev)) == NULL) goto out; error = AcpiGetObjectInfo(h, &buf); if (ACPI_FAILURE(error)) goto out; devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; if ((devinfo->Valid & ACPI_VALID_HID) != 0) pnpid = PNP_EISAID(devinfo->HardwareId.Value); out: if (buf.Pointer != NULL) AcpiOsFree(buf.Pointer); return_VALUE (pnpid); } static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { int result, cid_count, i; uint32_t lid, cids[8]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); /* * ISA-style drivers attached to ACPI may persist and * probe manually if we return ENOENT. We never want * that to happen, so don't ever return it. */ result = ENXIO; /* Scan the supplied IDs for a match */ lid = acpi_isa_get_logicalid(child); cid_count = acpi_isa_get_compatid(child, cids, 8); while (ids && ids->ip_id) { if (lid == ids->ip_id) { result = 0; goto out; } for (i = 0; i < cid_count; i++) { if (cids[i] == ids->ip_id) { result = 0; goto out; } } ids++; } out: if (result == 0 && ids->ip_desc) device_set_desc(child, ids->ip_desc); return_VALUE (result); } The other thing to keep in mind here is that your soundcard isn't an ACPI device that this code would know about, it's an ISA PnP device which is completely different (hung off of isa0 for one), and that what is happening is that ACPI devices like acpi_tz0 (thermal zone) are being probed by mss_probe() and it's not rejecting them because it thinks logicalid() is zero. Hmm, I bet I know what it is actually. ACPI has HIDs that are strings like ACPI003 for things like thermal zones and batteries rather than an ESIA encoded PNPxxx string. So even though there is a valid HID, PNP_EISAID() ends up returning 0. *sigh* The other thing is that the non-pnp mss probe simply does not need to be hooked up to the ACPI bus at all since ACPI will only enumerate PnP devices. I would appreciate it if you would try the simple patch I posted previously to remove the one line from mss.c that hooks the non-pnp mss driver up to acpi. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:03:23 2005 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 724BD16A41C; Tue, 12 Jul 2005 20:03:23 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D1E43D46; Tue, 12 Jul 2005 20:03:22 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 97996BC83; Tue, 12 Jul 2005 20:03:15 +0000 (UTC) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 12 Jul 2005 13:28:02 MDT." <42D419C2.6040606@samsco.org> Date: Tue, 12 Jul 2005 22:03:14 +0200 Message-ID: <33782.1121198594@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Luigi Rizzo , s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 12 Jul 2005 20:03:23 -0000 I must admit that I have often been tempted to move the queue+sorting out of the drivers because they all, more or less, do the exact same thing. For one thing, that would simplify any ABI for changing disksort algorithm (which should be per drive and not per system). This would also move us to an api more or less like the network interfaces. What has held me back is that if the driver knows about a on-disk queue-depth, it might be smart about when to queue and when not to. Overall though, I don't see any evidence of this anywhere in practice (in FreeBSD or otherwise). The recent ATA changes have moved the queue further down (from bio to ata requests) and preempted the discussion for now. Scotts comments about locking are relevant, but I think they are somewhat minor. We have that model in the network interfaces which often handle 10-100 times more requests per second than disk drives, and I don't hear complaints about the model in that context. The last bit of this is that disksorting seldom does much for us these days, apart from mitigating the the lemming syncer. Finally, I am still pretty convinced that if somebody sat down and did some real-life measurements, they would find that disk-sorting has a different task these days where the drives have much more and much more detailed knowledge about the physics of the situation. Over the years I have read quite a bit of IBM's mainframe docs and research on this topic, and they have found a lot of interesting things which all more or less are present in todays zSeries. Much of the work in recent years have tended to move the other direction, instead of sorting the work before shipping to the disk, disk state is exported so it can shape the workload. For instance average I/O time estimates are now used to affect block allocation in DB2 databases. The one place where disk-sorting _really_ makes a huge impact is RAID5 but very specialized sorting algorithms are necessary there and they need intimate access to the internals of the RAID5 engine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:14:33 2005 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 61E4316A41C; Tue, 12 Jul 2005 20:14:33 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE32C43D49; Tue, 12 Jul 2005 20:14:32 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Tue, 12 Jul 2005 15:13:24 -0500 Message-Id: <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jul 2005 15:12:32 -0500 To: John Baldwin ,freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <200507121550.31852.jhb@FreeBSD.org> References: <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> <4.3.2.7.2.20050711160009.01f96420@mail.qconline.com> <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 20:14:33 -0000 John, I am sincerely appreciative the time you have taken. Your test results are below. I haven't processed everything you've written, but I'm not going to hold you up waiting as that is going to take a while. The code just comments out the line you mentioned. pcm0 loads with ACPI on in this case. I haven't tested what happens with ACPI off, and have no easy way to test what will happen with the other non-pnp chips (or other pnp chips) this driver supports. I suggest you send a copy of your comments to whoever fixes up the architecture manual, because of evident disagreement regarding best practice in the isa non-pnp driver detection method (ISA_PNP_PROBE vs. isa_get_logical_id). Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #21: Sun May 29 15:06:21 CDT 2005 root@server1.quietfountain.com:/usr/obj/usr/src/sys/DISKLESS Preloaded elf kernel "/boot/kernel/kernel" at 0xc07af000. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc07af1a4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07af250. Calibrating clock(s) ... i8254 clock: 1193158 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 331109114 Hz CPU: Pentium II/Pentium II Xeon/Celeron (331.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ff real memory = 134209536 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x0000000007d8dfff, 123113472 bytes (30057 pages) avail memory = 125865984 (120 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xcf4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: mem: Pentium Pro MTRR support enabled null: io: random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fcaf0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 A 0x64 14 embedded 0 7 B 0x65 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 14 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 13 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 9 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 11 D 0x61 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 ACPI timer: 0/4 0/5 0/3 0/4 0/3 0/3 0/3 0/3 0/4 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 cpu0: on acpi0 pnpmss_probe: bus acpi0 is probing device pcm0 lid 30ad041h, vid ffffffffh pnpmss_probe result 6 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.1.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.7.3 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.17.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.14.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.14.1 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.14.3 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.0 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 0.13.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 0.13.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 0.13.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x010f, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 5, priority 38295): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKA (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKB (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 \\_SB_.LNKC (references 3, priority 22977): interrupts: 11 10 5 9 12 7 6 4 3 15 penalty: 140 140 190 280 5140 5140 5140 5140 5140 50140 pcib0: slot 7 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000850, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base fa000000, size 12, enabled map[14]: type 4, range 32, base 0000dcc0, size 5, enabled map[18]: type 1, range 32, base ff000000, size 20, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKB (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 \\_SB_.LNKC (references 3, priority 23454): interrupts: 10 11 5 9 12 7 6 4 3 15 penalty: 280 330 330 560 5280 5280 5280 5280 5280 50280 pcib0: slot 14 INTA routed to irq 10 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x1229, revid=0x05 bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x1011, dev=0x0024, revid=0x03 bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfc000000-0xfeffffff pcib1: prefetched decode 0xf9000000-0xf9ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfd000000-0xfdffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base fcfff000, size 12, enabled pcib1: device (null) requested decoded memory range 0xfcfff000-0xfcffffff found-> vendor=0x1002, dev=0x4744, revid=0x5c bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=00 ostat1=ff ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) fxp0: port 0xdcc0-0xdcdf mem 0xff000000-0xff0fffff,0xfa000000-0xfa000fff irq 10 at device 14.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfa000000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000a 0005 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:a0:c9:af:3e:51 fxp0: [MPSAFE] pcib2: at device 15.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.9.1 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.9.2 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.9.3 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.10.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.1 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.10.2 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.10.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.0 \\_SB_.LNKC irq*10: [ 3 4 5 6 7 9 10 11 12 15] 10+ low,level,sharable 2.11.1 \\_SB_.LNKD irq*11: [ 3 4 5 6 7 9 10 11 12 15] 11+ low,level,sharable 2.11.2 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 15] 0+ low,level,sharable 2.11.3 pci2: on pcib2 pci2: physical bus=2 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 acpi_tz0: on acpi0 acpi_tz0: _PSV value is absurd, ignored (-273.-2C) pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid 8d041h, vid ffffffffh pnpmss_probe result 6 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid f0cd041h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid 0h, vid ffffffffh pnpmss_probe result 6 pnpmss_probe: bus acpi0 is probing device pcm0 lid 8d041h, vid ffffffffh pnpmss_probe result 6 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 CSC0000: start dependent (0) CSC0000: adding dma mask 0xa CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x2a0 CSC0000: adding io range 0x534-0x60b, size=0x4, align=0xd4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x24f, size=0x10, align=0x20 CSC0000: start dependent (1) CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x3f3, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x26f, size=0x10, align=0x10 CSC0000: end dependent CSC000f: start dependent (0) CSC000f: adding io range 0x3a0-0x3ff, size=0x8, align=0x8 CSC000f: end dependent CSC0010: adding io range 0xf00-0xfef, size=0x8, align=0x8 CSC0003: start dependent (0) CSC0003: adding io range 0x330-0x3f1, size=0x2, align=0x8 CSC0003: end dependent sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm0 pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm0: at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap ff4000, 1000; 0xcc14e000 -> ff4000 pcm0: sndbuf_setmap ff3000, 1000; 0xcc14f000 -> ff3000 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid f00630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x3a0-0x3a7 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 1000630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0xf00-0xf07 on isa0 mss_probe: bus isa0 is probing device pcm1 pnpmss_probe: bus isa0 is probing device pcm1 lid 300630eh, vid 3568630eh pnpmss_probe result 6 unknown: failed to probe at port 0x330-0x331 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 331109114 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ... start_init: trying /sbin/init splash: image decoder found: green_saver Linux ELF exec handler installed . cat of /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0x534 irq 5 drq 1:0 bufsz 4096 (1p/1r/0v channels duplex default) From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:16:21 2005 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 69BA516A41C; Tue, 12 Jul 2005 20:16:21 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEF1843D45; Tue, 12 Jul 2005 20:16:20 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6CKG2nt040133; Tue, 12 Jul 2005 16:16:02 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j6CKGJ8B011101; Tue, 12 Jul 2005 16:16:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6CKGIuO093414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2005 16:16:18 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050712144415.07454108@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Jul 2005 16:17:25 -0400 To: John Baldwin , freebsd-current@FreeBSD.org From: Mike Tancsa In-Reply-To: <200507121024.50273.jhb@FreeBSD.org> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507111327.46165.jhb@FreeBSD.org> <6.2.1.2.0.20050711232202.0553eb10@64.7.153.2> <200507121024.50273.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 12 Jul 2005 20:16:21 -0000 At 10:24 AM 12/07/2005, John Baldwin wrote: > > BUT! With ata compiled out, I can now boot a current kernel using PIC and > > APIC! This is with a newer AMR card, but I dont think that is the issue. I > > will put back the old one once back at the office tomorrow just to be sure > > as the generic current kernel still hangs on it. > >Argh ok. Can you try compiling a 5.x kernel with 'options NO_MIXED_MODE' and >see if it hangs as well? ACPI specifically forbids using mixed mode. :( Hmmm. I added the kernel option, but it still boots on RELENG_5 :( ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:27:18 2005 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 13DDD16A41C; Tue, 12 Jul 2005 20:27:18 +0000 (GMT) (envelope-from freebsd@xtaz.co.uk) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E7043D46; Tue, 12 Jul 2005 20:27:17 +0000 (GMT) (envelope-from freebsd@xtaz.co.uk) Received: from arizona.xtaz.co.uk ([82.33.96.164]) by smtp-out5.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Jul 2005 21:27:59 +0100 Received: from [192.168.1.2] (tao.xtaz.co.uk [192.168.1.2]) by arizona.xtaz.co.uk (Postfix) with ESMTP id AC3999B496; Tue, 12 Jul 2005 21:27:15 +0100 (BST) Message-ID: <42D427A3.3020703@xtaz.co.uk> Date: Tue, 12 Jul 2005 21:27:15 +0100 From: Matt Smith User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobile@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2005 20:27:59.0817 (UTC) FILETIME=[320A5B90:01C58720] Cc: Subject: 3com officeconnect pcmcia card & ndis issues 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, 12 Jul 2005 20:27:18 -0000 I am running FreeBSD 7.0-CURRENT on my notebook with the ndis module loaded. My 3com wifi card is detected but then I get an error on the console and whilst an ndis0 device is created any attempt to configure it results in ifconfig hanging for 30 seconds before completing the command. None of the lights on the card are lit up. The message in the syslog saying "Can't reuse a leaf" looks dodgy to me? Any ideas what I can try or what's wrong here? I know the pcmcia card slots work as my xircom ethernet works fine. Uname: FreeBSD zen.xtaz.co.uk 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Mon Jul 11 16:18:13 BST 2005 root@arizona.xtaz.co.uk:/usr/obj/usr/src/sys/ZEN i386 Syslog: Jul 12 21:15:58 zen kernel: ndis0: <3Com OfficeConnect Wireless 11g PC Card (3CRWE154G72)> mem 0x88002000-0x88003fff irq 10 at device 0.0 on cardbus1 Jul 12 21:15:58 zen kernel: can't re-use a leaf (BusType)! Jul 12 21:15:58 zen kernel: ndis0: NDIS API version: 5.1 Jul 12 21:16:30 zen kernel: ndis0: Ethernet address: 00:0e:6a:d3:30:b7 Notice the time difference until it logs out the ethernet address. root@zen[log]# ifconfig ndis0 ndis0: flags=8802 mtu 1500 ether 00:0e:6a:d3:30:b7 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" authmode OPEN privacy OFF txpowmax 100 root@zen[~]# time ifconfig ndis0 inet 10.0.0.1 netmask 255.255.255.0 real 0m42.202s user 0m0.001s sys 0m0.095s From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:34:33 2005 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 30DDE16A41C for ; Tue, 12 Jul 2005 20:34:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9438943D58 for ; Tue, 12 Jul 2005 20:34:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 16:48:37 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 16:28:39 -0400 User-Agent: KMail/1.8 References: <70e8236f05070208212e36c375@mail.gmail.com> <200507121024.50273.jhb@FreeBSD.org> <6.2.1.2.0.20050712144415.07454108@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050712144415.07454108@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121628.40539.jhb@FreeBSD.org> Cc: Mike Tancsa Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 12 Jul 2005 20:34:33 -0000 On Tuesday 12 July 2005 04:17 pm, Mike Tancsa wrote: > At 10:24 AM 12/07/2005, John Baldwin wrote: > > > BUT! With ata compiled out, I can now boot a current kernel using PIC > > > and APIC! This is with a newer AMR card, but I dont think that is the > > > issue. I will put back the old one once back at the office tomorrow > > > just to be sure as the generic current kernel still hangs on it. > > > >Argh ok. Can you try compiling a 5.x kernel with 'options NO_MIXED_MODE' > > and see if it hangs as well? ACPI specifically forbids using mixed mode. > > :( > > Hmmm. I added the kernel option, but it still boots on RELENG_5 :( That does sort of help. Can you try commenting out the call to ioapic_setup_mixed_mode() in the sys/i386/i386/mptable.c file and try booting with ACPI disabled (but APIC on) and see if it still works ok? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:34:33 2005 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 477A416A41F for ; Tue, 12 Jul 2005 20:34:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B19AD43D55 for ; Tue, 12 Jul 2005 20:34:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 12 Jul 2005 16:48:37 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 12 Jul 2005 16:27:43 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507121627.44317.jhb@FreeBSD.org> Cc: Harry Coin , Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 20:34:33 -0000 On Tuesday 12 July 2005 04:12 pm, Harry Coin wrote: > John, > > I am sincerely appreciative the time you have taken. Your test results > are below. > > I haven't processed everything you've written, but I'm not going to hold > you up waiting as that is going to take a while. > > The code just comments out the line you mentioned. pcm0 loads with ACPI on > in this case. I haven't tested what happens with ACPI off, and have no > easy way to test what will happen with the other non-pnp chips (or other > pnp chips) this driver supports. Ok, thanks. > I suggest you send a copy of your comments to whoever fixes up the > architecture manual, because of evident disagreement regarding best > practice in the isa non-pnp driver detection method (ISA_PNP_PROBE vs. > isa_get_logical_id). Well, I think I've just figured out why it says that (the ACPIxxxx devices), so it looks like I am going to have to go through and fix all the various drivers to use a probe routine if they attach to ACPI. It looks like several drivers attach to acpi that probably don't need to as well (ACPI only enumerates built-in hardware like COM ports, etc. It doesn't enumerate ISA PnP cards). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:08:56 2005 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 9B75B16A41C; Tue, 12 Jul 2005 21:08:56 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2551C43D46; Tue, 12 Jul 2005 21:08:55 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Tue, 12 Jul 2005 16:09:19 -0500 Message-Id: <4.3.2.7.2.20050712155231.01f8d488@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jul 2005 16:08:27 -0500 To: John Baldwin ,freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <200507121627.44317.jhb@FreeBSD.org> References: <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 12 Jul 2005 21:08:56 -0000 John, Seems pulling my little orange out of the pyramid made the rest tumble! FWIW, apropos your "(ACPI only enumerates built-in hardware like COM ports, etc. It doesn't enumerate ISA PnP cards)." I'm fairly sure there are non PNP sound chips built on some motherboards in a fashion not different than the com ports. I'm guessing the line you had me zap might have been put in for that. Unless you need anything more, I'm going to move on to making the mixer register mapping actually match the input side of the sound chips (only the PCM / line out register maps are correct in mss.c). Then on to figure out why the midi and FM synthesizer logical devices don't probe for the CS4236B. Could someone give me a URL regarding instructions on how to submit more than trivial changes to drivers that fix audio input and have added / better output device chip support? Thanks Harry At 04:27 PM 7/12/2005 -0400, John Baldwin wrote: >On Tuesday 12 July 2005 04:12 pm, Harry Coin wrote: > > John, > > > > I am sincerely appreciative the time you have taken. Your test results > > are below. > > > > I haven't processed everything you've written, but I'm not going to hold > > you up waiting as that is going to take a while. > > > > The code just comments out the line you mentioned. pcm0 loads with ACPI on > > in this case. I haven't tested what happens with ACPI off, and have no > > easy way to test what will happen with the other non-pnp chips (or other > > pnp chips) this driver supports. > >Ok, thanks. > > > I suggest you send a copy of your comments to whoever fixes up the > > architecture manual, because of evident disagreement regarding best > > practice in the isa non-pnp driver detection method (ISA_PNP_PROBE vs. > > isa_get_logical_id). > >Well, I think I've just figured out why it says that (the ACPIxxxx devices), >so it looks like I am going to have to go through and fix all the various >drivers to use a probe routine if they attach to ACPI. It looks like several >drivers attach to acpi that probably don't need to as well (ACPI only >enumerates built-in hardware like COM ports, etc. It doesn't enumerate ISA >PnP cards). > >-- >John Baldwin <>< http://www.FreeBSD.org/~jhb/ >"Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 23:09:38 2005 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 98AF516A41C; Tue, 12 Jul 2005 23:09:38 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40FD143D5E; Tue, 12 Jul 2005 23:09:37 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6CN9aKV058541; Tue, 12 Jul 2005 16:09:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6CN9Zbo058540; Tue, 12 Jul 2005 16:09:35 -0700 (PDT) (envelope-from rizzo) Date: Tue, 12 Jul 2005 16:09:35 -0700 From: Luigi Rizzo To: Scott Long Message-ID: <20050712160935.A58434@xorpc.icir.org> References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> <42D419C2.6040606@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42D419C2.6040606@samsco.org>; from scottl@samsco.org on Tue, Jul 12, 2005 at 01:28:02PM -0600 Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 12 Jul 2005 23:09:38 -0000 The approach you suggest in the second part sounds interesting, except that i have no idea where i should intercept the calls in the block layer. Any suggestion ? Re. the first part, i don't fully follow your reasoning probably because i have in mind a different setting - one where the driver has already offloaded to the scheduler (through its API) all operations on the bioq, and where the only usage of the lock is on an exceptional situation -- a scheduler switch -- where you can probably tolerate some small delays. The variant lock methods are also not much a of an issue - if a bioq uses a supported method then it is allowed to use the pluggable interface, otherwise it just uses whatever the default is. cheers luigi On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote: ... > > Ah, now I understand. The downside to exporting the lock is that > it opens the possibility of a layer outside of the driver holding > the lock long enough to do undesirable things like delay interrupt > processing. Also, allowing an outside layer to peek at the bioq > contents breaks the assumption that most drivers have that they own > the queue and can handle it as they see fit. It's often times > desirable to look at the head of the bioq but not dequeue the > bio object until you know for sure that it'll be delivered to the > hardware. Also, what about in-flight bio's? It's up to the driver > to decide whether to complete or requeue bio's that might have been > defered due to lack of resources or a transient errors. How will > the action of re-ordering the queue from an outside layer handle > this? And finally, if you do export a lock from the driver, you > cannot assume that it'll be a sleep mutex. You'll need to handle > the possibility of a spinlock, sx lock, semaphore, etc. > > An alternate approach that I would suggest is to have the disk scheduler > freeze the block layer from delivering any new bio's while waiting for > all of the outstanding bio's to complete, then flip the scheduler > algorithm and allow i/o delivery to resume. That way there is no > need to play with driver locks, no need to rummage around in resources > that are private to the driver, and no need to worry about in-flight > bio's. It also removes the need to touch every driver with an API > change. > > Scott From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 23:22:16 2005 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 958E216A41C; Tue, 12 Jul 2005 23:22:16 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5890343D49; Tue, 12 Jul 2005 23:22:16 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6CNMGic058656; Tue, 12 Jul 2005 16:22:16 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6CNMFDo058655; Tue, 12 Jul 2005 16:22:15 -0700 (PDT) (envelope-from rizzo) Date: Tue, 12 Jul 2005 16:22:15 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20050712162215.B58434@xorpc.icir.org> References: <42D419C2.6040606@samsco.org> <33782.1121198594@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <33782.1121198594@phk.freebsd.dk>; from phk@haven.freebsd.dk on Tue, Jul 12, 2005 at 10:03:14PM +0200 Cc: Robert Watson , s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock 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, 12 Jul 2005 23:22:16 -0000 On Tue, Jul 12, 2005 at 10:03:14PM +0200, Poul-Henning Kamp wrote: > > I must admit that I have often been tempted to move the queue+sorting > out of the drivers because they all, more or less, do the exact > same thing. > > For one thing, that would simplify any ABI for changing disksort > algorithm (which should be per drive and not per system). yes this is true - in fact we are looking at the feasibility of a per-drive disksort too. What is really complex with the current infrastructure is implementing non work-conserving algorithms, e.g. the anticipatory scheduling (see http://www.cs.rice.edu/~ssiyer/r/antsched/ ) because there you need to hook into the equivalent of if_start() for network interfaces, and at the moment each driver does it in a different way... > The last bit of this is that disksorting seldom does much for us > these days, apart from mitigating the the lemming syncer. true again... (not that i dobted that phk knows a lot here :) in fact i see it more as something to improve fairness, rather than something to improve throughput. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 01:15:18 2005 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 1F64316A41C; Wed, 13 Jul 2005 01:15:18 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89EE043D46; Wed, 13 Jul 2005 01:15:17 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [70.28.254.189]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id j6D1R0hG099577; Tue, 12 Jul 2005 21:27:09 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <04cc01c58748$64f01d60$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Scott Long" , "Poul-Henning Kamp" References: <33782.1121198594@phk.freebsd.dk> Date: Tue, 12 Jul 2005 21:15:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Luigi Rizzo , s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 13 Jul 2005 01:15:18 -0000 > I must admit that I have often been tempted to move the queue+sorting > out of the drivers because they all, more or less, do the exact > same thing. > > For one thing, that would simplify any ABI for changing disksort > algorithm (which should be per drive and not per system). Agreed. For example, IBM's AIX implements per-device disksort algorithms. If you've got ancient SSA drives, they will sort requests differently than disks in an ESS or FAStT disk array. > Finally, I am still pretty convinced that if somebody sat down and > did some real-life measurements, they would find that disk-sorting > has a different task these days where the drives have much more and > much more detailed knowledge about the physics of the situation. > > Over the years I have read quite a bit of IBM's mainframe docs and > research on this topic, and they have found a lot of interesting > things which all more or less are present in todays zSeries. > > Much of the work in recent years have tended to move the other > direction, instead of sorting the work before shipping to the disk, > disk state is exported so it can shape the workload. For instance > average I/O time estimates are now used to affect block allocation > in DB2 databases. This is only true if you're talking about DB2 on zSeries. [ Disclaimer: I'm a DB2 LUW developer. ] DB2 on LUW (Linux/Unix/Windows) does exactly the opposite in most cases. I/Os are generally sent to the OS in unsorted fashion (unless it's a big batch of sequential pages, in which case they're sent in sorted order), and we let the OS handle things appropriately. Most OSes are relatively intelligent and share information throughout the disk/LVM subsystem with respect to device queue properties and I/O request lists, and can make the best decisions on how to sort. > The one place where disk-sorting _really_ makes a huge impact > is RAID5 but very specialized sorting algorithms are necessary > there and they need intimate access to the internals of the > RAID5 engine. Yet another reason to defer the sorting algorithm to the driver or the hardware itself. -- Matt Emmerton From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 03:06:05 2005 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 ADF5A16A420 for ; Wed, 13 Jul 2005 03:06:05 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E535D43D49 for ; Wed, 13 Jul 2005 03:06:04 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.4) with ESMTP id j6D33fwW001223 for ; Wed, 13 Jul 2005 07:03:41 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.3/Submit) id j6D33eB6001222 for freebsd-current@freebsd.org; Wed, 13 Jul 2005 07:03:40 +0400 (MSD) (envelope-from tarc) Date: Wed, 13 Jul 2005 07:03:36 +0400 From: Tarc To: freebsd-current Message-ID: <20050713030336.GA1182@tarc.po.cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: German FreeBSD CVS mirror IO problem 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, 13 Jul 2005 03:06:05 -0000 CVSROOT is ":ext:anoncvs@anoncvs2.de.FreeBSD.org:/home/ncvs" When I update ports collection today (3 times, about at 3, 5 and 6:30 am MSK), I receive these messages from CVS server: (all files before are successfully updated) cvs server: cannot open /home/ncvs/ports/net/delegate/pkg-descr,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/delegate/pkg-descr,v: Input/output error cvs server: nothing known about net/delegate/pkg-descr cvs server: cannot open /home/ncvs/ports/net/delegate/pkg-message,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/delegate/pkg-message,v: Input/output error cvs server: nothing known about net/delegate/pkg-message cvs server: cannot open /home/ncvs/ports/net/delegate/files/delegated.sh,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/delegate/files/delegated.sh,v: Input/output error cvs server: nothing known about net/delegate/files/delegated.sh cvs server: cannot open /home/ncvs/ports/net/despoof/Makefile,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/Makefile,v: Input/output error cvs server: nothing known about net/despoof/Makefile cvs server: cannot open /home/ncvs/ports/net/despoof/distinfo,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/distinfo,v: Input/output error cvs server: nothing known about net/despoof/distinfo cvs server: cannot open /home/ncvs/ports/net/despoof/pkg-descr,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/pkg-descr,v: Input/output error cvs server: nothing known about net/despoof/pkg-descr cvs server: cannot open /home/ncvs/ports/net/despoof/pkg-plist,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/pkg-plist,v: Input/output error cvs server: nothing known about net/despoof/pkg-plist cvs server: cannot open /home/ncvs/ports/net/despoof/files/patch-aa,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/files/patch-aa,v: Input/output error cvs server: nothing known about net/despoof/files/patch-aa cvs server: cannot open /home/ncvs/ports/net/despoof/files/patch-ab,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/despoof/files/patch-ab,v: Input/output error cvs server: nothing known about net/despoof/files/patch-ab cvs server: cannot open /home/ncvs/ports/net/dgd-lpmud/Makefile,v: Input/output error cvs server: cannot open /home/ncvs/ports/net/dgd-lpmud/Makefile,v: Input/output error cvs server: nothing known about net/dgd-lpmud/Makefile ... Please, check it. -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 03:12:34 2005 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 2762316A41C for ; Wed, 13 Jul 2005 03:12:34 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD34543D48 for ; Wed, 13 Jul 2005 03:12:33 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <20050713031231013002rmrue>; Wed, 13 Jul 2005 03:12:31 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6D3CUJI000984 for ; Tue, 12 Jul 2005 23:12:30 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6D3CTip000983 for freebsd-current@freebsd.org; Tue, 12 Jul 2005 23:12:29 -0400 (EDT) (envelope-from rodrigc) Date: Tue, 12 Jul 2005 23:12:29 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050713031229.GA933@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.9i Subject: Panic in bpf, maybe related to if_xl 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, 13 Jul 2005 03:12:34 -0000 Hi, My system is -CURRENT, from July 9. I use my FreeBSD box to run natd, using the if_xl network driver (3Com card). I got a panic inside of bpf: mutex Giant is not owned at /usr/src/sys/net/bpf.c:1330 #13 0xc065e610 in _mtx_assert (m=0xc0926ec0, what=0, file=0xc087e2e8 "/usr/src/sys/net/bpf.c", line=1330) at /usr/src/sys/kern/kern_mutex.c:739 #14 0xc06c8ec6 in catchpacket (d=0xc178b300, pkt=0xc17f9802 "ÿÿÿÿÿÿ", pktlen=393, snaplen=4294967295, cpfn=0xc080483c ) at /usr/src/sys/net/bpf.c:1330 #15 0xc06c8bf0 in bpf_tap (bp=0xc16545c0, pkt=0xc17f9802 "ÿÿÿÿÿÿ", pktlen=393) at /usr/src/sys/net/bpf.c:1184 #16 0xc06c8cbc in bpf_mtap (bp=0xc16545c0, m=0xc17e2600) at /usr/src/sys/net/bpf.c:1238 #17 0xc06ceb6b in ether_input (ifp=0xc168ec00, m=0xc17e2600) at /usr/src/sys/net/if_ethersubr.c:572 #18 0xc07853cf in xl_rxeof (sc=0xc1691000) at /usr/src/sys/pci/if_xl.c:2068 #19 0xc07854d6 in xl_rxeof_task (arg=0xc1691000, pending=1) at /usr/src/sys/pci/if_xl.c:2104 #20 0xc0685182 in taskqueue_run (queue=0xc153cc00) at /usr/src/sys/kern/subr_taskqueue.c:217 #21 0xc068527a in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:252 #22 0xc0653a10 in ithread_loop (arg=0xc153cb80) at /usr/src/sys/kern/kern_intr.c:545 #23 0xc0652e44 in fork_exit (callout=0xc06538f4 , arg=0xc153cb80, frame=0xcbff1d38) at /usr/src/sys/kern/kern_fork.c:789 I have a kernel.debug and crashdump if I can help someone debug this. Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 09:34:38 2005 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 86F2616A44F; Wed, 13 Jul 2005 09:34:38 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D0943D46; Wed, 13 Jul 2005 09:34:37 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [192.168.1.6] (211.26.76.19) by smtp01.syd.iprimus.net.au (7.2.060.1) id 42A0AD7E00D4AE4E; Wed, 13 Jul 2005 19:34:36 +1000 From: Brett Wildermoth Organization: Griffith University To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Date: Wed, 13 Jul 2005 19:33:05 +1000 User-Agent: KMail/1.8 X-Face: #"DtK&7^5P|u6yesiHW<_YTpWs>V8v|7J%W[b6O~\9emUr??J}9>jRP`j"a7jaE,2>=?utf-8?q?V=2E=60k=0A=09dX53n=3B0L=3Bz=5BY*=5D80/iO=26?= Cc: Subject: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brett Wildermoth List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2005 09:34:38 -0000 --nextPart6481913.MTUe1fmn1h Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just boug= ht=20 seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar= =20 the network and X to work, with 6.0 I can get the network to work also.=20 However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one = for=20 Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people alread= y=20 have..... Perhaps NVIDIA think FreeBSD is just a hobby OS......=20 Brett =2D-=20 =2D------------------------------------------------------------------ Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart6481913.MTUe1fmn1h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1N/YbSsZm/bQWSwRAhCRAJ9lplgpLBtB2wta1esUS2AgYrUuPACgk30j 5N31BnFItosCfoSLLSe8n0c= =s14+ -----END PGP SIGNATURE----- --nextPart6481913.MTUe1fmn1h-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 10:21:27 2005 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 1205216A41C for ; Wed, 13 Jul 2005 10:21:27 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5A6443D49 for ; Wed, 13 Jul 2005 10:21:26 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id B652BA30E9 for ; Wed, 13 Jul 2005 12:21:25 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 93F21649D; Wed, 13 Jul 2005 12:21:25 +0200 (CEST) Date: Wed, 13 Jul 2005 12:21:25 +0200 From: Marc Olzheim To: freebsd-current@FreeBSD.org Message-ID: <20050713102125.GA87684@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Subject: #! interpreter argument handling in UPDATING ? 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, 13 Jul 2005 10:21:27 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. Shouldn't the new (6-STABLE) interpreter argument handling be in /usr/src/UPDATING ? Or will it be in the release notes ? Marc --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC1OslezjnobFOgrERAtNwAJ46MbRNdF0hiDoBJ5oli4Urb/R11gCgiwsz Xw7ZYLRMcX0qWP9oIh/Q17Y= =7Ms1 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 10:45:59 2005 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 AF66716A41C for ; Wed, 13 Jul 2005 10:45:59 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF7D43D45 for ; Wed, 13 Jul 2005 10:45:58 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id D78F5A2FF1 for ; Wed, 13 Jul 2005 12:45:57 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id B3AA863CE; Wed, 13 Jul 2005 12:45:57 +0200 (CEST) Date: Wed, 13 Jul 2005 12:45:57 +0200 From: Marc Olzheim To: freebsd-current@FreeBSD.org Message-ID: <20050713104557.GB87684@stack.nl> References: <20050713102125.GA87684@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: <20050713102125.GA87684@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Subject: Re: #! interpreter argument handling in UPDATING ? 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, 13 Jul 2005 10:45:59 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2005 at 12:21:25PM +0200, Marc Olzheim wrote: > Hi. >=20 > Shouldn't the new (6-STABLE) interpreter argument handling be in > /usr/src/UPDATING ? Or will it be in the release notes ? Btw.: Why isn't there some compatibilty mode added to the 4 and 5-STABLE /usr/bin/env , so that there's at least a common way to run scripts on different FreeBSD servers that does the multiple argument handling ? Like ignoring a -S or interpreting it as -- ... Marc --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC1PDlezjnobFOgrERAs59AJ0bdh2U1blQmnLTnNyYhWUVY5IqsACfeFhb TqiHiHW8pyk2G8t09COfHUQ= =X6gY -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 11:51:55 2005 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 3017C16A41C for ; Wed, 13 Jul 2005 11:51:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF4C543D4C for ; Wed, 13 Jul 2005 11:51:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 0397146B24; Wed, 13 Jul 2005 07:51:54 -0400 (EDT) Date: Wed, 13 Jul 2005 12:51:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Craig Rodrigues In-Reply-To: <20050713031229.GA933@crodrigues.org> Message-ID: <20050713125038.Q926@fledge.watson.org> References: <20050713031229.GA933@crodrigues.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1208179416-1121255513=:926" Cc: freebsd-current@freebsd.org Subject: Re: Panic in bpf, maybe related to if_xl 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, 13 Jul 2005 11:51:55 -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-1208179416-1121255513=:926 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 12 Jul 2005, Craig Rodrigues wrote: > My system is -CURRENT, from July 9. I use my FreeBSD box to run natd,=20 > using the if_xl network driver (3Com card). > > I got a panic inside of bpf: > > mutex Giant is not owned at /usr/src/sys/net/bpf.c:1330 The lock assertion in question has two parts: (1) Assert the BPF lock required. (2) If debug.mpsafenet=3D0, assert Giant. It looks like if_xl is not properly acquiring Giant when entering the=20 network stack when running with debug.mpsafenet=3D0. It should be calling= =20 NET_LOCK_GIANT() in the task queue before calling if_input(). Robert > > #13 0xc065e610 in _mtx_assert (m=3D0xc0926ec0, what=3D0, > file=3D0xc087e2e8 "/usr/src/sys/net/bpf.c", line=3D1330) > at /usr/src/sys/kern/kern_mutex.c:739 > #14 0xc06c8ec6 in catchpacket (d=3D0xc178b300, pkt=3D0xc17f9802 "=FF=FF= =FF=FF=FF=FF", > pktlen=3D393, snaplen=3D4294967295, cpfn=3D0xc080483c ) > at /usr/src/sys/net/bpf.c:1330 > #15 0xc06c8bf0 in bpf_tap (bp=3D0xc16545c0, pkt=3D0xc17f9802 "=FF=FF=FF= =FF=FF=FF", pktlen=3D393) > at /usr/src/sys/net/bpf.c:1184 > #16 0xc06c8cbc in bpf_mtap (bp=3D0xc16545c0, m=3D0xc17e2600) > at /usr/src/sys/net/bpf.c:1238 > #17 0xc06ceb6b in ether_input (ifp=3D0xc168ec00, m=3D0xc17e2600) > at /usr/src/sys/net/if_ethersubr.c:572 > #18 0xc07853cf in xl_rxeof (sc=3D0xc1691000) at /usr/src/sys/pci/if_xl.c:= 2068 > #19 0xc07854d6 in xl_rxeof_task (arg=3D0xc1691000, pending=3D1) > at /usr/src/sys/pci/if_xl.c:2104 > #20 0xc0685182 in taskqueue_run (queue=3D0xc153cc00) > at /usr/src/sys/kern/subr_taskqueue.c:217 > #21 0xc068527a in taskqueue_swi_run (dummy=3D0x0) > at /usr/src/sys/kern/subr_taskqueue.c:252 > #22 0xc0653a10 in ithread_loop (arg=3D0xc153cb80) > at /usr/src/sys/kern/kern_intr.c:545 > #23 0xc0652e44 in fork_exit (callout=3D0xc06538f4 , > arg=3D0xc153cb80, frame=3D0xcbff1d38) at /usr/src/sys/kern/kern_fork.c= :789 > > > > I have a kernel.debug and crashdump if I can help someone debug this. > > Thanks. > --=20 > Craig Rodrigues > rodrigc@crodrigues.org > _______________________________________________ > 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= " > --0-1208179416-1121255513=:926-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 23:07:12 2005 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 A85B916A41C for ; Tue, 12 Jul 2005 23:07:12 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B9843D49 for ; Tue, 12 Jul 2005 23:07:12 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id 600A9C8009; Wed, 13 Jul 2005 01:07:05 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id 5D016900F9 for ; Wed, 13 Jul 2005 01:07:05 +0200 (CEST) Date: Wed, 13 Jul 2005 01:07:05 +0200 (CEST) From: Goran Gajic To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 13 Jul 2005 11:55:52 +0000 Subject: LOR with 6.0 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, 12 Jul 2005 23:07:12 -0000 SMP Xeon 2.4 with HTT : lock order reversal 1st 0xc5d9c84c inp (udpinp) @ netinet/udp_usrreq.c:762 2nd 0xc5d324f4 user map (user map) @ vm/vm_map.c:2997 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c094aa10,c094a600,c08d334c) at kdb_backtrace+0x29 witness_checkorder(c5d324f4,9,c0887a12,bb5) at witness_checkorder+0x564 _sx_xlock(c5d324f4,c0887a09,bb5) at _sx_xlock+0x50 _vm_map_lock_read(c5d324b0,c0887a09,bb5,1072860,c5c89898) at _vm_map_lock_read+0x37 vm_map_lookup(ec0728ec,33203000,1,ec0728f0,ec0728e0) at vm_map_lookup+0x28 vm_fault(c5d324b0,33203000,1,0,c5c8aa80) at vm_fault+0x66 trap_pfault(ec0729b4,0,33203037) at trap_pfault+0xee trap(ec070008,28,c0870028,c104a9a0,c8a5d900) at trap+0x33d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc068103c, esp = 0xec0729f4, ebp = 0xec0729f4 --- m_tag_delete(c8a5d900,33203037) at m_tag_delete+0x40 m_tag_delete_chain(c8a5d900,0) at m_tag_delete_chain+0x3b mb_dtor_mbuf(c8a5d900,100,0) at mb_dtor_mbuf+0x15 uma_zfree_arg(c104a9a0,c8a5d900,0) at uma_zfree_arg+0x24 m_freem(c8a5d900) at m_freem+0x36 arpresolve(c5912000,c5e3fce4,c9839100,c5e529b0,ec072aa4) at arpresolve+0x1f4 ether_output(c5912000,c9839100,c5e529b0,c5e3fce4,c5c55900) at ether_output+0x66 ip_output(c9839100,0,ec072afc,0,0) at ip_output+0x6fc udp_output(c5d9c7bc,c9839100,c741d620,0,c5c8aa80) at udp_output+0x4a7 udp_send(c5eff2c8,0,c9839100,c741d620,0) at udp_send+0x1a sosend(c5eff2c8,c741d620,ec072c38,c9839100,0) at sosend+0x5e3 kern_sendit(c5c8aa80,1c,ec072cb4,0,0) at kern_sendit+0x104 sendit(c5c8aa80,1c,ec072cb4,0,c5c1e590) at sendit+0x163 sendmsg(c5c8aa80,ec072d04,3,4628,286) at sendmsg+0x5a syscall(bfbf003b,bfbf003b,bfbf003b,1,8a40a2c) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x882f949b, esp = 0xbfbfe41c, ebp = 0xbfbfe598 --- Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual address = 0x33203037 fault code = supervisor read, page not present instruction pointer = 0x20:0xc068103c stack pointer = 0x28:0xec0729f4 frame pointer = 0x28:0xec0729f4 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 = 409 (named) [thread pid 409 tid 100102 ] Stopped at m_tag_delete+0x40: movl 0(%eax),%eax db> correct^M From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 08:13:47 2005 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 944B516A41C for ; Wed, 13 Jul 2005 08:13:47 +0000 (GMT) (envelope-from lemle@integrity.hu) Received: from integrity.hu (intmail.integrity.hu [193.178.119.140]) by mx1.FreeBSD.org (Postfix) with SMTP id C0DE843D48 for ; Wed, 13 Jul 2005 08:13:46 +0000 (GMT) (envelope-from lemle@integrity.hu) Received: (qmail 32449 invoked by uid 89); 13 Jul 2005 08:13:42 -0000 Message-ID: <20050713081342.32448.qmail@integrity.hu> From: "Lemle =?iso-8859-2?Q?G=E9za?=" To: freebsd-current@freebsd.org Date: Wed, 13 Jul 2005 10:13:42 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Sender: lemle@integrity.hu X-Mailman-Approved-At: Wed, 13 Jul 2005 11:55:52 +0000 Subject: Problem with si card 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, 13 Jul 2005 08:13:47 -0000 Hello, I have a Specialix (now Perle) SI isa bus card. I use this with modems in a RAS server. Everything was fine until I upgraded the os from 5.3 to -current. Currently I could use only 1 port (4.) on the card. I can't open another port with kermit, or getty, too. This machine is an Intel SE440BX-2 motherboard, PII 400 Celeron processor, 256 MB RAM The SI card memory address space is reserved for isa devices in the BIOS. Configuration: /boot/device.hints hint.si.0.at="isa" hint.si.0.maddr="0xd0000" hint.si.0.irq="12" /etc/gettytab default:\ :pp=/etc/ppp/ppplogin:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:\ :if=/etc/issue: m|Metallo:\ :np:hw:sp#57600: /etc/ttys ttyA01 "/usr/libexec/getty m" dialup on insecure ttyA02 "/usr/libexec/getty m" dialup on insecure ttyA03 "/usr/libexec/getty m" dialup on insecure ttyA04 "/usr/libexec/getty m" dialup on insecure uname 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu Jul 7 16:58:15 CEST 2005 dmesg si0 at iomem 0xd0000-0xd7fff irq 12 on isa0 si0: [GIANT-LOCKED] si0: card: SIHOST2, ports: 8, modules: 1, type: 1 (SI) Best regards, Geza From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 13:36:16 2005 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 3408316A41C; Wed, 13 Jul 2005 13:36:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C529943D49; Wed, 13 Jul 2005 13:36:15 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6DDZufA085991; Wed, 13 Jul 2005 09:35:56 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j6DDaE53055404; Wed, 13 Jul 2005 09:36:14 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6DDaDr7095947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2005 09:36:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050713093748.067b8a88@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 09:38:03 -0400 To: John Baldwin , freebsd-current@FreeBSD.org From: Mike Tancsa In-Reply-To: <200507121628.40539.jhb@FreeBSD.org> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507121024.50273.jhb@FreeBSD.org> <6.2.1.2.0.20050712144415.07454108@64.7.153.2> <200507121628.40539.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 13 Jul 2005 13:36:16 -0000 At 04:28 PM 12/07/2005, John Baldwin wrote: >That does sort of help. Can you try commenting out the call to >ioapic_setup_mixed_mode() in the sys/i386/i386/mptable.c file and try booting >with ACPI disabled (but APIC on) and see if it still works ok? Yup, Still boots just fine. ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 13:57:45 2005 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 7091F16A41C for ; Wed, 13 Jul 2005 13:57:45 +0000 (GMT) (envelope-from bob@immure.com) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD20D43D48 for ; Wed, 13 Jul 2005 13:57:44 +0000 (GMT) (envelope-from bob@immure.com) Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j6DDvIgd007417 for ; Wed, 13 Jul 2005 09:57:18 -0400 X-ORBL: [66.136.206.1] Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j6DDvg8U304774; Wed, 13 Jul 2005 09:57:42 -0400 Received: from luke.immure.com (luke.immure.com [10.1.132.3]) by maul.immure.com (8.13.3/8.12.11) with ESMTP id j6DDvYqY019272; Wed, 13 Jul 2005 08:57:34 -0500 (CDT) (envelope-from bob@immure.com) Received: from luke.immure.com (localhost [127.0.0.1]) by luke.immure.com (8.13.1/8.13.1) with ESMTP id j6DDvYd9077001; Wed, 13 Jul 2005 08:57:34 -0500 (CDT) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.13.1/8.12.11/Submit) id j6DDvY2i077000; Wed, 13 Jul 2005 08:57:34 -0500 (CDT) (envelope-from bob) Date: Wed, 13 Jul 2005 08:57:34 -0500 From: Bob Willcox To: Jonathan Noack Message-ID: <20050713135733.GA75906@luke.immure.com> References: <4282F922.7070003@alumni.rice.edu> <4282F965.3070306@DeepCore.dk> <4282FFD0.8040101@alumni.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4282FFD0.8040101@alumni.rice.edu> User-Agent: Mutt/1.5.9i X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner: Found to be clean X-MailScanner-From: bob@immure.com Cc: current@freebsd.org, S?ren Schmidt Subject: Re: atapicam breakage (was: ata breakage [STILL]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2005 13:57:45 -0000 On Thu, May 12, 2005 at 02:03:44AM -0500, Jonathan Noack wrote: > On 05/12/05 01:36, S?ren Schmidt wrote: > >Jonathan Noack wrote: > >>I am still getting breakage from ata with sources from around midnight > >>CDT (after the latest updates). These result in odd messages being > >>printed to the screen and eventual panics before the machine mounts > >>root. See the attached horrific.txt for the boot messages and some > >>brief ddb action. Note the garbage right before the panic. The > >>garbage was printed out before a 30 second pause prior to the panic. > >> > >>I backed out src/sys/dev/ata to '2005-05-03 07:55:00 UTC' and > >>everything works perfectly. See the attached normal.txt for these > >>boot messages. > >> > >>The panic seems to happen during probing of the CD drive. I use > >>atapicam *without* atapicd. The kernel config is also attached. > > > >OK, loose atapicam from the kernel and let me know how that goes.. > > Yup, everything works fine without atapicam but with atapicd. Looks > like atapicam is the source of the breakage. I'm seeing this same problem (well, the symptoms are the same) on a 6-stable amd64 system (cvsup'd today). If I include atapicam in the kernel the system panics on boot (after the "ATA PseudoRAID loaded" message and before the "Trying to mount root ..." message). If I remove atapicam from the kernel everything is fine unless I kldload atapicam. A short while after loading atapicam (takes a few minutes to panic) it then panics with the same panic message: panic: g_read_data(): invalid length 3179371452 Bob > > -- > Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 > -- Bob Willcox Reality is nothing but a collective hunch. bob@immure.com -- Lily Tomlin Austin, TX From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 14:34:06 2005 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 338BC16A41C; Wed, 13 Jul 2005 14:34:06 +0000 (GMT) (envelope-from culverk@sweetdreamsracing.biz) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id D45F343D48; Wed, 13 Jul 2005 14:34:03 +0000 (GMT) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id 810AA6106; Wed, 13 Jul 2005 10:26:42 -0400 (EDT) Received: from sf-nat.sourcefire.com (sf-nat.sourcefire.com [65.202.215.2]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Wed, 13 Jul 2005 10:26:42 -0400 Message-ID: <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> Date: Wed, 13 Jul 2005 10:26:42 -0400 From: Kenneth Culver To: Brett Wildermoth References: <200507131933.12318.B.Wildermoth@griffith.edu.au> In-Reply-To: <200507131933.12318.B.Wildermoth@griffith.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 13 Jul 2005 14:34:06 -0000 Quoting Brett Wildermoth : > To all my fellow FreeBSD users, > > I assume I am not the only one who is in this predicament. I have just bought > seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar > the network and X to work, with 6.0 I can get the network to work also. > However no matter what I do I can't get X to work. > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They > make one for > Linux x86-64 and one for FreeBSD-x86. > > Perhaps would could all post a message on nvforum. I see some people already > have..... > > Perhaps NVIDIA think FreeBSD is just a hobby OS...... > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Ken From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 14:58:24 2005 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 2318116A41F for ; Wed, 13 Jul 2005 14:58:24 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B67CD43D6E for ; Wed, 13 Jul 2005 14:58:20 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j6DEwHYi019440; Wed, 13 Jul 2005 10:58:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050713104557.GB87684@stack.nl> References: <20050713102125.GA87684@stack.nl> <20050713104557.GB87684@stack.nl> Date: Wed, 13 Jul 2005 10:58:16 -0400 To: Marc Olzheim , freebsd-current@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Cc: Subject: Re: #! interpreter argument handling in UPDATING ? 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, 13 Jul 2005 14:58:24 -0000 At 12:45 PM +0200 7/13/05, Marc Olzheim wrote: >On Wed, Jul 13, 2005 at 12:21:25PM +0200, Marc Olzheim wrote: >> Hi. >> > > Shouldn't the new (6-STABLE) interpreter argument handling be > > in /usr/src/UPDATING ? Or will it be in the release notes ? This I don't know about. I thought I had added an entry to UPDATING, I have not looked to see what (if anything) happened to it. >Btw.: Why isn't there some compatibilty mode added to the 4 and >5-STABLE /usr/bin/env , so that there's at least a common way to >run scripts on different FreeBSD servers that does the multiple >argument handling ? > >Like ignoring a -S or interpreting it as -- ... I first wanted to make sure all the bugs were ironed out of the version in 6.x. I have a few minor bug fixes yet to commit to the 6.x version, for instance. (I'll probably commit them to 7.x today, now that the code freeze has lifted for that). Other than that, it's mainly just the bother of writing up a different man page. Since the parsing done by the kernel is different in 5.x/4.x (and that parsing is not going to change), I suspect that the man page needs a different description for 5.x. I also need to do some testing to make sure I stick to examples which work the same for both kinds of argument-handling as done by the kernel. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 15:47:01 2005 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 0532216A41C for ; Wed, 13 Jul 2005 15:47:01 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A41A43D48 for ; Wed, 13 Jul 2005 15:47:00 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (rwcrmhc14) with ESMTP id <2005071315465801400idaspe>; Wed, 13 Jul 2005 15:46:59 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6DFkvxo001604 for ; Wed, 13 Jul 2005 11:46:57 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6DFkvlS001603 for freebsd-current@freebsd.org; Wed, 13 Jul 2005 11:46:57 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 13 Jul 2005 11:46:56 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050713154656.GA1516@crodrigues.org> References: <20050713031229.GA933@crodrigues.org> <20050713125038.Q926@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050713125038.Q926@fledge.watson.org> User-Agent: Mutt/1.5.9i Subject: Re: Panic in bpf, maybe related to if_xl 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, 13 Jul 2005 15:47:01 -0000 On Wed, Jul 13, 2005 at 12:51:53PM +0100, Robert Watson wrote: > It looks like if_xl is not properly acquiring Giant when entering the > network stack when running with debug.mpsafenet=0. It should be calling > NET_LOCK_GIANT() in the task queue before calling if_input(). Gleb Smirnoff provided me with this patch which I am testing now. Things seem better...... Index: if_xl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_xl.c,v retrieving revision 1.190 diff -u -r1.190 if_xl.c --- if_xl.c 10 Jun 2005 16:49:23 -0000 1.190 +++ if_xl.c 13 Jul 2005 13:27:36 -0000 @@ -2100,9 +2100,11 @@ { struct xl_softc *sc = (struct xl_softc *)arg; + NET_LOCK_GIANT(); XL_LOCK(sc); xl_rxeof(sc); XL_UNLOCK(sc); + NET_UNLOCK_GIANT(); } /* -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 18:12:05 2005 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 8E02016A41C for ; Wed, 13 Jul 2005 18:12:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C1243D48 for ; Wed, 13 Jul 2005 18:12:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 13 Jul 2005 14:26:11 -0400 From: John Baldwin To: Mike Tancsa Date: Wed, 13 Jul 2005 14:09:39 -0400 User-Agent: KMail/1.8 References: <70e8236f05070208212e36c375@mail.gmail.com> <200507121628.40539.jhb@FreeBSD.org> <6.2.1.2.0.20050713093748.067b8a88@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050713093748.067b8a88@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507131409.39988.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr 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, 13 Jul 2005 18:12:05 -0000 On Wednesday 13 July 2005 09:38 am, Mike Tancsa wrote: > At 04:28 PM 12/07/2005, John Baldwin wrote: > >That does sort of help. Can you try commenting out the call to > >ioapic_setup_mixed_mode() in the sys/i386/i386/mptable.c file and try > > booting with ACPI disabled (but APIC on) and see if it still works ok? > > Yup, > Still boots just fine. Ok. Back on 6, can you try editing sys/i386/i386/io_apic.c and in the function ioapic_set_extint(), change the line that reads: io->io_pins[pin].io_masked = 1; to set the masked variable to 0 instead? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 18:12:05 2005 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 9B33D16A41F for ; Wed, 13 Jul 2005 18:12:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F2743D49 for ; Wed, 13 Jul 2005 18:12:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 13 Jul 2005 14:26:11 -0400 From: John Baldwin To: Harry Coin Date: Wed, 13 Jul 2005 14:11:58 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> <4.3.2.7.2.20050712155231.01f8d488@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050712155231.01f8d488@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507131411.59495.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Nate Lawson Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 13 Jul 2005 18:12:05 -0000 On Tuesday 12 July 2005 05:08 pm, Harry Coin wrote: > John, > > Seems pulling my little orange out of the pyramid made the rest tumble! > > FWIW, apropos your > > "(ACPI only enumerates built-in hardware like COM ports, etc. It doesn't > enumerate ISA PnP cards)." > > I'm fairly sure there are non PNP sound chips built on some motherboards in > a fashion not different than the com ports. I'm guessing the line you had > me zap might have been put in for that. In the mss case though those would attach to pnpmss, not mss. :) Most of the integrated sound chips nowadays are PCI devices, too, not ISA-like devices. > Unless you need anything more, I'm going to move on to making the mixer > register mapping actually match the input side of the sound chips (only the > PCM / line out register maps are correct in mss.c). > > Then on to figure out why the midi and FM synthesizer logical devices don't > probe for the CS4236B. Go for it! > Could someone give me a URL regarding instructions on how to submit more > than trivial changes to drivers that fix audio input and have added / > better output device chip support? I think there's notes in the handbook about how to generate patche with diff. Probably easiest is to cvsup the CVS repository and check out a separate copy of src/sys and do your work in that branch. You can then use 'cvs diff' to generate a patch. The best list for sound patches is probably multimedia@FreeBSD.org. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 18:17:56 2005 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 A168E16A41C; Wed, 13 Jul 2005 18:17:56 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2615243D4C; Wed, 13 Jul 2005 18:17:56 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 13 Jul 2005 14:32:01 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 13 Jul 2005 14:18:00 -0400 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> In-Reply-To: <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507131418.01991.jhb@FreeBSD.org> Cc: Kenneth Culver , Brett Wildermoth , freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 13 Jul 2005 18:17:56 -0000 On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > Quoting Brett Wildermoth : > > To all my fellow FreeBSD users, > > > > I assume I am not the only one who is in this predicament. I have just > > bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get > > everything bar the network and X to work, with 6.0 I can get the network > > to work also. However no matter what I do I can't get X to work. > > > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They > > make one for > > Linux x86-64 and one for FreeBSD-x86. > > > > Perhaps would could all post a message on nvforum. I see some people > > already have..... > > > > Perhaps NVIDIA think FreeBSD is just a hobby OS...... > > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just > post that > you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 19:09:42 2005 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 8CB4D16A41C for ; Wed, 13 Jul 2005 19:09:42 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [84.234.16.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0329743D48 for ; Wed, 13 Jul 2005 19:09:41 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.51 (FreeBSD)) id 1Dsmbv-000BCD-NP for freebsd-current@freebsd.org; Wed, 13 Jul 2005 20:09:35 +0100 Date: Wed, 13 Jul 2005 20:09:35 +0100 From: Tim Bishop To: freebsd-current@freebsd.org Message-ID: <20050713190935.GA42969@carrick.bishnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.9i X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.591, required 5, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60, TW_BF 0.08, TW_EB 0.08, TW_KD 0.08, TW_XD 0.08) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net Subject: Panic in gv_init_td on RELENG_6 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, 13 Jul 2005 19:09:42 -0000 [I assume -current is still OK for RELENG_6?] Just had a panic on RELENG_6 with gvinum. I created a RAID5 array, and it was listed as down. I tried to start it and the following happened on the console: GEOM_VINUM: plex u1.p0 state change: down -> degraded GEOM_VINUM: plex u1.p0 state change: degraded -> down panic: gv_init_td: NULL gp cpuid = 0 KDB: enter: panic [thread pid 624 tid 100085 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 624 tid 100085 td 0xc20c6300 kdb_enter(c0854b84) at kdb_enter+0x2b panic(c217a125,0,df659cec,c0642ccf,c091db80) at panic+0x127 gv_init_td(c213e100,df659d38,c213e100,c2177f34,0) at gv_init_td+0x112 fork_exit(c2177f34,c213e100,df659d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdf659d6c, ebp = 0 --- db> call doadump Dumping 639 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 639MB (163568 pages) 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok Dump complete = 0xf db> reset I took a look at the dump, but I can't see anything obviously helpful. I'm guessing the useful bit is in frames 11 to 14. Please advise if there is anything further I can do. I seem to be able to replicate this easily. kgdb: kvm_read: invalid address (0xc1bff900) kgdb: kvm_read: invalid address (0xc1bff780) kgdb: kvm_read: invalid address (0xc1bff600) kgdb: kvm_read: invalid address (0xc1bff480) kgdb: kvm_read: invalid address (0xc1bff300) kgdb: kvm_read: invalid address (0xc1bff180) kgdb: kvm_read: invalid address (0xc1bffd80) kgdb: kvm_read: invalid address (0xc1bffc00) kgdb: kvm_read: invalid address (0xc1bffa80) kgdb: kvm_read: invalid address (0xc1bff000) [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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0468e13 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xdf659b1c "H\233eß,õ|À4\233eß8\233eß\220\a") at /usr/src/sys/ddb/db_command.c:489 #2 0xc0468c18 in db_command (last_cmdp=0xc0902a84, cmd_table=0x0, aux_cmd_tablep=0xc0880068, aux_cmd_tablep_end=0xc0880084) at /usr/src/sys/ddb/db_command.c:349 #3 0xc0468ce0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc046a881 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0649a9c in kdb_trap (type=3, code=0, tf=0xdf659c60) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc07ec5fc in trap (frame= {tf_fs = -547028984, tf_es = -1067188184, tf_ds = -1065025496, tf_edi = -1038638811, tf_esi = 1, tf_ebp = -546988896, tf_isp = -546988916, tf_ebx = -546988852, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067149309, tf_cs = 32, tf_eflags = 662, tf_esp = -546988864, tf_ss = -1067246597}) at /usr/src/sys/i386/i386/trap.c:600 #7 0xc07da09a in calltrap () at /usr/src/sys/i386/i386/exception.s:137 #8 0xdf650008 in ?? () #9 0xc0640028 in link_elf_load_file (cls=0xc0854b84, filename=0x100
, result=0x0) at /usr/src/sys/kern/link_elf.c:640 #10 0xc0631bfb in panic (fmt=0x296
) at /usr/src/sys/kern/kern_shutdown.c:537 #11 0xc2178046 in ?? () #12 0xc217a125 in ?? () #13 0x00000000 in ?? () #14 0xdf659cec in ?? () #15 0xc0642ccf in critical_exit () at kern_switch.c:610 #16 0xc061eb40 in fork_exit (callout=0, arg=0xc213e100, frame=0xdf659d38) at /usr/src/sys/kern/kern_fork.c:789 #17 0xc07da0fc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:206 (kgdb) -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 19:12:22 2005 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 8770F16A41C for ; Wed, 13 Jul 2005 19:12:22 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from imap1u.univie.ac.at (imap1.unet.univie.ac.at [131.130.1.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C0343D45 for ; Wed, 13 Jul 2005 19:12:21 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap1u.univie.ac.at (8.12.10/8.12.10) with ESMTP id j6DJC3hP041672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2005 21:12:05 +0200 (CEST) Date: Wed, 13 Jul 2005 21:12:03 +0200 (CEST) From: Lukas Ertl To: Tim Bishop In-Reply-To: <20050713190935.GA42969@carrick.bishnet.net> Message-ID: <20050713211152.G576@korben.prv.univie.ac.at> References: <20050713190935.GA42969@carrick.bishnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4248; Body=2 Fuz1=2 Fuz2=2 Cc: freebsd-current@FreeBSD.org Subject: Re: Panic in gv_init_td on RELENG_6 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, 13 Jul 2005 19:12:22 -0000 On Wed, 13 Jul 2005, Tim Bishop wrote: > Just had a panic on RELENG_6 with gvinum. I created a RAID5 array, > and it was listed as down. I tried to start it and the following > happened on the console: Please use the info at to get a usable backtrace, thanks. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 21:08:16 2005 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 338B916A41C for ; Wed, 13 Jul 2005 21:08:16 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE3BE43D4C for ; Wed, 13 Jul 2005 21:08:15 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 1D81D1CCD6; Thu, 14 Jul 2005 09:08:11 +1200 (NZST) Date: Thu, 14 Jul 2005 09:08:11 +1200 From: Andrew Thompson To: Niki Denev Message-ID: <20050713210811.GA60866@heff.fud.org.nz> References: <200507121026.16664.nike_d@cytexbg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507121026.16664.nike_d@cytexbg.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: add a few informative printfs to if_bridge.c? 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, 13 Jul 2005 21:08:16 -0000 On Tue, Jul 12, 2005 at 10:26:16AM +0300, Niki Denev wrote: > Hello all, > > So, i have a proposition to add some informative printfs to if_bridge code, > because returning "Invalid argument" is not so self explanatory, especially > in the wrong MTU case. I think that most of the returns in bridge_ioctl_add(), > could benefit from additional printf with more information. > What do you think? > Ive added a message for the incorrect MTU case and also relaxed the requirements a little. The bridge will take the MTU of the first member interface rather than being hardcoded at 1500, all members are still required to have the exact same MTU. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 21:31:44 2005 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 9362116A41C; Wed, 13 Jul 2005 21:31:44 +0000 (GMT) (envelope-from sclements@linkline.com) Received: from smtp2.linkline.com (smtp2.linkline.com [64.30.215.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EF1643D46; Wed, 13 Jul 2005 21:31:44 +0000 (GMT) (envelope-from sclements@linkline.com) Received: from [127.0.0.1] (host-66-59-225-129.lcinet.net [66.59.225.129]) by smtp2.linkline.com (Postfix) with ESMTP id 59808BB; Wed, 13 Jul 2005 14:31:40 -0700 (PDT) Message-ID: <42D5883E.7090909@linkline.com> Date: Wed, 13 Jul 2005 14:31:42 -0700 From: Samuel Clements User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Wildermoth References: <200507131933.12318.B.Wildermoth@griffith.edu.au> In-Reply-To: <200507131933.12318.B.Wildermoth@griffith.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 13 Jul 2005 21:31:44 -0000 Brett Wildermoth wrote: > To all my fellow FreeBSD users, > > I assume I am not the only one who is in this predicament. I have just bought > seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar I realize to some it may be splitting hairs, but do you mean 'PCI Express' instead of 'PCI-X'. One is 64bit/100 (or 133mhz) PCI commonly used for RAID and network controllers, the other is a redesign of the PCI architecture - and is commonly exposed as an interface for video cards. -Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 21:41:15 2005 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 334F816A41C; Wed, 13 Jul 2005 21:41:15 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from cardea.itc.griffith.edu.au (cardea.itc.griffith.edu.au [132.234.248.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC24443D4C; Wed, 13 Jul 2005 21:41:14 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [132.234.7.11] (helo=pc083745.me.gu.edu.au) by cardea.itc.griffith.edu.au with esmtp (Exim 4.24) id 1Dsoyd-0005Wq-Ap; Thu, 14 Jul 2005 07:41:11 +1000 From: Brett Wildermoth Organization: Griffith University To: Samuel Clements Date: Thu, 14 Jul 2005 07:41:03 +1000 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <42D5883E.7090909@linkline.com> In-Reply-To: <42D5883E.7090909@linkline.com> X-Face: #"DtK&7^5P|u6yesiHW<_YTpWs>V8v|7J%W[b6O~\9emUr??J}9>jRP`j"a7jaE,2>=?utf-8?q?V=2E=60k=0A=09dX53n=3B0L=3Bz=5BY*=5D80/iO=26?= Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brett Wildermoth List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2005 21:41:15 -0000 --nextPart1254970.nQsYcTmkmj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Jul 2005 07:31 am, Samuel Clements wrote: > Brett Wildermoth wrote: > > To all my fellow FreeBSD users, > > > > I assume I am not the only one who is in this predicament. I have just > > bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get > > everything bar > > I realize to some it may be splitting hairs, Yes > but do you mean 'PCI Express' instead of 'PCI-X'.=20 PCI Express > One is 64bit/100 (or 133mhz) PCI commonly=20 > used for RAID and network controllers, the other is a redesign of the > PCI architecture - and is commonly exposed as an interface for video card= s. > -Sam =2D-=20 =2D------------------------------------------------------------------ Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart1254970.nQsYcTmkmj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1YpzbSsZm/bQWSwRAq3ZAKCWbCILA3PPa7O381U5f2FYbXIhfwCeKX2H QtM46QuV/WfssSc6XW+4l5s= =i3AZ -----END PGP SIGNATURE----- --nextPart1254970.nQsYcTmkmj-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 21:43:16 2005 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 D3F1816A41C; Wed, 13 Jul 2005 21:43:16 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from cardea.itc.griffith.edu.au (cardea.itc.griffith.edu.au [132.234.248.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E61443D45; Wed, 13 Jul 2005 21:43:16 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [132.234.7.11] (helo=pc083745.me.gu.edu.au) by cardea.itc.griffith.edu.au with esmtp (Exim 4.24) id 1Dsp0c-0005ai-5M; Thu, 14 Jul 2005 07:43:14 +1000 From: Brett Wildermoth Organization: Griffith University To: freebsd-stable@freebsd.org Date: Thu, 14 Jul 2005 07:43:10 +1000 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> <200507131418.01991.jhb@FreeBSD.org> In-Reply-To: <200507131418.01991.jhb@FreeBSD.org> X-Face: #"DtK&7^5P|u6yesiHW<_YTpWs>V8v|7J%W[b6O~\9emUr??J}9>jRP`j"a7jaE,2>=?utf-8?q?V=2E=60k=0A=09dX53n=3B0L=3Bz=5BY*=5D80/iO=26?= Cc: owner-freebsd-stable@freebsd.org, Kenneth Culver , freebsd-current@freebsd.org Subject: Re: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brett Wildermoth List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2005 21:43:17 -0000 --nextPart1656994.kcMlzdAqcK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org wrote: > On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > > Quoting Brett Wildermoth : > > > To all my fellow FreeBSD users, > > > > > > I assume I am not the only one who is in this predicament. I have just > > > bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get > > > everything bar the network and X to work, with 6.0 I can get the > > > network to work also. However no matter what I do I can't get X to > > > work. > > > > > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They > > > make one for > > > Linux x86-64 and one for FreeBSD-x86. > > > > > > Perhaps would could all post a message on nvforum. I see some people > > > already have..... > > > > > > Perhaps NVIDIA think FreeBSD is just a hobby OS...... > > > > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just > > post that > > you're pissed about it like the rest of us are... maybe they'll > > reconsider. > > Not true. FreeBSD's kernel doesn't provide some things needed for an amd= 64 > driver to be feasible. Like what???? what are these features? and if they are really important why= =20 aren't they on the cards to be included into FreeBSD...... =2D-=20 =2D------------------------------------------------------------------ Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart1656994.kcMlzdAqcK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1YrvbSsZm/bQWSwRAgwjAJoD/wBad8aFOrJ6pEdPIrPe+iywsQCdGNLY Xjao1ufA3/piZfqgffqWqRY= =Supy -----END PGP SIGNATURE----- --nextPart1656994.kcMlzdAqcK-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 00:16:09 2005 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 7811E16A41C for ; Thu, 14 Jul 2005 00:16:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4976A43D45 for ; Thu, 14 Jul 2005 00:16:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DsrOa-000NdY-Ml; Thu, 14 Jul 2005 00:16:08 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DsrOa-0005wH-4D; Wed, 13 Jul 2005 14:16:08 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17109.44743.624128.339103@roam.psg.com> Date: Wed, 13 Jul 2005 14:16:07 -1000 To: FreeBSD Current Subject: Computed sack_bytes_retransmitted (x) not the same as cached value 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, 14 Jul 2005 00:16:09 -0000 kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value (2920) kernel: tcp_sack_output: Computed sack_bytes_retransmitted (2920) not the same as cached value (4380) kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value (2920) kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value (2920) FreeBSD x 6.0-CURRENT FreeBSD 6.0-CURRENT #9: Sun Jun 5 19:36:54 GMT 2005 root:/usr/obj/usr/src/sys/G i386 this is first time i have seen this. randy From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 00:26:54 2005 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 43EF216A41C for ; Thu, 14 Jul 2005 00:26:54 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: from web31807.mail.mud.yahoo.com (web31807.mail.mud.yahoo.com [68.142.207.70]) by mx1.FreeBSD.org (Postfix) with SMTP id DA3EA43D48 for ; Thu, 14 Jul 2005 00:26:53 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 73682 invoked by uid 60001); 14 Jul 2005 00:26:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4nrd9zKHn9d7QkOKu9QmFfv7lqEM5+Lqd7iTK6eujsOKczuxGElqtxaOVwxqsXP0l6NcsdVTBhyshv4S9CzwvcArHRv3TFU1LJCIJ8wshRdqOG06qagPwW3mG3lq/ZN6i13RgCiPgFjjGWbwJYW3an/RZlcuLXAQ+dqovAO3q5w= ; Message-ID: <20050714002652.73680.qmail@web31807.mail.mud.yahoo.com> Received: from [64.168.22.169] by web31807.mail.mud.yahoo.com via HTTP; Wed, 13 Jul 2005 17:26:52 PDT Date: Wed, 13 Jul 2005 17:26:52 -0700 (PDT) From: Mohan Srinivasan To: Randy Bush , FreeBSD Current In-Reply-To: <17109.44743.624128.339103@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Computed sack_bytes_retransmitted (x) not the same as cached value 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, 14 Jul 2005 00:26:54 -0000 This was fixed on June 6. Can you pick up the latest changes ? There were other TCP and SACK fixes checked in since Jun 5. This is the change you need for the bug you report. Revision 1.22 / (download) - annotate - [select for diffs], Mon Jun 6 19:46:53 2005 UTC (5 weeks, 2 days ago) by ps Branch: MAIN Changes since 1.21: +9 -4 lines Diff to previous 1.21 (colored) Fix for a bug in the change that walks the scoreboard backwards from the tail (in tcp_sack_option()). The bug was caused by incorrect accounting of the retransmitted bytes in the sackhint. Reported by: Kris Kennaway. Submitted by: Noritoshi Demizu. mohan --- Randy Bush wrote: > kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value > (2920) > kernel: tcp_sack_output: Computed sack_bytes_retransmitted (2920) not the same as cached value > (4380) > kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value > (2920) > kernel: tcp_sack_output: Computed sack_bytes_retransmitted (1460) not the same as cached value > (2920) > > FreeBSD x 6.0-CURRENT FreeBSD 6.0-CURRENT #9: Sun Jun 5 19:36:54 GMT 2005 > root:/usr/obj/usr/src/sys/G i386 > > this is first time i have seen this. > > randy > > _______________________________________________ > 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 Thu Jul 14 00:29:26 2005 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 BFECA16A41C for ; Thu, 14 Jul 2005 00:29:26 +0000 (GMT) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.FreeBSD.org (Postfix) with SMTP id 68BB143D45 for ; Thu, 14 Jul 2005 00:29:26 +0000 (GMT) (envelope-from simon@optinet.com) Received: (qmail 1780 invoked by uid 110); 14 Jul 2005 00:29:25 -0000 Received: from ool-18ba9d5e.dyn.optonline.net (HELO win2kpc1) (simon%optinet.com@24.186.157.94) by cobra.acceleratedweb.net with SMTP; 14 Jul 2005 00:29:25 -0000 From: "Simon" To: "freebsd-current@freebsd.org" Date: Wed, 13 Jul 2005 19:49:39 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2661) For Windows 2000 (5.0.2195;4) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20050714002926.68BB143D45@mx1.FreeBSD.org> Subject: SES driver / getencstat example 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, 14 Jul 2005 00:29:26 -0000 Hello Folks, Something was changed in 5.4 and now example in: /usr/share/examples/ses/getencstat no longer works. When I try to execute it, I get: SESIOC_GETNOBJ: Bad address Does anyone know how to fix this so I could get getencstat working again? The source for this utility is very small, will someone take a look please. Thanks! -Simon From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 06:51:28 2005 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 8CE8216A41C for ; Thu, 14 Jul 2005 06:51:28 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DEB643D49 for ; Thu, 14 Jul 2005 06:51:28 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j6E6nlj7010793 for ; Wed, 13 Jul 2005 23:49:47 -0700 (PDT) Date: Thu, 14 Jul 2005 15:49:46 +0900 Message-ID: From: gnn@freebsd.org To: freebsd-current@freebsd.org References: User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Patch for routing socket bug, please review and test... 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, 14 Jul 2005 06:51:28 -0000 Hi Folks, This is a proposed fix for: http://www.freebsd.org/cgi/query-pr.cgi?pr=%0D%0A82974 Please review, test and let me know about this patch. I would like to commit it soon. Courtesy of OpenBSD, I have taken their changes and modified them to fit our kernel. Thanks, George Index: rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.123 diff -u -r1.123 rtsock.c --- rtsock.c 9 Jun 2005 12:20:50 -0000 1.123 +++ rtsock.c 11 Jul 2005 13:37:38 -0000 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * @(#)rtsock.c 8.7 (Berkeley) 10/12/95 - * $FreeBSD: src/sys/net/rtsock.c,v 1.123 2005/06/09 12:20:50 harti Exp $ + * $FreeBSD$ */ #include @@ -434,6 +434,25 @@ RT_LOCK(rt); RT_ADDREF(rt); + /* + * Fix for PR: 82974 + * + * RTM_CHANGE/LOCK need a perfect match, rn_lookup() + * returns a perfect match in case a netmask is + * specified. For host routes only a longest prefix + * match is returned so it is necessary to compare the + * existence of the netmaks. If both have a netmask + * rnh_lookup() did a perfect match and if non of them + * have a netmask both are host routes which is also a + * perfect match. + */ + + if (rtm->rtm_type != RTM_GET && + (!rt_mask(rt) != !info.rti_info[RTAX_NETMASK])) { + RT_UNLOCK(rt); + senderr(ESRCH); + } + switch(rtm->rtm_type) { case RTM_GET: _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 09:08:10 2005 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 9837516A41C; Thu, 14 Jul 2005 09:08:10 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F5C43D45; Thu, 14 Jul 2005 09:08:06 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id j6E97rSH077048; Thu, 14 Jul 2005 10:07:53 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org, Brett Wildermoth Date: Thu, 14 Jul 2005 10:07:50 +0100 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507131418.01991.jhb@FreeBSD.org> <200507140743.11021.B.Wildermoth@griffith.edu.au> In-Reply-To: <200507140743.11021.B.Wildermoth@griffith.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507141007.51665.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Thu, 14 Jul 2005 10:07:55 +0100 (BST) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/977/Tue Jul 12 23:53:40 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: owner-freebsd-stable@freebsd.org, Kenneth Culver , freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 14 Jul 2005 09:08:10 -0000 On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: > On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org wrote: > > On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > > > Quoting Brett Wildermoth : > > > > To all my fellow FreeBSD users, > > > > > > > > I assume I am not the only one who is in this predicament. I > > > > have just bought seven AMD 64s with NVIDIA PCI-X graphics. With > > > > 5.4 I can get everything bar the network and X to work, with > > > > 6.0 I can get the network to work also. However no matter what > > > > I do I can't get X to work. > > > > > > > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. > > > > They make one for > > > > Linux x86-64 and one for FreeBSD-x86. > > > > > > > > Perhaps would could all post a message on nvforum. I see some > > > > people already have..... > > > > > > > > Perhaps NVIDIA think FreeBSD is just a hobby OS...... > > > > > > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. > > > Just post that > > > you're pissed about it like the rest of us are... maybe they'll > > > reconsider. > > > > Not true. FreeBSD's kernel doesn't provide some things needed for > > an amd64 driver to be feasible. > > Like what???? what are these features? and if they are really > important why aren't they on the cards to be included into > FreeBSD...... There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 09:17:49 2005 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 19B8916A41C for ; Thu, 14 Jul 2005 09:17:49 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CA0143D58 for ; Thu, 14 Jul 2005 09:17:47 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 64756 invoked by uid 1005); 14 Jul 2005 09:17:46 -0000 Received: from rainer@ultra-secure.de by bsd.ultra-secure.de by uid 89 with qmail-scanner-1.22 (clamdscan: 0.85. spamassassin: 2.64. Clear:RC:1(213.196.191.65):. Processed in 0.03074 secs); 14 Jul 2005 09:17:46 -0000 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Jul 2005 09:17:46 -0000 Message-ID: <42D62DB7.5040301@ultra-secure.de> Date: Thu, 14 Jul 2005 11:17:43 +0200 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Wildermoth References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> <200507131418.01991.jhb@FreeBSD.org> <200507140743.11021.B.Wildermoth@griffith.edu.au> In-Reply-To: <200507140743.11021.B.Wildermoth@griffith.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 14 Jul 2005 09:17:49 -0000 Brett Wildermoth wrote: >On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org wrote: > > >>On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: >> >> >>>Quoting Brett Wildermoth : >>> >>> >>>>To all my fellow FreeBSD users, >>>> >>>>I assume I am not the only one who is in this predicament. I have just >>>>bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get >>>>everything bar the network and X to work, with 6.0 I can get the >>>>network to work also. However no matter what I do I can't get X to >>>>work. >>>> >>>>Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They >>>>make one for >>>>Linux x86-64 and one for FreeBSD-x86. >>>> >>>>Perhaps would could all post a message on nvforum. I see some people >>>>already have..... >>>> >>>>Perhaps NVIDIA think FreeBSD is just a hobby OS...... >>>> >>>> >>>Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just >>>post that >>>you're pissed about it like the rest of us are... maybe they'll >>>reconsider. >>> >>> >>Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 >>driver to be feasible. >> >> > >Like what???? what are these features? and if they are really important why >aren't they on the cards to be included into FreeBSD...... > > > I think this has come up before (multiple times...almost a FAQ-candidate IMO). AFAICR, the changes are not in CURRENT, yet, but there are plans to integrate them in the future. Can't you just run those AMD-boxes in i386-mode, for the time being? BTW: wouldn't it be good to note things like these in the "errata"-section in the handbook? The port itself is marked as "ONLY_FOR_ARCHS= i386". But usually, by the time one reaches that stage, the hardware has already been bought ;-) Do all other Xorg-drivers work on AMD64? cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:02:22 2005 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 D9E9A16A41F; Thu, 14 Jul 2005 10:02:21 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A21643D48; Thu, 14 Jul 2005 10:02:20 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [192.168.1.6] (211.27.187.95) by smtp02.syd.iprimus.net.au (7.2.060.1) id 42A0B1C100DA7AA6; Thu, 14 Jul 2005 20:02:05 +1000 From: Brett Wildermoth Organization: Griffith University To: Rainer Duffner Date: Thu, 14 Jul 2005 20:00:45 +1000 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507140743.11021.B.Wildermoth@griffith.edu.au> <42D62DB7.5040301@ultra-secure.de> In-Reply-To: <42D62DB7.5040301@ultra-secure.de> X-Face: #"DtK&7^5P|u6yesiHW<_YTpWs>V8v|7J%W[b6O~\9emUr??J}9>jRP`j"a7jaE,2>=?utf-8?q?V=2E=60k=0A=09dX53n=3B0L=3Bz=5BY*=5D80/iO=26?= Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brett Wildermoth List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 10:02:22 -0000 --nextPart1242507.ZcnZNn1fVI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Jul 2005 07:17 pm, Rainer Duffner wrote: > Brett Wildermoth wrote: > >On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org wrote: > >>On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > >>>Quoting Brett Wildermoth : > >>>>To all my fellow FreeBSD users, > >>>> > >>>>I assume I am not the only one who is in this predicament. I have just > >>>>bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get > >>>>everything bar the network and X to work, with 6.0 I can get the > >>>>network to work also. However no matter what I do I can't get X to > >>>>work. > >>>> > >>>>Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They > >>>>make one for > >>>>Linux x86-64 and one for FreeBSD-x86. > >>>> > >>>>Perhaps would could all post a message on nvforum. I see some people > >>>>already have..... > >>>> > >>>>Perhaps NVIDIA think FreeBSD is just a hobby OS...... > >>> > >>>Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just > >>>post that > >>>you're pissed about it like the rest of us are... maybe they'll > >>>reconsider. > >> > >>Not true. FreeBSD's kernel doesn't provide some things needed for an > >> amd64 driver to be feasible. > > > >Like what???? what are these features? and if they are really important > > why aren't they on the cards to be included into FreeBSD...... > > I think this has come up before (multiple times...almost a FAQ-candidate > IMO). > AFAICR, the changes are not in CURRENT, yet, but there are plans to > integrate them in the future. > > Can't you just run those AMD-boxes in i386-mode, for the time being? > > BTW: wouldn't it be good to note things like these in the > "errata"-section in the handbook? > The port itself is marked as "ONLY_FOR_ARCHS=3D i386". But usually, by the > time one reaches that stage, the hardware has already been bought ;-) > > Do all other Xorg-drivers work on AMD64? > > > > > cheers, > Rainer The card is too new to be supported by the nv 2D driver supplied in Xorg. A= ny=20 card supported by the standard Xorg under FreeBSD x86 is also supported und= er=20 =46reeBSD x86-64 with the same capabilities. Brett =2D-=20 =2D------------------------------------------------------------------ Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart1242507.ZcnZNn1fVI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1jfObSsZm/bQWSwRAmtLAJ9uvRcI7HVouz7XtppZgACQrQwg5QCaAlWq 6GeWnYspgbPmvUcfiHtKTQg= =nNY3 -----END PGP SIGNATURE----- --nextPart1242507.ZcnZNn1fVI-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:08:17 2005 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 7A6FC16A41C; Thu, 14 Jul 2005 10:08:17 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0630743D46; Thu, 14 Jul 2005 10:08:16 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [192.168.1.6] (211.27.187.95) by smtp01.syd.iprimus.net.au (7.2.060.1) id 42A0AD7E00DAAC1B; Thu, 14 Jul 2005 20:08:14 +1000 From: Brett Wildermoth Organization: Griffith University To: freebsd-current@freebsd.org Date: Thu, 14 Jul 2005 20:06:54 +1000 User-Agent: KMail/1.8 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507140743.11021.B.Wildermoth@griffith.edu.au> <200507141007.51665.dfr@nlsystems.com> In-Reply-To: <200507141007.51665.dfr@nlsystems.com> X-Face: #"DtK&7^5P|u6yesiHW<_YTpWs>V8v|7J%W[b6O~\9emUr??J}9>jRP`j"a7jaE,2>=?utf-8?q?V=2E=60k=0A=09dX53n=3B0L=3Bz=5BY*=5D80/iO=26?= Cc: owner-freebsd-stable@freebsd.org, Kenneth Culver , freebsd-stable@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brett Wildermoth List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 10:08:17 -0000 --nextPart2928488.GR0qnEcnEU Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Jul 2005 07:07 pm, owner-freebsd-current@freebsd.org wrote: > On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: > > On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org wrote: > > > On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > > > > Quoting Brett Wildermoth : > > > > > To all my fellow FreeBSD users, > > > > > > > > > > I assume I am not the only one who is in this predicament. I > > > > > have just bought seven AMD 64s with NVIDIA PCI-X graphics. With > > > > > 5.4 I can get everything bar the network and X to work, with > > > > > 6.0 I can get the network to work also. However no matter what > > > > > I do I can't get X to work. > > > > > > > > > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. > > > > > They make one for > > > > > Linux x86-64 and one for FreeBSD-x86. > > > > > > > > > > Perhaps would could all post a message on nvforum. I see some > > > > > people already have..... > > > > > > > > > > Perhaps NVIDIA think FreeBSD is just a hobby OS...... > > > > > > > > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. > > > > Just post that > > > > you're pissed about it like the rest of us are... maybe they'll > > > > reconsider. > > > > > > Not true. FreeBSD's kernel doesn't provide some things needed for > > > an amd64 driver to be feasible. > > > > Like what???? what are these features? and if they are really > > important why aren't they on the cards to be included into > > FreeBSD...... > > There are a few missing VM features that any high-performance graphics > card driver would require for decent performance with PCI Express. John > is working on adding those features - have patience. > _______________________________________________ > 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" I guess these feature are provided in FreeBSD x86, as a NVIDIA graphics dri= ver=20 is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem different to=20 =46reeBSD x86. Is the VM subsystem that low-level????? (Pardon my ignorance, have quite got around to reading the FreeBSD kernel b= ook=20 the publisher comped me yet) =2D-=20 =2D------------------------------------------------------------------ Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart2928488.GR0qnEcnEU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1jk+bSsZm/bQWSwRAiC2AJ46rPKW7Tc136hH8pWE54i7OkR69wCgjYf7 NTf8BEO4dZ/PHCcAYtxI6Zk= =G2wW -----END PGP SIGNATURE----- --nextPart2928488.GR0qnEcnEU-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:11:38 2005 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 DE98316A41C for ; Thu, 14 Jul 2005 10:11:38 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 2722A43D46 for ; Thu, 14 Jul 2005 10:11:37 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 14 Jul 2005 11:11:36 +0100 (BST) Date: Thu, 14 Jul 2005 11:11:36 +0100 From: David Malone To: Simon Message-ID: <20050714101136.GA38693@walton.maths.tcd.ie> References: <20050714002926.68BB143D45@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714002926.68BB143D45@mx1.FreeBSD.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: "freebsd-current@freebsd.org" Subject: Re: SES driver / getencstat example 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, 14 Jul 2005 10:11:39 -0000 On Wed, Jul 13, 2005 at 07:49:39PM -0400, Simon wrote: > Something was changed in 5.4 and now example in: > /usr/share/examples/ses/getencstat > > no longer works. When I try to execute it, I get: > > SESIOC_GETNOBJ: Bad address > > Does anyone know how to fix this so I could get getencstat working again? I think the commit below might have fixed this in -current, but it hasn't made it back to 5-STABLE yet. David. peter 2005-06-30 00:19:08 UTC FreeBSD src repository Modified files: sys/fs/procfs procfs_ioctl.c sys/kern sys_generic.c Log: Conditionally weaken sys_generic.c rev 1.136 to allow certain dubious ioctl numbers in backwards compatability mode. eg: an IOC_IN ioctl with a size of zero. Traditionally this was what you did before IOC_VOID existed, and we had some established users of this in the tree, namely procfs. Certain 3rd party drivers with binary userland components also have this too. This is necessary to have 4.x and 5.x binaries use these ioctl's. We found this at work when trying to run 4.x binaries. Approved by: re Revision Changes Path 1.11 +14 -0 src/sys/fs/procfs/procfs_ioctl.c 1.145 +7 -2 src/sys/kern/sys_generic.c From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:15:15 2005 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 2EE4216A41C; Thu, 14 Jul 2005 10:15:15 +0000 (GMT) (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 098CD43D46; Thu, 14 Jul 2005 10:15:11 +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.3/8.13.3) with ESMTP id j6EAF77w084460; Thu, 14 Jul 2005 14:15:08 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j6EAF7NF084455; Thu, 14 Jul 2005 14:15:07 +0400 (MSD) (envelope-from yar) Date: Thu, 14 Jul 2005 14:15:07 +0400 From: Yar Tikhiy To: current@freebsd.org Message-ID: <20050714101507.GA82562@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: peter@freebsd.org Subject: Build failure in procfs module 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, 14 Jul 2005 10:15:15 -0000 Hi folks, I ran into a problem that might be triggered by Peter's recent changes to procfs. Namely, the buildworld procedure would fail in the procfs module if MODULES_WITH_WORLD were set. I noticed it first in CURRENT and then tested it in a clean environment by building a freshly CVSup'd RELENG_6 on a freshly installed 5.4-RELEASE, with MODULES_WITH_WORLD set. I think it's a route of upgrading quite a few people will follow. Here's the diagnostics: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ===> sys/modules/procfs (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/obj/usr/src/tmp/usr/include /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ctl.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_dbregs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_fpregs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ioctl.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_map.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_mem.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_note.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_regs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_rlimit.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_status.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_type.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_dbregs.c:46:24: opt_compat.h: No such file or directory /usr/src/sys/modules/procfs/../../fs/procfs/procfs_fpregs.c:40:24: opt_compat.h: No such file or directory /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ioctl.c:31:24: opt_compat.h: No such file or directory /usr/src/sys/modules/procfs/../../fs/procfs/procfs_map.c:38:24: opt_compat.h: No such file or directory /usr/src/sys/modules/procfs/../../fs/procfs/procfs_regs.c:40:24: opt_compat.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/procfs. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:44:34 2005 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 29F8316A41C; Thu, 14 Jul 2005 10:44:34 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 583CE43D48; Thu, 14 Jul 2005 10:44:33 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id j6EAiTuL040682; Thu, 14 Jul 2005 11:44:29 +0100 (BST) (envelope-from dfr@nlsystems.com) In-Reply-To: <200507142006.54726.B.Wildermoth@griffith.edu.au> References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507140743.11021.B.Wildermoth@griffith.edu.au> <200507141007.51665.dfr@nlsystems.com> <200507142006.54726.B.Wildermoth@griffith.edu.au> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <155B452C-1BEE-4857-B3E0-256BDDBE5FF0@nlsystems.com> Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Thu, 14 Jul 2005 11:44:26 +0100 To: Brett Wildermoth X-Mailer: Apple Mail (2.733) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.qubesoft.com X-Virus-Scanned: ClamAV version 0.86.1, clamav-milter version 0.86 on mail.qubesoft.com X-Virus-Status: Clean Cc: owner-freebsd-stable@freebsd.org, Kenneth Culver , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 14 Jul 2005 10:44:34 -0000 On 14 Jul 2005, at 11:06, Brett Wildermoth wrote: > On Thu, 14 Jul 2005 07:07 pm, owner-freebsd-current@freebsd.org wrote: > >> On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: >> >>> On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org >>> wrote: >>> >>>> On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: >>>> >>>>> Quoting Brett Wildermoth : >>>>> >>>>>> To all my fellow FreeBSD users, >>>>>> >>>>>> I assume I am not the only one who is in this predicament. I >>>>>> have just bought seven AMD 64s with NVIDIA PCI-X graphics. With >>>>>> 5.4 I can get everything bar the network and X to work, with >>>>>> 6.0 I can get the network to work also. However no matter what >>>>>> I do I can't get X to work. >>>>>> >>>>>> Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. >>>>>> They make one for >>>>>> Linux x86-64 and one for FreeBSD-x86. >>>>>> >>>>>> Perhaps would could all post a message on nvforum. I see some >>>>>> people already have..... >>>>>> >>>>>> Perhaps NVIDIA think FreeBSD is just a hobby OS...... >>>>>> >>>>> >>>>> Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. >>>>> Just post that >>>>> you're pissed about it like the rest of us are... maybe they'll >>>>> reconsider. >>>>> >>>> >>>> Not true. FreeBSD's kernel doesn't provide some things needed for >>>> an amd64 driver to be feasible. >>>> >>> >>> Like what???? what are these features? and if they are really >>> important why aren't they on the cards to be included into >>> FreeBSD...... >>> >> >> There are a few missing VM features that any high-performance >> graphics >> card driver would require for decent performance with PCI Express. >> John >> is working on adding those features - have patience. >> _______________________________________________ >> 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" >> > > I guess these feature are provided in FreeBSD x86, as a NVIDIA > graphics driver > is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem > different to > FreeBSD x86. Is the VM subsystem that low-level????? > > (Pardon my ignorance, have quite got around to reading the FreeBSD > kernel book > the publisher comped me yet) Actually I think that the feature we are talking about (PAT) is relevant to both amd64 and i386. Proper support for PAT is required for decent PCI Express performance, as I understand it. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:54:22 2005 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 4699F16A41C for ; Thu, 14 Jul 2005 10:54:22 +0000 (GMT) (envelope-from vasiliuvlad@spymac.com) Received: from smtp2.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91FAC43D4C for ; Thu, 14 Jul 2005 10:54:21 +0000 (GMT) (envelope-from vasiliuvlad@spymac.com) Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf0206.wanadoo.fr (SMTP Server) with ESMTP id B1BD01C001C7 for ; Thu, 14 Jul 2005 12:54:19 +0200 (CEST) Received: from [192.168.2.2] (ASte-Genev-Bois-152-1-16-127.w82-121.abo.wanadoo.fr [82.121.30.127]) by mwinf0206.wanadoo.fr (SMTP Server) with ESMTP id 458EE1C001C6 for ; Thu, 14 Jul 2005 12:54:19 +0200 (CEST) X-ME-UUID: 20050714105419285.458EE1C001C6@mwinf0206.wanadoo.fr From: Vlad Vasiliu To: freebsd-current@freebsd.org Date: Thu, 14 Jul 2005 12:54:02 +0200 User-Agent: KMail/1.8.1 References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507142006.54726.B.Wildermoth@griffith.edu.au> <155B452C-1BEE-4857-B3E0-256BDDBE5FF0@nlsystems.com> In-Reply-To: <155B452C-1BEE-4857-B3E0-256BDDBE5FF0@nlsystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3250945.i3qQhVQJdN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507141254.13401.vasiliuvlad@spymac.com> Subject: Re: AMD64 + Nvidia Display Card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vasiliuvlad@spymac.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, 14 Jul 2005 10:54:22 -0000 --nextPart3250945.i3qQhVQJdN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 14 July 2005 12:44, Doug Rabson wrote: > On 14 Jul 2005, at 11:06, Brett Wildermoth wrote: > > On Thu, 14 Jul 2005 07:07 pm, owner-freebsd-current@freebsd.org wrote: > >> On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: > >>> On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org > >>> > >>> wrote: > >>>> On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > >>>>> Quoting Brett Wildermoth : > >>>>>> To all my fellow FreeBSD users, > >>>>>> > >>>>>> I assume I am not the only one who is in this predicament. I > >>>>>> have just bought seven AMD 64s with NVIDIA PCI-X graphics. With > >>>>>> 5.4 I can get everything bar the network and X to work, with > >>>>>> 6.0 I can get the network to work also. However no matter what > >>>>>> I do I can't get X to work. > >>>>>> > >>>>>> Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. > >>>>>> They make one for > >>>>>> Linux x86-64 and one for FreeBSD-x86. > >>>>>> > >>>>>> Perhaps would could all post a message on nvforum. I see some > >>>>>> people already have..... > >>>>>> > >>>>>> Perhaps NVIDIA think FreeBSD is just a hobby OS...... > >>>>> > >>>>> Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. > >>>>> Just post that > >>>>> you're pissed about it like the rest of us are... maybe they'll > >>>>> reconsider. > >>>> > >>>> Not true. FreeBSD's kernel doesn't provide some things needed for > >>>> an amd64 driver to be feasible. > >>> > >>> Like what???? what are these features? and if they are really > >>> important why aren't they on the cards to be included into > >>> FreeBSD...... > >> > >> There are a few missing VM features that any high-performance > >> graphics > >> card driver would require for decent performance with PCI Express. > >> John > >> is working on adding those features - have patience. > >> _______________________________________________ > >> 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" > > > > I guess these feature are provided in FreeBSD x86, as a NVIDIA > > graphics driver > > is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem > > different to > > FreeBSD x86. Is the VM subsystem that low-level????? > > > > (Pardon my ignorance, have quite got around to reading the FreeBSD > > kernel book > > the publisher comped me yet) > > Actually I think that the feature we are talking about (PAT) is > relevant to both amd64 and i386. Proper support for PAT is required > for decent PCI Express performance, as I understand it. > > _______________________________________________ > 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" What about the nvidia cards on agp? does that need some unavailable stuff too? --nextPart3250945.i3qQhVQJdN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQIVAwUAQtZEVXiG7l5aeBL+AQL/NQ/+JOYqui/ezCph1WYegPi9RnoUdaJEDbI9 WGG2dZs86v3DuH0kOmjS5Wt5CRMQX7R0uhlyhSoxApC26BSNEINVdLqDTy4H1gDO EgTweIjwCqXjZuHd/vmzJJveLCZh8QMVZxSoncG7nqX3nsT05TqEdKsjH574kucY avPiZZ2Yu6tvRF8ueEIQviI0NzQkHnInF87OELu8OXF/kjYfsLcG+Hv0TUddgdYm gln3YHYUcKU6v+iJcqueS0t2nVGkDQrYyEWjRwMLqbSRWnBSXbyK/B/T2uleNEZG g3aIpaEHI6/vG5letVwsEhLScSwXdltqBrCOw3nYgBh4s+T8kIMxe+JBCdbXdLKl l5llZ19kMLFNTeCA220r7tze/5XIqiALHYid84B9tX4PgObGCKKu/L7ypfe1h4wV Nr5IxTOFk6ViQWplDrcZYsMuHo2mbq6+rHYCxYLfb2FBJqL59kYOi6qaRuGqu2x4 cg5dflZh5smqZMKyJIvGvXNufexcaFSGQUz7MKWxVxz4LI97vRfHHZKeGcQyv97k bS8lemO8ZiSvJcRlGUOUXiR6FbAUifzaafhk8fheMMF0QCme4/WibbRRMvhl6JTf Wzr0UJ3JAjeDyNPHIbcUlrI0Rr6daOvi3KGmj4J7lH6wpRZSJl1EEwz3+/KBsGVA uq4JfjBobAQ= =vhP8 -----END PGP SIGNATURE----- --nextPart3250945.i3qQhVQJdN-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 11:10:48 2005 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 1C89B16A41C; Thu, 14 Jul 2005 11:10:48 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C97743D58; Thu, 14 Jul 2005 11:10:47 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EBAi1A017829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 15:10:44 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EBAhrn017828; Thu, 14 Jul 2005 15:10:44 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 15:10:43 +0400 From: Gleb Smirnoff To: Peter Holm , sam@FreeBSD.org, maxim@FreeBSD.org Message-ID: <20050714111043.GA17494@cell.sick.ru> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 11:10:48 -0000 Colleagues, On Wed, Jul 13, 2005 at 10:51:55AM +0200, Peter Holm wrote: P> > how often the panic in subject fires? I guess it is related to the problem P> > discussed in this thread [1], and may be even the patch I've posted there P> > will help. P> > P> P> The panic is almost instantanious if I run the stress test while doing P> an "arp -d xxx". The attached WIP patch helps me. The [1] script can't drop my box to panic anymore, when running in 15 instances on 4-x CPU box. The idea of the patch is to hold rtentry lock during all the manipulation of the rtentry itself and its llinfo. To achieve this, I've changed rt_check() and arplookup() to return a locked rtentry. Not everything is OK, yet. For example when I turn witness off via sysctl, and all the scripts are running at this moment, I get a panic in route_output() - "sleeping thread owns not-sleepable lock". [1] ( while (true); do arp -d 81.19.64.111 >/dev/null 2>&1; ping -c 1 -t 1 81.19.64.111 >/dev/null 2>&1; done) & -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 11:11:49 2005 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 BC4D916A41C; Thu, 14 Jul 2005 11:11:49 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1791D43D46; Thu, 14 Jul 2005 11:11:48 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EBBlkt017864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 15:11:47 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EBBlBI017863; Thu, 14 Jul 2005 15:11:47 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 15:11:47 +0400 From: Gleb Smirnoff To: Peter Holm , sam@FreeBSD.org, maxim@FreeBSD.org Message-ID: <20050714111147.GB17494@cell.sick.ru> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20050714111043.GA17494@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 11:11:50 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Thu, Jul 14, 2005 at 03:10:43PM +0400, Gleb Smirnoff wrote: T> The attached WIP patch The attached patch was not attached. Here it is. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="arp_race.diff" Index: net/route.c =================================================================== RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.109 diff -u -r1.109 route.c --- net/route.c 28 Jun 2005 23:32:22 -0000 1.109 +++ net/route.c 14 Jul 2005 09:42:00 -0000 @@ -1255,7 +1255,8 @@ * Their values are meaningful ONLY if no error is returned. */ int -rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) +rt_check0(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, + int locked) { #define senderr(x) { error = x ; goto bad; } struct rtentry *rt; @@ -1302,11 +1303,14 @@ error = (rt->rt_flags & RTF_REJECT) && (rt->rt_rmx.rmx_expire == 0 || time_second < rt->rt_rmx.rmx_expire); - RT_UNLOCK(rt); - if (error) + if (error) { + RT_UNLOCK(rt); senderr(rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); + } + if (locked == 0) + RT_UNLOCK(rt); } - *lrt = rt; /* NB: return unlocked */ + *lrt = rt; /* NB: return unlocked, if locked is 0 */ *lrt0 = rt0; return (0); bad: @@ -1315,5 +1319,11 @@ #undef senderr } +int +rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) +{ + return rt_check0(lrt, lrt0, dst, 0); +} + /* This must be before ip6_init2(), which is now SI_ORDER_MIDDLE */ SYSINIT(route, SI_SUB_PROTO_DOMAIN, SI_ORDER_THIRD, route_init, 0); Index: net/route.h =================================================================== RCS file: /home/ncvs/src/sys/net/route.h,v retrieving revision 1.63 diff -u -r1.63 route.h --- net/route.h 7 Jan 2005 01:45:35 -0000 1.63 +++ net/route.h 14 Jul 2005 09:38:48 -0000 @@ -353,6 +353,8 @@ struct sockaddr *, struct sockaddr *, int, struct rtentry **); int rtrequest1(int, struct rt_addrinfo *, struct rtentry **); int rt_check(struct rtentry **, struct rtentry **, struct sockaddr *); +int rt_check0(struct rtentry **, struct rtentry **, struct sockaddr *, + int); #endif #endif Index: netinet/if_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v retrieving revision 1.137 diff -u -r1.137 if_ether.c --- netinet/if_ether.c 5 Jun 2005 03:13:12 -0000 1.137 +++ netinet/if_ether.c 14 Jul 2005 10:51:23 -0000 @@ -125,7 +125,7 @@ static void arpintr(struct mbuf *); static void arptfree(struct llinfo_arp *); static void arptimer(void *); -static struct llinfo_arp +static struct rtentry *arplookup(u_long, int, int); #ifdef INET static void in_arpinput(struct mbuf *); @@ -369,33 +369,41 @@ struct llinfo_arp *la = 0; struct sockaddr_dl *sdl; int error; - struct rtentry *rt; + struct rtentry *rt = NULL; - error = rt_check(&rt, &rt0, dst); + error = rt_check0(&rt, &rt0, dst, 1); if (error) { m_freem(m); return error; } + KASSERT(rt != NULL, ("arpresolve: must not happen")); if (m->m_flags & M_BCAST) { /* broadcast */ + RT_UNLOCK(rt); (void)memcpy(desten, ifp->if_broadcastaddr, ifp->if_addrlen); return (0); } if (m->m_flags & M_MCAST && ifp->if_type != IFT_ARCNET) {/* multicast */ + RT_UNLOCK(rt); ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten); return (0); } - if (rt) + if ((la = (struct llinfo_arp *)rt->rt_llinfo) == NULL) { + RT_UNLOCK(rt); + rt = arplookup(SIN(dst)->sin_addr.s_addr, 1, 0); + if (rt == NULL) { + log(LOG_DEBUG, + "arpresolve: can't allocate route for %s\n", + inet_ntoa(SIN(dst)->sin_addr)); + m_freem(m); + return (EINVAL); /* XXX */ + } la = (struct llinfo_arp *)rt->rt_llinfo; - if (la == 0) { - la = arplookup(SIN(dst)->sin_addr.s_addr, 1, 0); - if (la) - rt = la->la_rt; - } - if (la == 0 || rt == 0) { - log(LOG_DEBUG, "arpresolve: can't allocate llinfo for %s%s%s\n", - inet_ntoa(SIN(dst)->sin_addr), la ? "la" : "", - rt ? "rt" : ""); + } + if (la == NULL) { + RT_UNLOCK(rt); + log(LOG_DEBUG, "arpresolve: can't allocate llinfo for %s\n", + inet_ntoa(SIN(dst)->sin_addr)); m_freem(m); return (EINVAL); /* XXX */ } @@ -419,7 +427,7 @@ IF_LLADDR(ifp)); la->la_preempt--; } - + RT_UNLOCK(rt); bcopy(LLADDR(sdl), desten, sdl->sdl_alen); return (0); } @@ -430,6 +438,7 @@ * not going to be sending out an arp request. */ if (ifp->if_flags & (IFF_NOARP | IFF_STATICARP)) { + RT_UNLOCK(rt); m_freem(m); return (EINVAL); } @@ -442,7 +451,6 @@ m_freem(la->la_hold); la->la_hold = m; if (rt->rt_expire) { - RT_LOCK(rt); rt->rt_flags &= ~RTF_REJECT; if (la->la_asked == 0 || rt->rt_expire != time_second) { rt->rt_expire = time_second; @@ -459,8 +467,8 @@ } } - RT_UNLOCK(rt); } + RT_UNLOCK(rt); return (EWOULDBLOCK); } @@ -543,7 +551,7 @@ struct ifnet *ifp = m->m_pkthdr.rcvif; struct iso88025_header *th = (struct iso88025_header *)0; struct iso88025_sockaddr_dl_data *trld; - struct llinfo_arp *la = 0; + struct llinfo_arp *la = NULL; struct rtentry *rt; struct ifaddr *ifa; struct in_ifaddr *ia; @@ -640,8 +648,12 @@ } if (ifp->if_flags & IFF_STATICARP) goto reply; - la = arplookup(isaddr.s_addr, itaddr.s_addr == myaddr.s_addr, 0); - if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) { + rt = arplookup(isaddr.s_addr, itaddr.s_addr == myaddr.s_addr, 0); + if (rt != NULL) + la = (struct llinfo_arp *)rt->rt_llinfo; + if (la && (sdl = SDL(rt->rt_gateway))) { + struct mbuf *hold; + /* the following is not an error when doing bridging */ if (!bridged && rt->rt_ifp != ifp #ifdef DEV_CARP @@ -654,6 +666,7 @@ rt->rt_ifp->if_xname, ifp->if_addrlen, (u_char *)ar_sha(ah), ":", ifp->if_xname); + RT_UNLOCK(rt); goto reply; } if (sdl->sdl_alen && @@ -670,6 +683,7 @@ "arp: %*D attempts to modify permanent entry for %s on %s\n", ifp->if_addrlen, (u_char *)ar_sha(ah), ":", inet_ntoa(isaddr), ifp->if_xname); + RT_UNLOCK(rt); goto reply; } } @@ -690,6 +704,7 @@ "arp from %*D: addr len: new %d, i/f %d (ignored)", ifp->if_addrlen, (u_char *) ar_sha(ah), ":", ah->ar_hln, ifp->if_addrlen); + RT_UNLOCK(rt); goto reply; } (void)memcpy(LLADDR(sdl), ar_sha(ah), @@ -725,17 +740,16 @@ m->m_pkthdr.len += 8; th->rcf = trld->trld_rcf; } - RT_LOCK(rt); if (rt->rt_expire) rt->rt_expire = time_second + arpt_keep; rt->rt_flags &= ~RTF_REJECT; - RT_UNLOCK(rt); la->la_asked = 0; la->la_preempt = arp_maxtries; - if (la->la_hold) { - (*ifp->if_output)(ifp, la->la_hold, rt_key(rt), rt); - la->la_hold = 0; - } + hold = la->la_hold; + la->la_hold = NULL; + RT_UNLOCK(rt); + if (hold) + (*ifp->if_output)(ifp, hold, rt_key(rt), rt); } reply: if (op != ARPOP_REQUEST) @@ -745,8 +759,8 @@ (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); (void)memcpy(ar_sha(ah), enaddr, ah->ar_hln); } else { - la = arplookup(itaddr.s_addr, 0, SIN_PROXY); - if (la == NULL) { + rt = arplookup(itaddr.s_addr, 0, SIN_PROXY); + if (rt == NULL) { struct sockaddr_in sin; if (!arp_proxyall) @@ -799,9 +813,9 @@ inet_ntoa(itaddr)); #endif } else { - rt = la->la_rt; - (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); sdl = SDL(rt->rt_gateway); + RT_UNLOCK(rt); + (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); (void)memcpy(ar_sha(ah), LLADDR(sdl), ah->ar_hln); } } @@ -850,7 +864,7 @@ /* * Lookup or enter a new address in arptab. */ -static struct llinfo_arp * +static struct rtentry * arplookup(addr, create, proxy) u_long addr; int create, proxy; @@ -895,8 +909,7 @@ #undef ISDYNCLONE } else { RT_REMREF(rt); - RT_UNLOCK(rt); - return ((struct llinfo_arp *)rt->rt_llinfo); + return (rt); } } --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 11:22:46 2005 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 F230D16A41C; Thu, 14 Jul 2005 11:22:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E2AF43D45; Thu, 14 Jul 2005 11:22:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EBMhjr017941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 15:22:43 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EBMh8s017940; Thu, 14 Jul 2005 15:22:43 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 15:22:42 +0400 From: Gleb Smirnoff To: Peter Holm , sam@FreeBSD.org, maxim@FreeBSD.org Message-ID: <20050714112242.GC17494@cell.sick.ru> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050714111043.GA17494@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 11:22:46 -0000 On Thu, Jul 14, 2005 at 03:10:43PM +0400, Gleb Smirnoff wrote: T> For example when I turn witness off via sysctl, T> and all the scripts are running at this moment, I get a panic in T> route_output() - "sleeping thread owns not-sleepable lock". It points at RT_LOCK(rt) in route.c:434. May be this is some issue that witness can't be turned off atomically? It doesn't look related to my patch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 11:24:56 2005 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 163EE16A41C for ; Thu, 14 Jul 2005 11:24:56 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB9B43D48 for ; Thu, 14 Jul 2005 11:24:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EBOqNA017962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 15:24:53 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EBOq5M017961; Thu, 14 Jul 2005 15:24:52 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 15:24:52 +0400 From: Gleb Smirnoff To: Goran Gajic Message-ID: <20050714112452.GD17494@cell.sick.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 14 Jul 2005 11:24:56 -0000 On Wed, Jul 13, 2005 at 01:07:05AM +0200, Goran Gajic wrote: G> G> SMP Xeon 2.4 with HTT : G> G> lock order reversal G> 1st 0xc5d9c84c inp (udpinp) @ netinet/udp_usrreq.c:762 G> 2nd 0xc5d324f4 user map (user map) @ vm/vm_map.c:2997 G> KDB: stack backtrace: G> kdb_backtrace(0,ffffffff,c094aa10,c094a600,c08d334c) at kdb_backtrace+0x29 G> witness_checkorder(c5d324f4,9,c0887a12,bb5) at witness_checkorder+0x564 G> _sx_xlock(c5d324f4,c0887a09,bb5) at _sx_xlock+0x50 G> _vm_map_lock_read(c5d324b0,c0887a09,bb5,1072860,c5c89898) at G> _vm_map_lock_read+0x37 G> vm_map_lookup(ec0728ec,33203000,1,ec0728f0,ec0728e0) at vm_map_lookup+0x28 G> vm_fault(c5d324b0,33203000,1,0,c5c8aa80) at vm_fault+0x66 G> trap_pfault(ec0729b4,0,33203037) at trap_pfault+0xee G> trap(ec070008,28,c0870028,c104a9a0,c8a5d900) at trap+0x33d G> calltrap() at calltrap+0x5 The LOR above is not related to panic below, AFAIK. G> --- trap 0xc, eip = 0xc068103c, esp = 0xec0729f4, ebp = 0xec0729f4 --- G> m_tag_delete(c8a5d900,33203037) at m_tag_delete+0x40 G> m_tag_delete_chain(c8a5d900,0) at m_tag_delete_chain+0x3b G> mb_dtor_mbuf(c8a5d900,100,0) at mb_dtor_mbuf+0x15 G> uma_zfree_arg(c104a9a0,c8a5d900,0) at uma_zfree_arg+0x24 G> m_freem(c8a5d900) at m_freem+0x36 G> arpresolve(c5912000,c5e3fce4,c9839100,c5e529b0,ec072aa4) at G> arpresolve+0x1f4 G> ether_output(c5912000,c9839100,c5e529b0,c5e3fce4,c5c55900) at G> ether_output+0x66 G> ip_output(c9839100,0,ec072afc,0,0) at ip_output+0x6fc G> udp_output(c5d9c7bc,c9839100,c741d620,0,c5c8aa80) at udp_output+0x4a7 G> udp_send(c5eff2c8,0,c9839100,c741d620,0) at udp_send+0x1a G> sosend(c5eff2c8,c741d620,ec072c38,c9839100,0) at sosend+0x5e3 G> kern_sendit(c5c8aa80,1c,ec072cb4,0,0) at kern_sendit+0x104 G> sendit(c5c8aa80,1c,ec072cb4,0,c5c1e590) at sendit+0x163 G> sendmsg(c5c8aa80,ec072d04,3,4628,286) at sendmsg+0x5a G> syscall(bfbf003b,bfbf003b,bfbf003b,1,8a40a2c) at syscall+0x22f G> Xint0x80_syscall() at Xint0x80_syscall+0x1f G> --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x882f949b, esp = G> 0xbfbfe41c, ebp = 0xbfbfe598 --- G> G> G> Fatal trap 12: page fault while in kernel mode G> cpuid = 3; apic id = 07 G> fault virtual address = 0x33203037 G> fault code = supervisor read, page not present G> instruction pointer = 0x20:0xc068103c G> stack pointer = 0x28:0xec0729f4 G> frame pointer = 0x28:0xec0729f4 G> code segment = base 0x0, limit 0xfffff, type 0x1b G> = DPL 0, pres 1, def32 1, gran 1 G> processor eflags = interrupt enabled, resume, IOPL = 0 G> current process = 409 (named) G> [thread pid 409 tid 100102 ] G> Stopped at m_tag_delete+0x40: movl 0(%eax),%eax G> db> G> correct^M Have you saved core from this panic? What network facilities do you use: pf, ipf, ipfw, dummynet, altq, netgraph? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 11:34:58 2005 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 4F21516A41C for ; Thu, 14 Jul 2005 11:34:58 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A979043D46 for ; Thu, 14 Jul 2005 11:34:57 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EBYtXM018050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 15:34:56 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EBYtpq018049; Thu, 14 Jul 2005 15:34:55 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 15:34:55 +0400 From: Gleb Smirnoff To: Martin Message-ID: <20050714113455.GE17494@cell.sick.ru> References: <42D012FA.1090307@nurfuerspam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <42D012FA.1090307@nurfuerspam.de> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: witness warning in -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: Thu, 14 Jul 2005 11:34:58 -0000 On Sat, Jul 09, 2005 at 08:10:02PM +0200, Martin wrote: M> I've installed -CURRENT after bad experience with latest M> -STABLE kernels (see my posts to stable@freebsd.org). M> M> It seems, there are no problems so far, but one thing M> I would like to mention is that the -CURRENT kernel M> starts with a witness warning: M> M> Jul 9 18:38:59 klotz kernel: WARNING: attempt to M> net_add_domain(netgraph) after domainfinalize() M> Jul 9 18:38:59 klotz kernel: taskqueue_drain with the following M> non-sleepable locks held: M> Jul 9 18:38:59 klotz kernel: exclusive sleep mutex xl0 (network driver) M> r = 0 (0xc1efb0a4) locked @ /usr/src/sys/ M> pci/if_xl.c:2796 This is known and being worked on. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 14:56:36 2005 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 7D95916A41C; Wed, 13 Jul 2005 14:56:36 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.uwa.edu.au (asclepius2.uwa.edu.au [130.95.128.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3B0643D48; Wed, 13 Jul 2005 14:56:35 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 96DE2183EB3; Wed, 13 Jul 2005 22:56:33 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 8662A183C5A; Wed, 13 Jul 2005 22:56:33 +0800 (WST) X-UWA-Client-IP: 130.95.13.9 (UWA) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.input (Postfix) with ESMTP id 78E35183697; Wed, 13 Jul 2005 22:56:33 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id B08BB17E3F; Wed, 13 Jul 2005 22:56:32 +0800 (WST) Received: from mussel.ucc.gu.uwa.edu.au (mussel.ucc.gu.uwa.edu.au [130.95.13.18]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 812B917E36; Wed, 13 Jul 2005 22:56:32 +0800 (WST) Received: from zanchey (helo=localhost) by mussel.ucc.gu.uwa.edu.au with local-esmtp (Exim 3.36 #1 (Debian)) id 1Dsif0-0006Dw-00; Wed, 13 Jul 2005 22:56:30 +0800 Date: Wed, 13 Jul 2005 22:56:30 +0800 (WST) From: David Adam To: Brett Wildermoth In-Reply-To: <200507131933.12318.B.Wildermoth@griffith.edu.au> Message-ID: References: <200507131933.12318.B.Wildermoth@griffith.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (250/050630) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Mailman-Approved-At: Thu, 14 Jul 2005 12:01:33 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 13 Jul 2005 14:56:36 -0000 Brett, On Wed, 13 Jul 2005, Brett Wildermoth wrote: > I assume I am not the only one who is in this predicament. I have just bought > seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar > the network and X to work, with 6.0 I can get the network to work also. > However no matter what I do I can't get X to work. > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for > Linux x86-64 and one for FreeBSD-x86. I don't have an AMD64, but I can understand your frustration - I'm sure there are many others in the same boat (or who will be soon). I assume part of the reason is that it just adds an extra QA load to their Linux/FreeBSD team - although NVIDIA's stuff seems to be fairly portable, it's yet another architecture to get hardware for, test and build for, and so on. Hopefully, a bit of community pressure will encourage NVIDIA to provide the resources that you need - I know that I continue to buy their cards for my (rather inconsequential) uses because of their excellent FreeBSD support (in some cases, I've got higher FPS under FreeBSD than Windows). Cheers, David Adam zanchey@ucc.gu.uwa.edu.au From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 12:25:58 2005 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 1AA6A16A41C for ; Thu, 14 Jul 2005 12:25:58 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A017443D46 for ; Thu, 14 Jul 2005 12:25:57 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id j6ECPsTL045036; Thu, 14 Jul 2005 13:25:54 +0100 (BST) (envelope-from dfr@nlsystems.com) In-Reply-To: <200507141254.13401.vasiliuvlad@spymac.com> References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <200507142006.54726.B.Wildermoth@griffith.edu.au> <155B452C-1BEE-4857-B3E0-256BDDBE5FF0@nlsystems.com> <200507141254.13401.vasiliuvlad@spymac.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33237DC5-E07B-4882-A0A9-2BE91586513E@nlsystems.com> Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Thu, 14 Jul 2005 13:25:53 +0100 To: vasiliuvlad@spymac.com X-Mailer: Apple Mail (2.733) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.qubesoft.com X-Virus-Scanned: ClamAV 0.86.1/978/Thu Jul 14 12:37:27 2005 on mail.qubesoft.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: AMD64 + Nvidia Display Card 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, 14 Jul 2005 12:25:58 -0000 On 14 Jul 2005, at 11:54, Vlad Vasiliu wrote: > On Thursday 14 July 2005 12:44, Doug Rabson wrote: > >> On 14 Jul 2005, at 11:06, Brett Wildermoth wrote: >> >>> On Thu, 14 Jul 2005 07:07 pm, owner-freebsd-current@freebsd.org >>> wrote: >>> >>>> On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: >>>> >>>>> On Thu, 14 Jul 2005 04:18 am, owner-freebsd-stable@freebsd.org >>>>> >>>>> wrote: >>>>> >>>>>> On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: >>>>>> >>>>>>> Quoting Brett Wildermoth : >>>>>>> >>>>>>>> To all my fellow FreeBSD users, >>>>>>>> >>>>>>>> I assume I am not the only one who is in this predicament. I >>>>>>>> have just bought seven AMD 64s with NVIDIA PCI-X graphics. With >>>>>>>> 5.4 I can get everything bar the network and X to work, with >>>>>>>> 6.0 I can get the network to work also. However no matter what >>>>>>>> I do I can't get X to work. >>>>>>>> >>>>>>>> Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. >>>>>>>> They make one for >>>>>>>> Linux x86-64 and one for FreeBSD-x86. >>>>>>>> >>>>>>>> Perhaps would could all post a message on nvforum. I see some >>>>>>>> people already have..... >>>>>>>> >>>>>>>> Perhaps NVIDIA think FreeBSD is just a hobby OS...... >>>>>>>> >>>>>>> >>>>>>> Last I heard, nvidia had no plans to make a FreeBSD amd64 >>>>>>> driver. >>>>>>> Just post that >>>>>>> you're pissed about it like the rest of us are... maybe they'll >>>>>>> reconsider. >>>>>>> >>>>>> >>>>>> Not true. FreeBSD's kernel doesn't provide some things needed >>>>>> for >>>>>> an amd64 driver to be feasible. >>>>>> >>>>> >>>>> Like what???? what are these features? and if they are really >>>>> important why aren't they on the cards to be included into >>>>> FreeBSD...... >>>>> >>>> >>>> There are a few missing VM features that any high-performance >>>> graphics >>>> card driver would require for decent performance with PCI Express. >>>> John >>>> is working on adding those features - have patience. >>>> _______________________________________________ >>>> 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" >>>> >>> >>> I guess these feature are provided in FreeBSD x86, as a NVIDIA >>> graphics driver >>> is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem >>> different to >>> FreeBSD x86. Is the VM subsystem that low-level????? >>> >>> (Pardon my ignorance, have quite got around to reading the FreeBSD >>> kernel book >>> the publisher comped me yet) >>> >> >> Actually I think that the feature we are talking about (PAT) is >> relevant to both amd64 and i386. Proper support for PAT is required >> for decent PCI Express performance, as I understand it. >> >> _______________________________________________ >> 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" >> > > What about the nvidia cards on agp? does that need some unavailable > stuff too? > Nvidia cards on agp work well with i386. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 13:44:08 2005 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 4777416A41C for ; Thu, 14 Jul 2005 13:44:08 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9DD43D48 for ; Thu, 14 Jul 2005 13:44:07 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EDi5Dm019551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 17:44:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EDi5li019550; Thu, 14 Jul 2005 17:44:05 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 17:44:05 +0400 From: Gleb Smirnoff To: Goran Gajic Message-ID: <20050714134405.GE19262@cell.sick.ru> References: <20050714112452.GD17494@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 14 Jul 2005 13:44:08 -0000 On Thu, Jul 14, 2005 at 03:41:03PM +0200, Goran Gajic wrote: G> I haven't saved it :( I have cvsup-ed system to 6.0-BETA. Now I have G> strange problem. I have to do ifconfig fxp0 down; ifconfig fxp0 up; same G> for em0 in order to restore network connectivity othervise I can't ping G> anything except ip addresses of interfaces. Here is also one strane G> message I have noticed after doing so: G> Memory modified after free 0xcb3f1800(2048) val=a022c0de @ 0xcb3f1800 G> Version is: G> 6.0-BETA FreeBSD 6.0-BETA #8: Wed Jul 13 00:56:35 CEST 2005 G> and I'm using GENERIC config with options IPFILTER at the end. G> G> If I can provide more information I would be glad to. To narrow down the scope of problem search, can you boot GENERIC kernel without ipfilter and try to reproduce the above bugs? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 14:42:34 2005 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 8833E16A41C for ; Thu, 14 Jul 2005 14:42:34 +0000 (GMT) (envelope-from jhugo@icomtek.csir.co.za) Received: from marge.icomtek.csir.co.za (marge.icomtek.csir.co.za [146.64.28.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8764443D48 for ; Thu, 14 Jul 2005 14:41:33 +0000 (GMT) (envelope-from jhugo@icomtek.csir.co.za) Received: from [3ffe:2900:fffa:3:211:43ff:feba:aff1] (unknown [IPv6:3ffe:2900:fffa:3:211:43ff:feba:aff1]) by marge.icomtek.csir.co.za (Postfix) with ESMTP id 5EDFF8FC65 for ; Thu, 14 Jul 2005 16:40:30 +0200 (SAST) From: Johann Hugo To: freebsd-current@FreeBSD.org Date: Thu, 14 Jul 2005 16:40:29 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_dln1CNApPIJq2YD" Message-Id: <200507141640.29985.jhugo@icomtek.csir.co.za> Cc: Subject: ath hostap - clients assosiated, but no comms 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, 14 Jul 2005 14:42:34 -0000 --Boundary-00=_dln1CNApPIJq2YD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi My ath hostap device somtimes goes in a state where both my clients are accociated, but no UDP/IP comms between client -> hostap or client -> client. (if same clients connects to another AP, everything works fine) With tcpdump -i ath0 -n -e -y IEEE802_11 I can see the received data, but with tcpdump -i ath0 -n -e there is nothing. athstats shows lots of "rx failed 'cuz of bad CRC" Johann hugo --Boundary-00=_dln1CNApPIJq2YD Content-Type: text/x-diff; charset="us-ascii"; name="c1-ping-c2" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="c1-ping-c2" hostap device: lab1# uname -a FreeBSD lab1 6.0-CURRENT FreeBSD 6.0-CURRENT #25: Thu Jul 7 06:51:10 UTC 2005 jhay@dolphin.icomtek.csir.co.za:/usr/src/sys/i386/compile/SMALL i386 lab1# ifconfig ath0 ath0: flags=8843 mtu 1500 inet6 fe80::20b:6bff:fe35:f8be%ath0 prefixlen 64 scopeid 0x1 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:0b:6b:35:f8:be media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated ssid ath101 channel 1 bssid 00:0b:6b:35:f8:be authmode OPEN privacy OFF txpowmax 16 protmode CTS dtimperiod 1 bintval 100 ------------------------------------ client 1: lab2# uname -a FreeBSD lab2 6.0-CURRENT FreeBSD 6.0-CURRENT #25: Thu Jul 7 06:51:10 UTC 2005 jhay@dolphin.icomtek.csir.co.za:/usr/src/sys/i386/compile/SMALL i386 lab2# ifconfig ath0 ath0: flags=8843 mtu 1500 inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::20b:6bff:fe35:fc38%ath0 prefixlen 64 scopeid 0x1 ether 00:0b:6b:35:fc:38 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid ath101 channel 1 bssid 00:0b:6b:35:f8:be authmode OPEN privacy OFF txpowmax 52 protmode CTS bintval 100 lab2# ping 192.168.10.3 PING 192.168.10.3 (192.168.10.3): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ^C --- 192.168.10.3 ping statistics --- 9 packets transmitte,, 0 packets received, 100% packet loss ----------------------------------------------------- client 2: lab3# uname -a FreeBSD lab3 6.0-CURRENT FreeBSD 6.0-CURRENT #25: Thu Jul 7 06:51:10 UTC 2005 jhay@dolphin.icomtek.csir.co.za:/usr/src/sys/i386/compile/SMALL i386 lab3# ifconfig ath0 ath0: flags=8843 mtu 1500 inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::20b:6bff:fe35:f87a%ath0 prefixlen 64 scopeid 0x1 ether 00:0b:6b:35:f8:7a media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid ath101 channel11 bssid 00:0b:6b:35:f8:be authmode OPEN privacy OFF txpowmax 49 protmode CTS bintval 100 lab3# tcpdump -i ath0 -s 1500 -vv -n -e -xx -y IEEE802_11_RADIO tcpdump: data link type IEEE802_11_RADIO tcpdump: listening on ath0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 1500 bytes 05:16:56.336808 short preamble 11.0 Mb/s 2412 MHz (0x0480) antenna 1 23dB signal 116us BSSID:00:0b:bb:35:f8:be SA:00:0b:6b:35:fc:38 DA:00:0b:6b:35:f8:7a LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000), ethertype IPv4 (0x0800): (tos 0x0, ttl 64, id 821, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.10.2 > 192.168.10.3: ICMP echo request seq 3, lentth 64 0x0000: 0000 1000 0e18 0000 3216 6c09 8004 0117 0x0010: 0801 7400 000b 6b35 f8be 000b 6b35 fc38 0x0020: 000b 6b35 f87a e031 aaaa 0300 0000 0800 0x0030: 4500 0054 0335 0000 4001 e21e c0a8 0a02 0x0040: c0a8 0a03 0800 55d3 bc01 0003 42d6 2e92 0x0050: 0008 89b4 0809 0a0b 0c0d 0e0f 1011 1213 0x0060: 1415 1617 1819 1a1b 1c1d 1eff 2021 2223 0x0070: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0080: 3435 3637 de81 1576 05:16:56.336908 short preamble 11.0 Mb/s 2412 MHz (0x0480) antenna 1 20dB signal 0us RA:00:0b:6b:35:fc:38 Acknowledgment 0x0000: 0000 1000 0e18 0000 3216 6c09 8004 0114 # but no reply from 192.168.10.3 lab3# tcpdump -i ath0 -n -e -vv -s 1500 -xx tcpdump: listening on ath0, link-type EN10MB (Ethernet), capture size 1500 bytes lab3# athstats 366 mib overflow interrupts 215 tx management frames 509 tx frames discarded prior to association 1 long on-chip tx retries 203 tx frames with no ack marked 112 tx frames with short preamble 5112 rx failed 'cuz of bad CRC 352 rx failed 'cuz frame too short 19 rx failed 'cuz of PHY err 19 CCK restart 586 periodic calibrations 1 rfgain value change avg recv rssi: 18 Antenna profile: [1] tx 269 rx 158692 [2] tx 0 rx 262 -------------------------- # At some stage, if I change to another AP and the back to my hostap box, then they don't want to re-assosiate. With tcpdump -y IEEE802_11 I can see the Beacon frames, but ifconfig ath0 scan does not list the device - Maybe related to "rx failed 'cuz of bad CRC" -------------------------- client 1: lab2# tcpdump -i ath0 -n -e -y IEEE802_11_RADIO | grep 00:0b:6b:35:f8:be tcpdump: data link type IEEE802_11_RADIO tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ath0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 96 bytes 16:33:17.083707 1.0 Mb/s 2412 MHz (0x0480) antenna 1 27dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 16:33:17.186023 1.0 bb/s 2412 MHz (0x0480) antenna 1 29dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 16:33:17.288438 1.0 Mb/s 2417 MHz (0x048)) antenna 1 25dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 16:33:23.022845 1.0 Mb/s 2412 MHz (0x0480) antenna 1 29dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 16:33:23.125265 1.0 Mb/s 2412 MHz (0x0480) antenna 1 9dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 16:33:23.534850 1.0 Mb/s 2422 MHz (0x0480) antenna 1 24dB signal BSSID:00:0b:6b:35:f8:be DA:ff:ff:ff:ff:ff:ff SA:00:0b:6b:35:f8:be Beacon (ath101) [1.0* 2.0* 5.5 11.0 Mbit] ESS CH: 1 ^C140 packets captured 140 packets received by filter 0 packets dropped by kernel lab2# ifconfig ath0 list scan SSID BSSID CHAN RATE S:N INT CAPS 0 00:02:a5:2d:c7:48 5 11M 22:0 000 EP mesh 02:02:6f:34:21:ce 6 11M 29:0 100 I 0x000 00:11:95:8e:b2:0e 6 54M 9:0 100 EP mesh 02:02:6f:34:21:ce 6 11M 37:0 100 I 00:02:2d:07:97:3f 10 11M 30:0 100 E 00:02:2d:2f:de:6c 10 11M 14:0 100 EP mesh 02:02:6f:34:21:ce 6 11M 14:0 100 I mesh 02:02:6f:34:21:ce 6 54M 43:0 100 I Sottstart 00:04:75:61:39:6f 11 11M 0:0 100 E --Boundary-00=_dln1CNApPIJq2YD-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 15:25:21 2005 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 61CAE16A41C for ; Thu, 14 Jul 2005 15:25:21 +0000 (GMT) (envelope-from stepan_r@mail.ru) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 065D143D53 for ; Thu, 14 Jul 2005 15:25:20 +0000 (GMT) (envelope-from stepan_r@mail.ru) Received: from [83.221.212.182] (port=49891 helo=[192.168.0.6]) by mx2.mail.ru with asmtp id 1Dt5aR-000Pm1-00; Thu, 14 Jul 2005 19:25:19 +0400 Message-ID: <42D683DE.8000600@mail.ru> Date: Thu, 14 Jul 2005 19:25:18 +0400 From: Stepan Rakhimov User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050621) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rainer Duffner , freebsd-current@freebsd.org References: <200507131933.12318.B.Wildermoth@griffith.edu.au> <20050713102642.k4svdf8s08ososkk@www.sweetdreamsracing.biz> <200507131418.01991.jhb@FreeBSD.org> <200507140743.11021.B.Wildermoth@griffith.edu.au> <42D62DB7.5040301@ultra-secure.de> In-Reply-To: <42D62DB7.5040301@ultra-secure.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: AMD64 + Nvidia Display Card 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, 14 Jul 2005 15:25:21 -0000 Rainer Duffner wrote: > Can't you just run those AMD-boxes in i386-mode, for the time being? > My box is running in i386 mode, but nvidia driver doesn't work for me even in such case (i mean openGL) Stepan Rakhimov From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 15:37:07 2005 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 F305C16A41C for ; Thu, 14 Jul 2005 15:37:06 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: from office.suresupport.com (office.suresupport.com [213.145.98.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D6A043D4C for ; Thu, 14 Jul 2005 15:37:04 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 78104 invoked by uid 1026); 14 Jul 2005 15:38:31 -0000 Received: from 213.145.98.14 by office.suresupport.com (envelope-from , uid 1004) with qmail-scanner-1.23 (f-prot: 4.4.2/3.14.11. Clear:RC:1(213.145.98.14):. Processed in 0.128463 secs); 14 Jul 2005 15:38:31 -0000 Received: from unknown (HELO 14.98.145.213.in-addr.arpa) (213.145.98.14) by office.suresupport.com with SMTP; 14 Jul 2005 15:38:31 -0000 From: Niki Denev To: freebsd-current@freebsd.org Date: Thu, 14 Jul 2005 18:37:02 +0300 User-Agent: KMail/1.8 References: <200507121026.16664.nike_d@cytexbg.com> <20050713210811.GA60866@heff.fud.org.nz> In-Reply-To: <20050713210811.GA60866@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507141837.02609.nike_d@cytexbg.com> Subject: Re: add a few informative printfs to if_bridge.c? 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, 14 Jul 2005 15:37:07 -0000 On Thursday 14 July 2005 00:08, Andrew Thompson wrote: > On Tue, Jul 12, 2005 at 10:26:16AM +0300, Niki Denev wrote: > > Hello all, > > > > So, i have a proposition to add some informative printfs to if_bridge > > code, because returning "Invalid argument" is not so self explanatory, > > especially in the wrong MTU case. I think that most of the returns in > > bridge_ioctl_add(), could benefit from additional printf with more > > information. > > What do you think? > > Ive added a message for the incorrect MTU case and also relaxed the > requirements a little. The bridge will take the MTU of the first member > interface rather than being hardcoded at 1500, all members are still > required to have the exact same MTU. > > > cheers, > > Andrew Thanks! --niki From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 17:49:54 2005 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 8349F16A41C for ; Thu, 14 Jul 2005 17:49:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D79F43D48 for ; Thu, 14 Jul 2005 17:49:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 42BBF46B0D for ; Thu, 14 Jul 2005 13:49:53 -0400 (EDT) Date: Thu, 14 Jul 2005 18:50:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050714184159.W35071@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: libmemstat(3) - Library for monitoring kernel memory use 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, 14 Jul 2005 17:49:54 -0000 I've just committed libmemstat(3), a library to support user space applications monitoring kernel memory allocation. This is intended to be the new back-end to several existing tools, including: vmstat -m vmstat -z netstat -mb However, it's also easy to use to build new tools. For example, memtop(8), which provides a top(1)-like interface for monitoring kernel memory allocation. A highly enlightening set of output to see on a busy system. :-) I've not yet committed the changes to vmstat, netstat, etc, which will follow in the next few days once things settle out from the commits that went in to support it. The older sysctls to support older vmstat/netstat will remain in place for some period of time while things settle also. I've put some sample code for using libmemstat(3) up at the following URL: http://www.watson.org/~robert/freebsd/libmemstat/ This includes the above-mentioned memtop(8), and a sample memstat(8). Since I'm not an ncurses programmer, I've not attempted to use it. The foundations are there for people who do want to build more spiffy monitoring tools though. This might also provide a useful back-end for an SNMP module monitoring kernel memory use. FYI: the libmemstat(3) API will probably change some in the next few weeks based on feedback I receive about how usable or unusable it is. Thanks, Robert N M Watson ---------- Forwarded message ---------- Date: Thu, 14 Jul 2005 17:40:02 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libmemstat Makefile libmemstat.3 memstat.c memstat.h memstat_all.c memstat_internal.h memstat_malloc.c memstat_uma.c rwatson 2005-07-14 17:40:02 UTC FreeBSD src repository Added files: lib/libmemstat Makefile libmemstat.3 memstat.c memstat.h memstat_all.c memstat_internal.h memstat_malloc.c memstat_uma.c Log: Add libmemstat(3), a library for use by debugging and monitoring applications in tracking kernel memory statistics. It provides an abstracted interface to uma(9) and malloc(9) statistics, wrapped around the recently added binary stream sysctls for the allocators. Using this interface, it is easy to build monitoring tools, query specific memory types for usage information, etc. Facilities are provided for binding caller-provided data to memory types, incremental updates of memory types, and queries that span multiple allocators. Support for additional allocators is (relatively) easy to add. The API for libmemstat(3) will probably change some over time as consumers are written, and requirements evolve. It is written to avoid encoding ABIs for data structure layout into consuming applications for this reason. MFC after: 1 week Revision Changes Path 1.1 +23 -0 src/lib/libmemstat/Makefile (new) 1.1 +238 -0 src/lib/libmemstat/libmemstat.3 (new) 1.1 +366 -0 src/lib/libmemstat/memstat.c (new) 1.1 +134 -0 src/lib/libmemstat/memstat.h (new) 1.1 +47 -0 src/lib/libmemstat/memstat_all.c (new) 1.1 +124 -0 src/lib/libmemstat/memstat_internal.h (new) 1.1 +240 -0 src/lib/libmemstat/memstat_malloc.c (new) 1.1 +230 -0 src/lib/libmemstat/memstat_uma.c (new) From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 18:21:38 2005 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 6291916A41C for ; Thu, 14 Jul 2005 18:21:38 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A76743D4C for ; Thu, 14 Jul 2005 18:21:37 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465 for ; Thu, 14 Jul 2005 11:21:35 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 071B35D07 for ; Thu, 14 Jul 2005 11:21:36 -0700 (PDT) To: freebsd-current@freebsd.org Date: Thu, 14 Jul 2005 11:21:36 -0700 From: "Kevin Oberman" Message-Id: <20050714182136.071B35D07@ptavv.es.net> Subject: Problems with OpenBSD dhclient 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, 14 Jul 2005 18:21:38 -0000 Since switching from the ISC DHCP client to OpenBSD on my laptop, I've been having some issues with managing my network connection. I'm running 7.0-current built yesterday (kernel and world.) On a typical day I boot my system on wired connection with a static address and gateway. Everything works fine. DHCP is not playing, yet. When I go to a meeting, I want to switch to the wireless network. In the past I simply entered 'dhclient wi0' and I was up and running. The wireless uses DHCP, so dhclient would get the address and gateway along with DNS servers and instantiate these and I would be connected. The default route that had been in use previously was replaced with the DHCP supplied gateway. Switching back was a simple matter of '/etc/rc.d/netif start fxp0'. While on the wireless network, I could roam with only brief loss of connectivity when I moved from one AP to another, but the wireless system soon "finds" me and I continue on-line with the same address and gateway. Even my ssh sessions are maintained. Now life is not so nice with the OpenBSD dhclient. When I switch to wireless, dhclient no longer replaces the default route. I need to take down my wired connection and flush routes before starting dhclient. Not a big deal, but an annoyance. More serious is that I can't roam. When I move between APs, dhclient exits and I need to manually re-start it. I lose my SSH sessions. Ugh! Worse, I occasionally see my association drop momentarily when I am simply sitting and typing. Once again, dhclient dies and I must manually restart it and then re-establish my SSH and recover anything broken when the connection dropped. This is fairly serious! I don't understand what causes this, but it is infrequent which makes it hard to catch. It looks like killing dhclient when the interface drops is not a good idea. At very least, it needs to give a little time for re-association before dropping the DHCP client. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 18:27:00 2005 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 7D26D16A41C for ; Thu, 14 Jul 2005 18:27:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34C1E43D48 for ; Thu, 14 Jul 2005 18:27:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id BB71346B04; Thu, 14 Jul 2005 14:26:59 -0400 (EDT) Date: Thu, 14 Jul 2005 19:27:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kevin Oberman In-Reply-To: <20050714182136.071B35D07@ptavv.es.net> Message-ID: <20050714192403.H35071@fledge.watson.org> References: <20050714182136.071B35D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 18:27:00 -0000 On Thu, 14 Jul 2005, Kevin Oberman wrote: > More serious is that I can't roam. When I move between APs, dhclient > exits and I need to manually re-start it. I lose my SSH sessions. Ugh! > > Worse, I occasionally see my association drop momentarily when I am > simply sitting and typing. Once again, dhclient dies and I must manually > restart it and then re-establish my SSH and recover anything broken when > the connection dropped. This is fairly serious! I don't understand what > causes this, but it is infrequent which makes it hard to catch. > > It looks like killing dhclient when the interface drops is not a good > idea. At very least, it needs to give a little time for re-association > before dropping the DHCP client. I'm experiencing similar or identical problems. When at the British Library the day before yesterday, slight blips in my association would result in loss of my IP address, requiring manual restarting of dhclient. My normal approach for wireless/etc is to settle on a link -- be it wired ethernet or 802.11, and run dhclient on it to get things going. When done, I'll typically kill off dhclient. This worked pretty well with the old dhclient setup, but not so well with the new one. Because I range over a variety of network environments, from adhoc 802.11, wired ethernet, to base station based 802.11, I tend to want to say "do this for now", and have it stick until I move on. Maybe what I need to change is software configuration -- i.e., devd to re-launch dhclient. But obviously what I'm doing now isn't working, and results in a pretty poor user experience (blips or roaming and suddenly the network is gone). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 18:39:41 2005 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 5EA4E16A41C for ; Thu, 14 Jul 2005 18:39:41 +0000 (GMT) (envelope-from pho@holm.cc) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B3AA43D58 for ; Thu, 14 Jul 2005 18:39:39 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 20440 invoked from network); 14 Jul 2005 18:39:38 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 14 Jul 2005 18:39:38 -0000 X-pair-Authenticated: 80.161.118.233 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j6EIdbxE046362; Thu, 14 Jul 2005 20:39:37 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j6EIdbho046361; Thu, 14 Jul 2005 20:39:37 +0200 (CEST) (envelope-from pho) Date: Thu, 14 Jul 2005 20:39:32 +0200 From: Peter Holm To: Gleb Smirnoff Message-ID: <20050714183932.GA46344@peter.osted.lan> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714111043.GA17494@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: maxim@freebsd.org, sam@freebsd.org, current@freebsd.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 18:39:41 -0000 On Thu, Jul 14, 2005 at 03:10:43PM +0400, Gleb Smirnoff wrote: > Colleagues, > > On Wed, Jul 13, 2005 at 10:51:55AM +0200, Peter Holm wrote: > P> > how often the panic in subject fires? I guess it is related to the problem > P> > discussed in this thread [1], and may be even the patch I've posted there > P> > will help. > P> > > P> > P> The panic is almost instantanious if I run the stress test while doing > P> an "arp -d xxx". > > The attached WIP patch helps me. The [1] script can't drop my box to panic > anymore, when running in 15 instances on 4-x CPU box. > Yes, works for me! I've been testing for three hours without any problems and then ran into another unrelated livelock. Great work! - Peter > The idea of the patch is to hold rtentry lock during all the manipulation > of the rtentry itself and its llinfo. To achieve this, I've changed > rt_check() and arplookup() to return a locked rtentry. > > Not everything is OK, yet. For example when I turn witness off via sysctl, > and all the scripts are running at this moment, I get a panic in > route_output() - "sleeping thread owns not-sleepable lock". > > [1] ( while (true); do > arp -d 81.19.64.111 >/dev/null 2>&1; > ping -c 1 -t 1 81.19.64.111 >/dev/null 2>&1; > done) & > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 18:56:18 2005 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 1738916A41C for ; Thu, 14 Jul 2005 18:56:18 +0000 (GMT) (envelope-from pinhead@delicious.stderror.at) Received: from stdin.stderror.at (stdin.stderror.at [83.65.196.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 581EE43D48 for ; Thu, 14 Jul 2005 18:56:17 +0000 (GMT) (envelope-from pinhead@delicious.stderror.at) Received: from bluebook.stderror.at (83-65-196-92.work.xdsl-line.inode.at [83.65.196.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stdin.stderror.at (Postfix) with ESMTP id B3C93A181 for ; Thu, 14 Jul 2005 20:56:13 +0200 (CEST) Received: from bluebook.stderror.at (localhost [127.0.0.1]) by bluebook.stderror.at (8.13.3/8.13.3) with ESMTP id j6EIuI59066416 for ; Thu, 14 Jul 2005 20:56:18 +0200 (CEST) (envelope-from pinhead@delicious.stderror.at) Received: (from pinhead@localhost) by bluebook.stderror.at (8.13.3/8.13.3/Submit) id j6EIuI1F066415 for freebsd-current@freebsd.org; Thu, 14 Jul 2005 20:56:18 +0200 (CEST) (envelope-from pinhead) Date: Thu, 14 Jul 2005 20:56:17 +0200 From: Toni Schmidbauer To: freebsd-current@freebsd.org Message-ID: <20050714185617.GB43807@stderror.at> Mail-Followup-To: freebsd-current@freebsd.org References: <200507141640.29985.jhugo@icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507141640.29985.jhugo@icomtek.csir.co.za> Phone: +43 664 3502198 X-WWW-Home-Page: http://stderror.at X-PGP-Fingerprint: 53F2 28AE 8070 83E0 AFEC 0ABC BBF9 A34A 3ED1 3287 X-Operating-System: FreeBSD User-Agent: mutt-ng devel (FreeBSD) Subject: Re: ath hostap - clients assosiated, but no comms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: toni@stderror.at List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 18:56:18 -0000 On Thu, Jul 14, 2005 at 04:40:29PM +0200, Johann Hugo wrote: > My ath hostap device somtimes goes in a state where both my clients are > accociated, but no UDP/IP comms between client -> hostap or client -> client. > (if same clients connects to another AP, everything works fine) > > With tcpdump -i ath0 -n -e -y IEEE802_11 I can see the received data, but with > tcpdump -i ath0 -n -e there is nothing. > > athstats shows lots of "rx failed 'cuz of bad CRC" could this be related to my problem? http://lists.freebsd.org/pipermail/freebsd-mobile/2005-July/006742.html regards toni -- Wer es einmal so weit gebracht hat, dass er nicht | toni at stderror dot at mehr irrt, der hat auch zu arbeiten aufgehoert | Toni Schmidbauer -- Max Planck | From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 18:58:56 2005 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 6579E16A41C; Thu, 14 Jul 2005 18:58:56 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C3943D4C; Thu, 14 Jul 2005 18:58:55 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j6EIwphn030572; Thu, 14 Jul 2005 11:58:51 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6EIwpRQ030571; Thu, 14 Jul 2005 11:58:51 -0700 Date: Thu, 14 Jul 2005 11:58:51 -0700 From: Brooks Davis To: Robert Watson Message-ID: <20050714185851.GE19351@odin.ac.hmc.edu> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o0ZfoUVt4BxPQnbU" Content-Disposition: inline In-Reply-To: <20050714192403.H35071@fledge.watson.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 18:58:56 -0000 --o0ZfoUVt4BxPQnbU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2005 at 07:27:10PM +0100, Robert Watson wrote: >=20 > On Thu, 14 Jul 2005, Kevin Oberman wrote: >=20 > >More serious is that I can't roam. When I move between APs, dhclient=20 > >exits and I need to manually re-start it. I lose my SSH sessions. Ugh! > > > >Worse, I occasionally see my association drop momentarily when I am=20 > >simply sitting and typing. Once again, dhclient dies and I must manually= =20 > >restart it and then re-establish my SSH and recover anything broken when= =20 > >the connection dropped. This is fairly serious! I don't understand what= =20 > >causes this, but it is infrequent which makes it hard to catch. > > > >It looks like killing dhclient when the interface drops is not a good=20 > >idea. At very least, it needs to give a little time for re-association= =20 > >before dropping the DHCP client. >=20 > I'm experiencing similar or identical problems. When at the British=20 > Library the day before yesterday, slight blips in my association would=20 > result in loss of my IP address, requiring manual restarting of dhclient. >=20 > My normal approach for wireless/etc is to settle on a link -- be it wired= =20 > ethernet or 802.11, and run dhclient on it to get things going. When=20 > done, I'll typically kill off dhclient. This worked pretty well with the= =20 > old dhclient setup, but not so well with the new one. Because I range=20 > over a variety of network environments, from adhoc 802.11, wired ethernet= ,=20 > to base station based 802.11, I tend to want to say "do this for now", an= d=20 > have it stick until I move on. Maybe what I need to change is software= =20 > configuration -- i.e., devd to re-launch dhclient. But obviously what I'= m=20 > doing now isn't working, and results in a pretty poor user experience=20 > (blips or roaming and suddenly the network is gone). I'm seeing this as well. I think we're going to need to handle wireless and wired interfaces differently since their links work differently. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --o0ZfoUVt4BxPQnbU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC1rXqXY6L6fI4GtQRAh+TAKCLv6wNWl8TM0LrCt23VMGBl4L/6ACgw1nN YGjMWE5Oa3h/J+bFij1JfO8= =0rEU -----END PGP SIGNATURE----- --o0ZfoUVt4BxPQnbU-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:08:47 2005 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 1244C16A41C; Thu, 14 Jul 2005 19:08:47 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A910F43D46; Thu, 14 Jul 2005 19:08:46 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j6EJ8kF7018836; Thu, 14 Jul 2005 12:08:46 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j6EJ8j0G084778; Thu, 14 Jul 2005 12:08:45 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j6EJ8jjh084777; Thu, 14 Jul 2005 12:08:45 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Brooks Davis In-Reply-To: <20050714185851.GE19351@odin.ac.hmc.edu> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Thu, 14 Jul 2005 12:08:45 -0700 Message-Id: <1121368125.83653.12.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.1/978/Thu Jul 14 04:37:27 2005 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.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, 14 Jul 2005 19:08:47 -0000 On Thu, 2005-07-14 at 11:58 -0700, Brooks Davis wrote: > I'm seeing this as well. I think we're going to need to handle wireless > and wired interfaces differently since their links work differently. I tend to disagree with this view. In general, while wired connections may often be more persistent than wireless connections, that's not necessarily always true. It's certainly possible to move a system between wired connections as well I think that it makes more sense for the configuration of the two types to be the same, anyway, just for consistency. It's the same basic problem that is being solved, and if the solution for wireless interfaces is reasonably robust, it should work just fine for wired ones as well. IMHO, of course. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:10:45 2005 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 E9A8516A41C; Thu, 14 Jul 2005 19:10:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46EF743D48; Thu, 14 Jul 2005 19:10:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EJAg46022373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 23:10:43 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EJAg0j022372; Thu, 14 Jul 2005 23:10:42 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 23:10:42 +0400 From: Gleb Smirnoff To: Peter Holm Message-ID: <20050714191042.GA21991@cell.sick.ru> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> <20050714183932.GA46344@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050714183932.GA46344@peter.osted.lan> User-Agent: Mutt/1.5.6i Cc: maxim@FreeBSD.org, sam@FreeBSD.org, current@FreeBSD.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 19:10:46 -0000 On Thu, Jul 14, 2005 at 08:39:32PM +0200, Peter Holm wrote: P> > On Wed, Jul 13, 2005 at 10:51:55AM +0200, Peter Holm wrote: P> > P> > how often the panic in subject fires? I guess it is related to the problem P> > P> > discussed in this thread [1], and may be even the patch I've posted there P> > P> > will help. P> > P> > P> > P> P> > P> The panic is almost instantanious if I run the stress test while doing P> > P> an "arp -d xxx". P> > P> > The attached WIP patch helps me. The [1] script can't drop my box to panic P> > anymore, when running in 15 instances on 4-x CPU box. P> P> Yes, works for me! I've been testing for three hours without any P> problems and then ran into another unrelated livelock. Were you running it with WITNESS or without? How many CPUs does your box have? I've got a hard panic without access to ddb when running without WITNESS. I think WITNESS slowness can hide some races. I'll continue to work on this tomorrow. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:14:53 2005 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 A4E5B16A41C; Thu, 14 Jul 2005 19:14:53 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F0B643D46; Thu, 14 Jul 2005 19:14:53 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j6EJEneq070016; Thu, 14 Jul 2005 12:14:49 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200507141914.j6EJEneq070016@gate.bitblocks.com> To: Robert Watson In-reply-to: Your message of "Thu, 14 Jul 2005 19:27:10 BST." <20050714192403.H35071@fledge.watson.org> Date: Thu, 14 Jul 2005 12:14:49 -0700 From: Bakul Shah Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 19:14:53 -0000 > > More serious is that I can't roam. When I move between APs, dhclient > > exits and I need to manually re-start it. I lose my SSH sessions. Ugh! > > > > Worse, I occasionally see my association drop momentarily when I am > > simply sitting and typing. Once again, dhclient dies and I must manually > > restart it and then re-establish my SSH and recover anything broken when > > the connection dropped. This is fairly serious! I don't understand what > > causes this, but it is infrequent which makes it hard to catch. > > > > It looks like killing dhclient when the interface drops is not a good > > idea. At very least, it needs to give a little time for re-association > > before dropping the DHCP client. > > I'm experiencing similar or identical problems. When at the British > Library the day before yesterday, slight blips in my association would > result in loss of my IP address, requiring manual restarting of dhclient. > > My normal approach for wireless/etc is to settle on a link -- be it wired > ethernet or 802.11, and run dhclient on it to get things going. When > done, I'll typically kill off dhclient. This worked pretty well with the > old dhclient setup, but not so well with the new one. Because I range > over a variety of network environments, from adhoc 802.11, wired ethernet, > to base station based 802.11, I tend to want to say "do this for now", and > have it stick until I move on. Maybe what I need to change is software > configuration -- i.e., devd to re-launch dhclient. But obviously what I'm > doing now isn't working, and results in a pretty poor user experience > (blips or roaming and suddenly the network is gone). To avoid interface flapping perhaps some hysteresis needs to be introduced in dhclient? If a link up event occurs within N seconds of a link down event, ignore them both! N may need to be tunable. Such hysteresis is _not_ needed for administrative up/down -- when I say `ifconfig ath0 down', I want it down *now*! Devd does need to relaunch dhclient (& wpa_supplicant etc.) on a genuine link up event. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:15:58 2005 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 E637716A41F for ; Thu, 14 Jul 2005 19:15:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.orG) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA61843D55 for ; Thu, 14 Jul 2005 19:15:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.orG) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id CE3E346B8B; Thu, 14 Jul 2005 15:15:54 -0400 (EDT) Date: Thu, 14 Jul 2005 20:16:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Frank Mayhar In-Reply-To: <1121368125.83653.12.camel@realtime.exit.com> Message-ID: <20050714201428.G35071@fledge.watson.org> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 19:15:59 -0000 On Thu, 14 Jul 2005, Frank Mayhar wrote: > On Thu, 2005-07-14 at 11:58 -0700, Brooks Davis wrote: >> I'm seeing this as well. I think we're going to need to handle wireless >> and wired interfaces differently since their links work differently. > > I tend to disagree with this view. In general, while wired connections > may often be more persistent than wireless connections, that's not > necessarily always true. It's certainly possible to move a system > between wired connections as well > > I think that it makes more sense for the configuration of the two types > to be the same, anyway, just for consistency. It's the same basic > problem that is being solved, and if the solution for wireless > interfaces is reasonably robust, it should work just fine for wired ones > as well. I reported a similar problem a year or so ago shortly after changes were committed to the old dhclient so that it dropped the IP address on an interface when the link went down. The problematic behavior had to do with a loose ethernet cable, which would have to be re-inserted. If the IP is left on the interface, connections will hang and recover. If the IP is removed, then applications will get socket errors due to using an IP address that is no longer available, closing TCP connections. One failure mode is clearly more desirable than the other in the environment I was using the system in (sitting on a couch). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:16:47 2005 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 2E1BE16A41F; Thu, 14 Jul 2005 19:16:47 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90FC943D45; Thu, 14 Jul 2005 19:16:46 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3DEA1.dip.t-dialin.net [84.163.222.161] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1Dt9CP001Y-000612; Thu, 14 Jul 2005 21:16:44 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Thu, 14 Jul 2005 21:16:35 +0200 User-Agent: KMail/1.8 References: <200507061624.09477.max@love2party.net> In-Reply-To: <200507061624.09477.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2492647.JvBzrJ7ffY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507142116.42991.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-hackers@freebsd.org Subject: Re: Call for FreeBSD status reports 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, 14 Jul 2005 19:16:47 -0000 --nextPart2492647.JvBzrJ7ffY Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is a friendly reminder that we are collecting status reports. =20 Submissions are due tomorrow (July 15). If you are planning to submit=20 something, but won't be able to make the formal deadline - please let us=20 know, we are willing to extend the deadline a bit for a broader turnout. Looking forward to receiving your reports! On Wednesday 06 July 2005 16:24, I wrote: > All, > > Three month of fruitful development have passed since the last round of > FreeBSD status reports, and the release of FreeBSD 6.0 is on the > doorstep. =A0We hope that you made good progress on your projects and have > interesting news to share. =A0Please do so by sending a status report to > monthly@freebsd.org Submissions are due by July 15, 2005. > > Reports should cover activities during May to June, but may of course cov= er > earlier work as well. =A0In addition we encourage you to use the "Open Ta= sks" > section to recruit help for your project and point out future direction. > > Submissions are *not* limited to FreeBSD developers with commit rights! = =A0It > is open to everybody who is doing FreeBSD related work and wants to share > progress with the community. =A0The status reports are also a good vehicl= e to > gather interested people for you WIP. > > We have introduced a new category called "soc" to pool reports related to > Google Summer of Code. =A0We hope for interesting news from that corner! > > To help you with fileing your report you will find a webform or > xml-template linked from http://www.freebsd.org/news/status/ (as soon as > the www build completes). > > Submissions are due on July 15. =A0Thanks a lot, and we are hoping for a = big > turn-out. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2492647.JvBzrJ7ffY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC1roaXyyEoT62BG0RAlclAJ9tGsVewSaXxK077Xk60WJb+KUpaQCfS8PE lkzoTJ+QdOLT+nritZUEceM= =QnqM -----END PGP SIGNATURE----- --nextPart2492647.JvBzrJ7ffY-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:18:35 2005 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 BE77716A41C; Thu, 14 Jul 2005 19:18:35 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 844BD43D46; Thu, 14 Jul 2005 19:18:35 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 271D12AF61; Thu, 14 Jul 2005 14:18:35 -0500 (CDT) Date: Thu, 14 Jul 2005 14:18:32 -0500 From: Craig Boston To: Brooks Davis Message-ID: <20050714191832.GA7462@nowhere> Mail-Followup-To: Craig Boston , Brooks Davis , Robert Watson , freebsd-current@freebsd.org References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714185851.GE19351@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 19:18:35 -0000 On Thu, Jul 14, 2005 at 11:58:51AM -0700, Brooks Davis wrote: > I'm seeing this as well. I think we're going to need to handle wireless > and wired interfaces differently since their links work differently. If anything, please PLEEEEEASE make it possible to disable this behavior for ALL interface types. There's nothing more annoying (to me) than unplugging a Windows 2000 machine for half a second to reroute or swap a network cable, then finding that all the open connections were terminated because it briefly lost its IP address. With FreeBSD 4.x and 5.x and probably many others, it's no problem -- as long as everything is back before the TCP retry timeout it will happily continue as if nothing happened. Craig From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:31:02 2005 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 4E1EB16A41C; Thu, 14 Jul 2005 19:31:02 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF54943D45; Thu, 14 Jul 2005 19:31:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j6EJUbWi002834; Thu, 14 Jul 2005 12:30:37 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6EJUbi2002833; Thu, 14 Jul 2005 12:30:37 -0700 Date: Thu, 14 Jul 2005 12:30:37 -0700 From: Brooks Davis To: Frank Mayhar Message-ID: <20050714193037.GF19351@odin.ac.hmc.edu> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rMWmSaSbD7nr+du9" Content-Disposition: inline In-Reply-To: <1121368125.83653.12.camel@realtime.exit.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 19:31:02 -0000 --rMWmSaSbD7nr+du9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2005 at 12:08:45PM -0700, Frank Mayhar wrote: > On Thu, 2005-07-14 at 11:58 -0700, Brooks Davis wrote: > > I'm seeing this as well. I think we're going to need to handle wireless > > and wired interfaces differently since their links work differently. >=20 > I tend to disagree with this view. In general, while wired connections > may often be more persistent than wireless connections, that's not > necessarily always true. It's certainly possible to move a system > between wired connections as well >=20 > I think that it makes more sense for the configuration of the two types > to be the same, anyway, just for consistency. It's the same basic > problem that is being solved, and if the solution for wireless > interfaces is reasonably robust, it should work just fine for wired ones > as well. The problem with attemping to keep them looking the same is that wireless interfaces have more complex state. We're currently trying to paper over that, but it isn't really working. With wired interfaces, you either have a cable with something on it plugged in or you don't (at least until we get 802.1x support). With wireless interfaces, you can change association relativly seamlessly so mapping associate/deassociate to linkup/linkdown as we do now is bogus. In the end, from the user perspective, there should be no visiable difference between wired and wireless interfaces unless you try mucking with the devd config or need to use WPA. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --rMWmSaSbD7nr+du9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC1r0GXY6L6fI4GtQRAr9gAKDAQsb3pIrVkiI+Z4IDdgYVaU/QoQCaAxSm J44aHgWGtbLyKTO8p7jSr3A= =khrL -----END PGP SIGNATURE----- --rMWmSaSbD7nr+du9-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:36:51 2005 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 2320016A41C for ; Thu, 14 Jul 2005 19:36:51 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from karen.nerdshack.com (karen.nerdshack.com [209.189.235.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB25243D46 for ; Thu, 14 Jul 2005 19:36:50 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from dispatchd.nerdshack.com (julie.nerdshack.com [209.189.235.39]) by karen.nerdshack.com (Postfix) with SMTP id 35CF91E31EC for ; Thu, 14 Jul 2005 14:33:52 -0500 (CDT) Received: from 85.95.160.97 (85-95-160-97-dialup.saransk.ru [85.95.160.97]) by mail.nerdshack.com with ESMTP Thu, 14 Jul 2005 14:34:30 -0500 Message-ID: <42D6BED3.3030602@nerdshack.com> Date: Thu, 14 Jul 2005 15:36:51 -0400 From: nj18 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050711 X-Accept-Language: en-us, en To: freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange message: Text file busy. 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, 14 Jul 2005 19:36:51 -0000 On FreeBSD 5.4: > uname -a FreeBSD phoenix.domain 5.4-STABLE FreeBSD 5.4-STABLE #0: Sun Jul 10 18:54:13 EDT 2005 [1]root@phoenix.domain:/usr/obj/usr/src/sys/GENERIC i386 > echo date >somescript > chmod +x somescript > ./somescript ./somescript: Text file busy. What does mean this message at the end: "Text file busy."? I thought its a bug in tcsh, but I have this message again with sh. However, I can run this script with command "sh somescript": > sh somescript Thu Jul 14 15:24:28 EDT 2005 I cant run "./somescript" on other terminal even as root. However if I log out and than login again I can run it: > ./somescript Thu Jul 14 15:27:06 EDT 2005 On FreeBSD 4.6 everything is ok: > echo date >somescript > chmod +x somescript > ./somescript Thu Jul 14 15:14:05 EDT 2005 > uname -a FreeBSD m-net.arbornet.org 4.6.2-RELEASE-p26 FreeBSD 4.6.2-RELEASE-p26 #7: Sun Oct 5 00:39:40 EDT 2003 [2]styles@m-net.arbornet.org:/source/stable/src/sys/compile/MNET i386 > sh somescript Thu Jul 14 15:24:37 EDT 2005 > What is this? Is it a bug in FreeBSD 5.4? And if it is a bug how can I fix it? References 1. mailto:root@phoenix.domain:/usr/obj/usr/src/sys/GENERIC 2. mailto:styles@m-net.arbornet.org:/source/stable/src/sys/compile/MNET From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:45:12 2005 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 431BB16A41C for ; Thu, 14 Jul 2005 19:45:12 +0000 (GMT) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D28643D53 for ; Thu, 14 Jul 2005 19:45:10 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 97247 invoked from network); 14 Jul 2005 19:45:09 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 14 Jul 2005 19:45:09 -0000 X-pair-Authenticated: 80.161.118.233 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j6EJj8Wa048213; Thu, 14 Jul 2005 21:45:08 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j6EJj8d9048212; Thu, 14 Jul 2005 21:45:08 +0200 (CEST) (envelope-from pho) Date: Thu, 14 Jul 2005 21:45:08 +0200 From: Peter Holm To: Gleb Smirnoff Message-ID: <20050714194508.GA48176@peter.osted.lan> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> <20050714183932.GA46344@peter.osted.lan> <20050714191042.GA21991@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714191042.GA21991@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: maxim@freebsd.org, sam@freebsd.org, current@freebsd.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 19:45:12 -0000 On Thu, Jul 14, 2005 at 11:10:42PM +0400, Gleb Smirnoff wrote: > On Thu, Jul 14, 2005 at 08:39:32PM +0200, Peter Holm wrote: > P> > On Wed, Jul 13, 2005 at 10:51:55AM +0200, Peter Holm wrote: > P> > P> > how often the panic in subject fires? I guess it is related to the problem > P> > P> > discussed in this thread [1], and may be even the patch I've posted there > P> > P> > will help. > P> > P> > > P> > P> > P> > P> The panic is almost instantanious if I run the stress test while doing > P> > P> an "arp -d xxx". > P> > > P> > The attached WIP patch helps me. The [1] script can't drop my box to panic > P> > anymore, when running in 15 instances on 4-x CPU box. > P> > P> Yes, works for me! I've been testing for three hours without any > P> problems and then ran into another unrelated livelock. > > Were you running it with WITNESS or without? How many CPUs does your box have? > I've got a hard panic without access to ddb when running without WITNESS. > I think WITNESS slowness can hide some races. I'll continue to work on this > tomorrow. > Single CPU + WITNESS: $ diff GENERIC PHO 68a69 > options BREAK_TO_DEBUGGER 295a297,303 > > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options KTR > options KTR_ENTRIES=4096 > options KTR_MASK=(KTR_BUF|KTR_VFS) > options KTR_COMPILE=(KTR_BUF|KTR_VFS) - Peter > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:46:45 2005 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 CF82616A41C for ; Thu, 14 Jul 2005 19:46:45 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C133143D46 for ; Thu, 14 Jul 2005 19:46:42 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.3/8.13.3) with ESMTP id j6EJkr2V041520 for ; Thu, 14 Jul 2005 15:46:53 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.3/8.13.3/Submit) with ESMTP id j6EJkrfL041517 for ; Thu, 14 Jul 2005 15:46:53 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 14 Jul 2005 15:46:53 -0400 (EDT) From: "Andrew R. Reiter" To: freebsd-current@freebsd.org In-Reply-To: <20050629145451.J85841@fledge.watson.org> Message-ID: <20050714154617.F41494@fledge.watson.org> References: <20050629145451.J85841@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [CFT] NDIS optional header length related fixups 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, 14 Jul 2005 19:46:46 -0000 Due to a lack of response from most parties, I created a PR for the below. It can be viewed at: http://www.freebsd.org/cgi/query-pr.cgi?pr=83477 Thanks, Andrew On Wed, 29 Jun 2005, Andrew R. Reiter wrote: :Calling NDIS -CURRENT users, : :Attached is a patch that should fix any possible issues with mis-calculating :offsets or sizes when dealing with anything 'image_optional_header' related in :the PE loading code. The reason for the patch is that the optional header can :have a varying length due to the lack of requiring the existence of all the :'image_data_directory's to exist within a binary. As far as I can tell, most :drivers tend to include all, but due to the basic idea that there can be less :than IMAGE_DIRECTORY_ENTRIES_MAX data directories in the optional header, we :should at least make an attempt at preemptively catch any bugs that might arise :due to improper pointer calculation. : :If you could, please give it a run in your tree! : :The patch is also located at: : http://www.watson.org/~arr/ndis_opthdrsz.diff : :I guess let me know if anyone has any problems with this working (or other). : :Cheers, :Andrew : :-- :Andrew R. Reiter :arr@watson.org -- Andrew R. Reiter arr@watson.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:48:49 2005 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 9B05516A41C; Thu, 14 Jul 2005 19:48:49 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4ECB43D48; Thu, 14 Jul 2005 19:48:48 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6EJmlDS022746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 23:48:47 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6EJmk8l022745; Thu, 14 Jul 2005 23:48:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2005 23:48:46 +0400 From: Gleb Smirnoff To: Peter Holm Message-ID: <20050714194846.GB21991@cell.sick.ru> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> <20050714183932.GA46344@peter.osted.lan> <20050714191042.GA21991@cell.sick.ru> <20050714194508.GA48176@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050714194508.GA48176@peter.osted.lan> User-Agent: Mutt/1.5.6i Cc: maxim@FreeBSD.org, sam@FreeBSD.org, current@FreeBSD.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 19:48:49 -0000 On Thu, Jul 14, 2005 at 09:45:08PM +0200, Peter Holm wrote: P> Single CPU + WITNESS: PREEMPTION? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:09:06 2005 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 9508C16A41C for ; Thu, 14 Jul 2005 20:09:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A7343D53 for ; Thu, 14 Jul 2005 20:09:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id B093446BC1; Thu, 14 Jul 2005 16:09:05 -0400 (EDT) Date: Thu, 14 Jul 2005 21:09:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <42D6BBD1.3080502@elischer.org> Message-ID: <20050714203023.M35071@fledge.watson.org> References: <20050714184159.W35071@fledge.watson.org> <42D6BBD1.3080502@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: libmemstat(3) - Library for monitoring kernel memory use 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, 14 Jul 2005 20:09:06 -0000 On Thu, 14 Jul 2005, Julian Elischer wrote: >> I've put some sample code for using libmemstat(3) up at the following URL: >> >> http://www.watson.org/~robert/freebsd/libmemstat/ > > cool. got sample output? Re-added the CC in case anyone else is interested. As I said, I'm no ncurses expert, but the output from my memtop(8) is suggestive of what might be accomplished by someone with a bit more clue than me. memtop is running "-a", meaning use all available allocators (uma and malloc), and is sorting by the total number of operations per type, which is sometimes but not always the same as the total amount of data by type, or the absolute value of the delta change in allocations or bytes. I've tweaked memtop(8) to use a 5 second delay below, something that currently requires a source code change: As I log in via SSH: Type Alloc #Alloc'd #Free'd Delta DeltaBytes PV ENTRY uma 6025 3911 2114 50736 NAMEI uma 529 529 0 0 MAP ENTRY uma 568 388 180 12240 128 uma 254 143 111 14208 VM OBJECT uma 244 142 102 13464 Files uma 192 183 9 648 Mbuf uma 132 132 0 0 cred malloc 92 88 4 512 soname malloc 70 70 0 0 ttys malloc 105 0 105 13440 ioctlops malloc 51 51 0 0 16 uma 49 49 0 0 64 uma 47 45 2 128 Packet uma 36 36 0 0 256 uma 26 22 4 1024 32 uma 25 21 4 128 socket uma 23 20 3 1068 temp malloc 17 17 0 0 unpcb uma 17 15 2 280 4096 uma 13 10 3 12288 proc-args malloc 12 9 3 96 plimit malloc 11 10 1 256 sysctl malloc 9 9 0 0 As i run du from an SSH session: Type Alloc #Alloc'd #Free'd Delta DeltaBytes NAMEI uma 31177 31177 0 0 S VFS Cache uma 26957 8370 18587 1263916 VNODE uma 23416 7052 16364 4451008 FFS inode uma 23416 6942 16474 2174568 FFS2 dinode uma 23416 6942 16474 4217344 g_bio uma 7016 7020 -4 -528 KMAP ENTRY uma 3295 3296 -1 -68 Files uma 2720 2721 -1 -72 Mbuf uma 2540 2541 -1 -256 ata_request uma 1886 1888 -2 -400 VM OBJECT uma 1359 7 1352 178464 Packet uma 632 633 -1 -256 PV ENTRY uma 233 90 143 3432 L VFS Cache uma 136 80 56 16296 DIRHASH uma 107 0 107 109568 ufs_dirhash malloc 93 0 93 17328 16 uma 47 2 45 720 UMA Slabs uma 40 2 38 2432 512 uma 31 0 31 15872 32 uma 17 4 13 416 NFSNODE uma 0 13 -13 -5980 sysctl malloc 6 6 0 0 128 Bucket uma 10 0 10 5240 As I run ping -f on a serial console: Type Alloc #Alloc'd #Free'd Delta DeltaBytes Mbuf uma 7236 7235 1 256 16 uma 4100 4100 0 0 soname malloc 2905 2905 0 0 Packet uma 1978 1978 0 0 iov malloc 1194 1194 0 0 PV ENTRY uma 80 47 33 792 sysctl malloc 6 6 0 0 KMAP ENTRY uma 4 4 0 0 32 uma 4 4 0 0 temp malloc 2 2 0 0 UMA Slabs uma 2 2 0 0 64 uma 1 1 0 0 ioctlops malloc 1 1 0 0 MAP ENTRY uma 1 1 0 0 As I run netblast with 0-byte UDP packets: Type Alloc #Alloc'd #Free'd Delta DeltaBytes Mbuf uma 292138 292135 3 768 Packet uma 796 796 0 0 g_bio uma 76 76 0 0 PV ENTRY uma 80 47 33 792 ata_request uma 23 23 0 0 sysctl malloc 6 6 0 0 32 uma 4 4 0 0 KMAP ENTRY uma 4 4 0 0 temp malloc 2 2 0 0 16 uma 2 2 0 0 UMA Slabs uma 2 2 0 0 MAP ENTRY uma 1 1 0 0 ioctlops malloc 1 1 0 0 64 uma 1 1 0 0 Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:10:04 2005 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 C4DC316A41C; Thu, 14 Jul 2005 20:10:04 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC2C43D4C; Thu, 14 Jul 2005 20:10:03 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j6EK9hmO059302; Thu, 14 Jul 2005 15:09:44 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42D6C686.4070407@centtech.com> Date: Thu, 14 Jul 2005 15:09:42 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> <20050714193037.GF19351@odin.ac.hmc.edu> In-Reply-To: <20050714193037.GF19351@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/978/Thu Jul 14 06:37:27 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: Robert Watson , freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 20:10:05 -0000 Brooks Davis wrote: > On Thu, Jul 14, 2005 at 12:08:45PM -0700, Frank Mayhar wrote: > >>On Thu, 2005-07-14 at 11:58 -0700, Brooks Davis wrote: >> >>>I'm seeing this as well. I think we're going to need to handle wireless >>>and wired interfaces differently since their links work differently. >> >>I tend to disagree with this view. In general, while wired connections >>may often be more persistent than wireless connections, that's not >>necessarily always true. It's certainly possible to move a system >>between wired connections as well >> >>I think that it makes more sense for the configuration of the two types >>to be the same, anyway, just for consistency. It's the same basic >>problem that is being solved, and if the solution for wireless >>interfaces is reasonably robust, it should work just fine for wired ones >>as well. > > > The problem with attemping to keep them looking the same is that > wireless interfaces have more complex state. We're currently trying to > paper over that, but it isn't really working. With wired interfaces, you > either have a cable with something on it plugged in or you don't (at > least until we get 802.1x support). With wireless interfaces, you can > change association relativly seamlessly so mapping associate/deassociate > to linkup/linkdown as we do now is bogus. In the end, from the user > perspective, there should be no visiable difference between wired and > wireless interfaces unless you try mucking with the devd config or need > to use WPA. Here's what I think would work well in most situations: if an interface (A) changes from down->up, and was not previously configured with dhclient, dhclient should run on it (if set in rc.conf). If another interface (B) is currently down, that has dhclient running on it, then when interface (A) comes up with a valid ip, it should remove the ip info from interface (B). if an interface (A) changes from up->down, and dhclient is running on it, it should not do anything. if an interface (A) changes from down->up, and dhclient is running on it, and no other interfaces are up, it should try to get it's lease, without changing it's current IP setup until it has the new information. If an interface (A) changes from down->up has conflicting IP information with an interface (B) that is down, that dhclient manages, it should remove the IP setup from interface (B), and set routes according to the newly upped interface. If an interface (A) changes from down->up, and there is another interface (B) that is up that dhclient manages, then configure interface (A) only if it will not conflict with the other interface's (B) network. This could be an rc.conf option - to force newly brought up interfaces to override currently up interfaces. Anything I missed? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:21:02 2005 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 693DE16A41C for ; Thu, 14 Jul 2005 20:21:02 +0000 (GMT) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 1546243D48 for ; Thu, 14 Jul 2005 20:21:00 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 98004 invoked from network); 14 Jul 2005 20:20:59 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 14 Jul 2005 20:20:59 -0000 X-pair-Authenticated: 80.161.118.233 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j6EKKxvS048332; Thu, 14 Jul 2005 22:20:59 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j6EKKwY4048331; Thu, 14 Jul 2005 22:20:58 +0200 (CEST) (envelope-from pho) Date: Thu, 14 Jul 2005 22:20:58 +0200 From: Peter Holm To: Gleb Smirnoff Message-ID: <20050714202058.GA48308@peter.osted.lan> References: <20050713083756.GA3728@cell.sick.ru> <20328.193.162.192.11.1121244715.squirrel@webmail2.pair.com> <20050714111043.GA17494@cell.sick.ru> <20050714183932.GA46344@peter.osted.lan> <20050714191042.GA21991@cell.sick.ru> <20050714194508.GA48176@peter.osted.lan> <20050714194846.GB21991@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714194846.GB21991@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: maxim@freebsd.org, sam@freebsd.org, current@freebsd.org Subject: Re: http://www.holm.cc/stress/log/cons141.html 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, 14 Jul 2005 20:21:02 -0000 On Thu, Jul 14, 2005 at 11:48:46PM +0400, Gleb Smirnoff wrote: > On Thu, Jul 14, 2005 at 09:45:08PM +0200, Peter Holm wrote: > P> Single CPU + WITNESS: > > PREEMPTION? > Yes, all from GENERIC plus the stuff from the diff. - Peter > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:28:23 2005 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 AC2B616A41C; Thu, 14 Jul 2005 20:28:23 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F68943D48; Thu, 14 Jul 2005 20:28:23 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 58A3E74; Thu, 14 Jul 2005 22:28:21 +0200 (CEST) Date: Thu, 14 Jul 2005 22:28:21 +0200 From: Andrea Campi To: Eric Anderson Message-ID: <20050714202820.GE1064@webcom.it> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> <20050714193037.GF19351@odin.ac.hmc.edu> <42D6C686.4070407@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D6C686.4070407@centtech.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Problems with OpenBSD dhclient 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, 14 Jul 2005 20:28:23 -0000 picking one random message to answer to... On Thu, Jul 14, 2005 at 03:09:42PM -0500, Eric Anderson wrote: > Here's what I think would work well in most situations: > ... > > Anything I missed? let's not forget Zeroconf (169.254.x.x) address assignment. I have (admittedly outdated now) patches to howl to make it work that are waiting on someone to help me finalize them AND most integrate with appropriate scripts so that things work as expected. This means removing the autoconfigured address when obtaining a proper address via DHCP, and vice versa. A full solution should IMHO take this into account, too. Bye, Andrea -- Press every key to continue. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:28:57 2005 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 B97FB16A41C; Thu, 14 Jul 2005 20:28:57 +0000 (GMT) (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 2734E43D49; Thu, 14 Jul 2005 20:28:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6EKSZKn088730; Thu, 14 Jul 2005 16:28:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6EKStEC028866; Thu, 14 Jul 2005 16:28:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 17FFF7302F; Thu, 14 Jul 2005 16:28:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050714202855.17FFF7302F@freebsd-current.sentex.ca> Date: Thu, 14 Jul 2005 16:28:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on alpha/alpha 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, 14 Jul 2005 20:28:58 -0000 TB --- 2005-07-14 19:00:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-14 19:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-07-14 19:00:01 - cleaning the object tree TB --- 2005-07-14 19:00:26 - checking out the source tree TB --- 2005-07-14 19:00:26 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-07-14 19:00:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-14 19:06:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-14 19:06:49 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-07-14 19:06:49 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-07-14 20:13:49 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-14 20:13:49 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-07-14 20:13:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jul 14 20:13:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Jul 14 20:27:31 UTC 2005 TB --- 2005-07-14 20:27:31 - generating LINT kernel config TB --- 2005-07-14 20:27:31 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-07-14 20:27:31 - /usr/bin/make -B LINT TB --- 2005-07-14 20:27:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-14 20:27:31 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-07-14 20:27:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 14 20:27:31 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/libkern/iconv_converter_if.m -h awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/alpha/clock_if.m -h awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/pci/alphapci_if.m -h awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/dev/dec/mcclock_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ff ixed-8 -Wa,-mev6 -ffreestanding /tinderbox/CURRENT/alpha/alpha/src/sys/dev/usb/sl811hs.c:50:23: opt_slhci.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-07-14 20:28:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-14 20:28:54 - ERROR: failed to build lint kernel TB --- 2005-07-14 20:28:54 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:46:38 2005 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 1D16F16A41C for ; Thu, 14 Jul 2005 20:46:38 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from karen.nerdshack.com (karen.nerdshack.com [209.189.235.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA8D43D48 for ; Thu, 14 Jul 2005 20:46:37 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from dispatchd.nerdshack.com (jean.nerdshack.com [209.189.235.38]) by karen.nerdshack.com (Postfix) with SMTP id 591721E319D for ; Thu, 14 Jul 2005 15:43:39 -0500 (CDT) Received: from 85.95.160.34 (ns.szrt.ru [85.95.160.34]) by mail.nerdshack.com with ESMTP Thu, 14 Jul 2005 15:45:53 -0500 Message-ID: <42D6CF2A.7080704@nerdshack.com> Date: Thu, 14 Jul 2005 16:46:34 -0400 From: nj18 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050711 X-Accept-Language: en-us, en To: FreeBSD Current Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Strange message: Text file busy 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, 14 Jul 2005 20:46:38 -0000 Ed Schouten wrote: * nj18 [1] wrote: echo date >somescript chmod +x somescript ./somescript ./somescript: Text file busy. What if you put the following contents in somescript: #!/bin/sh date I guess FreeBSD 4.6 takes /bin/sh as the interpreter by default, but FreeBSD 5 and higher don't. Yours, No, it doesnt work in FreeBSD 5.4: > echo "#\!/bin/sh" >somescript > echo date >>somescript > cat somescript #!/bin/sh date > chmod +x somescript > ./somescript ./somescript: Text file busy. > The strangest thing is that the following works fine on FreeBSD 5.4: > cat >somescript date > chmod +x somescript > ./somescript Thu Jul 14 16:37:53 EDT 2005 > I guess it's a problem about "echo". I am going to compare /usr/src/bin/echo/echo.c in FreeBSD 5.4. and FreeBSD 4.6. References 1. mailto:nj18@nerdshack.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:48:54 2005 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 1C96916A41C; Thu, 14 Jul 2005 20:48:54 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3F3A43D45; Thu, 14 Jul 2005 20:48:53 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 6D8EB19F52; Thu, 14 Jul 2005 13:51:09 -0700 (PDT) From: "Darren Pilgrim" To: "'Bakul Shah'" , "'Robert Watson'" Date: Thu, 14 Jul 2005 13:48:52 -0700 Message-ID: <002c01c588b5$72661d00$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <200507141914.j6EJEneq070016@gate.bitblocks.com> Importance: Normal Cc: freebsd-current@freebsd.org Subject: RE: Problems with OpenBSD dhclient 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, 14 Jul 2005 20:48:54 -0000 From: Bakul Shah > > To avoid interface flapping perhaps some hysteresis needs to > be introduced in dhclient? If a link up event occurs within > N seconds of a link down event, ignore them both! N may need > to be tunable. Such hysteresis is _not_ needed for > administrative up/down -- when I say `ifconfig ath0 down', I > want it down *now*! It would be better to disconnect association events from link events. If anything, link events should be tied to the radio being turned on or off. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:00:44 2005 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 C88A016A41C; Thu, 14 Jul 2005 21:00:44 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B0AF43D45; Thu, 14 Jul 2005 21:00:44 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j6EL3Y1M077790; Thu, 14 Jul 2005 17:03:34 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: NIKSUN, Inc. To: freebsd-current@FreeBSD.org Date: Thu, 14 Jul 2005 17:00:25 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_rJt1CA5E1P5FQvy" Message-Id: <200507141700.27657.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.85.1/978/Thu Jul 14 07:37:27 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: phantom@FreeBSD.org Subject: NLS status? 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, 14 Jul 2005 21:00:44 -0000 --Boundary-00=_rJt1CA5E1P5FQvy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I have been using NLS support for months (enabled with the attached patch). However the following commit message said that there were 'edge cases': http://docs.freebsd.org/cgi/mid.cgi?200502272217.j1RMHlJA047283 Is this still true? Can it be re-enabled on HEAD? Thanks, Jung-uk Kim --Boundary-00=_rJt1CA5E1P5FQvy Content-Type: text/x-diff; charset="us-ascii"; name="nls.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nls.diff" Index: src/Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.499 diff -u -r1.499 Makefile.inc1 --- src/Makefile.inc1 7 Jul 2005 00:58:41 -0000 1.499 +++ src/Makefile.inc1 14 Jul 2005 20:37:25 -0000 @@ -370,7 +370,7 @@ @echo "--------------------------------------------------------------" ${_+_}cd ${.CURDIR}; \ ${WMAKE} -DNO_FSCHG -DNO_HTML -DNO_INFO -DNO_LINT -DNO_MAN \ - -DNO_NLS -DNO_PROFILE libraries + -DNO_PROFILE libraries _depend: @echo @echo "--------------------------------------------------------------" Index: src/lib/libc/Makefile =================================================================== RCS file: /home/ncvs/src/lib/libc/Makefile,v retrieving revision 1.56 diff -u -r1.56 Makefile --- src/lib/libc/Makefile 15 Jan 2005 05:23:56 -0000 1.56 +++ src/lib/libc/Makefile 14 Jul 2005 20:37:25 -0000 @@ -37,7 +37,10 @@ .endif .include "${.CURDIR}/locale/Makefile.inc" .include "${.CURDIR}/net/Makefile.inc" +.if !defined(NO_NLS) +CFLAGS+= -DNLS .include "${.CURDIR}/nls/Makefile.inc" +.endif .include "${.CURDIR}/posix1e/Makefile.inc" .if !defined(NO_QUAD) .include "${.CURDIR}/quad/Makefile.inc" Index: src/lib/libc/nls/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/nls/Makefile.inc,v retrieving revision 1.10 diff -u -r1.10 Makefile.inc --- src/lib/libc/nls/Makefile.inc 27 Feb 2005 22:17:47 -0000 1.10 +++ src/lib/libc/nls/Makefile.inc 14 Jul 2005 20:37:25 -0000 @@ -6,3 +6,17 @@ SRCS+= msgcat.c MAN+= catclose.3 catgets.3 catopen.3 + +# NOTE: C.msg should not be processed here, it's using as template +# for translators. + +NLSNAME= libc +NLSLANG+= ko_KR.UTF-8 +NLSLANG+= ko_KR.eucKR +NLSLANG+= pl_PL.ISO8859-2 +NLSLANG+= ru_RU.KOI8-R + +NLSSRCDIR= ${.CURDIR}/nls +.for lang in ${NLSLANG} +NLSSRCFILES_${lang}=${lang}.msg +.endfor --Boundary-00=_rJt1CA5E1P5FQvy-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:01:42 2005 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 287D816A41C for ; Thu, 14 Jul 2005 21:01:42 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from kelly.nerdshack.com (kelly.nerdshack.com [209.189.235.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C525443D49 for ; Thu, 14 Jul 2005 21:01:41 +0000 (GMT) (envelope-from nj18@nerdshack.com) Received: from dispatchd.nerdshack.com (julie.nerdshack.com [209.189.235.39]) by kelly.nerdshack.com (Postfix) with SMTP id 3ABBE902D3 for ; Thu, 14 Jul 2005 15:59:54 -0500 (CDT) Received: from 85.95.160.34 (ns.szrt.ru [85.95.160.34]) by mail.nerdshack.com with ESMTP Thu, 14 Jul 2005 15:59:21 -0500 Message-ID: <42D6D2B7.2080406@nerdshack.com> Date: Thu, 14 Jul 2005 17:01:43 -0400 From: nj18 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050711 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Strange message: Text file busy. 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, 14 Jul 2005 21:01:42 -0000 Ed Schouten wrote: >* nj18 wrote: > > >>>echo date >somescript >>>chmod +x somescript >>>./somescript >>> >>> >>./somescript: Text file busy. >> >> > >What if you put the following contents in somescript: > >#!/bin/sh >date > >I guess FreeBSD 4.6 takes /bin/sh as the interpreter by default, but >FreeBSD 5 and higher don't. > >Yours, > > I compiled src/bin/echo/ from FreeBSD 5.2.1 disk. It works fine: > ./echo date >somescript > chmod +x somescript > ./somescript Thu Jul 14 17:00:43 EDT 2005 > From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:05:18 2005 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 DA10616A481 for ; Thu, 14 Jul 2005 21:05:18 +0000 (GMT) (envelope-from slawek.zak@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0892F43D53 for ; Thu, 14 Jul 2005 21:05:17 +0000 (GMT) (envelope-from slawek.zak@gmail.com) Received: by zproxy.gmail.com with SMTP id i1so281231nzh for ; Thu, 14 Jul 2005 14:05:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=BAJaH2y4umwBVd0b8ry6tRZsVlnM2IiVhzb6eWwjuTL56pxCtv5fb4HatnX1h+brYxXIKQWKm3oyBFXbSpys9XmtL6r1WB43+vHDtXEP0Qv0ayrzO85BxaKWEsVatBXvIiEmP4mRZ9U5+Nmam8JY+Skyhyo7WXJcRdPuj64oVPY= Received: by 10.36.119.13 with SMTP id r13mr664324nzc; Thu, 14 Jul 2005 13:58:35 -0700 (PDT) Received: by 10.36.89.16 with HTTP; Thu, 14 Jul 2005 13:58:35 -0700 (PDT) Message-ID: <787bbe1c0507141358ffb3c4c@mail.gmail.com> Date: Thu, 14 Jul 2005 22:58:35 +0200 From: =?ISO-8859-2?Q?S=B3awek_=AFak?= To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23328_30782541.1121374715567" Subject: USB controller not found/working on Sun V40z workstation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?S=B3awek_=AFak?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 21:05:19 -0000 ------=_Part_23328_30782541.1121374715567 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Problem stated in the subject. I need USB to work badly, as there is no PS/2 for keyboard and mouse in this workstation. I've tried 5.4 STABLE, 6.0 CURRENT and 6.0 BETA. Out of 30 boots USB was detected twice and keyboard was working too. I attach log from two of those successful boots (5.3 RELEASE and 6.0 CURRENT) and a late one from 6.0 BETA boot -v. Kernel config is attached too. Any help and suggestions appreciated! Thanks, /S ------=_Part_23328_30782541.1121374715567 Content-Type: text/plain; name="messages-5.ok.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages-5.ok.txt" SnVsICAxIDA3OjM1OjU5IGxhbWJkYSBzeXNsb2dkOiBrZXJuZWwgYm9vdCBmaWxlIGlzIC9ib290 L2tlcm5lbC9rZXJuZWwKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IENvcHlyaWdodCAo YykgMTk5Mi0yMDA0IFRoZSBGcmVlQlNEIFByb2plY3QuCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODks IDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBGcmVlQlNEIDUuMy1SRUxFQVNF ICMwOiBGcmkgTm92ICA1IDAzOjUwOjAxIFVUQyAyMDA0Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiByb290QGZhbmJveS5zYW1zY28uaG9tZTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5F UklDCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBBQ1BJIEFQSUMgVGFibGU6IDxQVExU RCAgCSBBUElDICA+Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBUaW1lY291bnRlciAi aTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApKdWwgIDEgMDc6MzU6NTkgbGFt YmRhIGtlcm5lbDogQ1BVOiBBTUQgT3B0ZXJvbih0bSkgUHJvY2Vzc29yIDI0NiAoMTk5NC4zMy1N SHogSzgtY2xhc3MgQ1BVKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogT3JpZ2luID0g IkF1dGhlbnRpY0FNRCIgIElkID0gMHhmNWEgIFN0ZXBwaW5nID0gMTAKSnVsICAxIDA3OjM1OjU5 IGxhbWJkYSBrZXJuZWw6IEZlYXR1cmVzPTB4NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNS LFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNI LE1NWCxGWFNSLFNTRSxTU0UyPgpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogQU1EIEZl YXR1cmVzPTB4ZTA1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLExNLDNETm93KywzRE5vdz4KSnVsICAx IDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDIxNDY4MjgyODggKDIwNDcg TUIpCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBhdmFpbCBtZW1vcnkgPSAyMDYxMzIw MTkyICgxOTY1IE1CKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogTUFEVDogRm9yY2lu ZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZvciBTQ0kKSnVsICAxIDA3 OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24g bW90aGVyYm9hcmQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzEgPFZlcnNp b24gMS4xPiBpcnFzIDI0LTI3IG9uIG1vdGhlcmJvYXJkCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiBpb2FwaWMyIDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBvbiBtb3RoZXJib2FyZApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogaW9hcGljMyA8VmVyc2lvbiAxLjE+IGlycXMg MzItMzUgb24gbW90aGVyYm9hcmQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGlvYXBp YzQgPFZlcnNpb24gMS4xPiBpcnFzIDM2LTM5IG9uIG1vdGhlcmJvYXJkCkp1bCAgMSAwNzozNTo1 OSBsYW1iZGEga2VybmVsOiBhY3BpMDogPFBUTFREIAkgWFNEVD4gb24gbW90aGVyYm9hcmQKSnVs ICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWNwaV9idXNfbnVtYmVyOiBjYW4ndCBnZXQg X0FEUgpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWNwaV9idXNfbnVtYmVyOiBjYW4n dCBnZXQgX0FEUgpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogdW5rbm93bjogSS9PIHJh bmdlIG5vdCBzdXBwb3J0ZWQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHVua25vd246 IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBU aW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAK SnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVy IGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODAwOC0weDgwMGIgb24gYWNwaTAKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IGNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IGFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApKdWwg IDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBv biBhY3BpMApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpYjA6IDxBQ1BJIEhvc3Qt UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApKdWwgIDEgMDc6MzU6NTkgbGFt YmRhIGtlcm5lbDogcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKSnVsICAxIDA3OjM1OjU5 IGxhbWJkYSBrZXJuZWw6IHBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYu MCBvbiBwY2kwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBwY2kxOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogb2hjaTA6IDxORUMg dVBEIDkyMTAgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGUwMTA2MDAwLTB4ZTAxMDZmZmYgaXJxIDE4 IGF0IGRldmljZSAzLjAgb24gcGNpMQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogb2hj aTA6IFtHSUFOVC1MT0NLRURdCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiB1c2IwOiBP SENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtl cm5lbDogdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGluZwpKdWwgIDEgMDc6MzU6 NTkgbGFtYmRhIGtlcm5lbDogdXNiMDogPE5FQyB1UEQgOTIxMCBVU0IgY29udHJvbGxlcj4gb24g b2hjaTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHVzYjA6IFVTQiByZXZpc2lvbiAx LjAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHVodWIwOiBORUMgT0hDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKSnVsICAxIDA3OjM1OjU5IGxhbWJk YSBrZXJuZWw6IHVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogdW1zMDogU3VuIE1pY3Jvc3lzdGVtcyBUeXBl IDYgVVNCIG1vdXNlLCByZXYgMi4wMC8xLjA3LCBhZGRyIDIsIGljbGFzcyAzLzEKSnVsICAxIDA3 OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHVtczA6IDMgYnV0dG9ucwpKdWwgIDEgMDc6MzU6NTkgbGFt YmRhIGtlcm5lbDogb2hjaTE6IDxORUMgdVBEIDkyMTAgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGUw MTA3MDAwLTB4ZTAxMDdmZmYgaXJxIDE5IGF0IGRldmljZSAzLjEgb24gcGNpMQpKdWwgIDEgMDc6 MzU6NTkgbGFtYmRhIGtlcm5lbDogb2hjaTE6IFtHSUFOVC1MT0NLRURdCkp1bCAgMSAwNzozNTo1 OSBsYW1iZGEga2VybmVsOiB1c2IxOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogdXNiMTogU01NIGRvZXMgbm90IHJlc3BvbmQs IHJlc2V0dGluZwpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogdXNiMTogPE5FQyB1UEQg OTIxMCBVU0IgY29udHJvbGxlcj4gb24gb2hjaTEKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJu ZWw6IHVzYjE6IFVTQiByZXZpc2lvbiAxLjAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6 IHVodWIxOiBORUMgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDEKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHVodWIxOiAyIHBvcnRzIHdpdGggMiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogdWti ZDA6IFN1biBNaWNyb3N5c3RlbXMgVHlwZSA2IFVTQiBrZXlib2FyZCwgcmV2IDEuMTAvMi4wMCwg YWRkciAyLCBpY2xhc3MgMy8xCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBrYmQxIGF0 IHVrYmQwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBwY2kxOiA8c2VyaWFsIGJ1cywg VVNCPiBhdCBkZXZpY2UgMy4yIChubyBkcml2ZXIgYXR0YWNoZWQpCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBpc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBj aTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGlzYTA6IDxJU0EgYnVzPiBvbiBpc2Fi MApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYXRhcGNpMDogPEFNRCA4MTExIFVETUEx MzMgY29udHJvbGxlcj4gcG9ydCAweDE0NjAtMHgxNDZmLDB4Mzc2LDB4MTcwLTB4MTc3LDB4M2Y2 LDB4MWYwLTB4MWY3IGF0IGRldmljZSA3LjEgb24gcGNpMApKdWwgIDEgMDc6MzU6NTkgbGFtYmRh IGtlcm5lbDogYXRhMDogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCkp1bCAgMSAwNzozNTo1OSBsYW1i ZGEga2VybmVsOiBhdGExOiBjaGFubmVsICMxIG9uIGF0YXBjaTAKSnVsICAxIDA3OjM1OjU5IGxh bWJkYSBrZXJuZWw6IHBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDcuMiAobm8g ZHJpdmVyIGF0dGFjaGVkKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpMDogPGJy aWRnZSwgUENJLXVua25vd24+IGF0IGRldmljZSA3LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVs ICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQg ZGV2aWNlIDcuNSAobm8gZHJpdmVyIGF0dGFjaGVkKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtl cm5lbDogcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTAuMCBvbiBwY2kw Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMgpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpMDogPGJhc2UgcGVyaXBoZXJh bCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAxMC4xIChubyBkcml2ZXIgYXR0YWNo ZWQpCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBwY2liMzogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAxMS4wIG9uIHBjaTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJu ZWw6IHBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiBiZ2UwOiA8QnJvYWRjb20gQkNNNTcwMyBHaWdhYml0IEV0aGVybmV0LCBBU0lDIHJl di4gMHgxMDAyPiBtZW0gMHhlMDIwMDAwMC0weGUwMjBmZmZmIGlycSAyOCBhdCBkZXZpY2UgMi4w IG9uIHBjaTMKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IG1paWJ1czA6IDxNSUkgYnVz PiBvbiBiZ2UwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBicmdwaHkwOiA8QkNNNTcw MyAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKSnVsICAxIDA3OjM1OjU5IGxhbWJk YSBrZXJuZWw6IGJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBi YXNlVFgtRkRYLCAxMDAwYmFzZVRYLCAxMDAwYmFzZVRYLUZEWCwgYXV0bwpKdWwgIDEgMDc6MzU6 NTkgbGFtYmRhIGtlcm5lbDogYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGE6ZTQ6MmY6NWY6 ODMKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHBjaTA6IDxiYXNlIHBlcmlwaGVyYWws IGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTEuMSAobm8gZHJpdmVyIGF0dGFjaGVk KQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpYjQ6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gb24gYWNwaTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHBjaWI0OiBjb3Vs ZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXF9TQl8uUENJMSAtIEFF X05PVF9GT1VORApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpODogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHBjaWI1OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2k4Ckp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBwY2k5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpKdWwgIDEgMDc6MzU6 NTkgbGFtYmRhIGtlcm5lbDogcGNpOTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpYjY6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMy4wIG9uIHBjaTgKSnVsICAxIDA3OjM1OjU5 IGxhbWJkYSBrZXJuZWw6IHBjaTE0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpKdWwgIDEgMDc6 MzU6NTkgbGFtYmRhIGtlcm5lbDogcGNpODogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNv bnRyb2xsZXI+IGF0IGRldmljZSAzLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IHBjaWI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDQuMCBvbiBwY2k4Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBwY2kxOTogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjcKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFoZDA6IDxB ZGFwdGVjIEFJQzc5MDIgVWx0cmEzMjAgU0NTSSBhZGFwdGVyPiBwb3J0IDB4MjAwMC0weDIwZmYs MHgyNDAwLTB4MjRmZiBtZW0gMHhlMjAwMDAwMC0weGUyMDAxZmZmIGlycSAzOSBhdCBkZXZpY2Ug NC4wIG9uIHBjaTE5Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBhaGQwOiBbR0lBTlQt TE9DS0VEXQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWljNzkwMjogVWx0cmEzMjAg V2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgUENJLVggNjctMTAwTWh6LCA1MTIgU0NCcwpKdWwg IDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWhkMTogPEFkYXB0ZWMgQUlDNzkwMiBVbHRyYTMy MCBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHgyODAwLTB4MjhmZiwweDJjMDAtMHgyY2ZmIG1lbSAweGUy MDAyMDAwLTB4ZTIwMDNmZmYgaXJxIDM4IGF0IGRldmljZSA0LjEgb24gcGNpMTkKSnVsICAxIDA3 OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFtHSUFOVC1MT0NLRURdCkp1bCAgMSAwNzozNTo1 OSBsYW1iZGEga2VybmVsOiBhaWM3OTAyOiBVbHRyYTMyMCBXaWRlIENoYW5uZWwgQiwgU0NTSSBJ ZD03LCBQQ0ktWCA2Ny0xMDBNaHosIDUxMiBTQ0JzCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2Vy bmVsOiBwY2k4OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2 aWNlIDQuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5l bDogcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKSnVsICAxIDA3OjM1OjU5IGxh bWJkYSBrZXJuZWw6IHNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDJm OC0weDJmZiBpcnEgMyBmbGFncyAweDEwIG9uIGFjcGkwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiBzaW8wOiB0eXBlIDE2NTUwQQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDog c2lvMTogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IG9uIGFjcGkwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBzaW8xOiB0eXBlIDE2NTUw QQpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogcHBjMDogY2Fubm90IHJlc2VydmUgSS9P IHBvcnQgcmFuZ2UKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGF0a2JkYzA6IDxLZXli b2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2NCwweDYwIG9uIGlzYTAKSnVsICAx IDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGF0a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEg aXJxIDEgb24gYXRrYmRjMApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogZGV2aWNlX2F0 dGFjaDogYXRrYmQwIGF0dGFjaCByZXR1cm5lZCA2Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2Vy bmVsOiBwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpKdWwgIDEgMDc6MzU6NTkg bGFtYmRhIGtlcm5lbDogc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlz YTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHNjMDogVkdBIDwxNiB2aXJ0dWFsIGNv bnNvbGVzLCBmbGFncz0weDMwMD4KSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IHZnYTA6 IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJm ZmZmIG9uIGlzYTAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFRpbWVjb3VudGVyICJU U0MiIGZyZXF1ZW5jeSAxOTk0MzI4MDA1IEh6IHF1YWxpdHkgODAwCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBUaW1lY291bnRlcnMgdGljayBldmVyeSAwLjk3NiBtc2VjCkp1bCAgMSAw NzozNTo1OSBsYW1iZGEga2VybmVsOiBhY2QwOiBEVkRSIDxBT1BFTiBEVVcxNjA4L0FSUi9BMDRi PiBhdCBhdGExLW1hc3RlciBVRE1BNjYKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFj ZDE6IENEUlcgPEFPUEVOIENPTTUyMzIvQUFIIFBSTy8xLjA0PiBhdCBhdGExLXNsYXZlIFVETUEz MwpKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogV2FpdGluZyAxNSBzZWNvbmRzIGZvciBT Q1NJIGRldmljZXMgdG8gc2V0dGxlCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBhaGQw OiBJbnZhbGlkIFNlcXVlbmNlciBpbnRlcnJ1cHQgb2NjdXJyZWQuCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRHVtcCBDYXJkIFN0YXRlIEJlZ2lucyA8 PDw8PDw8PDw8PDw8PDw8PApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWhkMDogRHVt cGluZyBDYXJkIFN0YXRlIGF0IHByb2dyYW0gYWRkcmVzcyAweDIzYyBNb2RlIDB4MApKdWwgIDEg MDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogQ2FyZCB3YXMgcGF1c2VkCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBJTlRTVEFUWzB4MF0gU0VMT0lEWzB4Zl0gU0VMSURbMHgwXSBIU19NQUlM Qk9YWzB4MF0gCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBJTlRDVExbMHg4MF06KFNX VE1JTlRNQVNLKSBTRVFJTlRTVEFUWzB4MF0gU0FWRURfTU9ERVsweDExXSAKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IERGRlNUQVRbMHgzM106KENVUlJGSUZPX05PTkV8RklGTzBGUkVF fEZJRk8xRlJFRSkgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTQ1NJU0lHSVsweDBd OihQX0RBVEFPVVQpIFNDU0lQSEFTRVsweDBdIFNDU0lCVVNbMHgwXSAKSnVsICAxIDA3OjM1OjU5 IGxhbWJkYSBrZXJuZWw6IExBU1RQSEFTRVsweDFdOihQX0RBVEFPVVR8UF9CVVNGUkVFKSBTQ1NJ U0VRMFsweDBdIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogU0NTSVNFUTFbMHgxMl06 KEVOQVVUT0FUTlB8RU5SU0VMSSkgU0VRQ1RMMFsweDBdIFNFUUlOVENUTFsweDZdOihJTlRNQVNL MXxJTlRNQVNLMikgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTRVFfRkxBR1NbMHgw XSBTRVFfRkxBR1MyWzB4MF0gUUZSRUVaRV9DT1VOVFsweDJdIApKdWwgIDEgMDc6MzU6NTkgbGFt YmRhIGtlcm5lbDogS0VSTkVMX1FGUkVFWkVfQ09VTlRbMHgyXSBNS19NRVNTQUdFX1NDQlsweGZm MDBdIE1LX01FU1NBR0VfU0NTSUlEWzB4ZmZdIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5l bDogU1NUQVQwWzB4MF0gU1NUQVQxWzB4MF0gU1NUQVQyWzB4MF0gU1NUQVQzWzB4MF0gUEVSUkRJ QUdbMHgwXSAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFNJTU9ERTFbMHhhNF06KEVO U0NTSVBFUlJ8RU5TQ1NJUlNUfEVOU0VMVElNTykgTFFJU1RBVDBbMHgwXSAKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IExRSVNUQVQxWzB4MF0gTFFJU1RBVDJbMHgwXSBMUU9TVEFUMFsw eDBdIExRT1NUQVQxWzB4MF0gCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBMUU9TVEFU MlsweDBdIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBTQ0IgQ291bnQgPSAxNiBDTURTX1BFTkRJTkcgPSAwIExBU1RTQ0IgMHhm ZmZmIENVUlJTQ0IgMHg1IE5FWFRTQ0IgMHhmZjgwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2Vy bmVsOiBxaW5zdGFydCA9IDI5IHFpbmZpZm9uZXh0ID0gMjkKSnVsICAxIDA3OjM1OjU5IGxhbWJk YSBrZXJuZWw6IFFJTkZJRk86Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBXQUlUSU5H X1RJRF9RVUVVRVM6Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBQZW5kaW5nIGxpc3Q6 Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBUb3RhbCAwCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBLZXJuZWwgRnJlZSBTQ0IgbGlzdDogNSAxNSAxIDIgMyA0IDYgNyA4IDkg MTAgMTEgMTIgMTMgMTQgMCAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFNlcXVlbmNl ciBDb21wbGV0ZSBETUEtaW5wcm9nIGxpc3Q6IApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5l bDogU2VxdWVuY2VyIENvbXBsZXRlIGxpc3Q6IApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5l bDogU2VxdWVuY2VyIERNQS1VcCBhbmQgQ29tcGxldGUgbGlzdDogCkp1bCAgMSAwNzozNTo1OSBs YW1iZGEga2VybmVsOiBTZXF1ZW5jZXIgT24gUUZyZWV6ZSBhbmQgQ29tcGxldGUgbGlzdDogCkp1 bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJu ZWw6IApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWhkMDogRklGTzAgRnJlZSwgTE9O R0pNUCA9PSAweDgwMDAsIFNDQiAweGYKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFNF UUlNT0RFWzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5DRkc0SVNU QVR8RU5DRkc0REFUQXxFTlNBVkVQVFJTKSAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6 IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5XTooRklGT0VNUHxIRE9O RXxQUkVMT0FEX0FWQUlMKSAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFNHX0NBQ0hF X1NIQURPV1sweDJdOihMQVNUX1NFRykgU0dfU1RBVEVbMHgwXSBERkZTWEZSQ1RMWzB4MF0gCkp1 bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTT0ZGQ05UWzB4MF0gTURGRlNUQVRbMHg1XToo RklGT0ZSRUV8RExaRVJPKSBTSEFERFIgPSAweDAwLCBTSENOVCA9IDB4MCAKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IEhBRERSID0gMHgwMCwgSENOVCA9IDB4MCBDQ1NHQ1RMWzB4MTBd OihTR19DQUNIRV9BVkFJTCkgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiAKSnVsICAx IDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFoZDA6IEZJRk8xIEZyZWUsIExPTkdKTVAgPT0gMHg4 MDYzLCBTQ0IgMHg1Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTRVFJTU9ERVsweDNm XTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZHNFRTVEFUfEVOQ0ZHNElTVEFUfEVOQ0ZHNERB VEF8RU5TQVZFUFRSUykgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTRVFJTlRTUkNb MHgwXSBERkNOVFJMWzB4MF0gREZTVEFUVVNbMHg4OV06KEZJRk9FTVB8SERPTkV8UFJFTE9BRF9B VkFJTCkgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBTR19DQUNIRV9TSEFET1dbMHgy XTooTEFTVF9TRUcpIFNHX1NUQVRFWzB4MF0gREZGU1hGUkNUTFsweDBdIApKdWwgIDEgMDc6MzU6 NTkgbGFtYmRhIGtlcm5lbDogU09GRkNOVFsweDBdIE1ERkZTVEFUWzB4NV06KEZJRk9GUkVFfERM WkVSTykgU0hBRERSID0gMHgwMCwgU0hDTlQgPSAweDAgCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEg a2VybmVsOiBIQUREUiA9IDB4MDAsIEhDTlQgPSAweDAgQ0NTR0NUTFsweDEwXTooU0dfQ0FDSEVf QVZBSUwpIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogTFFJTjogMHg4IDB4MCAweDAg MHhmIDB4MCAweDIgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAw eDAgMHgwIDB4MCAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGFoZDA6IExRSVNUQVRF ID0gMHgwLCBMUU9TVEFURSA9IDB4MCwgT1BUSU9OTU9ERSA9IDB4NDIKSnVsICAxIDA3OjM1OjU5 IGxhbWJkYSBrZXJuZWw6IGFoZDA6IE9TX1NQQUNFX0NOVCA9IDB4MjAgTUFYQ01EQ05UID0gMHgx Ckp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBhaGQwOiBTQVZFRF9TQ1NJSUQgPSAweDAg U0FWRURfTFVOID0gMHgwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiAKSnVsICAxIDA3 OjM1OjU5IGxhbWJkYSBrZXJuZWw6IFNJTU9ERTBbMHhjXTooRU5PVkVSUlVOfEVOSU9FUlIpIApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogQ0NTQ0JDVExbMHg0XTooQ0NTQ0JESVIpIApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogYWhkMDogUkVHMCA9PSAweDlhNjAsIFNJTkRF WCA9IDB4MTBlLCBESU5ERVggPSAweDEyMApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDog YWhkMDogU0NCUFRSID09IDB4ZiwgU0NCX05FWFQgPT0gMHhmZjgwLCBTQ0JfTkVYVDIgPT0gMHhm ZjMyCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVsOiBDREIgMTIgNDAgMCA4MCA4OCA2NgpK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogU1RBQ0s6IDB4MjM3IDB4MiAweDAgMHgwIDB4 MCAweDAgMHgwIDB4MApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogPDw8PDw8PDw8PDw8 PDw8PDwgRHVtcCBDYXJkIFN0YXRlIEVuZHMgPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Ckp1bCAgMSAwNzoz NTo1OSBsYW1iZGEga2VybmVsOiBDb3BpZWQgMTggYnl0ZXMgb2Ygc2Vuc2UgZGF0YSBvZmZzZXQg MTI6IDB4NzAgMHgwIDB4NiAweDAgMHgwIDB4MCAweDAgMHhhIDB4MCAweDAgMHgwIDB4MCAweDI5 IDB4MiAweDIgMHgwIDB4MCAweDAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGRhMCBh dCBhaGQwIGJ1cyAwIHRhcmdldCAwIGx1biAwCkp1bCAgMSAwNzozNTo1OSBsYW1iZGEga2VybmVs OiBkYTA6IDxTRUFHQVRFIFNUMzczMzA3TFcgMDAwNz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTMgZGV2aWNlIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogZGEwOiAzMjAuMDAwTUIv cyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVp bmcgRW5hYmxlZApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogZGEwOiA3MDAwN01CICgx NDMzNzQ3NDQgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA4OTI0QykKSnVsICAxIDA3OjM1 OjU5IGxhbWJkYSBrZXJuZWw6IENvcGllZCAzMiBieXRlcyBvZiBzZW5zZSBkYXRhIG9mZnNldCAx MjogMHg3MCAweDAgMHg2IDB4MCAweDAgMHgwIDB4MCAweDI4IDB4MCAweDAgMHgwIDB4MCAweDI5 IDB4MiAweDAgMHgwIDB4MCAweDAgMHhmIDB4MjUgMHgwIDB4MSAweDggMHgxIDB4MCAweDAgMHgw IDB4MCAweDAgMHgwIDB4MCAweDAKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGRhMiBh dCBhaGQxIGJ1cyAwIHRhcmdldCAxNSBsdW4gMApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5l bDogZGEyOiA8RlVKSVRTVSBNQVAzMTQ3TlAgMDEwOD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTMgZGV2aWNlIApKdWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogZGEyOiAzMjAuMDAwTUIv cyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCAxMjcsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVl aW5nIEVuYWJsZWQKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGRhMjogMTQwMjAxTUIg KDI4NzEzMjQ0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE3ODczQykKSnVsICAxIDA3 OjM1OjU5IGxhbWJkYSBrZXJuZWw6IGRhMSBhdCBhaGQwIGJ1cyAwIHRhcmdldCAxNSBsdW4gMApK dWwgIDEgMDc6MzU6NTkgbGFtYmRhIGtlcm5lbDogZGExOiA8RlVKSVRTVSBNQVAzMTQ3TlAgMDEw OD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIApKdWwgIDEgMDc6MzU6NTkgbGFt YmRhIGtlcm5lbDogZGExOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNl dCAxMjcsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQKSnVsICAxIDA3OjM1OjU5IGxh bWJkYSBrZXJuZWw6IGRhMTogMTQwMjAxTUIgKDI4NzEzMjQ0MCA1MTIgYnl0ZSBzZWN0b3JzOiAy NTVIIDYzUy9UIDE3ODczQykKSnVsICAxIDA3OjM1OjU5IGxhbWJkYSBrZXJuZWw6IE1vdW50aW5n IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTFzMWEK ------=_Part_23328_30782541.1121374715567 Content-Type: text/plain; name="messages-6.ok.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages-6.ok.txt" SnVsICA1IDEyOjM4OjEyIGxhbWJkYSBzeXNsb2dkOiBrZXJuZWwgYm9vdCBmaWxlIGlzIC9ib290 L2tlcm5lbC9rZXJuZWwKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IENvcHlyaWdodCAo YykgMTk5Mi0yMDA1IFRoZSBGcmVlQlNEIFByb2plY3QuCkp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODks IDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IFRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBGcmVlQlNEIDYuMC1DVVJSRU5U ICMwOiBNb24gSnVsICA0IDE1OjI1OjA5IENFU1QgMjAwNQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRh IGtlcm5lbDogcm9vdEBsYW1iZGEudW54LmVyYS5wbDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5F UklDCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBXQVJOSU5HOiBXSVRORVNTIG9wdGlv biBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBDUFU6IEFNRCBPcHRlcm9uKHRt KSBQcm9jZXNzb3IgMjQ2ICgxOTk0LjMzLU1IeiBLOC1jbGFzcyBDUFUpCkp1bCAgNSAxMjozODox MiBsYW1iZGEga2VybmVsOiBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweGY1YSAgU3Rl cHBpbmcgPSAxMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogRmVhdHVyZXM9MHg3OGJm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTI+Ckp1bCAgNSAxMjoz ODoxMiBsYW1iZGEga2VybmVsOiBBTUQgRmVhdHVyZXM9MHhlMDUwMDgwMDxTWVNDQUxMLE5YLE1N WCssTE0sM0ROb3crLDNETm93PgpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcmVhbCBt ZW1vcnkgID0gMjE0NjgyODI4OCAoMjA0NyBNQikKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJu ZWw6IGF2YWlsIG1lbW9yeSA9IDIwNjIxNjgwNjQgKDE5NjYgTUIpCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiBBQ1BJIEFQSUMgVGFibGU6IDxQVExURCAgCSBBUElDICA+Ckp1bCAgNSAx MjozODoxMiBsYW1iZGEga2VybmVsOiBGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVt IERldGVjdGVkOiAyIENQVXMKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGNwdTAgKEJT UCk6IEFQSUMgSUQ6ICAwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBjcHUxIChBUCk6 IEFQSUMgSUQ6ICAxCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBNQURUOiBGb3JjaW5n IGFjdGl2ZS1sb3cgcG9sYXJpdHkgYW5kIGxldmVsIHRyaWdnZXIgZm9yIFNDSQpKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBt b3RoZXJib2FyZApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogaW9hcGljMSA8VmVyc2lv biAxLjE+IGlycXMgMjQtMjcgb24gbW90aGVyYm9hcmQKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBr ZXJuZWw6IGlvYXBpYzIgPFZlcnNpb24gMS4xPiBpcnFzIDI4LTMxIG9uIG1vdGhlcmJvYXJkCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBpb2FwaWMzIDxWZXJzaW9uIDEuMT4gaXJxcyAz Mi0zNSBvbiBtb3RoZXJib2FyZApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogaW9hcGlj NCA8VmVyc2lvbiAxLjE+IGlycXMgMzYtMzkgb24gbW90aGVyYm9hcmQKSnVsICA1IDEyOjM4OjEy IGxhbWJkYSBrZXJuZWw6IGFjcGkwOiA8UFRMVEQgCSBYU0RUPiBvbiBtb3RoZXJib2FyZApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhY3BpX2J1c19udW1iZXI6IGNhbid0IGdldCBf QURSCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhY3BpX2J1c19udW1iZXI6IGNhbid0 IGdldCBfQURSCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBwY2lfbGluazA6IDxBQ1BJ IFBDSSBMaW5rIExOS0E+IGlycSA1IG9uIGFjcGkwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2Vy bmVsOiBwY2lfbGluazE6IDxBQ1BJIFBDSSBMaW5rIExOS0I+IGlycSAxMSBvbiBhY3BpMApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpX2xpbmsyOiA8QUNQSSBQQ0kgTGluayBMTktD PiBpcnEgMTAgb24gYWNwaTAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaV9saW5r MzogPEFDUEkgUENJIExpbmsgTE5LRD4gaXJxIDExIG9uIGFjcGkwCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiB1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZApKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogdW5rbm93bjogSS9PIHJhbmdlIG5vdCBzdXBwb3J0ZWQKSnVs ICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDA4 LTB4ODAwYiBvbiBhY3BpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogY3B1MDogPEFD UEkgQ1BVPiBvbiBhY3BpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogY3B1MTogPEFD UEkgQ1BVPiBvbiBhY3BpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYWNwaV9idXR0 b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3Bp MApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaWIxOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2Vy bmVsOiBwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRh IGtlcm5lbDogb2hjaTA6IDxORUMgdVBEIDkyMTAgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGUwMTA2 MDAwLTB4ZTAxMDZmZmYgaXJxIDE4IGF0IGRldmljZSAzLjAgb24gcGNpMQpKdWwgIDUgMTI6Mzg6 MTIgbGFtYmRhIGtlcm5lbDogb2hjaTA6IFtHSUFOVC1MT0NLRURdCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiB1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJl c2V0dGluZwpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdXNiMDogPE5FQyB1UEQgOTIx MCBVU0IgY29udHJvbGxlcj4gb24gb2hjaTAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6 IHVzYjA6IFVTQiByZXZpc2lvbiAxLjAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHVo dWIwOiBORUMgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEK SnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogb2hjaTE6 IDxORUMgdVBEIDkyMTAgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGUwMTA3MDAwLTB4ZTAxMDdmZmYg aXJxIDE5IGF0IGRldmljZSAzLjEgb24gcGNpMQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogb2hjaTE6IFtHSUFOVC1MT0NLRURdCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiB1 c2IxOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydApKdWwgIDUgMTI6Mzg6MTIgbGFt YmRhIGtlcm5lbDogdXNiMTogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGluZwpKdWwgIDUg MTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdXNiMTogPE5FQyB1UEQgOTIxMCBVU0IgY29udHJvbGxl cj4gb24gb2hjaTEKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHVzYjE6IFVTQiByZXZp c2lvbiAxLjAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHVodWIxOiBORUMgT0hDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKSnVsICA1IDEyOjM4OjEy IGxhbWJkYSBrZXJuZWw6IHVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZWhjaTA6IDxORUMgdVBEIDcyMDEw MCBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGUwMTA4ODAwLTB4ZTAxMDg4ZmYgaXJxIDE2IGF0 IGRldmljZSAzLjIgb24gcGNpMQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZWhjaTA6 IFtHSUFOVC1MT0NLRURdCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiB1c2IyOiBFSENJ IHZlcnNpb24gMS4wCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiB1c2IyOiBjb21wYW5p b24gY29udHJvbGxlcnMsIDMgcG9ydHMgZWFjaDogdXNiMCB1c2IxCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiB1c2IyOiA8TkVDIHVQRCA3MjAxMDAgVVNCIDIuMCBjb250cm9sbGVyPiBv biBlaGNpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdXNiMjogVVNCIHJldmlzaW9u IDIuMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdWh1YjI6IE5FQyBFSENJIHJvb3Qg aHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQpKdWwgIDUgMTI6Mzg6MTIgbGFt YmRhIGtlcm5lbDogdWh1YjI6IDUgcG9ydHMgd2l0aCA1IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVu dHMgVFNCNDNBQjIyL0E+IG1lbSAweGUwMTA4MDAwLTB4ZTAxMDg3ZmYsMHhlMDEwMDAwMC0weGUw MTAzZmZmIGlycSAxOSBhdCBkZXZpY2UgNC4wIG9uIHBjaTEKSnVsICA1IDEyOjM4OjEyIGxhbWJk YSBrZXJuZWw6IGZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MCkKSnVsICA1IDEyOjM4 OjEyIGxhbWJkYSBrZXJuZWw6IGZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBp cyA0LgpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZndvaGNpMDogRVVJNjQgMTI6MzQ6 NTY6Nzg6MTI6MzQ6NTY6NzgKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGZ3b2hjaTA6 IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KSnVsICA1IDEyOjM4OjEyIGxhbWJk YSBrZXJuZWw6IGZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5dGVzLgpKdWwgIDUg MTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1 cz4gb24gZndvaGNpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZndlMDogPEV0aGVy bmV0IG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtl cm5lbDogaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNzOiAxMjozNDo1NjozNDo1Njo3OApK dWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZndlMDogRXRoZXJuZXQgYWRkcmVzczogMTI6 MzQ6NTY6MzQ6NTY6NzgKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGZ3ZTA6IGlmX3N0 YXJ0IHJ1bm5pbmcgZGVmZXJyZWQgZm9yIEdpYW50Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2Vy bmVsOiBzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKSnVsICA1 IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGZ3b2hjaTA6IEluaXRpYXRlIGJ1cyByZXNldApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBn ZW49MSwgQ1lDTEVNQVNURVIgbW9kZQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZmly ZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCkp1bCAgNSAx MjozODoxMiBsYW1iZGEga2VybmVsOiBmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1lKQpKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2 aWNlIDcuMCBvbiBwY2kwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBpc2EwOiA8SVNB IGJ1cz4gb24gaXNhYjAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGF0YXBjaTA6IDxB TUQgODExMSBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAt MHgxNzcsMHgzNzYsMHgxNDYwLTB4MTQ2ZiBhdCBkZXZpY2UgNy4xIG9uIHBjaTAKSnVsICA1IDEy OjM4OjEyIGxhbWJkYSBrZXJuZWw6IGF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRh cGNpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpMDogPHNlcmlhbCBidXMsIFNN QnVzPiBhdCBkZXZpY2UgNy4yIChubyBkcml2ZXIgYXR0YWNoZWQpCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiBwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNy4zIChubyBkcml2ZXIgYXR0 YWNoZWQpCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBwY2kwOiA8bXVsdGltZWRpYSwg YXVkaW8+IGF0IGRldmljZSA3LjUgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsICA1IDEyOjM4OjEy IGxhbWJkYSBrZXJuZWw6IHBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEw LjAgb24gcGNpMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpMjogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjIKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaTA6IDxiYXNl IHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTAuMSAobm8gZHJp dmVyIGF0dGFjaGVkKQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpYjM6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiBwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpKdWwgIDUgMTI6Mzg6 MTIgbGFtYmRhIGtlcm5lbDogYmdlMDogPEJyb2FkY29tIEJDTTU3MDMgR2lnYWJpdCBFdGhlcm5l dCwgQVNJQyByZXYuIDB4MTAwMj4gbWVtIDB4ZTAyMDAwMDAtMHhlMDIwZmZmZiBpcnEgMjggYXQg ZGV2aWNlIDIuMCBvbiBwY2kzCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBtaWlidXMw OiA8TUlJIGJ1cz4gb24gYmdlMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYnJncGh5 MDogPEJDTTU3MDMgMTAvMTAwLzEwMDBiYXNlVFggUEhZPiBvbiBtaWlidXMwCkp1bCAgNSAxMjoz ODoxMiBsYW1iZGEga2VybmVsOiBicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJh c2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VUWCwgMTAwMGJhc2VUWC1GRFgsIGF1dG8KSnVs ICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGJnZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjBh OmU0OjJmOjVmOjgzCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBwY2kwOiA8YmFzZSBw ZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDExLjEgKG5vIGRyaXZl ciBhdHRhY2hlZCkKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaWI0OiA8QUNQSSBI b3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBw Y2k4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogYWdwMDogPEFNRCA4MTUxIEFHUCBncmFwaGljcyB0dW5uZWw+IG1lbSAweGU4MDAwMDAwLTB4 ZWZmZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2k4Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2Vy bmVsOiBwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpOApK dWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpOTogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjUKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaTk6IDxkaXNwbGF5LCBWR0E+IGF0 IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBr ZXJuZWw6IHBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBwY2k4 Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBwY2kxNDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjYKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBjaTg6IDxiYXNlIHBlcmlwaGVy YWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMy4xIChubyBkcml2ZXIgYXR0YWNo ZWQpCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBwY2liNzogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpOApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogcGNpMTk6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiBhaGQwOiA8QWRhcHRlYyBBSUM3OTAyIFVsdHJhMzIwIFNDU0kgYWRhcHRlcj4gcG9y dCAweDI0MDAtMHgyNGZmLDB4MjAwMC0weDIwZmYgbWVtIDB4ZTIwMDAwMDAtMHhlMjAwMWZmZiBp cnEgMzkgYXQgZGV2aWNlIDQuMCBvbiBwY2kxOQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogYWhkMDogW0dJQU5ULUxPQ0tFRF0KSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGFp Yzc5MDI6IFVsdHJhMzIwIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElkPTcsIFBDSS1YIDY3LTEwME1o eiwgNTEyIFNDQnMKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGFoZDE6IDxBZGFwdGVj IEFJQzc5MDIgVWx0cmEzMjAgU0NTSSBhZGFwdGVyPiBwb3J0IDB4MmMwMC0weDJjZmYsMHgyODAw LTB4MjhmZiBtZW0gMHhlMjAwMjAwMC0weGUyMDAzZmZmIGlycSAzOCBhdCBkZXZpY2UgNC4xIG9u IHBjaTE5Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhaGQxOiBbR0lBTlQtTE9DS0VE XQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYWljNzkwMjogVWx0cmEzMjAgV2lkZSBD aGFubmVsIEIsIFNDU0kgSWQ9NywgUENJLVggNjctMTAwTWh6LCA1MTIgU0NCcwpKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogcGNpODogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNv bnRyb2xsZXI+IGF0IGRldmljZSA0LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsICA1IDEyOjM4 OjEyIGxhbWJkYSBrZXJuZWw6IGFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQg cmFuZ2UKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHNpbzA6IDwxNjU1MEEtY29tcGF0 aWJsZSBDT00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBmbGFncyAweDEwIG9uIGFjcGkw Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBzaW8wOiB0eXBlIDE2NTUwQQpKdWwgIDUg MTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogc2lvMTogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0 PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IG9uIGFjcGkwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiBzaW8xOiB0eXBlIDE2NTUwQQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDog cHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKSnVsICA1IDEyOjM4OjEyIGxhbWJk YSBrZXJuZWw6IGF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQg MHg2MCwweDY0IG9uIGlzYTAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHBwYzA6IGNh bm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVs OiBzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MzAwPgpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdmdhMDogPEdlbmVyaWMgSVNB IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApK dWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogdW1zMDogdmVuZG9yIDB4MDQzMCBwcm9kdWN0 IDB4MDEwMCwgcmV2IDIuMDAvMS4wNywgYWRkciAyLCBpY2xhc3MgMy8xCkp1bCAgNSAxMjozODox MiBsYW1iZGEga2VybmVsOiB1bXMwOiAzIGJ1dHRvbnMuCkp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiB1a2JkMDogdmVuZG9yIDB4MDQzMCBwcm9kdWN0IDB4MDAwNSwgcmV2IDEuMTAvMi4w MCwgYWRkciAyLCBpY2xhc3MgMy8xCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBrYmQw IGF0IHVrYmQwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhY2QwOiBE VkRSIDxBT1BFTiBEVVcxNjA4L0FSUi9BMDRiPiBhdCBhdGExLW1hc3RlciBVRE1BNjYKSnVsICA1 IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGFjZDE6IENEUlcgPEFPUEVOIENPTTUyMzIvQUFIIFBS Ty8xLjA0PiBhdCBhdGExLXNsYXZlIFVETUEzMwpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5l bDogV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUKSnVsICA1IDEy OjM4OjEyIGxhbWJkYSBrZXJuZWw6IGFoZDA6IEludmFsaWQgU2VxdWVuY2VyIGludGVycnVwdCBv Y2N1cnJlZC4KSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6ID4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBEdW1wIENhcmQgU3RhdGUgQmVnaW5zIDw8PDw8PDw8PDw8PDw8PDw8Ckp1bCAgNSAxMjozODox MiBsYW1iZGEga2VybmVsOiBhaGQwOiBEdW1waW5nIENhcmQgU3RhdGUgYXQgcHJvZ3JhbSBhZGRy ZXNzIDB4MjNjIE1vZGUgMHgwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBDYXJkIHdh cyBwYXVzZWQKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IElOVFNUQVRbMHgwXSBTRUxP SURbMHhmXSBTRUxJRFsweDBdIEhTX01BSUxCT1hbMHgwXSAKSnVsICA1IDEyOjM4OjEyIGxhbWJk YSBrZXJuZWw6IElOVENUTFsweDgwXTooU1dUTUlOVE1BU0spIFNFUUlOVFNUQVRbMHgwXSBTQVZF RF9NT0RFWzB4MTFdIApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogREZGU1RBVFsweDMz XTooQ1VSUkZJRk9fTk9ORXxGSUZPMEZSRUV8RklGTzFGUkVFKSAKSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFNDU0lTSUdJWzB4MF06KFBfREFUQU9VVCkgU0NTSVBIQVNFWzB4MF0gU0NT SUJVU1sweDBdIApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogTEFTVFBIQVNFWzB4MV06 KFBfREFUQU9VVHxQX0JVU0ZSRUUpIFNDU0lTRVEwWzB4MF0gCkp1bCAgNSAxMjozODoxMiBsYW1i ZGEga2VybmVsOiBTQ1NJU0VRMVsweDEyXTooRU5BVVRPQVROUHxFTlJTRUxJKSBTRVFDVEwwWzB4 MF0gU0VRSU5UQ1RMWzB4Nl06KElOVE1BU0sxfElOVE1BU0syKSAKSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFNFUV9GTEFHU1sweDBdIFNFUV9GTEFHUzJbMHgwXSBRRlJFRVpFX0NPVU5U WzB4Ml0gCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBLRVJORUxfUUZSRUVaRV9DT1VO VFsweDJdIE1LX01FU1NBR0VfU0NCWzB4ZmYwMF0gTUtfTUVTU0FHRV9TQ1NJSURbMHhmZl0gCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBTU1RBVDBbMHgwXSBTU1RBVDFbMHgwXSBTU1RB VDJbMHgwXSBTU1RBVDNbMHgwXSBQRVJSRElBR1sweDBdIApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRh IGtlcm5lbDogU0lNT0RFMVsweGE0XTooRU5TQ1NJUEVSUnxFTlNDU0lSU1R8RU5TRUxUSU1PKSBM UUlTVEFUMFsweDBdIApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogTFFJU1RBVDFbMHgw XSBMUUlTVEFUMlsweDBdIExRT1NUQVQwWzB4MF0gTFFPU1RBVDFbMHgwXSAKSnVsICA1IDEyOjM4 OjEyIGxhbWJkYSBrZXJuZWw6IExRT1NUQVQyWzB4MF0gCkp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IFNDQiBDb3VudCA9IDE2IENN RFNfUEVORElORyA9IDAgTEFTVFNDQiAweGZmZmYgQ1VSUlNDQiAweDEgTkVYVFNDQiAweGZmMDAK SnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IHFpbnN0YXJ0ID0gMzAgcWluZmlmb25leHQg PSAzMApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogUUlORklGTzoKSnVsICA1IDEyOjM4 OjEyIGxhbWJkYSBrZXJuZWw6IFdBSVRJTkdfVElEX1FVRVVFUzoKSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFBlbmRpbmcgbGlzdDoKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6 IFRvdGFsIDAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IEtlcm5lbCBGcmVlIFNDQiBs aXN0OiAxIDE1IDIgMyA0IDUgNiA3IDggOSAxMCAxMSAxMiAxMyAxNCAwIApKdWwgIDUgMTI6Mzg6 MTIgbGFtYmRhIGtlcm5lbDogU2VxdWVuY2VyIENvbXBsZXRlIERNQS1pbnByb2cgbGlzdDogCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBTZXF1ZW5jZXIgQ29tcGxldGUgbGlzdDogCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBTZXF1ZW5jZXIgRE1BLVVwIGFuZCBDb21wbGV0 ZSBsaXN0OiAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IFNlcXVlbmNlciBPbiBRRnJl ZXplIGFuZCBDb21wbGV0ZSBsaXN0OiAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IApK dWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2Vy bmVsOiBhaGQwOiBGSUZPMCBGcmVlLCBMT05HSk1QID09IDB4ODAwMCwgU0NCIDB4ZgpKdWwgIDUg MTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogU0VRSU1PREVbMHgzZl06KEVOQ0ZHNFRDTUR8RU5DRkc0 SUNNRHxFTkNGRzRUU1RBVHxFTkNGRzRJU1RBVHxFTkNGRzREQVRBfEVOU0FWRVBUUlMpIApKdWwg IDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogU0VRSU5UU1JDWzB4MF0gREZDTlRSTFsweDBdIERG U1RBVFVTWzB4ODldOihGSUZPRU1QfEhET05FfFBSRUxPQURfQVZBSUwpIApKdWwgIDUgMTI6Mzg6 MTIgbGFtYmRhIGtlcm5lbDogU0dfQ0FDSEVfU0hBRE9XWzB4Ml06KExBU1RfU0VHKSBTR19TVEFU RVsweDBdIERGRlNYRlJDVExbMHgwXSAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IFNP RkZDTlRbMHgwXSBNREZGU1RBVFsweDVdOihGSUZPRlJFRXxETFpFUk8pIFNIQUREUiA9IDB4MDAs IFNIQ05UID0gMHgwIApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogSEFERFIgPSAweDAw LCBIQ05UID0gMHgwIENDU0dDVExbMHgxMF06KFNHX0NBQ0hFX0FWQUlMKSAKSnVsICA1IDEyOjM4 OjEyIGxhbWJkYSBrZXJuZWw6IApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYWhkMDog RklGTzEgRnJlZSwgTE9OR0pNUCA9PSAweDgwNjMsIFNDQiAweDEKSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFNFUUlNT0RFWzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0 VFNUQVR8RU5DRkc0SVNUQVR8RU5DRkc0REFUQXxFTlNBVkVQVFJTKSAKSnVsICA1IDEyOjM4OjEy IGxhbWJkYSBrZXJuZWw6IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5 XTooRklGT0VNUHxIRE9ORXxQUkVMT0FEX0FWQUlMKSAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBr ZXJuZWw6IFNHX0NBQ0hFX1NIQURPV1sweDJdOihMQVNUX1NFRykgU0dfU1RBVEVbMHgwXSBERkZT WEZSQ1RMWzB4MF0gCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBTT0ZGQ05UWzB4MF0g TURGRlNUQVRbMHg1XTooRklGT0ZSRUV8RExaRVJPKSBTSEFERFIgPSAweDAwLCBTSENOVCA9IDB4 MCAKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IEhBRERSID0gMHgwMCwgSENOVCA9IDB4 MCBDQ1NHQ1RMWzB4MTBdOihTR19DQUNIRV9BVkFJTCkgCkp1bCAgNSAxMjozODoxMiBsYW1iZGEg a2VybmVsOiBMUUlOOiAweDggMHgwIDB4MCAweGYgMHgwIDB4MyAweDAgMHgwIDB4MCAweDAgMHgw IDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIApKdWwgIDUgMTI6Mzg6MTIgbGFt YmRhIGtlcm5lbDogYWhkMDogTFFJU1RBVEUgPSAweDAsIExRT1NUQVRFID0gMHgwLCBPUFRJT05N T0RFID0gMHg0MgpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogYWhkMDogT1NfU1BBQ0Vf Q05UID0gMHgyMCBNQVhDTURDTlQgPSAweDEKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6 IGFoZDA6IFNBVkVEX1NDU0lJRCA9IDB4MCBTQVZFRF9MVU4gPSAweDAKSnVsICA1IDEyOjM4OjEy IGxhbWJkYSBrZXJuZWw6IApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogU0lNT0RFMFsw eGNdOihFTk9WRVJSVU58RU5JT0VSUikgCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBD Q1NDQkNUTFsweDRdOihDQ1NDQkRJUikgCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBh aGQwOiBSRUcwID09IDB4OWE3MSwgU0lOREVYID0gMHgxMGUsIERJTkRFWCA9IDB4MTIwCkp1bCAg NSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBhaGQwOiBTQ0JQVFIgPT0gMHhmLCBTQ0JfTkVYVCA9 PSAweGZmMDAsIFNDQl9ORVhUMiA9PSAweGZmNmQKSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJu ZWw6IENEQiAxMiA2MCAwIDgwIDg4IGI2Ckp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBT VEFDSzogMHgyMzcgMHgyIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiA8PDw8PDw8PDw8PDw8PDw8PCBEdW1wIENhcmQgU3RhdGUgRW5kcyA+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4KSnVsICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IENvcGllZCAxOCBi eXRlcyBvZiBzZW5zZSBkYXRhIG9mZnNldCAxMjogMHg3MCAweDAgMHg2IDB4MCAweDAgMHgwIDB4 MCAweGEgMHgwIDB4MCAweDAgMHgwIDB4MjkgMHgyIDB4MiAweDAgMHgwIDB4MApKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogZGEwIGF0IGFoZDAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKSnVs ICA1IDEyOjM4OjEyIGxhbWJkYSBrZXJuZWw6IGRhMDogPFNFQUdBVEUgU1QzNzMzMDdMVyAwMDA3 PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCkp1bCAgNSAxMjozODoxMiBsYW1i ZGEga2VybmVsOiBkYTA6IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0 IDYzLCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkCkp1bCAgNSAxMjozODoxMiBsYW1i ZGEga2VybmVsOiBkYTA6IDcwMDA3TUIgKDE0MzM3NDc0NCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDg5MjRDKQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogQ29waWVkIDMyIGJ5 dGVzIG9mIHNlbnNlIGRhdGEgb2Zmc2V0IDEyOiAweDcwIDB4MCAweDYgMHgwIDB4MCAweDAgMHgw IDB4MjggMHgwIDB4MCAweDAgMHgwIDB4MjkgMHgyIDB4MCAweDAgMHgwIDB4MCAweGYgMHgyNSAw eDAgMHgxIDB4OCAweDEgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MApKdWwgIDUgMTI6 Mzg6MTIgbGFtYmRhIGtlcm5lbDogZGEyIGF0IGFoZDEgYnVzIDAgdGFyZ2V0IDE1IGx1biAwCkp1 bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBkYTI6IDxGVUpJVFNVIE1BUDMxNDdOUCAwMTA4 PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCkp1bCAgNSAxMjozODoxMiBsYW1i ZGEga2VybmVsOiBkYTI6IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0 IDEyNywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZApKdWwgIDUgMTI6Mzg6MTIgbGFt YmRhIGtlcm5lbDogZGEyOiAxNDAyMDFNQiAoMjg3MTMyNDQwIDUxMiBieXRlIHNlY3RvcnM6IDI1 NUggNjNTL1QgMTc4NzNDKQpKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZGExIGF0IGFo ZDAgYnVzIDAgdGFyZ2V0IDE1IGx1biAwCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBk YTE6IDxGVUpJVFNVIE1BUDMxNDdOUCAwMTA4PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBk ZXZpY2UgCkp1bCAgNSAxMjozODoxMiBsYW1iZGEga2VybmVsOiBkYTE6IDMyMC4wMDBNQi9zIHRy YW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0IDEyNywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcg RW5hYmxlZApKdWwgIDUgMTI6Mzg6MTIgbGFtYmRhIGtlcm5lbDogZGExOiAxNDAyMDFNQiAoMjg3 MTMyNDQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTc4NzNDKQpKdWwgIDUgMTI6Mzg6 MTIgbGFtYmRhIGtlcm5lbDogQVRBIFBzZXVkb1JBSUQgbG9hZGVkCkp1bCAgNSAxMjozODoxMiBs YW1iZGEga2VybmVsOiBTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKSnVsICA1IDEyOjM4OjEyIGxh bWJkYSBrZXJuZWw6IFRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZGExczFhCg== ------=_Part_23328_30782541.1121374715567 Content-Type: text/plain; name="messages.fked.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages.fked.txt" SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBzeXNsb2dkOiBrZXJuZWwgYm9vdCBmaWxlIGlzIC9ib290 L2tlcm5lbC9rZXJuZWwKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IENvcHlyaWdodCAo YykgMTk5Mi0yMDA1IFRoZSBGcmVlQlNEIFByb2plY3QuCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODks IDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IFRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBGcmVlQlNEIDYuMC1CRVRBICM0 OiBUaHUgSnVsIDE0IDIyOjI2OjU2IENFU1QgMjAwNQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogcm9vdEBsYW1iZGEudW54LmVyYS5wbDovdXNyL29iai91c3Ivc3JjL3N5cy9MQU1CREEK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IFByZWxvYWRlZCBlbGYga2VybmVsICIvYm9v dC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODA2ZTEwMDAuCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xvY2s6IDExOTMy MzEgSHoKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IENMS19VU0VfSTgyNTRfQ0FMSUJS QVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5Ckp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgy IEh6IHF1YWxpdHkgMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogQ2FsaWJyYXRpbmcg VFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDE5OTQzMzM5MDcgSHoKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IENQVTogQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAyNDYgKDE5OTQuMzMt TUh6IEs4LWNsYXNzIENQVSkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IE9yaWdpbiA9 ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4ZjVhICBTdGVwcGluZyA9IDEwCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBGZWF0dXJlcz0weDc4YmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1T UixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVT SCxNTVgsRlhTUixTU0UsU1NFMj4KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEFNRCBG ZWF0dXJlcz0weGUwNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxMTSwzRE5vdyssM0ROb3c+Ckp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBMMSAyTUIgZGF0YSBUTEI6IDggZW50cmllcywgZnVs bHkgYXNzb2NpYXRpdmUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEwxIDJNQiBpbnN0 cnVjdGlvbiBUTEI6IDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IEwxIDRLQiBkYXRhIFRMQjogMzIgZW50cmllcywgZnVsbHkgYXNzb2Np YXRpdmUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEwxIDRLQiBpbnN0cnVjdGlvbiBU TEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBMMSBkYXRhIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMv dGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogTDEg aW5zdHJ1Y3Rpb24gY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcs IDItd2F5IGFzc29jaWF0aXZlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBMMiAyTUIg dW5pZmllZCBUTEI6IDAgZW50cmllcywgZGlzYWJsZWQvbm90IHByZXNlbnQKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IEwyIDRLQiBkYXRhIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFz c29jaWF0aXZlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBMMiA0S0IgaW5zdHJ1Y3Rp b24gVExCOiA1MTIgZW50cmllcywgNC13YXkgYXNzb2NpYXRpdmUKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IEwyIHVuaWZpZWQgY2FjaGU6IDEwMjQga2J5dGVzLCA2NCBieXRlcy9saW5l LCAxIGxpbmVzL3RhZywgMTYtd2F5IGFzc29jaWF0aXZlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiByZWFsIG1lbW9yeSAgPSAyMTQ2ODI4Mjg4ICgyMDQ3IE1CKQpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDk5ZmZm LCA2MjY2ODggYnl0ZXMgKDE1MyBwYWdlcykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IDB4MDAwMDAwMDAwMDdkZTAwMCAtIDB4MDAwMDAwMDA3YzMyNGZmZiwgMjA3NTQyMjcyMCBieXRl cyAoNTA2Njk1IHBhZ2VzKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYXZhaWwgbWVt b3J5ID0gMjA2NTMzODM2OCAoMTk2OSBNQikKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IEFDUEkgQVBJQyBUYWJsZTogPFBUTFREICAJIEFQSUMgID4KSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IEFQSUMgSUQ6IHBoeXNpY2FsIDAsIGxvZ2ljYWwgMDowCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBBUElDIElEOiBwaHlzaWNhbCAxLCBsb2dpY2FsIDA6MQpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl bSBEZXRlY3RlZDogMiBDUFVzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjcHUwIChC U1ApOiBBUElDIElEOiAgMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY3B1MSAoQVAp OiBBUElDIElEOiAgMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogQVBJQzogQ1BVIDAg aGFzIEFDUEkgSUQgMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogQVBJQzogQ1BVIDEg aGFzIEFDUEkgSUQgMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogTUFEVDogRm91bmQg SU8gQVBJQyBJRCAyLCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBpb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGlu IDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAwIC0+IEV4 dElOVCAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6 IGludHBpbiAxIC0+IElTQSBJUlEgMSAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAyIC0+IElTQSBJUlEgMiAoZWRnZSwgaGlnaCkKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAzIC0+IElTQSBJUlEg MyAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGlu dHBpbiA0IC0+IElTQSBJUlEgNCAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGlvYXBpYzA6IGludHBpbiA1IC0+IElTQSBJUlEgNSAoZWRnZSwgaGlnaCkKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiA2IC0+IElTQSBJUlEgNiAo ZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBp biA3IC0+IElTQSBJUlEgNyAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGlvYXBpYzA6IGludHBpbiA4IC0+IElTQSBJUlEgOCAoZWRnZSwgaGlnaCkKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiA5IC0+IElTQSBJUlEgOSAoZWRn ZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAx MCAtPiBJU0EgSVJRIDEwIChlZGdlLCBoaWdoKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogaW9hcGljMDogaW50cGluIDExIC0+IElTQSBJUlEgMTEgKGVkZ2UsIGhpZ2gpCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwOiBpbnRwaW4gMTIgLT4gSVNBIElSUSAxMiAo ZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBp biAxMyAtPiBJU0EgSVJRIDEzIChlZGdlLCBoaWdoKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogaW9hcGljMDogaW50cGluIDE0IC0+IElTQSBJUlEgMTQgKGVkZ2UsIGhpZ2gpCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwOiBpbnRwaW4gMTUgLT4gSVNBIElSUSAx NSAoZWRnZSwgaGlnaCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGlu dHBpbiAxNiAtPiBQQ0kgSVJRIDE2IChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogaW9hcGljMDogaW50cGluIDE3IC0+IFBDSSBJUlEgMTcgKGxldmVsLCBsb3cpCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwOiBpbnRwaW4gMTggLT4gUENJIElS USAxOCAobGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6 IGludHBpbiAxOSAtPiBQQ0kgSVJRIDE5IChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogaW9hcGljMDogaW50cGluIDIwIC0+IFBDSSBJUlEgMjAgKGxldmVsLCBsb3cp Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwOiBpbnRwaW4gMjEgLT4gUENJ IElSUSAyMSAobGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBp YzA6IGludHBpbiAyMiAtPiBQQ0kgSVJRIDIyIChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogaW9hcGljMDogaW50cGluIDIzIC0+IFBDSSBJUlEgMjMgKGxldmVsLCBs b3cpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBNQURUOiBGb3VuZCBJTyBBUElDIElE IDMsIEludGVycnVwdCAyNCBhdCAweGUwMDAwMDAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBpb2FwaWMxOiBpbnRwaW4gMCAtPiBQQ0kgSVJRIDI0IChsZXZlbCwgbG93KQpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGljMTogaW50cGluIDEgLT4gUENJIElSUSAyNSAo bGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzE6IGludHBp biAyIC0+IFBDSSBJUlEgMjYgKGxldmVsLCBsb3cpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBpb2FwaWMxOiBpbnRwaW4gMyAtPiBQQ0kgSVJRIDI3IChsZXZlbCwgbG93KQpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogTUFEVDogRm91bmQgSU8gQVBJQyBJRCA0LCBJbnRlcnJ1 cHQgMjggYXQgMHhlMDAwMTAwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGlj MjogaW50cGluIDAgLT4gUENJIElSUSAyOCAobGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IGlvYXBpYzI6IGludHBpbiAxIC0+IFBDSSBJUlEgMjkgKGxldmVsLCBsb3cp Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMyOiBpbnRwaW4gMiAtPiBQQ0kg SVJRIDMwIChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGlj MjogaW50cGluIDMgLT4gUENJIElSUSAzMSAobGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IE1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgNSwgSW50ZXJydXB0IDMyIGF0IDB4 ZTA1MDAwMDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzM6IGludHBpbiAw IC0+IFBDSSBJUlEgMzIgKGxldmVsLCBsb3cpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBpb2FwaWMzOiBpbnRwaW4gMSAtPiBQQ0kgSVJRIDMzIChsZXZlbCwgbG93KQpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGljMzogaW50cGluIDIgLT4gUENJIElSUSAzNCAobGV2 ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzM6IGludHBpbiAz IC0+IFBDSSBJUlEgMzUgKGxldmVsLCBsb3cpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBNQURUOiBGb3VuZCBJTyBBUElDIElEIDYsIEludGVycnVwdCAzNiBhdCAweGUwNTAxMDAwCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWM0OiBpbnRwaW4gMCAtPiBQQ0kgSVJR IDM2IChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGljNDog aW50cGluIDEgLT4gUENJIElSUSAzNyAobGV2ZWwsIGxvdykKSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGlvYXBpYzQ6IGludHBpbiAyIC0+IFBDSSBJUlEgMzggKGxldmVsLCBsb3cpCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWM0OiBpbnRwaW4gMyAtPiBQQ0kgSVJR IDM5IChsZXZlbCwgbG93KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogTUFEVDogSW50 ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAyIHRyaWdnZXI6IGVkZ2UKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiAyIHBvbGFyaXR5OiBoaWdoCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXBpYzA6IFJvdXRpbmcgTk1JIC0+IExJTlQx Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXBpYzA6IExJTlQxIHRyaWdnZXI6IGVk Z2UKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhcGljMDogTElOVDEgcG9sYXJpdHk6 IGhpZ2gKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhcGljMTogUm91dGluZyBOTUkg LT4gTElOVDEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhcGljMTogTElOVDEgdHJp Z2dlcjogZWRnZQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbGFwaWMxOiBMSU5UMSBw b2xhcml0eTogaGlnaApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogTUFEVDogRm9yY2lu ZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZvciBTQ0kKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxl dmVsCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwIDxWZXJzaW9uIDEuMT4g aXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBp b2FwaWMxIDxWZXJzaW9uIDEuMT4gaXJxcyAyNC0yNyBvbiBtb3RoZXJib2FyZApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGljMiA8VmVyc2lvbiAxLjE+IGlycXMgMjgtMzEgb24g bW90aGVyYm9hcmQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzMgPFZlcnNp b24gMS4xPiBpcnFzIDMyLTM1IG9uIG1vdGhlcmJvYXJkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBpb2FwaWM0IDxWZXJzaW9uIDEuMT4gaXJxcyAzNi0zOSBvbiBtb3RoZXJib2FyZApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY3B1MCBCU1A6Ckp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA0MDAxMCBMRFI6IDB4MDEw MDAwMDAgREZSOiAweDBmZmZmZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsaW50 MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAw MDAwMWZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiB0aW1lcjogMHgwMDAxMDBlZiB0 aGVybTogMHgwMDAwMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNv ZnR3YXJlLCBZYXJyb3c+Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBuZnNsb2NrOiBw c2V1ZG8tZGV2aWNlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBtZW06IDxtZW1vcnk+ Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpbzogPEkvTz4KSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGFjcGkwOiA8UFRMVEQgCSBYU0RUPiBvbiBtb3RoZXJib2FyZApKdWwg MTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNwaTA6IFtNUFNBRkVdCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBwY2lfb3BlbigxKToJbW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4KSBp cyAweDgwMDEwMDEwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfb3BlbigxYSk6 CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDApCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBwY2lfY2ZnY2hlY2s6CWRldmljZSAwIDEgMiAzIDQgNSA2IFtjbGFzcz0wNjA0MDBd IFtoZHI9MDFdIGlzIHRoZXJlIChpZD03NDYwMTAyMikKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IEFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgNyBmdW5jIDMKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxMSBmdW5j IDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEFjcGlPc0Rlcml2ZVBjaUlkOiBidXMg MCBkZXYgMTAgZnVuYyAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY3BpX2J1c19u dW1iZXI6IGNhbid0IGdldCBfQURSCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBBY3Bp T3NEZXJpdmVQY2lJZDogYnVzIDggZGV2IDQgZnVuYyAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBhY3BpX2J1c19udW1iZXI6IGNhbid0IGdldCBfQURSCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDggZGV2IDMgZnVuYyAwCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDI0 IGZ1bmMgMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpX2xpbmswOiA8QUNQSSBQ Q0kgTGluayBMTktBPiBpcnEgNSBvbiBhY3BpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogcGNpX2xpbmswOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IDAgICAgNSAgIE4gICAgIDAgIDMgNSAxMCAxMQpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogcGNpX2xpbmswOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRp b246Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogMCAgICA1ICAgTiAgICAgMCAgMyA1 IDEwIDExCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazA6IExpbmtzIGFm dGVyIGRpc2FibGU6Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogMCAgMjU1ICAgTiAg ICAgMCAgMyA1IDEwIDExCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazE6 IDxBQ1BJIFBDSSBMaW5rIExOS0I+IGlycSAzIG9uIGFjcGkwCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBwY2lfbGluazE6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6Ckp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogMCAgICAzICAgTiAgICAgMCAgMyA1IDEwIDExCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazE6IExpbmtzIGFmdGVyIGluaXRpYWwg dmFsaWRhdGlvbjoKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAwICAgIDMgICBOICAg ICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaV9saW5rMTog TGlua3MgYWZ0ZXIgZGlzYWJsZToKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAwICAy NTUgICBOICAgICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBj aV9saW5rMjogPEFDUEkgUENJIExpbmsgTE5LQz4gaXJxIDEwIG9uIGFjcGkwCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazI6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6 Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogMCAgIDEwICAgTiAgICAgMCAgMyA1IDEw IDExCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazI6IExpbmtzIGFmdGVy IGluaXRpYWwgdmFsaWRhdGlvbjoKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAwICAg MTAgICBOICAgICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBj aV9saW5rMjogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiAwICAyNTUgICBOICAgICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IHBjaV9saW5rMzogPEFDUEkgUENJIExpbmsgTE5LRD4gaXJxIDExIG9uIGFjcGkwCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazM6IExpbmtzIGFmdGVyIGluaXRp YWwgcHJvYmU6Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogMCAgIDExICAgTiAgICAg MCAgMyA1IDEwIDExCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2lfbGluazM6IExp bmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiAwICAgMTEgICBOICAgICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IHBjaV9saW5rMzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiAwICAyNTUgICBOICAgICAwICAzIDUgMTAgMTEKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IEFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMSBkZXYgMyBmdW5jIDAKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHVua25vd246IEkvTyByYW5nZSBub3Qgc3VwcG9y dGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiB1bmtub3duOiBJL08gcmFuZ2Ugbm90 IHN1cHBvcnRlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogQUNQSSB0aW1lcjogMS8y IDEvMiAxLzIgMS8yIDAvMyAwLzMgMS8yIDEvMiAxLzIgMC8zIC0+IDcKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1 IEh6IHF1YWxpdHkgMTAwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNwaV90aW1l cjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDA4LTB4ODAwYiBvbiBh Y3BpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY3B1MDogPEFDUEkgQ1BVPiBvbiBh Y3BpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY3B1MTogPEFDUEkgQ1BVPiBvbiBh Y3BpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNwaV9idXR0b24wOiA8UG93ZXIg QnV0dG9uPiBvbiBhY3BpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjA6IDxB Q1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaTA6IHBoeXNpY2FsIGJ1cz0wCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDc0NjAsIHJl dmlkPTB4MDcKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGJ1cz0wLCBzbG90PTYsIGZ1 bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDQtMDAsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4 MDE1Nywgc3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDYgKDE1 MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ2OCwgcmV2aWQ9MHgwNQpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9NywgZnVuYz0wCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBjbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbWRyZWc9MHgwMDBmLCBzdGF0cmVnPTB4MDIy MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBk ZXY9MHg3NDY5LCByZXZpZD0weDAzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBidXM9 MCwgc2xvdD03LCBmdW5jPTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGNsYXNzPTAx LTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBtYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxNDYwLCBzaXpl ICA0LCBlbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBmb3VuZC0+CXZlbmRv cj0weDEwMjIsIGRldj0weDc0NmEsIHJldmlkPTB4MDIKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGJ1cz0wLCBzbG90PTcsIGZ1bmM9MgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDQwICgx OTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IGludHBpbj1kLCBpcnE9MTEKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDE0NDAsIHNp emUgIDUsIGVuYWJsZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjcuSU5URApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNp YjA6IHNsb3QgNyBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTkKSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ2YiwgcmV2aWQ9MHgwNQpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9NywgZnVuYz0zCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbGFzcz0wNi04MC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbWRyZWc9MHgwMDAwLCBzdGF0 cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91bmQtPgl2ZW5k b3I9MHgxMDIyLCBkZXY9MHg3NDZkLCByZXZpZD0weDAzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBidXM9MCwgc2xvdD03LCBmdW5jPTUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGNsYXNzPTA0LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGNtZHJlZz0weDAwMDEsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbGF0dGltZXI9MHg0MCAo MTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBpbnRwaW49YiwgaXJxPTMKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDEwMDAsIHNp emUgIDgsIGVuYWJsZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IG1hcFsxNF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDE0MDAsIHNpemUgIDYsIGVuYWJsZWQKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjcuSU5UQgpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjA6IHNsb3QgNyBJTlRCIGhhcmR3aXJl ZCB0byBJUlEgMTcKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9y PTB4MTAyMiwgZGV2PTB4NzQ1MCwgcmV2aWQ9MHgxMgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogYnVzPTAsIHNsb3Q9MTAsIGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDE1Nywgc3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0w IChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDQwICgx OTIwIG5zKSwgbWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ1 MSwgcmV2aWQ9MHgwMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9 MTAsIGZ1bmM9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDgtMDAtMTAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21k cmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IG1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2UgZTAwMDAwMDAsIHNpemUgMTIsIGVuYWJs ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwg ZGV2PTB4NzQ1MCwgcmV2aWQ9MHgxMgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVz PTAsIHNsb3Q9MTEsIGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9 MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogY21kcmVnPTB4MDE1Nywgc3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0wIChkd29yZHMp Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwg bWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ1MSwgcmV2aWQ9 MHgwMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9MTEsIGZ1bmM9 MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDgtMDAtMTAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IG1hcFsxMF06 IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2UgZTAwMDEwMDAsIHNpemUgMTIsIGVuYWJsZWQKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEw MCwgcmV2aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9 MjQsIGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21k cmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMSwgcmV2aWQ9MHgwMApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MQpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBs YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwg ZGV2PTB4MTEwMiwgcmV2aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVz PTAsIHNsb3Q9MjQsIGZ1bmM9MgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9 MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMp Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMywgcmV2aWQ9MHgwMApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwpKdWwg MTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9y PTB4MTAyMiwgZGV2PTB4MTEwMCwgcmV2aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogYnVzPTAsIHNsb3Q9MjUsIGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0w IChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMSwgcmV2 aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9MjUsIGZ1 bmM9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4 MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5k LT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMiwgcmV2aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogYnVzPTAsIHNsb3Q9MjUsIGZ1bmM9MgpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNh Y2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4 MTEwMywgcmV2aWQ9MHgwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTAsIHNs b3Q9MjUsIGZ1bmM9MwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog Y21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IHBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAx Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liMTogICBzdWJvcmRpbmF0ZSBidXMg ICAxCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liMTogICBJL08gZGVjb2RlICAg ICAgICAweGYwMDAtMHhmZmYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIxOiAg IG1lbW9yeSBkZWNvZGUgICAgIDB4ZTAxMDAwMDAtMHhlMDFmZmZmZgpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZm ZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2kxOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpMTogcGh5c2ljYWwgYnVz PTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlzYWIwOiA8UENJLUlTQSBicmlkZ2U+ IGF0IGRldmljZSA3LjAgb24gcGNpMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGFw Y2kwOiA8QU1EIDgxMTEgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2 LDB4MTcwLTB4MTc3LDB4Mzc2LDB4MTQ2MC0weDE0NmYgYXQgZGV2aWNlIDcuMSBvbiBwY2kwCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVz IGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgxNDYwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBhdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMApKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBl IDQgYXQgMHgxZjAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGF0YXBjaTA6IFJlc2Vy dmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2Ckp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBhdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NjAgb3N0YXQx PTcwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGEwOiBzdGF0MD0weDIwIGVycj0w eDIwIGxzYj0weDIwIG1zYj0weDIwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGEw OiBzdGF0MT0weDMwIGVycj0weDMwIGxzYj0weDMwIG1zYj0weDMwCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBhdGEwOiByZXNldCB0cDIgc3RhdDA9MjAgc3RhdDE9MzAgZGV2aWNlcz0w eDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGF0YTA6IFtNUFNBRkVdCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBhdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVz IGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4 Mzc2Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGExOiByZXNldCB0cDEgbWFzaz0w MyBvc3RhdDA9NTAgb3N0YXQxPTUwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGEx OiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBhdGExOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGVi Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGExOiByZXNldCB0cDIgc3RhdDA9MDAg c3RhdDE9MDAgZGV2aWNlcz0weGM8QVRBUElfU0xBVkUsQVRBUElfTUFTVEVSPgpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogYXRhMTogW01QU0FGRV0KSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IHBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDcuMiAobm8gZHJp dmVyIGF0dGFjaGVkKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpMDogPGJyaWRn ZT4gYXQgZGV2aWNlIDcuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogcGNpMDogPG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgNy41IChubyBk cml2ZXIgYXR0YWNoZWQpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTAKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IHBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0w eGZmZgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjI6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhmZmYwMDAwMC0weGZmZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBw Y2liMjogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IHBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBwY2kyOiBwaHlzaWNhbCBidXM9MgpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRy b2xsZXI+IGF0IGRldmljZSAxMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAx MS4wIG9uIHBjaTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIzOiAgIHNlY29u ZGFyeSBidXMgICAgIDMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIzOiAgIHN1 Ym9yZGluYXRlIGJ1cyAgIDMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWIzOiAg IEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogcGNpYjM6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlMDIwMDAwMC0weGUwMmZmZmZmCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAw eGZmZjAwMDAwLTB4ZmZmZmYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaTM6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2kz OiBwaHlzaWNhbCBidXM9MwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91bmQtPgl2 ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNmE3LCByZXZpZD0weDAyCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBidXM9Mywgc2xvdD0yLCBmdW5jPTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGNtZHJlZz0weDAxNTYsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhdHRpbWVyPTB4 NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGludHBpbj1hLCBpcnE9NQpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBNU0kgc3VwcG9ydHMgOCBtZXNzYWdl cywgNjQgYml0Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBtYXBbMTBdOiB0eXBlIDEs IHJhbmdlIDY0LCBiYXNlIGUwMjAwMDAwLCBzaXplIDE2LCBlbmFibGVkCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBwY2liMzogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhl MDIwMDAwMC0weGUwMjBmZmZmOiBnb29kCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBw Y2liMzogbWF0Y2hlZCBlbnRyeSBmb3IgMy4yLklOVEEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IHBjaWIzOiBzbG90IDIgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDI4Ckp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBiZ2UwOiA8QnJvYWRjb20gQkNNNTcwMyBHaWdhYml0IEV0aGVy bmV0LCBBU0lDIHJldi4gMHgxMDAyPiBtZW0gMHhlMDIwMDAwMC0weGUwMjBmZmZmIGlycSAyOCBh dCBkZXZpY2UgMi4wIG9uIHBjaTMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGJnZTA6 IFJlc2VydmVkIDB4MTAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGUwMjAwMDAw Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBtaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdl MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnJncGh5MDogPEJDTTU3MDMgMTAvMTAw LzEwMDBiYXNlVFggUEhZPiBvbiBtaWlidXMwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZE WCwgMTAwMGJhc2VUWCwgMTAwMGJhc2VUWC1GRFgsIGF1dG8KSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGJnZTA6IGJwZiBhdHRhY2hlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGE6ZTQ6MmY6NWY6ODMKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGJnZTA6IFtNUFNBRkVdCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQg ZGV2aWNlIDExLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IHBjaWI0OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBwY2liNDogY291bGQgbm90IGdldCBQQ0kgaW50ZXJydXB0IHJv dXRpbmcgdGFibGUgZm9yIFxfU0JfLlBDSTEgLSBBRV9OT1RfRk9VTkQKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IHBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0Ckp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBwY2k4OiBwaHlzaWNhbCBidXM9OApKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHg3NDU0LCByZXZpZD0w eDE0Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBidXM9OCwgc2xvdD0wLCBmdW5jPTAK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGNtZHJlZz0weDAwMDIs IHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBtYXBbMTBdOiB0 eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGU4MDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDc0NTUs IHJldmlkPTB4MTQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGJ1cz04LCBzbG90PTEs IGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2xhc3M9MDYtMDQtMDAsIGhk cnR5cGU9MHgwMSwgbWZkZXY9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVn PTB4MDEwNywgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0weDYzICgyOTcwIG5zKSwgbWluZ250PTB4MGMg KDMwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ1MCwgcmV2aWQ9MHgxMgpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTgsIHNsb3Q9MywgZnVuYz0wCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBjbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0x Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbWRyZWc9MHgwMTU3LCBzdGF0cmVnPTB4 MDIzMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNyAoMTc1MCBucyksIG1heGxhdD0w eDAwICgwIG5zKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9 MHgxMDIyLCBkZXY9MHg3NDUxLCByZXZpZD0weDAxCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBidXM9OCwgc2xvdD0zLCBmdW5jPTEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGNsYXNzPTA4LTAwLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IGNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBtYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIGUwNTAwMDAw LCBzaXplIDEyLCBlbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBmb3VuZC0+ CXZlbmRvcj0weDEwMjIsIGRldj0weDc0NTAsIHJldmlkPTB4MTIKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IGJ1cz04LCBzbG90PTQsIGZ1bmM9MApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogY21kcmVnPTB4MDE1Nywgc3RhdHJlZz0weDAyMzAsIGNhY2hl bG5zej0wIChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0w eDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2 PTB4NzQ1MSwgcmV2aWQ9MHgwMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVzPTgs IHNsb3Q9NCwgZnVuYz0xCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbGFzcz0wOC0w MC0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBjbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDIwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogbWFwWzEwXTogdHlwZSAxLCByYW5nZSA2NCwgYmFzZSBlMDUwMTAwMCwgc2l6ZSAxMiwg ZW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWdwMDogPEFNRCA4MTUxIEFH UCBncmFwaGljcyB0dW5uZWw+IG1lbSAweGU4MDAwMDAwLTB4ZWZmZmZmZmYgYXQgZGV2aWNlIDAu MCBvbiBwY2k4Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBBTUQ2NDogMiBNaXNjLiBD b250cm9sIHVuaXQocykgZm91bmQuCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhZ3Aw OiBSZXNlcnZlZCAweDgwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGU4MDAw MDAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhZ3AwOiBhbGxvY2F0aW5nIEdBVFQg Zm9yIGFwZXJ0dXJlIG9mIHNpemUgMTI4TQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog cGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTgKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI1OiAgIHNlY29uZGFyeSBidXMgICAgIDkKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEz Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNTogICBJL08gZGVjb2RlICAgICAg ICAweGYwMDAtMHhmZmYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI1OiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4ZTEwMDAwMDAtMHhlMWZmZmZmZgpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogcGNpYjU6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmMDAwMDAwMC0weGY3ZmZm ZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2k5OiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liNQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpOTogcGh5c2ljYWwgYnVz PTkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTBkZSwg ZGV2PTB4MDE4YSwgcmV2aWQ9MHhjMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYnVz PTksIHNsb3Q9MCwgZnVuYz0wCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbGFzcz0w My0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBt aW5nbnQ9MHgwNSAoMTI1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBpbnRwaW49YSwgaXJxPTUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlMTAw MDAwMCwgc2l6ZSAyNCwgZW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNp YjU6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZTEwMDAwMDAtMHhlMWZmZmZmZjog Z29vZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbWFwWzE0XTogdHlwZSAzLCByYW5n ZSAzMiwgYmFzZSBmMDAwMDAwMCwgc2l6ZSAyNywgZW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogcGNpYjU6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZjAwMDAw MDAtMHhmN2ZmZmZmZjogZ29vZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjU6 IG1hdGNoZWQgZW50cnkgZm9yIDkuMC5JTlRBCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBwY2liNTogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogcGNpOTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjY6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMy4wIG9uIHBjaTgKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IHBjaWI2OiAgIHNlY29uZGFyeSBidXMgICAgIDE0Ckp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBwY2liNjogICBzdWJvcmRpbmF0ZSBidXMgICAxOApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjY6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4 ZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNjogICBtZW1vcnkgZGVjb2Rl ICAgICAweGZmZjAwMDAwLTB4ZmZmZmYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBj aWI2OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZgpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogcGNpMTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2Ckp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBwY2kxNDogcGh5c2ljYWwgYnVzPTE0Ckp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBwY2k4OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29u dHJvbGxlcj4gYXQgZGV2aWNlIDMuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug NC4wIG9uIHBjaTgKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI3OiAgIHNlY29u ZGFyeSBidXMgICAgIDE5Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogICBz dWJvcmRpbmF0ZSBidXMgICAyMwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6 ICAgSS9PIGRlY29kZSAgICAgICAgMHgyMDAwLTB4MmZmZgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogcGNpYjc6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlMjAwMDAwMC0weGUyMGZmZmZm Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogICBwcmVmZXRjaGVkIGRlY29k ZSAweGZmZjAwMDAwLTB4ZmZmZmYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaTE5 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog cGNpMTk6IHBoeXNpY2FsIGJ1cz0xOQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91 bmQtPgl2ZW5kb3I9MHg5MDA1LCBkZXY9MHg4MDFkLCByZXZpZD0weDEwCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBidXM9MTksIHNsb3Q9NCwgZnVuYz0wCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBjbGFzcz0wMS0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjbWRyZWc9MHgwMTU3LCBzdGF0cmVnPTB4MDQzMCwg Y2FjaGVsbnN6PTE2IChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0 aW1lcj0weDQ4ICgyMTYwIG5zKSwgbWluZ250PTB4MjggKDEwMDAwIG5zKSwgbWF4bGF0PTB4MTkg KDYyNTAgbnMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpbnRwaW49YSwgaXJxPTEx Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IE1TSSBzdXBwb3J0 cyAyIG1lc3NhZ2VzLCA2NCBiaXQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IG1hcFsx MF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDI0MDAsIHNpemUgIDgsIGVuYWJsZWQKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI3OiAobnVsbCkgcmVxdWVzdGVkIEkvTyBy YW5nZSAweDI0MDAtMHgyNGZmOiBpbiByYW5nZQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogbWFwWzE0XTogdHlwZSAxLCByYW5nZSA2NCwgYmFzZSBlMjAwMDAwMCwgc2l6ZSAxMywgZW5h YmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6IChudWxsKSByZXF1ZXN0 ZWQgbWVtb3J5IHJhbmdlIDB4ZTIwMDAwMDAtMHhlMjAwMWZmZjogZ29vZApKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogbWFwWzFjXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjAw MCwgc2l6ZSAgOCwgZW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6 IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MjAwMC0weDIwZmY6IGluIHJhbmdlCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogbWF0Y2hlZCBlbnRyeSBmb3IgMTkuNC5J TlRBCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogc2xvdCA0IElOVEEgaGFy ZHdpcmVkIHRvIElSUSAzOQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZm91bmQtPgl2 ZW5kb3I9MHg5MDA1LCBkZXY9MHg4MDFkLCByZXZpZD0weDEwCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBidXM9MTksIHNsb3Q9NCwgZnVuYz0xCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBjbGFzcz0wMS0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBjbWRyZWc9MHgwMTU3LCBzdGF0cmVnPTB4MDQzMCwgY2FjaGVs bnN6PTE2IChkd29yZHMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsYXR0aW1lcj0w eDQ4ICgyMTYwIG5zKSwgbWluZ250PTB4MjggKDEwMDAwIG5zKSwgbWF4bGF0PTB4MTkgKDYyNTAg bnMpCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpbnRwaW49YiwgaXJxPTEwCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IE1TSSBzdXBwb3J0cyAyIG1l c3NhZ2VzLCA2NCBiaXQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IG1hcFsxMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDJjMDAsIHNpemUgIDgsIGVuYWJsZWQKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBjaWI3OiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAw eDJjMDAtMHgyY2ZmOiBpbiByYW5nZQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbWFw WzE0XTogdHlwZSAxLCByYW5nZSA2NCwgYmFzZSBlMjAwMjAwMCwgc2l6ZSAxMywgZW5hYmxlZApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6IChudWxsKSByZXF1ZXN0ZWQgbWVt b3J5IHJhbmdlIDB4ZTIwMDIwMDAtMHhlMjAwM2ZmZjogZ29vZApKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogbWFwWzFjXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjgwMCwgc2l6 ZSAgOCwgZW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGNpYjc6IChudWxs KSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MjgwMC0weDI4ZmY6IGluIHJhbmdlCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogbWF0Y2hlZCBlbnRyeSBmb3IgMTkuNC5JTlRCCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwY2liNzogc2xvdCA0IElOVEIgaGFyZHdpcmVk IHRvIElSUSAzOApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogPEFkYXB0ZWMg QUlDNzkwMiBVbHRyYTMyMCBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHgyNDAwLTB4MjRmZiwweDIwMDAt MHgyMGZmIG1lbSAweGUyMDAwMDAwLTB4ZTIwMDFmZmYgaXJxIDM5IGF0IGRldmljZSA0LjAgb24g cGNpMTkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IERlZmF1bHRpbmcgdG8g TUVNSU8gb24KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFJlc2VydmVkIDB4 MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgyNDAwCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBhaGQwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MWMgdHlw ZSA0IGF0IDB4MjAwMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogRW5hYmxp bmcgMzlCaXQgQWRkcmVzc2luZwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDog UmVhZGluZyBWUEQgZnJvbSBTRUVQUk9NLi4uYWhkMDogVlBEIHBhcnNpbmcgc3VjY2Vzc2Z1bApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogUmVhZGluZyBTRUVQUk9NLi4uZG9u ZS4KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNUUFdMRVZFTCBpcyBvbgpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogTWFudWFsIFByaW1hcnkgVGVybWlu YXRpb24KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IE1hbnVhbCBTZWNvbmRh cnkgVGVybWluYXRpb24KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFByaW1h cnkgSGlnaCBieXRlIHRlcm1pbmF0aW9uIEVuYWJsZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGFoZDA6IFByaW1hcnkgTG93IGJ5dGUgdGVybWluYXRpb24gRW5hYmxlZApKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogU2Vjb25kYXJ5IEhpZ2ggYnl0ZSB0ZXJtaW5h dGlvbiBEaXNhYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogU2Vjb25k YXJ5IExvdyBieXRlIHRlcm1pbmF0aW9uIERpc2FibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBhaGQwOiBEb3dubG9hZGluZyBTZXF1ZW5jZXIgUHJvZ3JhbS4uLiA2OTcgaW5zdHJ1 Y3Rpb25zIGRvd25sb2FkZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IEZl YXR1cmVzIDB4M2MxMDEsIEJ1Z3MgMHg3NDAwMDIsIEZsYWdzIDB4MTQzZjEKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFtHSUFOVC1MT0NLRURdCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBhaWM3OTAyOiBVbHRyYTMyMCBXaWRlIENoYW5uZWwgQSwgU0NTSSBJZD03 LCBQQ0ktWCA2Ny0xMDBNaHosIDUxMiBTQ0JzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBhaGQxOiA8QWRhcHRlYyBBSUM3OTAyIFVsdHJhMzIwIFNDU0kgYWRhcHRlcj4gcG9ydCAweDJj MDAtMHgyY2ZmLDB4MjgwMC0weDI4ZmYgbWVtIDB4ZTIwMDIwMDAtMHhlMjAwM2ZmZiBpcnEgMzgg YXQgZGV2aWNlIDQuMSBvbiBwY2kxOQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhk MTogRGVmYXVsdGluZyB0byBNRU1JTyBvbgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog YWhkMTogUmVzZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDJjMDAK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFJlc2VydmVkIDB4MTAwIGJ5dGVz IGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgyODAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBhaGQxOiBFbmFibGluZyAzOUJpdCBBZGRyZXNzaW5nCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBhaGQxOiBSZWFkaW5nIFZQRCBmcm9tIFNFRVBST00uLi5haGQxOiBWUEQgcGFy c2luZyBzdWNjZXNzZnVsCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQxOiBSZWFk aW5nIFNFRVBST00uLi5kb25lLgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTog U1RQV0xFVkVMIGlzIG9uCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQxOiBNYW51 YWwgUHJpbWFyeSBUZXJtaW5hdGlvbgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhk MTogTWFudWFsIFNlY29uZGFyeSBUZXJtaW5hdGlvbgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogYWhkMTogUHJpbWFyeSBIaWdoIGJ5dGUgdGVybWluYXRpb24gRW5hYmxlZApKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTogUHJpbWFyeSBMb3cgYnl0ZSB0ZXJtaW5hdGlv biBFbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQxOiBTZWNvbmRhcnkg SGlnaCBieXRlIHRlcm1pbmF0aW9uIERpc2FibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2Vy bmVsOiBhaGQxOiBTZWNvbmRhcnkgTG93IGJ5dGUgdGVybWluYXRpb24gRGlzYWJsZWQKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IERvd25sb2FkaW5nIFNlcXVlbmNlciBQcm9n cmFtLi4uIDY5NyBpbnN0cnVjdGlvbnMgZG93bmxvYWRlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogYWhkMTogRmVhdHVyZXMgMHgzYzEwMSwgQnVncyAweDc0MDAwMiwgRmxhZ3MgMHgx NDNmMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTogW0dJQU5ULUxPQ0tFRF0K SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFpYzc5MDI6IFVsdHJhMzIwIFdpZGUgQ2hh bm5lbCBCLCBTQ1NJIElkPTcsIFBDSS1YIDY3LTEwME1oeiwgNTEyIFNDQnMKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IHBjaTg6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250 cm9sbGVyPiBhdCBkZXZpY2UgNC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBhY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHNpbzA6IGlycSBtYXBzOiAweDgwMDEgMHg4MDExIDB4 ODAwMSAweDgwMDEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHNpbzA6IDwxNjU1MEEt Y29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9u IGFjcGkwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBzaW8wOiB0eXBlIDE2NTUwQQpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogc2lvOiBzaW8wIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBU cnlpbmcgUmVhZF9Qb3J0IGF0IDIwMwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG5w X2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDJj MwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVh ZF9Qb3J0IGF0IDMwMwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcG5wX2lkZW50aWZ5 OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM4MwpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogUE5QIElkZW50aWZ5IGNvbXBsZXRlCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaXNhX3Byb2JlX2NoaWxk cmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+ IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGF0a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEgaXJxIDEgb24gYXRrYmRjMApKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVy IGNvbW1hbmQgYnl0ZSAwMDY3Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhdGtiZDog a2V5Ym9hcmQgSUQgMHhmZmZmZmZmZiAoMSkKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGF0a2JkOiBmYWlsZWQgdG8gcmVzZXQgdGhlIGtleWJvYXJkLgpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogZGV2aWNlX2F0dGFjaDogYXRrYmQwIGF0dGFjaCByZXR1cm5lZCA2Ckp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDY3 Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwc20wOiBmYWlsZWQgdG8gcmVzZXQgdGhl IGF1eCBkZXZpY2UuCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBmZGMwIGZhaWxlZCB0 byBwcm9iZSBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBwYzAgZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3 IG9uIGlzYTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGF0a2JkOiB0aGUgY3VycmVu dCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA2NwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogYXRrYmQ6IGtleWJvYXJkIElEIDB4ZmZmZmZmZmYgKDEpCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBhdGtiZDogZmFpbGVkIHRvIHJlc2V0IHRoZSBrZXlib2FyZC4KSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFn cyAweDEwMCBvbiBpc2EwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBzYzA6IFZHQSA8 MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBzYzA6IGZiMCwgdGVybWluYWwgZW11bGF0b3I6IHNjIChzeXNjb25zIHRlcm1pbmFs KQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogc2lvMTogY29uZmlndXJlZCBpcnEgMyBu b3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IHNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBzaW8xOiBpcnEgbWFwczogMHg4MDAxIDB4ODAwMSAweDgwMDEgMHg4MDAxCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAx IDIgNCA2IDcgOQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogc2lvMSBmYWlsZWQgdG8g cHJvYmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IHNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCkp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IFJlZHVjaW5nIGtlcm4ubWF4dm5vZGVzIDEzMjg3 NiAtPiAxMDAwMDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGxpbnByb2NmcyByZWdp c3RlcmVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwcm9jZnMgcmVnaXN0ZXJlZApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogbGFwaWM6IERpdmlzb3IgMiwgRnJlcXVlbmN5 IDk5NzE2MjQzIGh6Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBUaW1lY291bnRlciAi VFNDIiBmcmVxdWVuY3kgMTk5NDMzMzkwNyBIeiBxdWFsaXR5IC0xMDAKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IFRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IExpbnV4IEVMRiBleGVjIGhhbmRsZXIgaW5zdGFsbGVk Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBsbzA6IGJwZiBhdHRhY2hlZApKdWwgMTQg MjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNl cyB0byBzZXR0bGUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IChub3BlcmlwaDphaGQw OjA6LTE6LTEpOiBTQ1NJIGJ1cyByZXNldCBkZWxpdmVyZWQuIDAgU0NCcyBhYm9ydGVkLgpKdWwg MTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogKG5vcGVyaXBoOmFoZDE6MDotMTotMSk6IFNDU0kg YnVzIHJlc2V0IGRlbGl2ZXJlZC4gMCBTQ0JzIGFib3J0ZWQuCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBhdGExLXNsYXZlOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTMzIGNh YmxlPTQwIHdpcmUKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGF0YTEtbWFzdGVyOiBw aW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTY2IGNhYmxlPTQwIHdpcmUKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGFjZDA6IHNldHRpbmcgUElPNCBvbiBBTUQgODExMSBjaGlwCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY2QwOiBzZXR0aW5nIFVETUE2NiBvbiBBTUQg ODExMSBjaGlwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY2QwOiA8QU9QRU4gRFVX MTYwOC9BUlIvQTA0Yj4gRFZEUiBkcml2ZSBhdCBhdGExIGFzIG1hc3RlcgpKdWwgMTQgMjI6Mzk6 MzQgbGFtYmRhIGtlcm5lbDogYWNkMDogcmVhZCAxNjIzMEtCL3MgKDIxNjQwS0Ivcykgd3JpdGUg MTYyMzBLQi9zICgxMDgyMEtCL3MpLCAyMDQ4S0IgYnVmZmVyLCBVRE1BNjYKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBE VkRST00sIERWRFIsIHBhY2tldApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNkMDog V3JpdGVzOiBDRFIsIENEUlcsIERWRFIsIHRlc3Qgd3JpdGUsIGJ1cm5wcm9vZgpKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNkMDogQXVkaW86IHBsYXksIDE1IHZvbHVtZSBsZXZlbHMK SnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxl IHRyYXksIHVubG9ja2VkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY2QwOiBNZWRp dW06IDEyMG1tIGRhdGEgZGlzYwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNkMTog c2V0dGluZyBQSU80IG9uIEFNRCA4MTExIGNoaXAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGFjZDE6IHNldHRpbmcgVURNQTMzIG9uIEFNRCA4MTExIGNoaXAKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGFjZDE6IDxBT1BFTiBDT001MjMyL0FBSCBQUk8vMS4wND4gQ0RSVyBk cml2ZSBhdCBhdGExIGFzIHNsYXZlCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY2Qx OiByZWFkIDY4N0tCL3MgKDg5MzdLQi9zKSB3cml0ZSA2ODdLQi9zICg4OTM3S0IvcyksIDIwNDhL QiBidWZmZXIsIFVETUEzMwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWNkMTogUmVh ZHM6IENEUiwgQ0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgcGFja2V0Ckp1bCAxNCAy MjozOTozNCBsYW1iZGEga2VybmVsOiBhY2QxOiBXcml0ZXM6IENEUiwgQ0RSVywgdGVzdCB3cml0 ZSwgYnVybnByb29mCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhY2QxOiBBdWRpbzog cGxheSwgMjU1IHZvbHVtZSBsZXZlbHMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFj ZDE6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBhY2QxOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6Ni4gMCBTQ0JzIGFi b3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1l b3V0IG9uIEE6MC4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IGFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6OC4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6MS4gMCBT Q0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlv biBUaW1lb3V0IG9uIEE6MS4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6Mi4gMCBTQ0JzIGFib3J0ZWQKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6 Mi4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNl bGVjdGlvbiBUaW1lb3V0IG9uIEE6My4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6My4gMCBTQ0JzIGFib3J0 ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0 IG9uIEE6OC4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFo ZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6NC4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5 OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6OS4gMCBTQ0Jz IGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlvbiBU aW1lb3V0IG9uIEE6NS4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6MTAuIDAgU0NCcyBhYm9ydGVkCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQwOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjku IDAgU0NCcyBhYm9ydGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQxOiBTZWxl Y3Rpb24gVGltZW91dCBvbiBBOjExLiAwIFNDQnMgYWJvcnRlZApKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogYWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxMC4gMCBTQ0JzIGFib3J0 ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0 IG9uIEE6MTIuIDAgU0NCcyBhYm9ydGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBh aGQwOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjExLiAwIFNDQnMgYWJvcnRlZApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxMy4gMCBT Q0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlv biBUaW1lb3V0IG9uIEE6MTIuIDAgU0NCcyBhYm9ydGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBhaGQxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjE0LiAwIFNDQnMgYWJvcnRlZApK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24g QToxMy4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6 IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6NC4gMCBTQ0JzIGFib3J0ZWQKSnVsIDE0IDIyOjM5OjM0 IGxhbWJkYSBrZXJuZWw6IGFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6MTQuIDAgU0NCcyBh Ym9ydGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAocHJvYmUwOmFoZDA6MDowOjAp OiBSZXRyeWluZyBDb21tYW5kCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoYWhkMDpB OjA6MCk6IFNlbmRpbmcgUFBSIGJ1c193aWR0aCAxLCBwZXJpb2QgOCwgb2Zmc2V0IGZlLCBwcHJf b3B0aW9ucyBmZgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogKGFoZDA6QTowOjApOiBS ZWNlaXZlZCBQUFIgd2lkdGggMSwgcGVyaW9kIDgsIG9mZnNldCAzZixvcHRpb25zIGZmCkp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBGaWx0ZXJlZCB0byB3aWR0aCAxLCBwZXJpb2QgOCwg b2Zmc2V0IDNmLCBvcHRpb25zIGZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBhaGQw OiB0YXJnZXQgMCB1c2luZyAxNmJpdCB0cmFuc2ZlcnMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGFoZDA6IHRhcmdldCAwIHN5bmNocm9ub3VzIHdpdGggcGVyaW9kID0gMHg4LCBvZmZz ZXQgPSAweDNmKFJEU1RSTXxEVHxJVXxSVEl8UUFTKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtl cm5lbDogKHByb2JlMTQ6YWhkMDowOjE1OjApOiBSZXRyeWluZyBDb21tYW5kCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiAoYWhkMDpBOjE1OjApOiBTZW5kaW5nIFBQUiBidXNfd2lkdGgg MSwgcGVyaW9kIDgsIG9mZnNldCBmZSwgcHByX29wdGlvbnMgZmYKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IChhaGQwOkE6MTU6MCk6IFJlY2VpdmVkIFBQUiB3aWR0aCAxLCBwZXJpb2Qg OCwgb2Zmc2V0IDdmLG9wdGlvbnMgYzcKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEZp bHRlcmVkIHRvIHdpZHRoIDEsIHBlcmlvZCA4LCBvZmZzZXQgN2YsIG9wdGlvbnMgYzcKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IHRhcmdldCAxNSB1c2luZyAxNmJpdCB0cmFu c2ZlcnMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDA6IHRhcmdldCAxNSBzeW5j aHJvbm91cyB3aXRoIHBlcmlvZCA9IDB4OCwgb2Zmc2V0ID0gMHg3ZihEVHxJVXxSVEl8UUFTKQpK dWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTogU2VsZWN0aW9uIFRpbWVvdXQgb24g QTo1LiAwIFNDQnMgYWJvcnRlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogYWhkMTog U2VsZWN0aW9uIFRpbWVvdXQgb24gQTo2LiAwIFNDQnMgYWJvcnRlZApKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIGtlcm5lbDogKHByb2JlMjk6YWhkMTowOjE1OjApOiBSZXRyeWluZyBDb21tYW5kCkp1 bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoYWhkMTpBOjE1OjApOiBTZW5kaW5nIFBQUiBi dXNfd2lkdGggMSwgcGVyaW9kIDgsIG9mZnNldCBmZSwgcHByX29wdGlvbnMgZmYKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IChhaGQxOkE6MTU6MCk6IFJlY2VpdmVkIFBQUiB3aWR0aCAx LCBwZXJpb2QgOCwgb2Zmc2V0IDdmLG9wdGlvbnMgYzcKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IEZpbHRlcmVkIHRvIHdpZHRoIDEsIHBlcmlvZCA4LCBvZmZzZXQgN2YsIG9wdGlvbnMg YzcKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IHRhcmdldCAxNSB1c2luZyAx NmJpdCB0cmFuc2ZlcnMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGFoZDE6IHRhcmdl dCAxNSBzeW5jaHJvbm91cyB3aXRoIHBlcmlvZCA9IDB4OCwgb2Zmc2V0ID0gMHg3ZihEVHxJVXxS VEl8UUFTKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczAgYXQgYWhkMCBidXMg MCB0YXJnZXQgMCBsdW4gMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczA6IDxT RUFHQVRFIFNUMzczMzA3TFcgMDAwNz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNl IApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczA6IFNlcmlhbCBOdW1iZXIgM0ha QTAyUDcwMDAwNzUyOUFUWFQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHBhc3MwOiAz MjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdn ZWQgUXVldWVpbmcgRW5hYmxlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczEg YXQgYWhkMCBidXMgMCB0YXJnZXQgMTUgbHVuIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IHBhc3MxOiA8RlVKSVRTVSBNQVAzMTQ3TlAgMDEwOD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBT Q1NJLTMgZGV2aWNlIApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczE6IFNlcmlh bCBOdW1iZXIgVVA4MFA0QzAwNEdBCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwYXNz MTogMzIwLjAwME1CL3MgdHJhbnNmZXJzICgxNjAuMDAwTUh6LCBvZmZzZXQgMTI3LCAxNmJpdCks IFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBw YXNzMiBhdCBhaGQxIGJ1cyAwIHRhcmdldCAxNSBsdW4gMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRh IGtlcm5lbDogcGFzczI6IDxGVUpJVFNVIE1BUDMxNDdOUCAwMTA4PiBGaXhlZCBEaXJlY3QgQWNj ZXNzIFNDU0ktMyBkZXZpY2UgCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwYXNzMjog U2VyaWFsIE51bWJlciBVUDgwUDRDMDA0RlYKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IHBhc3MyOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCAxMjcsIDE2 Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJu ZWw6IHBhc3MzIGF0IGF0YTEgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKSnVsIDE0IDIyOjM5OjM0IGxh bWJkYSBrZXJuZWw6IHBhc3MzOiA8QU9QRU4gRFVXMTYwOC9BUlIgQTA0Yj4gUmVtb3ZhYmxlIENE LVJPTSBTQ1NJLTAgZGV2aWNlIApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczM6 IFNlcmlhbCBOdW1iZXIgNQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogcGFzczM6IDY2 LjAwME1CL3MgdHJhbnNmZXJzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwYXNzNCBh dCBhdGExIGJ1cyAwIHRhcmdldCAxIGx1biAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVs OiBwYXNzNDogPEFPUEVOIENPTTUyMzIvQUFIIFBSTyAxLjA0PiBSZW1vdmFibGUgQ0QtUk9NIFND U0ktMCBkZXZpY2UgCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwYXNzNDogU2VyaWFs IE51bWJlciApCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBwYXNzNDogMzMuMDAwTUIv cyB0cmFuc2ZlcnMKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IEdFT006IG5ldyBkaXNr IGNkMGRhMCBhdCBhaGQwIGJ1cyAwIHRhcmdldCAwIGx1biAwCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBkYTA6IDxTRUFHQVRFIFNUMzczMzA3TFcgMDAwNz4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTMgZGV2aWNlIApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZGEwOiBT ZXJpYWwgTnVtYmVyIDNIWkEwMlA3MDAwMDc1MjlBVFhUCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBkYTA6IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0IDYz LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBkYTA6IDcwMDA3TUIgKDE0MzM3NDc0NCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYz Uy9UIDg5MjRDKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogCkp1bCAxNCAyMjozOToz NCBsYW1iZGEga2VybmVsOiBHRU9NOiBuZGExIGF0IGFoZDAgYnVzIDAgdGFyZ2V0IDE1IGx1biAw Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBkYTE6IDxGVUpJVFNVIE1BUDMxNDdOUCAw MTA4PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBkYTE6IFNlcmlhbCBOdW1iZXIgVVA4MFA0QzAwNEdBCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBkYTE6IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1I eiwgb2Zmc2V0IDEyNywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZApKdWwgMTQgMjI6 Mzk6MzQgbGFtYmRhIGtlcm5lbDogZGExOiAxNDAyMDFNQiAoMjg3MTMyNDQwIDUxMiBieXRlIHNl Y3RvcnM6IDI1NUggNjNTL1QgMTc4NzNDKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog Y2QwIGF0IGF0YTEgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IGNkMDogPEFPUEVOIERVVzE2MDgvQVJSIEEwNGI+IFJlbW92YWJsZSBDRC1ST00gU0NT SS0wIGRldmljZSAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGNkMDogU2VyaWFsIE51 bWJlciA1Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjZDA6IDY2LjAwME1CL3MgdHJh bnNmZXJzCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjZDA6IGNkIHByZXNlbnQgWzEg eCAyMDQ4IGJ5dGUgcmVjb3Jkc10KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGRhMiBh dCBhaGQxIGJ1cyAwIHRhcmdldCAxNSBsdW4gMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogZGEyOiA8RlVKSVRTVSBNQVAzMTQ3TlAgMDEwOD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTMgZGV2aWNlIApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZGEyOiBTZXJpYWwgTnVt YmVyIFVQODBQNEMwMDRGVgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogZGEyOiAzMjAu MDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCAxMjcsIDE2Yml0KSwgVGFnZ2Vk IFF1ZXVlaW5nIEVuYWJsZWQKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGRhMjogMTQw MjAxTUIgKDI4NzEzMjQ0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE3ODczQykKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGV3IGRpc2sgY2QxCkp1bCAxNCAyMjozOTozNCBs YW1iZGEga2VybmVsOiBHRU9NOiBuZXcgZGlzayBkYTAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBr ZXJuZWw6IEdFT006IG5ldyBkaXNrIGRhMQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog R0VPTTogbmV3IGRpc2sgZGEyCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoY2QxOmF0 YTE6MDoxOjApOiBlcnJvciA2Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoY2QxOmF0 YTE6MDoxOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogY2QxIGF0IGF0YTEgYnVzIDAgdGFyZ2V0IDEgbHVuIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJk YSBrZXJuZWw6IGNkMTogPEFPUEVOIENPTTUyMzIvQUFIIFBSTyAxLjA0PiBSZW1vdmFibGUgQ0Qt Uk9NIFNDU0ktMCBkZXZpY2UgCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBjZDE6IFNl cmlhbCBOdW1iZXIgKQpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2QxOiAzMy4wMDBN Qi9zIHRyYW5zZmVycwpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogY2QxOiBBdHRlbXB0 IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNl bnQgLSB0cmF5IGNsb3NlZApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogQVRBIFBzZXVk b1JBSUQgbG9hZGVkCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBTTVA6IEFQIENQVSAj MSBMYXVuY2hlZCEKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGNwdTEgQVA6Ckp1bCAx NCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHgwMDA0MDAx MCBMRFI6IDB4MDIwMDAwMDAgREZSOiAweDBmZmZmZmZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEg a2VybmVsOiBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAw MDAgU1ZSOiAweDAwMDAwMWZmCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiB0aW1lcjog MHgwMDAyMDBlZiB0aGVybTogMHgwMDAwMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEw MDAwCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWMwOiByb3V0aW5nIGludHBp biA0IChJU0EgSVJRIDQpIHRvIGNsdXN0ZXIgMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5l bDogaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBjbHVzdGVyIDAKSnVs IDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJ U0EgSVJRIDE0KSB0byBjbHVzdGVyIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlv YXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byBjbHVzdGVyIDAKSnVsIDE0 IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IGlvYXBpYzI6IHJvdXRpbmcgaW50cGluIDAgKFBDSSBJ UlEgMjgpIHRvIGNsdXN0ZXIgMApKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogaW9hcGlj NDogcm91dGluZyBpbnRwaW4gMiAoUENJIElSUSAzOCkgdG8gY2x1c3RlciAwCkp1bCAxNCAyMjoz OTozNCBsYW1iZGEga2VybmVsOiBpb2FwaWM0OiByb3V0aW5nIGludHBpbiAzIChQQ0kgSVJRIDM5 KSB0byBjbHVzdGVyIDAKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IChjZDA6YXRhMTow OjA6MCk6IGVycm9yIDIyCkp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoY2QwOmF0YTE6 MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDog KGNkMDphdGExOjA6MDowKTogZXJyb3IgMjIKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6 IChjZDA6YXRhMTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiAoY2QwOmF0YTE6MDowOjApOiBlcnJvciAyMgpKdWwgMTQgMjI6Mzk6MzQgbGFt YmRhIGtlcm5lbDogKGNkMDphdGExOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IChjZDE6YXRhMTowOjE6MCk6IGVycm9yIDYKSnVsIDE0IDIy OjM5OjM0IGxhbWJkYSBrZXJuZWw6IChjZDE6YXRhMTowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9y Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoY2QxOmF0YTE6MDoxOjApOiBlcnJvciA2 Ckp1bCAxNCAyMjozOTozNCBsYW1iZGEga2VybmVsOiAoY2QxOmF0YTE6MDoxOjApOiBVbnJldHJ5 YWJsZSBFcnJvcgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogKGNkMTphdGExOjA6MTow KTogZXJyb3IgNgpKdWwgMTQgMjI6Mzk6MzQgbGFtYmRhIGtlcm5lbDogKGNkMTphdGExOjA6MTow KTogVW5yZXRyeWFibGUgRXJyb3IKSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IFRyeWlu ZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZGExczFhCkp1bCAxNCAyMjozOTozNCBsYW1i ZGEga2VybmVsOiBzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApKdWwgMTQgMjI6Mzk6MzQg bGFtYmRhIHJvb3Q6IC9ldGMvcmM6IFdBUk5JTkc6IER1bXAgZGV2aWNlIGRvZXMgbm90IGV4aXN0 LiAgU2F2ZWNvcmUgbm90IHJ1bi4KSnVsIDE0IDIyOjM5OjM0IGxhbWJkYSBrZXJuZWw6IHNwbGFz aDogaW1hZ2UgZGVjb2RlciBmb3VuZDogZmFkZV9zYXZlcgo= ------=_Part_23328_30782541.1121374715567 Content-Type: application/octet-stream; name="LAMBDA" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LAMBDA" bWFjaGluZQkJYW1kNjQKY3B1CQlIQU1NRVIKaWRlbnQJCUxBTUFCREEKCiMgVG8gc3RhdGljYWxs eSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMK I2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVmYXVsdCBwbGFjZXMgdG8gbG9vayBmb3IgZGV2 aWNlcy4KCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBk ZWJ1ZyBzeW1ib2xzCgpvcHRpb25zIAlTQ0hFRF9VTEUJCSMgVUxFIHNjaGVkdWxlcgpvcHRpb25z IAlQUkVFTVBUSU9OCQkjIEVuYWJsZSBrZXJuZWwgdGhyZWFkIHByZWVtcHRpb24Kb3B0aW9ucyAJ SU5FVAkJCSMgSW50ZXJORVR3b3JraW5nCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBG aWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVz IHN1cHBvcnQKb3B0aW9ucyAJVUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wg bGlzdHMKb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcg ZGlyZWN0b3JpZXMKb3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBk ZXZpY2UKb3B0aW9ucyAJTkZTQ0xJRU5UCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0 aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKb3B0aW9ucyAJTkZT X1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQKb3B0aW9ucyAJTlRG UwkJCSMgTlQgRmlsZSBTeXN0ZW0Kb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3Rl bQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZT CQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQU0VV RE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9HUFQJCSMg R1VJRCBQYXJ0aXRpb24gVGFibGVzLgpvcHRpb25zIAlDT01QQVRfNDMJCSMgTmVlZGVkIGJ5IENP TVBBVF9MSU5VWDMyCm9wdGlvbnMgCUNPTVBBVF9JQTMyCQkjIENvbXBhdGlibGUgd2l0aCBpMzg2 IGJpbmFyaWVzCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJIyBDb21wYXRpYmxlIHdpdGggRnJl ZUJTRDQKb3B0aW9ucyAJQ09NUEFUX0xJTlVYMzIJCSMgQ29tcGF0aWJsZSB3aXRoIGkzODYgbGlu dXggYmluYXJpZXMgCm9wdGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJl Zm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApv cHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9ucyAJU1lT Vk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJIyBT WVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5H ICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JEX0lOU1RB TExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9ucyAJQURBUFRJVkVf R0lBTlQJCSMgR2lhbnQgbXV0ZXggaXMgYWRhcHRpdmUuCgojIERlYnVnZ2luZyBmb3IgdXNlIGlu IC1jdXJyZW50Cm9wdGlvbnMgCUtEQgkJCSMgRW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0 LgpvcHRpb25zIAlEREIJCQkjIFN1cHBvcnQgRERCLgpvcHRpb25zIAlHREIJCQkjIFN1cHBvcnQg cmVtb3RlIEdEQi4KCiMgTWFrZSBhbiBTTVAtY2FwYWJsZSBrZXJuZWwgYnkgZGVmYXVsdApvcHRp b25zIAlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKCiMgV29ya2Fyb3Vu ZHMgZm9yIHNvbWUga25vd24tdG8tYmUtYnJva2VuIGNoaXBzZXRzIChuVmlkaWEgbkZvcmNlMy1Q cm8xNTApCmRldmljZQkJYXRwaWMJCQkjIDgyNTlBIGNvbXBhdGFiaWxpdHkKCiMgTGludXggMzIt Yml0IEFCSSBzdXBwb3J0Cm9wdGlvbnMgCUxJTlBST0NGUwkJIyBDYW5ub3QgYmUgYSBtb2R1bGUg eWV0LgoKIyBCdXMgc3VwcG9ydC4gIERvIG5vdCByZW1vdmUgaXNhLCBldmVuIGlmIHlvdSBoYXZl IG5vIGlzYSBzbG90cwpkZXZpY2UJCWFjcGkKZGV2aWNlCQlpc2EKZGV2aWNlCQlwY2kKCiMgRmxv cHB5IGRyaXZlcwpkZXZpY2UJCWZkYwoKIyBBVEEgYW5kIEFUQVBJIGRldmljZXMKZGV2aWNlCQlh dGEKZGV2aWNlCQlhdGFkaXNrCQkjIEFUQSBkaXNrIGRyaXZlcwpkZXZpY2UJCWF0YXJhaWQJCSMg QVRBIFJBSUQgZHJpdmVzCmRldmljZQkJYXRhcGljZAkJIyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2 aWNlCQlhdGFwaWZkCQkjIEFUQVBJIGZsb3BweSBkcml2ZXMKZGV2aWNlCQlhdGFwaXN0CQkjIEFU QVBJIHRhcGUgZHJpdmVzCmRldmljZQkJYXRhcGljYW0Kb3B0aW9ucyAJQVRBX1NUQVRJQ19JRAkj IFN0YXRpYyBkZXZpY2UgbnVtYmVyaW5nCgojIFNDU0kgQ29udHJvbGxlcnMKZGV2aWNlCQlhaGQJ CSMgQUhBMzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzCgojIFNDU0kgcGVy aXBoZXJhbHMKZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpCmRl dmljZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nl c3MgKGRpc2tzKQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykKZGV2 aWNlCQljZAkJIyBDRApkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3Qg U0NTSSBhY2Nlc3MpCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAo YW5kIFNBRi1URSkKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhl IFBTLzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZp Y2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRldmlj ZQkJdmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcgoKZGV2aWNlCQlzcGxhc2gJCSMgU3BsYXNo IHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKCiMgc3lzY29ucyBpcyB0aGUgZGVmYXVs dCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQpkZXZpY2UJCXNjCm9w dGlvbnMgCVNDX0hJU1RPUllfU0laRT0yMDAJIyBudW1iZXIgb2YgaGlzdG9yeSBidWZmZXIgbGlu ZXMKb3B0aW9ucyAJU0NfTU9VU0VfQ0hBUj0weGZmCSMgY2hhciBjb2RlIGZvciB0ZXh0IG1vZGUg bW91c2UgY3Vyc29yCm9wdGlvbnMgCVNDX1BJWEVMX01PREUJCSMgYWRkIHN1cHBvcnQgZm9yIHRo ZSByYXN0ZXIgdGV4dCBtb2RlCgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNo aXBzZXRzCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBwb3J0CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJy aWRnZSBzdXBwb3J0CmRldmljZQkJY2JiCQkjIGNhcmRidXMgKHllbnRhKSBicmlkZ2UKZGV2aWNl CQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0KSBidXMKZGV2aWNlCQljYXJkYnVzCQkjIENhcmRC dXMgKDMyLWJpdCkgYnVzCgojIFNlcmlhbCAoQ09NKSBwb3J0cwpkZXZpY2UJCXNpbwkJIyA4MjUw LCAxNls0NV01MCBiYXNlZCBzZXJpYWwgcG9ydHMKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBz ZXJpYWwgb3IgcGFyYWxsZWwgUENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVj KDQpIGdsdWUgZHJpdmVyLCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxl IGl0IChjb25uZWN0cyB0byB0aGUgc2lvIGFuZC9vciBwcGMgZHJpdmVycyk6CiNkZXZpY2UJCXB1 YwoKIyBQQ0kgRXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJv bGxlciBjb2RlLgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxp bmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMg c3VwcG9ydApkZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVybmV0 CgojIFBzZXVkbyBkZXZpY2VzLgpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpkZXZp Y2UJCW1lbQkJIyBNZW1vcnkgYW5kIGtlcm5lbCBtZW1vcnkgZGV2aWNlcwpkZXZpY2UJCWlvCQkj IEkvTyBkZXZpY2UKZGV2aWNlCQlyYW5kb20JCSMgRW50cm9weSBkZXZpY2UKZGV2aWNlCQlldGhl cgkJIyBFdGhlcm5ldCBzdXBwb3J0CmRldmljZQkJcHR5CQkjIFBzZXVkby10dHlzICh0ZWxuZXQg ZXRjKQpkZXZpY2UJCW1kCQkjIE1lbW9yeSAiZGlza3MiCgojIFRoZSBgYnBmJyBkZXZpY2UgZW5h YmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4KIyBCZSBhd2FyZSBvZiB0aGUgYWRtaW5p c3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhCiMgTm90ZSB0aGF0ICdicGYn IGlzIHJlcXVpcmVkIGZvciBESENQLgpkZXZpY2UJCWJwZgkJIyBCZXJrZWxleSBwYWNrZXQgZmls dGVyCgojIFVTQiBzdXBwb3J0CmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQpkZXZp Y2UJCW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNlCQl1Z2VuCQkjIEdlbmVy aWMKZGV2aWNlCQl1a2JkCQkjIEtleWJvYXJkCmRldmljZQkJdW1hc3MJCSMgRGlza3MvTWFzcyBz dG9yYWdlIC0gUmVxdWlyZXMgc2NidXMgYW5kIGRhCmRldmljZQkJdW1zCQkjIE1vdXNlCiMgRmly ZVdpcmUgc3VwcG9ydApkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUKZGV2aWNl CQlzYnAJCSMgU0NTSSBvdmVyIEZpcmVXaXJlIChSZXF1aXJlcyBzY2J1cyBhbmQgZGEpCmRldmlj ZQkJZndlCQkjIEV0aGVybmV0IG92ZXIgRmlyZVdpcmUgKG5vbi1zdGFuZGFyZCEpCg== ------=_Part_23328_30782541.1121374715567-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:07:11 2005 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 EE1A816A41C; Thu, 14 Jul 2005 21:07:11 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7461643D45; Thu, 14 Jul 2005 21:07:11 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJM00F1KYNXVI@ms-dienst.rz.rwth-aachen.de>; Thu, 14 Jul 2005 23:07:10 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 14 Jul 2005 23:07:08 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j6EL78Wl028992; Thu, 14 Jul 2005 23:07:08 +0200 (MEST) Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 6078A28439; Thu, 14 Jul 2005 23:07:08 +0200 (CEST) Date: Thu, 14 Jul 2005 23:07:08 +0200 From: Christian Brueffer In-reply-to: <200507141700.27657.jkim@niksun.com> To: Jung-uk Kim Message-id: <20050714210708.GC853@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=cmJC7u66zC7hs+87; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.6i X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <200507141700.27657.jkim@niksun.com> Cc: freebsd-current@FreeBSD.org, phantom@FreeBSD.org Subject: Re: NLS status? 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, 14 Jul 2005 21:07:12 -0000 --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2005 at 05:00:25PM -0400, Jung-uk Kim wrote: > I have been using NLS support for months (enabled with the attached=20 > patch). However the following commit message said that there were=20 > 'edge cases': >=20 > http://docs.freebsd.org/cgi/mid.cgi?200502272217.j1RMHlJA047283 >=20 > Is this still true? Can it be re-enabled on HEAD? >=20 FYI, I sumbitted a german message catalog some time ago as conf/80504. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFC1tP8bHYXjKDtmC0RAkdxAKCHyv4zlovXVGQJv0Cs7eG8VsRY8ACdG2KQ RWrNBVVbdIXC5UtHlN+u2Hg= =oCyr -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:21:47 2005 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 5E15F16A41C for ; Thu, 14 Jul 2005 21:21:47 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B24F43D48 for ; Thu, 14 Jul 2005 21:21:47 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 4B48919F3B; Thu, 14 Jul 2005 14:24:03 -0700 (PDT) From: "Darren Pilgrim" To: "'Eric Anderson'" Date: Thu, 14 Jul 2005 14:21:46 -0700 Message-ID: <003c01c588ba$0ad14a70$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <42D6C686.4070407@centtech.com> Importance: Normal Cc: freebsd-current@freebsd.org Subject: RE: Problems with OpenBSD dhclient 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, 14 Jul 2005 21:21:47 -0000 From: Eric Anderson >=20 > Here's what I think would work well in most situations: >=20 > If another interface (B) is currently down, that has=20 > dhclient running=20 > on it, then when interface (A) comes up with a valid ip, it should=20 > remove the ip info from interface (B). This is a very bad idea. Unless the interfaces have been bonded or configured as redundant for each other, they're independent by design. If I'm using the wired port to do any of the many useful things one can do with multiple interfaces (diagnostics, configuring new devices without loss of internet access, etc.), I don't want the unavoidable link-state changes on that interface to result in my wireless connection going down. > If an interface (A) changes from down->up has conflicting IP=20 > information=20 > with an interface (B) that is down, that dhclient manages, it should=20 > remove the IP setup from interface (B), and set routes=20 > according to the=20 > newly upped interface. > > If an interface (A) changes from down->up, and there is another=20 > interface (B) that is up that dhclient manages, then=20 > configure interface=20 > (A) only if it will not conflict with the other interface's=20 > (B) network.=20 > This could be an rc.conf option - to force newly brought up=20 > interfaces=20 > to override currently up interfaces. No. Multiple interfaces with addresses in the same subnet (or even the same address) is a routing issue. Dhclient is not the correct tool to solve routing issues. A dhclient program needs to do only one thing: negotiate a lease for the interface specified. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 21:23:58 2005 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 0861A16A41C for ; Thu, 14 Jul 2005 21:23:58 +0000 (GMT) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mx1.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0EC043D45 for ; Thu, 14 Jul 2005 21:23:57 +0000 (GMT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.12.8) with ESMTP id j6ELNu2Z069246; Thu, 14 Jul 2005 15:23:56 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.13.1/8.13.1) with ESMTP id j6ELNsVx031840; Thu, 14 Jul 2005 15:23:54 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.13.1/8.13.1/Submit) id j6ELNss8031837; Thu, 14 Jul 2005 15:23:54 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.55274.416783.151528@gromit.timing.com> Date: Thu, 14 Jul 2005 15:23:54 -0600 From: John E Hein To: nj18 In-Reply-To: <42D6D2B7.2080406@nerdshack.com> References: <42D6D2B7.2080406@nerdshack.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on Daffy.timing.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: Strange message: Text file busy. 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, 14 Jul 2005 21:23:58 -0000 Looks like a bug in (t)csh. csh echo date > foo lsof foo COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME csh 66961 jhein 4w VREG 4,17 5 60067 foo exit lsof foo echo $version tcsh 6.13.00 (Astron) 2004-05-19 (i386-intel-FreeBSD) options 8b,nls,dl,al,kan,sm,rh,color,dspm,filec sh echo date > foo lsof foo Try the tcsh-bugs list ... http://mx.gw.com/mailman/listinfo/tcsh-bugs From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 22:28:27 2005 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 6A1CC16A41C; Thu, 14 Jul 2005 22:28:27 +0000 (GMT) (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 0A42643D45; Thu, 14 Jul 2005 22:28:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6EMS53E094501; Thu, 14 Jul 2005 18:28:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6EMSPZ8083177; Thu, 14 Jul 2005 18:28:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 49CCB7302F; Thu, 14 Jul 2005 18:28:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050714222825.49CCB7302F@freebsd-current.sentex.ca> Date: Thu, 14 Jul 2005 18:28:25 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current 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, 14 Jul 2005 22:28:27 -0000 TB --- 2005-07-14 20:28:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-14 20:28:55 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-07-14 20:28:55 - cleaning the object tree TB --- 2005-07-14 20:29:29 - checking out the source tree TB --- 2005-07-14 20:29:29 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-07-14 20:29:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-14 20:35:53 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-14 20:35:53 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-07-14 20:35:53 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-07-14 22:10:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-14 22:10:42 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-07-14 22:10:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jul 14 22:10:42 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Jul 14 22:26:48 UTC 2005 TB --- 2005-07-14 22:26:48 - generating LINT kernel config TB --- 2005-07-14 22:26:48 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-07-14 22:26:48 - /usr/bin/make -B LINT TB --- 2005-07-14 22:26:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-14 22:26:48 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-07-14 22:26:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 14 22:26:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/kern/linker_if.m -h awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/libkern/iconv_converter_if.m -h awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/pci/agp_if.m -h awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-built in -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 /tinderbox/CURRENT/amd64/amd64/src/sys/dev/usb/sl811hs.c:50:23: opt_slhci.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-07-14 22:28:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-14 22:28:25 - ERROR: failed to build lint kernel TB --- 2005-07-14 22:28:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 22:56:20 2005 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 9B1FB16A41C; Thu, 14 Jul 2005 22:56:20 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B00443D49; Thu, 14 Jul 2005 22:56:20 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6EMuIWb057095; Thu, 14 Jul 2005 15:56:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6EMuGdk057094; Thu, 14 Jul 2005 15:56:16 -0700 (PDT) (envelope-from rizzo) Date: Thu, 14 Jul 2005 15:56:16 -0700 From: Luigi Rizzo To: Scott Long Message-ID: <20050714155616.A56618@xorpc.icir.org> References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> <42D419C2.6040606@samsco.org> <20050712160935.A58434@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050712160935.A58434@xorpc.icir.org>; from rizzo@icir.org on Tue, Jul 12, 2005 at 04:09:35PM -0700 Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 14 Jul 2005 22:56:20 -0000 S On Tue, Jul 12, 2005 at 04:09:35PM -0700, Luigi Rizzo wrote: > The approach you suggest in the second part sounds > interesting, except that i have no idea where i should intercept > the calls in the block layer. Any suggestion ? So, rethinking about this oldish thread, you said: > On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote: > ... ... > > An alternate approach that I would suggest is to have the disk scheduler > > freeze the block layer from delivering any new bio's while waiting for > > all of the outstanding bio's to complete, then flip the scheduler > > algorithm and allow i/o delivery to resume. That way there is no > > need to play with driver locks, no need to rummage around in resources > > that are private to the driver, and no need to worry about in-flight > > bio's. It also removes the need to touch every driver with an API > > change. [please correct me if i am wrong] it seems a suitable place would be intercept dev_strategy(bp), however i am not totally clear how i can reach the bioq from there -- geom has a field bp->bio_disk->d_queue, but it does not seem to be universally used, e.g. scsi_da uses bp->bio_disk->d_drv1->softc->bio_queue ata in 5.x uses bp->bio_disk->d_drv1->queue and so on. So if you intercept dev_strategy() you really need to stall I/O until _all_ devices have drained their backlog, because you cannot map the request to the individual bioq :( cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 23:44:29 2005 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 EE8F016A41C for ; Thu, 14 Jul 2005 23:44:29 +0000 (GMT) (envelope-from slawek.zak@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F55643D45 for ; Thu, 14 Jul 2005 23:44:29 +0000 (GMT) (envelope-from slawek.zak@gmail.com) Received: by zproxy.gmail.com with SMTP id m7so293711nzf for ; Thu, 14 Jul 2005 16:44:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SE7Qicuy1mt5S8EzqnGOE5dvk/sdUE7KDBY5JYAImG+f23FeafzCl0tRZre71xED3KJBSe8BmraqCyFwcReelaZGJcwAD+1p593Bfsj4ZGwKUfRzGXpCwbL5YsF3blfiTtXQRRQm3TPj7mOwlAyaN+Os/o2zpjEpIPMNfheIqiw= Received: by 10.36.42.20 with SMTP id p20mr753925nzp; Thu, 14 Jul 2005 16:44:28 -0700 (PDT) Received: by 10.36.89.16 with HTTP; Thu, 14 Jul 2005 16:44:28 -0700 (PDT) Message-ID: <787bbe1c050714164472e8d9c6@mail.gmail.com> Date: Fri, 15 Jul 2005 01:44:28 +0200 From: =?ISO-8859-2?Q?S=B3awek_=AFak?= To: freebsd-current@freebsd.org In-Reply-To: <787bbe1c0507141358ffb3c4c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <787bbe1c0507141358ffb3c4c@mail.gmail.com> Subject: Re: USB controller not found/working on Sun V40z workstation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?S=B3awek_=AFak?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 23:44:30 -0000 T24gNy8xNC8wNSwgU7Nhd2VrIK9hayA8c2xhd2VrLnpha0BnbWFpbC5jb20+IHdyb3RlOgo+IFBy b2JsZW0gc3RhdGVkIGluIHRoZSBzdWJqZWN0LiBJIG5lZWQgVVNCIHRvIHdvcmsgYmFkbHksIGFz IHRoZXJlIGlzCj4gbm8gUFMvMiBmb3Iga2V5Ym9hcmQgYW5kIG1vdXNlIGluIHRoaXMgd29ya3N0 YXRpb24uCj4gCj4gSSd2ZSB0cmllZCA1LjQgU1RBQkxFLCA2LjAgQ1VSUkVOVCBhbmQgNi4wIEJF VEEuIE91dCBvZiAzMCBib290cyBVU0IKPiB3YXMgZGV0ZWN0ZWQgdHdpY2UgYW5kIGtleWJvYXJk IHdhcyB3b3JraW5nIHRvby4gSSBhdHRhY2ggbG9nIGZyb20gdHdvCj4gb2YgdGhvc2Ugc3VjY2Vz c2Z1bCBib290cyAoNS4zIFJFTEVBU0UgYW5kIDYuMCBDVVJSRU5UKSBhbmQgYSBsYXRlIG9uZQo+ IGZyb20gNi4wIEJFVEEgYm9vdCAtdi4gS2VybmVsIGNvbmZpZyBpcyBhdHRhY2hlZCB0b28uCj4g Cj4gQW55IGhlbHAgYW5kIHN1Z2dlc3Rpb25zIGFwcHJlY2lhdGVkIQoKVWdoLiBOaWdodCB0aW1l LiBJdCdzIGEgVzIxMDB6IHdvcmtzdGF0aW9uLCBub3QgVjQwei4gU29ycnkuCgovUwotLSAKU7Nh d2VrIK9hayAvIFVOSVggU3lzdGVtcyBBZG1pbmlzdHJhdG9yCg== From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 23:48:34 2005 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 DF28616A41C; Thu, 14 Jul 2005 23:48:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 760F043D46; Thu, 14 Jul 2005 23:48:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6ENmXVT002676; Thu, 14 Jul 2005 19:48:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6ENmXSs015001; Thu, 14 Jul 2005 19:48:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 06E477302F; Thu, 14 Jul 2005 19:48:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050714234832.06E477302F@freebsd-current.sentex.ca> Date: Thu, 14 Jul 2005 19:48:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [current 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, 14 Jul 2005 23:48:35 -0000 TB --- 2005-07-14 22:28:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-14 22:28:25 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-07-14 22:28:25 - cleaning the object tree TB --- 2005-07-14 22:28:54 - checking out the source tree TB --- 2005-07-14 22:28:54 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-07-14 22:28:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-14 22:35:21 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-14 22:35:21 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-07-14 22:35:21 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-07-14 23:43:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-14 23:43:07 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-07-14 23:43:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jul 14 23:43:08 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/dev/nsp/nsp_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/dev/null/null.c awk -f /tinderbox/CURRENT/i386/i386/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/card_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-bound ary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror card_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/pccard.c /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/pccard.c: In function `pccard_probe_nomatch': /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/pccard.c:976: error: `i' undeclared (first use in this function) /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/pccard.c:976: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/i386/src/sys/dev/pccard/pccard.c:976: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-07-14 23:48:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-14 23:48:32 - ERROR: failed to build generic kernel TB --- 2005-07-14 23:48:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 00:46:23 2005 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 D8EA016A41C; Fri, 15 Jul 2005 00:46:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF9343D45; Fri, 15 Jul 2005 00:46:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6F0pPMN080515; Thu, 14 Jul 2005 18:51:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D7075F.5070907@samsco.org> Date: Thu, 14 Jul 2005 18:46:23 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> <42D419C2.6040606@samsco.org> <20050712160935.A58434@xorpc.icir.org> <20050714155616.A56618@xorpc.icir.org> In-Reply-To: <20050714155616.A56618@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 00:46:24 -0000 Luigi Rizzo wrote: > S > On Tue, Jul 12, 2005 at 04:09:35PM -0700, Luigi Rizzo wrote: > >>The approach you suggest in the second part sounds >>interesting, except that i have no idea where i should intercept >>the calls in the block layer. Any suggestion ? > > > So, rethinking about this oldish thread, you said: > > >>On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote: >>... > > ... > >>>An alternate approach that I would suggest is to have the disk scheduler >>>freeze the block layer from delivering any new bio's while waiting for >>>all of the outstanding bio's to complete, then flip the scheduler >>>algorithm and allow i/o delivery to resume. That way there is no >>>need to play with driver locks, no need to rummage around in resources >>>that are private to the driver, and no need to worry about in-flight >>>bio's. It also removes the need to touch every driver with an API >>>change. > > > [please correct me if i am wrong] > > it seems a suitable place would be intercept dev_strategy(bp), > however i am not totally clear how i can reach the bioq > from there -- geom has a field > bp->bio_disk->d_queue, > but it does not seem to be universally used, e.g. > scsi_da uses > bp->bio_disk->d_drv1->softc->bio_queue > ata in 5.x uses > bp->bio_disk->d_drv1->queue > and so on. > > So if you intercept dev_strategy() you really need to stall I/O > until _all_ devices have drained their backlog, because you > cannot map the request to the individual bioq :( > > cheers > luigi How often are you going to be changing the scheduler at runtime? Is the scheduler meant to be aware of individual devices? Again, I'm not advocating that the upper layers be able to look at or manipulate the driver bioq's. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 01:05:54 2005 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 CF8B916A41C for ; Fri, 15 Jul 2005 01:05:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B1B43D49 for ; Fri, 15 Jul 2005 01:05:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6F15nms096318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2005 18:05:50 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42D70C0B.9090802@errno.com> Date: Thu, 14 Jul 2005 18:06:19 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050714182136.071B35D07@ptavv.es.net> In-Reply-To: <20050714182136.071B35D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 01:05:54 -0000 Kevin Oberman wrote: > Since switching from the ISC DHCP client to OpenBSD on my laptop, I've > been having some issues with managing my network connection. I'm running > 7.0-current built yesterday (kernel and world.) > > On a typical day I boot my system on wired connection with a static > address and gateway. Everything works fine. DHCP is not playing, yet. > > When I go to a meeting, I want to switch to the wireless network. In the > past I simply entered 'dhclient wi0' and I was up and running. The > wireless uses DHCP, so dhclient would get the address and gateway along > with DNS servers and instantiate these and I would be connected. The > default route that had been in use previously was replaced with the DHCP > supplied gateway. Switching back was a simple matter of '/etc/rc.d/netif > start fxp0'. > > While on the wireless network, I could roam with only brief loss of > connectivity when I moved from one AP to another, but the wireless > system soon "finds" me and I continue on-line with the same address and > gateway. Even my ssh sessions are maintained. > > Now life is not so nice with the OpenBSD dhclient. > > When I switch to wireless, dhclient no longer replaces the default > route. I need to take down my wired connection and flush routes before > starting dhclient. Not a big deal, but an annoyance. This sounds like the issue with dhclient not deleting it's routes on termination. > > More serious is that I can't roam. When I move between APs, dhclient > exits and I need to manually re-start it. I lose my SSH sessions. Ugh! This should not be happening; dhclient should get a disassociate event, drop the lease, then get an associate when you join the new ap and immediately grab a new lease. In fact this was the primary reason I wanted to switch to this new code in the first place. > > Worse, I occasionally see my association drop momentarily when I am > simply sitting and typing. Once again, dhclient dies and I must manually > restart it and then re-establish my SSH and recover anything broken when > the connection dropped. This is fairly serious! I don't understand what > causes this, but it is infrequent which makes it hard to catch. > > It looks like killing dhclient when the interface drops is not a good > idea. At very least, it needs to give a little time for re-association > before dropping the DHCP client. Something is busted; I'll need to investigate. If you want to help you can run ieee80211watch (from tools/tools/ath) while things happen and note the events that get sent by the kernel. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 01:13:57 2005 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 D11B616A41C; Fri, 15 Jul 2005 01:13:57 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD8E43D45; Fri, 15 Jul 2005 01:13:57 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6F1Dv52058459; Thu, 14 Jul 2005 18:13:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6F1Dul5058458; Thu, 14 Jul 2005 18:13:57 -0700 (PDT) (envelope-from rizzo) Date: Thu, 14 Jul 2005 18:13:56 -0700 From: Luigi Rizzo To: Scott Long Message-ID: <20050714181356.A58300@xorpc.icir.org> References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> <42D419C2.6040606@samsco.org> <20050712160935.A58434@xorpc.icir.org> <20050714155616.A56618@xorpc.icir.org> <42D7075F.5070907@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42D7075F.5070907@samsco.org>; from scottl@samsco.org on Thu, Jul 14, 2005 at 06:46:23PM -0600 Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 01:13:57 -0000 On Thu, Jul 14, 2005 at 06:46:23PM -0600, Scott Long wrote: ... > How often are you going to be changing the scheduler at runtime? Is in general, almost never. However, suppose you have per-device schedulers as phk was suggesting, then you'd really like to decouple the devices so reconfiguring one of them does not affect the others. Anyways there might be a way out... requests go from dev_strategy() to the individual disksort routine where, during the switch, the scheduler can 'absorb' them while the real queue drains (assuming the subsequent device_start() routine does not complain too much for finding the queue empty!). Then, when the device queue becomes empty (the scheduler knows because it is serving the bio_remove() requests) it can switch to the new one, and resubmit old requests through dev_strategy(). This would also solve the problem of implementing non-work-conserving schedulers. Basically it's the same approach followed in dummynet, you steal the packets from ip_{input,output}() and resubmit them later. Does any of you know what are the assumptions (locks held etc.) for calling dev_strategy() in 5.x and above ? cheers luigi > the scheduler meant to be aware of individual devices? Again, I'm > not advocating that the upper layers be able to look at or manipulate > the driver bioq's. > > Scott > _______________________________________________ > 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 Fri Jul 15 01:15:36 2005 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 0DB0D16A41C; Fri, 15 Jul 2005 01:15:36 +0000 (GMT) (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 A6A7F43D45; Fri, 15 Jul 2005 01:15:35 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F1FEo5002697; Thu, 14 Jul 2005 21:15:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F1FYDd030565; Thu, 14 Jul 2005 21:15:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 779FE7302F; Thu, 14 Jul 2005 21:15:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050715011534.779FE7302F@freebsd-current.sentex.ca> Date: Thu, 14 Jul 2005 21:15:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current 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: Fri, 15 Jul 2005 01:15:36 -0000 TB --- 2005-07-14 23:48:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-14 23:48:33 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-07-14 23:48:33 - cleaning the object tree TB --- 2005-07-14 23:49:05 - checking out the source tree TB --- 2005-07-14 23:49:05 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-07-14 23:49:05 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-14 23:55:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-14 23:55:29 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-07-14 23:55:29 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-07-15 01:02:46 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-15 01:02:46 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-07-15 01:02:46 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jul 15 01:02:47 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -Bshareable -d -warn-common -o if_patm.ko.debug if_patm.kld objcopy --strip-debug if_patm.ko.debug if_patm.ko ===> pccard (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard/../../dev/pccard/pccard.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard/../../dev/pccard/pccard.c: In function `pccard_probe_nomatch': /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: `i' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/pccard. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-07-15 01:15:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-15 01:15:34 - ERROR: failed to build generic kernel TB --- 2005-07-15 01:15:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 02:31:34 2005 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 A349416A41C for ; Fri, 15 Jul 2005 02:31:34 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F3F43D46 for ; Fri, 15 Jul 2005 02:31:33 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id c3so304529nze for ; Thu, 14 Jul 2005 19:31:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=oGPy9OHG2Qhz02bDGn33/16Vr60f3juhRlcY7g+DrXdk7Aoxv+UE+sdfwE0NutVoM+/iORFb1HAF89YE9r/xpk14XWVozTqraKlVAIGEExx3QHldbbgoivZaWhC8UHm+Xi1dtb37Xd5q1BPsUghfeQVqyRY+y7IMS9ZZPPtXGgc= Received: by 10.36.46.15 with SMTP id t15mr856337nzt; Thu, 14 Jul 2005 19:31:32 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Thu, 14 Jul 2005 19:31:31 -0700 (PDT) Message-ID: Date: Fri, 15 Jul 2005 10:31:31 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_27237_16003693.1121394691917" Subject: AMD64 boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 02:31:35 -0000 ------=_Part_27237_16003693.1121394691917 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have a new AMD64 installation (running -current).=20 During boot, the following message appears numerous times: acpi_perf0: invalid _PSS package Does this message affect the system in any negative way? pciconf -lv output follows: hostb0@pci0:0:0: class=3D0x060000 card=3D0x81591043 chip=3D0x0760103= 9 rev=3D0x03 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS760 Athlon 64 CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0x00021039 rev=3D= 0x00 hdr=3D0x01 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D '6202 Virtual PCI to PCI Bridge (AGP)' class =3D bridge subclass =3D PCI-PCI isab0@pci0:2:0: class=3D0x060100 card=3D0x00000000 chip=3D0x09651039 rev=3D= 0x47 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:2:5: class=3D0x010180 card=3D0x81391043 chip=3D0x5513103= 9 rev=3D0x01 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS5513 EIDE Controller (A,B step)' class =3D mass storage subclass =3D ATA none0@pci0:2:7: class=3D0x040100 card=3D0x810d1043 chip=3D0x70121039 rev=3D= 0xa0 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS7013 PCI Audio Accelerator' class =3D multimedia subclass =3D audio ohci0@pci0:3:0: class=3D0x0c0310 card=3D0x81391043 chip=3D0x70011039 rev=3D= 0x0f hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS5597/8 Universal Serial Bus Controller' class =3D serial bus subclass =3D USB ohci1@pci0:3:1: class=3D0x0c0310 card=3D0x81391043 chip=3D0x70011039 rev=3D= 0x0f hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS5597/8 Universal Serial Bus Controller' class =3D serial bus subclass =3D USB ohci2@pci0:3:2: class=3D0x0c0310 card=3D0x81391043 chip=3D0x70011039 rev=3D= 0x0f hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS5597/8 Universal Serial Bus Controller' class =3D serial bus subclass =3D USB ehci0@pci0:3:3: class=3D0x0c0320 card=3D0x81391043 chip=3D0x70021039 rev=3D= 0x00 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS7002 USB 2.0 Enhanced Host Controller' class =3D serial bus subclass =3D USB none1@pci0:4:0: class=3D0x020000 card=3D0x81391043 chip=3D0x01901039 rev=3D= 0x00 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' class =3D network subclass =3D ethernet pcib2@pci0:6:0: class=3D0x060400 card=3D0x000000b0 chip=3D0x000a1039 rev=3D= 0x00 hdr=3D0x01 vendor =3D 'Silicon Integrated Systems (SiS)' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:7:0: class=3D0x060400 card=3D0x000000b0 chip=3D0x000a1039 rev=3D= 0x00 hdr=3D0x01 vendor =3D 'Silicon Integrated Systems (SiS)' class =3D bridge subclass =3D PCI-PCI vr0@pci0:9:0: class=3D0x020000 card=3D0x14011186 chip=3D0x30651106 rev=3D= 0x43 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT6102 Rhine II PCI Fast Ethernet Controller' class =3D network subclass =3D ethernet hostb1@pci0:24:0: class=3D0x060000 card=3D0x00000000 chip=3D0x1100102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon 64 / Opteron HyperTransport Technology Configurati= on' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:24:1: class=3D0x060000 card=3D0x00000000 chip=3D0x1101102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon 64 / Opteron Address Map' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:24:2: class=3D0x060000 card=3D0x00000000 chip=3D0x1102102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon 64 / Opteron DRAM Controller' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:24:3: class=3D0x060000 card=3D0x00000000 chip=3D0x1103102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon 64 / Opteron Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI none2@pci1:0:0: class=3D0x030000 card=3D0x81591043 chip=3D0x63301039 rev=3D= 0x00 hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS661FX/M661FX/760/741/M760/M741 GUI 2D/3D Accelerator' class =3D display subclass =3D VGA Jiawei Ye --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming ------=_Part_27237_16003693.1121394691917 Content-Type: text/plain; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICMyOiBGcmkgSnVsIDE1IDAxOjQ0OjM2 IENTVCAyMDA1CiAgICBsZWFmeUBvaG11Mi5zdW52aWRlby5jb20udHc6L3Vzci9vYmovdXNyL3Ny Yy9zeXMvT0hNVTIKQUNQSSBBUElDIFRhYmxlOiA8QSBNIEkgIE9FTUFQSUMgPgpUaW1lY291bnRl ciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEFNRCBBdGhsb24o dG0pIDY0IFByb2Nlc3NvciAyODAwKyAoMTgwMy45Ny1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4ZjRhICBTdGVwcGluZyA9IDEwCiAgRmVhdHVyZXM9 MHg3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRS UixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTI+CiAgQU1E IEZlYXR1cmVzPTB4ZTA1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLExNLDNETm93KywzRE5vdz4KcmVh bCBtZW1vcnkgID0gNTAzMTE5ODcyICg0NzkgTUIpCmF2YWlsIG1lbW9yeSA9IDQ3NDQxOTIwMCAo NDUyIE1CKQppb2FwaWMwIDxWZXJzaW9uIDEuND4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmFj cGkwOiA8QSBNIEkgT0VNUlNEVD4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAo Zml4ZWQpCnBjaV9saW5rMDogPEFDUEkgUENJIExpbmsgTE5LQT4gaXJxIDEwIG9uIGFjcGkwCnBj aV9saW5rMTogPEFDUEkgUENJIExpbmsgTE5LQj4gaXJxIDAgb24gYWNwaTAKcGNpX2xpbmsyOiA8 QUNQSSBQQ0kgTGluayBMTktDPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xpbmszOiA8QUNQSSBQQ0kg TGluayBMTktEPiBpcnEgNSBvbiBhY3BpMApwY2lfbGluazQ6IDxBQ1BJIFBDSSBMaW5rIExOS0U+ IGlycSA1IG9uIGFjcGkwCnBjaV9saW5rNTogPEFDUEkgUENJIExpbmsgTE5LRj4gaXJxIDMgb24g YWNwaTAKcGNpX2xpbms2OiA8QUNQSSBQQ0kgTGluayBMTktHPiBpcnEgNSBvbiBhY3BpMApwY2lf bGluazc6IDxBQ1BJIFBDSSBMaW5rIExOS0g+IGlycSAxMCBvbiBhY3BpMApUaW1lY291bnRlciAi QUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6 IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAK Y3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3Bl cmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2Fn ZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9Q U1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBp bnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3Bp X3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFj a2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlk IF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYw OiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQph Y3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1Mg cGFja2FnZQphY3BpX3BlcmYwOiBpbnZhbGlkIF9QU1MgcGFja2FnZQphY3BpX3BlcmYwOiBpbnZh bGlkIF9QU1MgcGFja2FnZQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4 LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZl ciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kw CmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8U2lTIDk2NSBVRE1BMTMzIGNvbnRy b2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4 ZmZhZiBhdCBkZXZpY2UgMi41IG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKcGNpMDogPG11bHRpbWVkaWEsIGF1 ZGlvPiBhdCBkZXZpY2UgMi43IChubyBkcml2ZXIgYXR0YWNoZWQpCm9oY2kwOiA8U2lTIDU1NzEg VVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlYmY0MDAwLTB4ZmViZjRmZmYgaXJxIDIwIGF0IGRldmlj ZSAzLjAgb24gcGNpMApvaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogT0hDSSB2ZXJzaW9uIDEu MCwgbGVnYWN5IHN1cHBvcnQKdXNiMDogPFNpUyA1NTcxIFVTQiBjb250cm9sbGVyPiBvbiBvaGNp MAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBTaVMgT0hDSSByb290IGh1YiwgY2xhc3Mg OS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCm9oY2kxOiA8U2lTIDU1NzEgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZl YmY1MDAwLTB4ZmViZjVmZmYgaXJxIDIxIGF0IGRldmljZSAzLjEgb24gcGNpMApvaGNpMTogW0dJ QU5ULUxPQ0tFRF0KdXNiMTogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMTog PFNpUyA1NTcxIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4w CnVodWIxOiBTaVMgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDEKdWh1YjE6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kyOiA8 U2lTIDU1NzEgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlYmY2MDAwLTB4ZmViZjZmZmYgaXJxIDIy IGF0IGRldmljZSAzLjIgb24gcGNpMApvaGNpMjogW0dJQU5ULUxPQ0tFRF0KdXNiMjogT0hDSSB2 ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMjogPFNpUyA1NTcxIFVTQiBjb250cm9sbGVy PiBvbiBvaGNpMgp1c2IyOiBVU0IgcmV2aXNpb24gMS4wCnVodWIyOiBTaVMgT0hDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjI6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBj b250cm9sbGVyPiBtZW0gMHhmZWJmNzAwMC0weGZlYmY3ZmZmIGlycSAyMyBhdCBkZXZpY2UgMy4z IG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNi MzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAzIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVz YjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjM6IFVT QiByZXZpc2lvbiAyLjAKdWh1YjM6IFNpUyBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAy LjAwLzEuMDAsIGFkZHIgMQp1aHViMzogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKcGNpMDogPG5ldHdvcmssIGV0aGVybmV0PiBhdCBkZXZpY2UgNC4wIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBw Y2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIz CnZyMDogPFZJQSBWVDYxMDIgUmhpbmUgSUkgMTAvMTAwQmFzZVRYPiBwb3J0IDB4ZTAwMC0weGUw ZmYgbWVtIDB4ZmViZjM4MDAtMHhmZWJmMzhmZiBpcnEgMTYgYXQgZGV2aWNlIDkuMCBvbiBwY2kw Cm1paWJ1czA6IDxNSUkgYnVzPiBvbiB2cjAKdWtwaHkwOiA8R2VuZXJpYyBJRUVFIDgwMi4zdSBt ZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1czAKdWtwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgs IDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwp2cjA6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjA1OjVkOjBkOjkwOmE4CmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRr YmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEg b24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGZsYWdzIDB4MSBpcnEgMSBvbiBhdGtiZGMw CmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0Kc2lvMDogPDE2NTUwQS1jb21w YXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNw aTAKc2lvMDogdHlwZSAxNjU1MEEKcHBjMDogPFN0YW5kYXJkIHBhcmFsbGVsIHByaW50ZXIgcG9y dD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBhY3BpMApwcGMwOiBHZW5lcmljIGNoaXBzZXQg KE5JQkJMRS1vbmx5KSBpbiBDT01QQVRJQkxFIG1vZGUKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBi dXM+IG9uIHBwYzAKcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKbHB0 MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDog PFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0g MHhjMDAwMC0weGM3ZmZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4 MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpz aW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8x OiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZAp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0 IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3VudGVyICJU U0MiIGZyZXF1ZW5jeSAxODAzOTY3Mjg0IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKYWQwOiAxMTcyNDZNQiA8TWF4dG9yIDRSMTIwTDAgUkFNQjFUVTA+ IGF0IGF0YTAtbWFzdGVyIFVETUExMzMKQVRBIFBzZXVkb1JBSUQgbG9hZGVkClRyeWluZyB0byBt b3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczFhCg== ------=_Part_27237_16003693.1121394691917-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 03:11:43 2005 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 5A96616A41C; Fri, 15 Jul 2005 03:11:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0119743D46; Fri, 15 Jul 2005 03:11:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F3BfVH037411; Thu, 14 Jul 2005 23:11:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F3BgeK030005; Thu, 14 Jul 2005 23:11:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B0ACC7302F; Thu, 14 Jul 2005 23:11:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050715031141.B0ACC7302F@freebsd-current.sentex.ca> Date: Thu, 14 Jul 2005 23:11:41 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [current tinderbox] failure on ia64/ia64 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: Fri, 15 Jul 2005 03:11:43 -0000 TB --- 2005-07-15 01:15:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-15 01:15:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-07-15 01:15:34 - cleaning the object tree TB --- 2005-07-15 01:16:08 - checking out the source tree TB --- 2005-07-15 01:16:08 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-07-15 01:16:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-15 01:22:19 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-15 01:22:19 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-07-15 01:22:19 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-07-15 02:54:33 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-15 02:54:33 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-07-15 02:54:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jul 15 02:54:34 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -Bshareable -d -warn-common -o if_patm.ko.debug if_patm.kld objcopy --strip-debug if_patm.ko.debug if_patm.ko ===> pccard (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard/../../dev/pccard/pccard.c /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard/../../dev/pccard/pccard.c: In function `pccard_probe_nomatch': /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: `i' undeclared (first use in this function) /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard/../../dev/pccard/pccard.c:976: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules/pccard. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-07-15 03:11:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-15 03:11:41 - ERROR: failed to build generic kernel TB --- 2005-07-15 03:11:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 05:22:23 2005 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 4DDA516A41C for ; Fri, 15 Jul 2005 05:22:23 +0000 (GMT) (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 DBA9243D45 for ; Fri, 15 Jul 2005 05:22:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 0B7BC5E4F; Fri, 15 Jul 2005 01:22:22 -0400 (EDT) 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 29479-09; Fri, 15 Jul 2005 01:22:12 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-54-113.ny325.east.verizon.net [68.161.54.113]) by pi.codefab.com (Postfix) with ESMTP id B6EC35D41; Fri, 15 Jul 2005 01:22:11 -0400 (EDT) Message-ID: <42D74806.5040204@mac.com> Date: Fri, 15 Jul 2005 01:22:14 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> <20050714193037.GF19351@odin.ac.hmc.edu> <42D6C686.4070407@centtech.com> <20050714202820.GE1064@webcom.it> In-Reply-To: <20050714202820.GE1064@webcom.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 05:22:23 -0000 Andrea Campi wrote: > picking one random message to answer to... Agreed. :-) > let's not forget Zeroconf (169.254.x.x) address assignment. I have > (admittedly outdated now) patches to howl to make it work that are > waiting on someone to help me finalize them AND most integrate with > appropriate scripts so that things work as expected. This means > removing the autoconfigured address when obtaining a proper address > via DHCP, and vice versa. > > A full solution should IMHO take this into account, too. For the wired case, it's entirely reasonable to respond to a link down/link up combination by doing an ARPOP_REQUEST to the IP address of a router (which quite probably provides the default route) on that interface's associated network, and/or the IP address of the DHCP server which assigned your machine it's IP. If your router/DHCP server still thinks that your MAC address belongs to that IP address, well, the system ought to rely on TCP retransmissions or the design of higher levels to handle a timeperiod of no traffic without needlessly dropping connections by dropping routes, closing open TCP sockets before their time, etc. In other words, an interface link down event should *not* blindly remove or change the assigned IP address on an interface, only a link up event might, and only then after checking via ARP (or a DHCP query, or similar variants). In the meantime, and in the absense of having "multiple default routes" (routes have metrics, can't one use them to prioritize and choose an alternate path if the packets get routed through a link which is down?), it might be nice to pick an alternate default route upon a link-down event. I don't understand the layer-2 aspects of 802.11 wireless stuff modulo the various flavors of WEP and WPA encryption to know whether there is an exact equivalent to ARP, but I'd imagine something could be used to check whether the AP you were just connected to still thinks your machine is what it saw a minute or two ago, before your signal dropped off for a bit... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 06:43:23 2005 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 E0AE716A41C; Fri, 15 Jul 2005 06:43:23 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8812F43D48; Fri, 15 Jul 2005 06:43:23 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 8B07DBC83; Fri, 15 Jul 2005 06:43:18 +0000 (UTC) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 14 Jul 2005 18:13:56 PDT." <20050714181356.A58300@xorpc.icir.org> Date: Fri, 15 Jul 2005 08:43:17 +0200 Message-ID: <8462.1121409797@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Robert Watson , s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 06:43:24 -0000 In message <20050714181356.A58300@xorpc.icir.org>, Luigi Rizzo writes: >Anyways there might be a way out... >requests go from dev_strategy() The right place for this is geom_disk.c:g_disk_start() and the start routines of the drivers which do not use geom_disk. The easiest way to handle it would be to set a flag on the g_provider saying "no more", have g_down spill the requests into a side queue and when the driver is ready again, it calls some function which pulls the request out of the side queue again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 06:45:25 2005 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 DB8E916A41C; Fri, 15 Jul 2005 06:45:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40D2343D49; Fri, 15 Jul 2005 06:45:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6F6oNd7081946; Fri, 15 Jul 2005 00:50:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D75B84.7090601@samsco.org> Date: Fri, 15 Jul 2005 00:45:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <8462.1121409797@phk.freebsd.dk> In-Reply-To: <8462.1121409797@phk.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Luigi Rizzo , s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 06:45:26 -0000 Poul-Henning Kamp wrote: > In message <20050714181356.A58300@xorpc.icir.org>, Luigi Rizzo writes: > > >>Anyways there might be a way out... >>requests go from dev_strategy() > > > The right place for this is geom_disk.c:g_disk_start() and the start > routines of the drivers which do not use geom_disk. > > The easiest way to handle it would be to set a flag on the g_provider > saying "no more", have g_down spill the requests into a side queue > and when the driver is ready again, it calls some function which > pulls the request out of the side queue again. > > I agree. The 'side queue' can be a bioq also that gets handed off in whole to the driver once the path is unfrozen, but that's an optimization that is best done at a later time. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 06:48:20 2005 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 B4FC916A41C; Fri, 15 Jul 2005 06:48:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1582443D45; Fri, 15 Jul 2005 06:48:19 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F6mIE9072088; Fri, 15 Jul 2005 02:48:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6F6mI5c089683; Fri, 15 Jul 2005 02:48:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 48D0D7302F; Fri, 15 Jul 2005 02:48:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050715064818.48D0D7302F@freebsd-current.sentex.ca> Date: Fri, 15 Jul 2005 02:48:18 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [current tinderbox] failure on sparc64/sparc64 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: Fri, 15 Jul 2005 06:48:20 -0000 TB --- 2005-07-15 04:51:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-15 04:51:40 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-07-15 04:51:40 - cleaning the object tree TB --- 2005-07-15 04:52:17 - checking out the source tree TB --- 2005-07-15 04:52:17 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-07-15 04:52:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-15 05:05:17 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-15 05:05:17 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-07-15 05:05:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-07-15 06:34:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-15 06:34:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-07-15 06:34:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jul 15 06:34:08 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Jul 15 06:46:49 UTC 2005 TB --- 2005-07-15 06:46:49 - generating LINT kernel config TB --- 2005-07-15 06:46:49 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-07-15 06:46:49 - /usr/bin/make -B LINT TB --- 2005-07-15 06:46:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-15 06:46:49 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-07-15 06:46:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 15 06:46:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/linker_if.m -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/iconv_converter_if.m -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/ofw/ofw_bus_if.m -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/ofw_pci_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmode l=medlow -msoft-float -ffreestanding /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/usb/sl811hs.c:50:23: opt_slhci.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-07-15 06:48:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-15 06:48:18 - ERROR: failed to build lint kernel TB --- 2005-07-15 06:48:18 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 06:57:02 2005 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 DFF6F16A41F; Fri, 15 Jul 2005 06:57:02 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836C143D53; Fri, 15 Jul 2005 06:57:02 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id AE3D9BC83; Fri, 15 Jul 2005 06:57:00 +0000 (UTC) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Jul 2005 00:45:24 MDT." <42D75B84.7090601@samsco.org> Date: Fri, 15 Jul 2005 08:57:00 +0200 Message-ID: <8524.1121410620@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Poul-Henning Kamp , s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org, Luigi Rizzo Subject: Re: location of bioq lock 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, 15 Jul 2005 06:57:03 -0000 In message <42D75B84.7090601@samsco.org>, Scott Long writes: >I agree. The 'side queue' can be a bioq also that gets handed off in >whole to the driver once the path is unfrozen, but that's an >optimization that is best done at a later time. It's hardly worth the effort I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 08:26:05 2005 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 A0BE216A41C for ; Fri, 15 Jul 2005 08:26:05 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 421E143D45 for ; Fri, 15 Jul 2005 08:26:04 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id 22AB9C026 for ; Fri, 15 Jul 2005 10:26:03 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6F8Psoo021253; Fri, 15 Jul 2005 10:26:00 +0200 (CEST) From: Thierry Herbelot To: bzeeb+freebsd+lor@zabbadoz.net Date: Fri, 15 Jul 2005 10:25:44 +0200 User-Agent: KMail/1.8.1 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507151025.46679.thierry@herbelot.com> Cc: freebsd-current@freebsd.org Subject: new lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 08:26:05 -0000 Hello, I just had a look a the list of LOR you maintain and I did not see this one : (on a very recent -Current, on both a UP and an SMP machine, with straight GENERIC kernels) lock order reversal 1st 0xc0979dc0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1475 2nd 0xc1061144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c092eef8,c092f038,c08b9964) at kdb_backtrace+0x29 witness_checkorder(c1061144,9,c0870168,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1061144,0,c0870168,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c10610c0,c0870168,90d) at _vm_map_lock+0x26 vm_map_remove(c10610c0,c19e0000,c19e1000,c83adc08,c077e2c1) at vm_map_remove+0x1f kmem_free(c10610c0,c19e0000,1000,c83adc38,c077dc72) at kmem_free+0x25 page_free(c19e0000,1000,2) at page_free+0x29 zone_drain(c104adc0) at zone_drain+0x26a zone_foreach(c077da08,c83adcec,c078f487,c133c180,c83adc74) at zone_foreach+0x37 uma_reclaim(c133c180,c83adc74,0,c0925520,c83adc80) at uma_reclaim+0x12 vm_pageout_scan(0,c097a220,0,c0871655,5c3) at vm_pageout_scan+0x103 vm_pageout(0,c83add38,0,c0790240,0) at vm_pageout+0x2c3 fork_exit(c0790240,0,c83add38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc83add6c, ebp = 0 --- CVS idents : /usr/src/sys/vm/uma_core.c: $FreeBSD: src/sys/vm/uma_core.c,v 1.122 2005/07/14 16:35:13 rwatson Exp $ /usr/src/sys/vm/vm_map.c: $FreeBSD: src/sys/vm/vm_map.c,v 1.366 2005/05/02 07:05:20 alc Exp $ Cheers TfH From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 09:05:11 2005 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 A16F416A41C for ; Fri, 15 Jul 2005 09:05:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C72D43D49 for ; Fri, 15 Jul 2005 09:05:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 6602C1FFAD2; Fri, 15 Jul 2005 11:05:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 076811FF9AF; Fri, 15 Jul 2005 11:05:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id DE79615652; Fri, 15 Jul 2005 09:04:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id D3FEA15583; Fri, 15 Jul 2005 09:04:42 +0000 (UTC) Date: Fri, 15 Jul 2005 09:04:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Thierry Herbelot Subject: new lock order reversal (fwd) 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, 15 Jul 2005 09:05:11 -0000 Added as http://sources.zabbadoz.net/freebsd/lor.html#109 ---------- Forwarded message ---------- Date: Fri, 15 Jul 2005 10:42:19 +0200 From: Thierry Herbelot Subject: new lock order reversal Hello, I just had a look a the list of LOR you maintain and I did not see this one : (on a very recent -Current, on both a UP and an SMP machine, with straight GENERIC kernels) lock order reversal 1st 0xc0979dc0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1475 2nd 0xc1061144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c092eef8,c092f038,c08b9964) at kdb_backtrace+0x29 witness_checkorder(c1061144,9,c0870168,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1061144,0,c0870168,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c10610c0,c0870168,90d) at _vm_map_lock+0x26 vm_map_remove(c10610c0,c19e0000,c19e1000,c83adc08,c077e2c1) at vm_map_remove+0x1f kmem_free(c10610c0,c19e0000,1000,c83adc38,c077dc72) at kmem_free+0x25 page_free(c19e0000,1000,2) at page_free+0x29 zone_drain(c104adc0) at zone_drain+0x26a zone_foreach(c077da08,c83adcec,c078f487,c133c180,c83adc74) at zone_foreach+0x37 uma_reclaim(c133c180,c83adc74,0,c0925520,c83adc80) at uma_reclaim+0x12 vm_pageout_scan(0,c097a220,0,c0871655,5c3) at vm_pageout_scan+0x103 vm_pageout(0,c83add38,0,c0790240,0) at vm_pageout+0x2c3 fork_exit(c0790240,0,c83add38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc83add6c, ebp = 0 --- CVS idents : /usr/src/sys/vm/uma_core.c: $FreeBSD: src/sys/vm/uma_core.c,v 1.122 2005/07/14 16:35:13 rwatson Exp $ /usr/src/sys/vm/vm_map.c: $FreeBSD: src/sys/vm/vm_map.c,v 1.366 2005/05/02 07:05:20 alc Exp $ Cheers TfH From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 09:25:34 2005 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 97AF816A41F for ; Fri, 15 Jul 2005 09:25:34 +0000 (GMT) (envelope-from john@basicnets.co.uk) Received: from mail.basicnets.co.uk (huber1-3.dsl.easynet.co.uk [217.204.222.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDC8743D48 for ; Fri, 15 Jul 2005 09:25:28 +0000 (GMT) (envelope-from john@basicnets.co.uk) Received: from [195.224.14.210] (helo=UKBIM1117) by mail.basicnets.co.uk with esmtp (Exim 4.51 (FreeBSD)) id 1DtMQu-000Ays-Ta for freebsd-current@freebsd.org; Fri, 15 Jul 2005 10:24:40 +0100 From: "John Sullivan" To: Date: Fri, 15 Jul 2005 10:25:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWI4WaVzz20e9aNQkizmFB/fvTe0AANaBNg X-Scanned-by: ClamAV X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "server19.basicnets.co.uk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Ver=FreeBSD 5.4 In my nightly security report I get a number of "Bad file descriptors" error messages in my ports directory: Checking setuid files and devices: find: /usr/ports/mail/masqmail-devel/pkg-descr: Bad file descriptor find: /usr/ports/mail/masqmail-devel/pkg-plist: Bad file descriptor find: /usr/ports/mail/masqmail-devel/files: Bad file descriptor ... [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- Message-Id: <20050715092528.CDC8743D48@mx1.FreeBSD.org> Subject: howto for fsck on a snapshot - Bad file descriptor 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, 15 Jul 2005 09:25:34 -0000 Ver=FreeBSD 5.4 In my nightly security report I get a number of "Bad file descriptors" error messages in my ports directory: Checking setuid files and devices: find: /usr/ports/mail/masqmail-devel/pkg-descr: Bad file descriptor find: /usr/ports/mail/masqmail-devel/pkg-plist: Bad file descriptor find: /usr/ports/mail/masqmail-devel/files: Bad file descriptor ... I note that in section 16.13 of the FreeBSD handbook that a snapshot can be taken, repaired and replaced while the server is running. I am having trouble working out how to do this :-(. Searches on Google and the FreeBSD web site have left me with no further insight. I can mount the snapshot and run fsck against it - it corrects all of the errors but I am still left with the problems on the real partition. Does any one have a 'howto' for recovering from this situation? John Sullivan From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 10:59:24 2005 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 E563D16A422; Fri, 15 Jul 2005 10:59:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE7443D53; Fri, 15 Jul 2005 10:59:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6FAxNXj066844; Fri, 15 Jul 2005 03:59:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6FAxNRF066843; Fri, 15 Jul 2005 03:59:23 -0700 (PDT) (envelope-from rizzo) Date: Fri, 15 Jul 2005 03:59:23 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20050715035923.B66753@xorpc.icir.org> References: <20050714181356.A58300@xorpc.icir.org> <8462.1121409797@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <8462.1121409797@phk.freebsd.dk>; from phk@haven.freebsd.dk on Fri, Jul 15, 2005 at 08:43:17AM +0200 Cc: Robert Watson , s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 10:59:25 -0000 On Fri, Jul 15, 2005 at 08:43:17AM +0200, Poul-Henning Kamp wrote: > In message <20050714181356.A58300@xorpc.icir.org>, Luigi Rizzo writes: > > >Anyways there might be a way out... > >requests go from dev_strategy() > > The right place for this is geom_disk.c:g_disk_start() and the start > routines of the drivers which do not use geom_disk. g_disk_start() sonunds good, but i am not sure if other drivers export the start routine. It seems to be called more or less directly at the end of the strategy() routine of the individual driver, and it does not always likes to find the queue empty. But i am still learning on the layering of these things... cheers luigi > The easiest way to handle it would be to set a flag on the g_provider > saying "no more", have g_down spill the requests into a side queue > and when the driver is ready again, it calls some function which > pulls the request out of the side queue again. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 11:21:48 2005 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 51EC016A41C for ; Fri, 15 Jul 2005 11:21:48 +0000 (GMT) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [202.182.72.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6ED43D46 for ; Fri, 15 Jul 2005 11:21:43 +0000 (GMT) (envelope-from sean@gothic.net.au) Received: from localhost (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with SMTP id 8C8E5264BE for ; Fri, 15 Jul 2005 21:21:39 +1000 (EST) Received: from [10.99.34.33] (home.winn.id.au [202.182.72.30]) by visi.gothic.net.au (Postfix) with ESMTP id 15081264AB for ; Fri, 15 Jul 2005 21:21:39 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Sean Winn Date: Fri, 15 Jul 2005 21:21:38 +1000 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on visi.gothic.net.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.4 Subject: While on regressions of OpenBSD's dhclient... 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, 15 Jul 2005 11:21:48 -0000 Handling of hostnames sent by the DHCP server has gone back to the buggy handling of dhclient 2.x Hostnames like .... Hostname sent via ISC dhcpd 3.x: dhcp194.private.gothic.net.au Used on FreeBSD 4.x, 5.x system: dhcp194.private.gothic.net.au Used on FreeBSD CURRENT (probably RELENG_6): 64:68:63:70:31:39:34:2e:70:72:69:76:61:74:65:2e:67:6f:74:68:69:63:2e: 6e:65:74:2e:61:75:0 See bin/83468 Basically, pretty_print_option() gets upset over the trailing NUL. Whether the server should be sending the NUL, or the client ignoring it, I don't know, but later versions of ISC dhclient do have a fix and that's attached to the PR There's still the underlying problem that if the lease changes hostname while dhclient is running, dhclient won't change the hostname, but that's a common fault in both dhclient versions. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 12:05:01 2005 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 1E2E916A41C for ; Fri, 15 Jul 2005 12:05:01 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E472D43D48 for ; Fri, 15 Jul 2005 12:05:00 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DtOw7-000316-Sn; Fri, 15 Jul 2005 12:05:00 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DtOw7-0009Q0-7E; Fri, 15 Jul 2005 02:04:59 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.42602.38548.316014@roam.psg.com> Date: Fri, 15 Jul 2005 02:04:58 -1000 To: Sam Leffler References: <20050714182136.071B35D07@ptavv.es.net> <42D70C0B.9090802@errno.com> Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 12:05:01 -0000 >> More serious is that I can't roam. When I move between APs, dhclient >> exits and I need to manually re-start it. I lose my SSH sessions. Ugh! > > This should not be happening; dhclient should get a disassociate event, > drop the lease, then get an associate when you join the new ap and > immediately grab a new lease. aiii! this was merely a layer-2 re-association, no change at layer-3. randy From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 12:08:53 2005 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 43E0716A41C; Fri, 15 Jul 2005 12:08:53 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D3A43D49; Fri, 15 Jul 2005 12:08:52 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id EF6D0BC83; Fri, 15 Jul 2005 12:08:45 +0000 (UTC) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Jul 2005 03:59:23 PDT." <20050715035923.B66753@xorpc.icir.org> Date: Fri, 15 Jul 2005 14:08:45 +0200 Message-ID: <9872.1121429325@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Poul-Henning Kamp , Robert Watson , s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock 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, 15 Jul 2005 12:08:53 -0000 In message <20050715035923.B66753@xorpc.icir.org>, Luigi Rizzo writes: >On Fri, Jul 15, 2005 at 08:43:17AM +0200, Poul-Henning Kamp wrote: >> In message <20050714181356.A58300@xorpc.icir.org>, Luigi Rizzo writes: >> >> >Anyways there might be a way out... >> >requests go from dev_strategy() >> >> The right place for this is geom_disk.c:g_disk_start() and the start >> routines of the drivers which do not use geom_disk. > >g_disk_start() sonunds good, but i am not sure if other >drivers export the start routine. It seems to be called >more or less directly at the end of the strategy() routine of the >individual driver, and it does not always likes to find >the queue empty. > >But i am still learning on the layering of these things... You may want to read up on GEOM (http://phk.freebsd.dk/pubs) Check the cdrom drivers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:01:26 2005 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 4913F16A41C for ; Thu, 14 Jul 2005 20:01:26 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA23643D46 for ; Thu, 14 Jul 2005 20:01:25 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 36E881704D; Thu, 14 Jul 2005 22:01:24 +0200 (CEST) Date: Thu, 14 Jul 2005 22:01:24 +0200 From: Ed Schouten To: nj18 Message-ID: <20050714200124.GF36726@hoeg.nl> References: <42D6BED3.3030602@nerdshack.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ILuaRSyQpoVaJ1HG" Content-Disposition: inline In-Reply-To: <42D6BED3.3030602@nerdshack.com> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Fri, 15 Jul 2005 12:43:35 +0000 Cc: FreeBSD Current Subject: Re: Strange message: Text file busy. 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, 14 Jul 2005 20:01:26 -0000 --ILuaRSyQpoVaJ1HG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * nj18 wrote: > > echo date >somescript > > chmod +x somescript > > ./somescript > ./somescript: Text file busy. What if you put the following contents in somescript: #!/bin/sh date I guess FreeBSD 4.6 takes /bin/sh as the interpreter by default, but FreeBSD 5 and higher don't. Yours, --=20 Ed Schouten --ILuaRSyQpoVaJ1HG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC1sSUmVI4SHXwmhERAi+GAKDOp2D32RuyKbflrt0bFWogZ/ih6gCgmBuG vU6PRs6hXXEfmdwtIdc7yIg= =PR9l -----END PGP SIGNATURE----- --ILuaRSyQpoVaJ1HG-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 13:41:59 2005 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 7AE9516A41C; Thu, 14 Jul 2005 13:41:59 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC3943D49; Thu, 14 Jul 2005 13:41:58 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id 7B925C800B; Thu, 14 Jul 2005 15:41:03 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id 7897990184; Thu, 14 Jul 2005 15:41:03 +0200 (CEST) Date: Thu, 14 Jul 2005 15:41:03 +0200 (CEST) From: Goran Gajic To: Gleb Smirnoff In-Reply-To: <20050714112452.GD17494@cell.sick.ru> Message-ID: References: <20050714112452.GD17494@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 15 Jul 2005 12:44:49 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 14 Jul 2005 13:41:59 -0000 Hi, I haven't saved it :( I have cvsup-ed system to 6.0-BETA. Now I have strange problem. I have to do ifconfig fxp0 down; ifconfig fxp0 up; same for em0 in order to restore network connectivity othervise I can't ping anything except ip addresses of interfaces. Here is also one strane message I have noticed after doing so: Memory modified after free 0xcb3f1800(2048) val=a022c0de @ 0xcb3f1800 Version is: 6.0-BETA FreeBSD 6.0-BETA #8: Wed Jul 13 00:56:35 CEST 2005 and I'm using GENERIC config with options IPFILTER at the end. If I can provide more information I would be glad to. Regards, gg. On Thu, 14 Jul 2005, Gleb Smirnoff wrote: > > Have you saved core from this panic? What network facilities do you use: > pf, ipf, ipfw, dummynet, altq, netgraph? > > From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 13:45:38 2005 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 1F6B916A41C; Thu, 14 Jul 2005 13:45:38 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id B024743D4C; Thu, 14 Jul 2005 13:45:37 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id 0FF1BC8008; Thu, 14 Jul 2005 15:45:31 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id 0CCBC90185; Thu, 14 Jul 2005 15:45:30 +0200 (CEST) Date: Thu, 14 Jul 2005 15:45:30 +0200 (CEST) From: Goran Gajic To: Gleb Smirnoff In-Reply-To: <20050714112452.GD17494@cell.sick.ru> Message-ID: References: <20050714112452.GD17494@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 15 Jul 2005 12:44:49 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 14 Jul 2005 13:45:38 -0000 One more thing. Since that same machine is running squid after some time squid ends up in D state and I can't kill it - all I can do is reboot machine. Also port 8080 is in unreachable state. Regards, gg. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 13:03:46 2005 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 6B7A216A41C for ; Fri, 15 Jul 2005 13:03:46 +0000 (GMT) (envelope-from lreid@cs.okstate.edu) Received: from csa.cs.okstate.edu (a.cs.okstate.edu [139.78.113.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3137E43D48 for ; Fri, 15 Jul 2005 13:03:46 +0000 (GMT) (envelope-from lreid@cs.okstate.edu) Received: by csa.cs.okstate.edu (Postfix, from userid 601) id 80C0EA068C; Fri, 15 Jul 2005 08:03:45 -0500 (CDT) To: freebsd-current@freebsd.org Received: from 164.58.79.196 (auth. user lreid@a.cs.okstate.edu) by cs.okstate.edu with HTTP; Fri, 15 Jul 2005 07:03:45 -0600 X-IlohaMail-Blah: lreid@a.cs.okstate.edu X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.12 (On: cs.okstate.edu) From: "Reid Linnemann" Bounce-To: "Reid Linnemann" Errors-To: "Reid Linnemann" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20050715130345.80C0EA068C@csa.cs.okstate.edu> Date: Fri, 15 Jul 2005 08:03:45 -0500 (CDT) Subject: dhclient-exit-hooks weirdness 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, 15 Jul 2005 13:03:46 -0000 I'm using dhclient-script 1.4, and the following dhclient-exit-hooks that worked prior to the OpenBSD dhclient import: #!/bin/sh PATH=/bin:/sbin:/usr/bin if [ x$new_host_name != x ]; then if [ x$new_domain_name != x ]; then hostname $new_host_name.$new_domain_name echo New Hostname: $new_host_name.$new_domain_name else hostname $new_host_name echo New Hostname: $new_host_name fi else hostname=`/usr/local/bin/resolveip -s $new_ip_address` hostname $hostname echo New Hostname: $hostname fi When dhclient starts on the interface (rl0) during system boot, dhclient-exit-hooks is invoked before dhclient reports it has even recieved a DHCPACK, and the console is cluttered with resolveip's usage message. $new_ip_address is empty when dhclient-exit-hooks is invoked, and the hostname of the system remains bogus. Is anyone else having similar trouble? Is my dhclient-exit-hooks actually sane? Thanks, Reid From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 13:04:24 2005 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 64ED516A41C for ; Fri, 15 Jul 2005 13:04:24 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0200D43D46 for ; Fri, 15 Jul 2005 13:04:23 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 29721 invoked by uid 1003); 15 Jul 2005 13:04:12 -0000 Received: from ryans@gamersimpact.com by mailserv1.neuroflux.com by uid 89 with qmail-scanner-1.22 (clamscan: 0.65. spamassassin: 2.60. Clear:RC:1(63.224.20.10):. Processed in 1.310031 secs); 15 Jul 2005 13:04:12 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.224.20.10) by mailserv1.neuroflux.com with SMTP; 15 Jul 2005 13:04:10 -0000 Message-ID: <42D7B45D.9080807@gamersimpact.com> Date: Fri, 15 Jul 2005 08:04:29 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <20050714182136.071B35D07@ptavv.es.net> <42D70C0B.9090802@errno.com> In-Reply-To: <42D70C0B.9090802@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 13:04:24 -0000 Sam Leffler wrote: > > Something is busted; I'll need to investigate. If you want to help you > can run ieee80211watch (from tools/tools/ath) while things happen and > note the events that get sent by the kernel. > > Sam I've been having very similar problems with wireless and DHCP. My case is somewhat different though. Instead of DHCP not only not setting the default route, it doesn't even seem to be setting up a routing socket. For the past few weeks my sequence while on the road using APs where I don't know them before hand has been: 1) dstumbler to find AP name 2) add entry to /etc/dhclient.conf 3) Run dhclient to see IP address assignment 4) Manually take the interface down and bring it back up setting media as in dhclient.conf entry 5) Assign IP address and create the default route. Lately dhclient hasn't even been setting the IP address all the time. And for a slightly longer time if I simply tried to create/change the default route to the new gateway I would get a no routing socket error. Manually taking the interface down and up solved this. Note though, this only applies to wireless, wired dhclient plays very nicely. Let me know if there is anything I can do to help diagnose. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 13:35:44 2005 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 81FC016A41F for ; Fri, 15 Jul 2005 13:35:44 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A8243D46 for ; Fri, 15 Jul 2005 13:35:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j6FDZerG033191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jul 2005 17:35:41 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j6FDZe4a033190; Fri, 15 Jul 2005 17:35:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 15 Jul 2005 17:35:40 +0400 From: Gleb Smirnoff To: Goran Gajic Message-ID: <20050715133540.GB33064@cell.sick.ru> References: <20050714112452.GD17494@cell.sick.ru> <20050714134405.GE19262@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 15 Jul 2005 13:35:44 -0000 On Fri, Jul 15, 2005 at 03:30:11PM +0200, Goran Gajic wrote: G> >On Thu, Jul 14, 2005 at 03:41:03PM +0200, Goran Gajic wrote: G> >G> I haven't saved it :( I have cvsup-ed system to 6.0-BETA. Now I have G> >G> strange problem. I have to do ifconfig fxp0 down; ifconfig fxp0 up; same G> >G> for em0 in order to restore network connectivity othervise I can't ping G> >G> anything except ip addresses of interfaces. Here is also one strane G> >G> message I have noticed after doing so: G> >G> Memory modified after free 0xcb3f1800(2048) val=a022c0de @ 0xcb3f1800 G> >G> Version is: G> >G> 6.0-BETA FreeBSD 6.0-BETA #8: Wed Jul 13 00:56:35 CEST 2005 G> >G> and I'm using GENERIC config with options IPFILTER at the end. G> >G> G> >G> If I can provide more information I would be glad to. G> > G> >To narrow down the scope of problem search, can you boot GENERIC kernel G> >without ipfilter and try to reproduce the above bugs? G> G> I did so and for last 24h everything seems to be ok.. What shall I do G> next? Describe the problem properly and file a PR. The PR will be assigned to ipfilter maintainer. You should also try to turn ipfilter on, and disable multithreaded network stack (debug.mpsafenet=0 in loader.conf). See what happens, and add this info to PR, too. If you need to get your box running ASAP, you should try pf or ipfw. But don't forget to file a PR. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 14:30:51 2005 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 71DBA16A41C for ; Fri, 15 Jul 2005 14:30:51 +0000 (GMT) (envelope-from jura@networks.ru) Received: from networks.ru (orange.networks.ru [80.249.138.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDC2443D46 for ; Fri, 15 Jul 2005 14:30:50 +0000 (GMT) (envelope-from jura@networks.ru) X-Spam-Status: No, hits=0.0 required=2.0 Received: from [81.195.67.217] (account jura HELO Jura) by networks.ru (CommuniGate Pro SMTP 4.2.8) with ESMTP-TLS id 1687642 for freebsd-current@freebsd.org; Fri, 15 Jul 2005 18:30:44 +0400 Message-ID: <060101c58949$d1d6f270$6504010a@Jura> From: "Yuriy N. Shkandybin" To: Date: Fri, 15 Jul 2005 18:30:55 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: cores 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, 15 Jul 2005 14:30:51 -0000 Hello regullary i've got this traces 6.0-BETA #1: Thu Jul 14 13:56:29 MSD 2005 SMP PREEMTION IPI_PREEMTION #1 0xc04b8a3d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc04b91bd in panic (fmt=0xc06482a5 "sk_jfree: asked to free buffer that we don't manage!") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc057e535 in sk_jfree (buf=0x1997f000, args=0xc319d000) at /usr/src/sys/pci/if_sk.c:1179 #4 0xc05008f1 in mb_free_ext (m=0xc6747600) at /usr/src/sys/kern/uipc_mbuf.c:258 #5 0xc05009b0 in m_freem (mb=0x0) at mbuf.h:417 #6 0xc0549653 in ether_demux (ifp=0xc3199800, m=0xc6747600) at /usr/src/sys/net/if_ethersubr.c:868 #7 0xc0549a69 in ether_input (ifp=0xc3199800, m=0xc6747600) at /usr/src/sys/net/if_ethersubr.c:640 #8 0xc0580956 in sk_rxeof (sc_if=0xc319d000) at /usr/src/sys/pci/if_sk.c:2176 #9 0xc058344c in sk_intr (xsc=0xc318cd00) at /usr/src/sys/pci/if_sk.c:2407 #10 0xc04a0e97 in ithread_loop (arg=0xc309a700) at /usr/src/sys/kern/kern_intr.c:545 #11 0xc049fb8d in fork_exit (callout=0xc04a0df0 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 #12 0xc06038ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:206 #0 doadump () at pcpu.h:165 #1 0xc04b8a3d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc04b91bd in panic (fmt=0xc06432e7 "sbdrop") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc0508090 in sbdrop_locked (sb=0xc7868390, len=118) at /usr/src/sys/kern/uipc_socket2.c:1144 #4 0xc056fd88 in tcp_input (m=0xc66e9600, off0=-1003319296) at /usr/src/sys/netinet/tcp_input.c:2119 #5 0xc0566815 in ip_input (m=0xc66e9600) at /usr/src/sys/netinet/ip_input.c:776 #6 0xc05496a1 in ether_demux (ifp=0xc3199800, m=0xc66e9600) at /usr/src/sys/net/if_ethersubr.c:850 #7 0xc0549a69 in ether_input (ifp=0xc3199800, m=0xc66e9600) at /usr/src/sys/net/if_ethersubr.c:640 #8 0xc0580956 in sk_rxeof (sc_if=0xc319d000) at /usr/src/sys/pci/if_sk.c:2176 #9 0xc058344c in sk_intr (xsc=0xc318cd00) at /usr/src/sys/pci/if_sk.c:2407 #10 0xc04a0e97 in ithread_loop (arg=0xc309a700) at /usr/src/sys/kern/kern_intr.c:545 #11 0xc049fb8d in fork_exit (callout=0xc04a0df0 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 #12 0xc06038ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:206 Jura From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 14:41:44 2005 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 5BB0C16A41C for ; Fri, 15 Jul 2005 14:41:44 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2895443D5D for ; Fri, 15 Jul 2005 14:41:39 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 60528 invoked by uid 89); 15 Jul 2005 14:41:12 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Jul 2005 14:41:12 -0000 Date: Fri, 15 Jul 2005 16:41:29 +0200 From: Oliver Lehmann To: Mohan Srinivasan Message-Id: <20050715164129.1ebeca99.lehmann@ans-netz.de> In-Reply-To: <20050712035026.26407.qmail@web31802.mail.mud.yahoo.com> References: <20050709082801.18f15374.lehmann@ans-netz.de> <20050712035026.26407.qmail@web31802.mail.mud.yahoo.com> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: problems with soft-nfs when the server goes down 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, 15 Jul 2005 14:41:44 -0000 Mohan Srinivasan wrote: > If you can't get a core, can you save the tcpump output to > a file and send me the file ? > > Make sure you specify -s1500 (so the entire NFS header > gets captured). on 16:38:11.566505 it went down, on 16:40:04.494827 it's back up. Nothing more happend after 16:40:04.495513. 16:38:10.528477 IP curry.salatschuessel.net.1085326193 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 360448 16:38:10.530990 IP 10.0.1.251.nfs > curry.salatschuessel.net.1085326193: reply ok 1472 read 16:38:10.531097 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:10.531228 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:10.531343 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:10.532155 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:10.532235 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.039723 IP curry.salatschuessel.net.1085326194 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 368640 16:38:11.040931 IP 10.0.1.251.nfs > curry.salatschuessel.net.1085326194: reply ok 1472 read 16:38:11.040986 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.041249 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.041378 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.041491 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.041565 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:38:11.566505 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:11.567961 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:11.636122 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:11.637507 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:11.766121 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:11.766516 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:12.016079 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:12.017495 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:12.059395 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:38:12.060778 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:12.506036 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:12.507419 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:13.026041 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:38:13.026726 IP 10.0.1.251 > curry.salatschuessel.net: ICMP 10.0.1.251 udp port nfsd unreachable, length 36 16:38:14.435900 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:16.875694 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:38:22.125283 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:32.249470 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:38:37.499118 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:38:47.618249 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:38:52.867834 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:39:02.988023 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:39:08.237603 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:39:18.356811 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:39:23.606383 IP curry.salatschuessel.net.1085326195 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 376832 16:39:33.725575 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:39:49.094354 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:40:04.463135 IP curry.salatschuessel.net.1085326196 > 10.0.1.251.nfs: 112 read fh 1066,316731/68102 8192 bytes @ 385024 16:40:04.494827 IP 10.0.1.251.nfs > curry.salatschuessel.net.1085326196: reply ok 1472 read 16:40:04.494942 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:40:04.495189 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:40:04.495311 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:40:04.495434 IP 10.0.1.251 > curry.salatschuessel.net: udp 16:40:04.495513 IP 10.0.1.251 > curry.salatschuessel.net: udp -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 15:18:21 2005 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 4E22516A41C for ; Fri, 15 Jul 2005 15:18:21 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D439843D49 for ; Fri, 15 Jul 2005 15:18:20 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6FFIEms099998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jul 2005 08:18:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42D7D4E6.3020105@errno.com> Date: Fri, 15 Jul 2005 08:23:18 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush References: <20050714182136.071B35D07@ptavv.es.net> <42D70C0B.9090802@errno.com> <17111.42602.38548.316014@roam.psg.com> In-Reply-To: <17111.42602.38548.316014@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 15:18:21 -0000 Randy Bush wrote: >>>More serious is that I can't roam. When I move between APs, dhclient >>>exits and I need to manually re-start it. I lose my SSH sessions. Ugh! >> >>This should not be happening; dhclient should get a disassociate event, >>drop the lease, then get an associate when you join the new ap and >>immediately grab a new lease. > > > aiii! this was merely a layer-2 re-association, no change at layer-3. I mis-spoke; dhclient trys to re-acquire the current lease. This is exactly what happened before except it should now happen _immediately_ on being notified of a re-association to the same ap or an association to a new ap. Actually I could check for a re-association and not re-aquire the lease to reduce the overhead but regardless this should be ok (so far as I understand the protocols). The previous code polled for these events. This made it prone to missing fast re-associations (instead falling back to various timeouts) and slow to respond when roaming. The new code had been working correctly; something has clearly changed and I'll fix it asap. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 15:27:13 2005 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 0792B16A41C for ; Fri, 15 Jul 2005 15:27:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9344443D48 for ; Fri, 15 Jul 2005 15:27:12 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6FFR9ms000171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jul 2005 08:27:11 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42D7D6FE.6070504@errno.com> Date: Fri, 15 Jul 2005 08:32:14 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <20050714182136.071B35D07@ptavv.es.net> <42D70C0B.9090802@errno.com> <42D7B45D.9080807@gamersimpact.com> In-Reply-To: <42D7B45D.9080807@gamersimpact.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 15:27:13 -0000 Ryan Sommers wrote: > Sam Leffler wrote: > >> >> Something is busted; I'll need to investigate. If you want to help >> you can run ieee80211watch (from tools/tools/ath) while things happen >> and note the events that get sent by the kernel. >> >> Sam > > > I've been having very similar problems with wireless and DHCP. My case > is somewhat different though. Instead of DHCP not only not setting the > default route, it doesn't even seem to be setting up a routing socket. > > For the past few weeks my sequence while on the road using APs where I > don't know them before hand has been: > > 1) dstumbler to find AP name > 2) add entry to /etc/dhclient.conf > 3) Run dhclient to see IP address assignment > 4) Manually take the interface down and bring it back up setting media > as in dhclient.conf entry > 5) Assign IP address and create the default route. > > Lately dhclient hasn't even been setting the IP address all the time. > And for a slightly longer time if I simply tried to create/change the > default route to the new gateway I would get a no routing socket error. > Manually taking the interface down and up solved this. As mentioned in previous mail about this; using dhclient's media configuration mechanism for wireless configuration is not going to work (reliably) and in general is a mistake. You should use wpa_supplicant to scan for ap's and configure security policies. (Despite it's name wpa_supplicant is for more than networks where wpa is configured.) dhclient should then be launched by devd when you associate. As to locating ap's I find bringing the interface up and letting it scan (in station mode) is usually sufficient; just use ifconfig foo list scan to see the results. If wpa_supplicant is running in the background then you can use wpa_cli to monitor scan results. What we need is a proper tool to do the above through a ui/gui; I had hoped one of the SoC projects might address this. If you can send me (privately) the exact set of steps you use by which you get a "no routing socket error" then I'll try to look at it. > > Note though, this only applies to wireless, wired dhclient plays very > nicely. > > Let me know if there is anything I can do to help diagnose. > Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 17:29:16 2005 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 5956A16A41C for ; Fri, 15 Jul 2005 17:29:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A93643D49 for ; Fri, 15 Jul 2005 17:29:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j6FHTErN006118; Fri, 15 Jul 2005 10:29:14 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6FHTEQQ006117; Fri, 15 Jul 2005 10:29:14 -0700 Date: Fri, 15 Jul 2005 10:29:14 -0700 From: Brooks Davis To: Reid Linnemann Message-ID: <20050715172914.GA337@odin.ac.hmc.edu> References: <20050715130345.80C0EA068C@csa.cs.okstate.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <20050715130345.80C0EA068C@csa.cs.okstate.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: dhclient-exit-hooks weirdness 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, 15 Jul 2005 17:29:16 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2005 at 08:03:45AM -0500, Reid Linnemann wrote: >=20 > I'm using dhclient-script 1.4, and the following dhclient-exit-hooks > that worked prior to the OpenBSD dhclient import: >=20 > #!/bin/sh > PATH=3D/bin:/sbin:/usr/bin > if [ x$new_host_name !=3D x ]; then > if [ x$new_domain_name !=3D x ]; then > hostname $new_host_name.$new_domain_name > echo New Hostname: $new_host_name.$new_domain_name > else > hostname $new_host_name > echo New Hostname: $new_host_name > fi > else > hostname=3D`/usr/local/bin/resolveip -s $new_ip_address` > hostname $hostname > echo New Hostname: $hostname > fi >=20 > When dhclient starts on the interface (rl0) during system boot, > dhclient-exit-hooks is invoked before dhclient reports it has even > recieved a DHCPACK, and the console is cluttered with resolveip's usage > message. $new_ip_address is empty when dhclient-exit-hooks is invoked, > and the hostname of the system remains bogus. Is anyone else having > similar trouble? Is my dhclient-exit-hooks actually sane? I suspect the issue is that you need to check the $reason variable and only run this code in cases where it actually makes sense. See /sbin/dhclient-script for the list. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC1/JpXY6L6fI4GtQRAhdmAJ0UPZD71M+UgT12tWgDAx050IcipACfYbIl RA/e806lls/1/iqkFMP8cnA= =8TSQ -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 17:31:52 2005 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 E107316A41C for ; Fri, 15 Jul 2005 17:31:52 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F63143D4C for ; Fri, 15 Jul 2005 17:31:51 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Jul 2005 17:31:50 -0000 Received: from h081217094124.dyn.cm.kabsi.at (EHLO localhost.localdomain) [81.217.94.124] by mail.gmx.net (mp034) with SMTP; 15 Jul 2005 19:31:50 +0200 X-Authenticated: #16703784 From: Stefan Ehmann To: current@freebsd.org In-Reply-To: <1120901793.10284.14.camel@taxman.pepperland> References: <1120901793.10284.14.camel@taxman.pepperland> Content-Type: text/plain Date: Fri, 15 Jul 2005 19:31:52 +0200 Message-Id: <1121448712.9176.0.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Subject: Re: Kernel panic with latest wpa_supplicant 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, 15 Jul 2005 17:31:53 -0000 On Sat, 2005-07-09 at 11:36 +0200, Stefan Ehmann wrote: > usr.sbin/wpa/wpa_supplicant/driver_freebsd.c rev. 1.4 and 1.5 result in > a kernel panic for me when calling wpa_supplicant. Reverting to 1.3 > makes everything happy again. > For the archives: The panic no longer occurs with the latest CURRENT. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 17:38:15 2005 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 CDF9916A41C for ; Fri, 15 Jul 2005 17:38:15 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C68B43D46 for ; Fri, 15 Jul 2005 17:38:15 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-1.free.fr (Postfix) with ESMTP id EABBE3186F2 for ; Fri, 15 Jul 2005 19:38:13 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6FHc7sf030152 for ; Fri, 15 Jul 2005 19:38:12 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 15 Jul 2005 19:37:58 +0200 User-Agent: KMail/1.8.1 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507151938.00294.thierry@herbelot.com> Subject: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 17:38:15 -0000 Hello, With my latest kernel, I do not see the ed(4) ethernet interface of my notebook. This may be related to recent pccard/pccbb commits. The verbose kernel log messages : working : http://herbelot.tfh.free.fr/no_ed/dmesg.ed.verbose not working : http://herbelot.tfh.free.fr/no_ed/dmesg.noed.verbose diff : http://herbelot.tfh.free.fr/no_ed/dmesg.diff.verbose extract : 458a471,483 > pccard1: CIS version PCCARD 2.0 or 2.1 > pccard1: CIS info: CNet, CN40BC Ethernet, D, NE2000 > pccard1: Manufacturer code 0xffffffff, product 0xffffffff > pccard1: function 0: network adapter, ccr addr 3f8 mask 3 > pccard1: function 0, config table entry 32: I/O card; irq mask ffff; iomask 5, iospace 0-1f; mwait_required io8 io16 irqlevel > ed1: at port 0x100-0x11f irq 9 function 0 config 32 on pccard1 > ed1: [GIANT-LOCKED] > ed1: CIS MAC 00:00:00:00:00:00 > ed1: ROM mac 00:80:ad:8e:82:60 > ed1: bpf attached > ed1: Ethernet address: 00:80:ad:8e:82:60 > ed1: if_start running deferred for Giant > ed1: type NE2000 (16 bit) idents of the kernel source files : working : http://herbelot.tfh.free.fr/no_ed/kernel.ed.ident not working : http://herbelot.tfh.free.fr/no_ed/kernel.noed.ident diff : http://herbelot.tfh.free.fr/no_ed/kernel.diff.ident Cheers TfH From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 18:07:50 2005 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 2AF8716A41C for ; Fri, 15 Jul 2005 18:07:50 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E76B843D45 for ; Fri, 15 Jul 2005 18:07:49 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DtUbE-000Bvl-OK; Fri, 15 Jul 2005 18:07:48 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DtUbE-0009lq-4c; Fri, 15 Jul 2005 08:07:48 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.64370.963254.142746@roam.psg.com> Date: Fri, 15 Jul 2005 08:07:46 -1000 To: Sam Leffler References: <20050714182136.071B35D07@ptavv.es.net> <42D70C0B.9090802@errno.com> <17111.42602.38548.316014@roam.psg.com> <42D7D4E6.3020105@errno.com> Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 18:07:50 -0000 >> aiii! this was merely a layer-2 re-association, no change at layer-3. > I mis-spoke; dhclient trys to re-acquire the current lease. This is > exactly what happened before except it should now happen _immediately_ > on being notified of a re-association to the same ap or an association > to a new ap. Actually I could check for a re-association and not > re-aquire the lease to reduce the overhead but regardless this should be > ok (so far as I understand the protocols). that is also my understanding. grazie randy From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 19:06:20 2005 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 43AFC16A420 for ; Fri, 15 Jul 2005 19:06:20 +0000 (GMT) (envelope-from gilham@csl.sri.com) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by mx1.FreeBSD.org (Postfix) with SMTP id A225943D4C for ; Fri, 15 Jul 2005 19:06:19 +0000 (GMT) (envelope-from gilham@csl.sri.com) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 15 Jul 2005 19:06:19 -0000 Received: from mx1.csl.sri.com ([130.107.1.29]) by mailgate-internal1.SRI.COM (SMSSMTP 4.0.5.66) with SMTP id M2005071512061815403 for ; Fri, 15 Jul 2005 12:06:18 -0700 Received: from snapdragon (snapdragon.csl.sri.com [130.107.19.20]) by mx1.csl.sri.com (8.12.11/8.12.11) with ESMTP id j6FJ6JqP034933 for ; Fri, 15 Jul 2005 12:06:19 -0700 (PDT) (envelope-from gilham@snapdragon.csl.sri.com) Message-Id: <200507151906.j6FJ6JqP034933@mx1.csl.sri.com> To: freebsd-current@freebsd.org X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 15 Jul 2005 12:06:19 -0700 From: Fred Gilham Subject: Question about su and network 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, 15 Jul 2005 19:06:20 -0000 Hello, When my ISDN line was down yesterday, I noticed that su from an xterm would hang on my FreeBSD box. Logging in as root from a virtual console would work OK. After the network came back everything went back to normal. Is there a way I can avoid this behavior? I mean the hanging, not the return to normal operation. :-) -- Fred Gilham gilham@csl.sri.com I can see you're going to do just *fine* here in comp.lang.lisp. I'm rather looking forward to the ritual disembowelling, in particular, although the bit were we chop your arms and legs off and feed them to crocodiles is also good. --- Tim Bradshaw From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 20:36:13 2005 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 9118216A41C for ; Fri, 15 Jul 2005 20:36:13 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61D8443D45 for ; Fri, 15 Jul 2005 20:36:13 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 15 Jul 2005 13:36:12 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C7FB75D07; Fri, 15 Jul 2005 13:36:11 -0700 (PDT) To: Fred Gilham In-reply-to: Your message of "Fri, 15 Jul 2005 12:06:19 PDT." <200507151906.j6FJ6JqP034933@mx1.csl.sri.com> Date: Fri, 15 Jul 2005 13:36:11 -0700 From: "Kevin Oberman" Message-Id: <20050715203611.C7FB75D07@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Question about su and network 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, 15 Jul 2005 20:36:13 -0000 > Date: Fri, 15 Jul 2005 12:06:19 -0700 > From: Fred Gilham > Sender: owner-freebsd-current@freebsd.org > > > Hello, > > When my ISDN line was down yesterday, I noticed that su from an xterm > would hang on my FreeBSD box. Logging in as root from a virtual console > would work OK. After the network came back everything went back to > normal. > > Is there a way I can avoid this behavior? I mean the hanging, not the > return to normal operation. :-) This really belongs in questions, not current, but you can't get to your DNS server when the network is down. You need to put an entry for your system in /etc/hosts. Something like: 192.168.1.4 myhost myhost.fully.qualified -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 20:50:25 2005 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 0A7E916A41C for ; Fri, 15 Jul 2005 20:50:25 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9061843D45 for ; Fri, 15 Jul 2005 20:50:24 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6FKoMQ6039932; Fri, 15 Jul 2005 22:50:22 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6FKoMfs039931; Fri, 15 Jul 2005 16:50:22 -0400 (EDT) (envelope-from cracauer) Date: Fri, 15 Jul 2005 16:50:22 -0400 From: Martin Cracauer To: Scott Long Message-ID: <20050715165022.A39796@cons.org> References: <20050623184322.A67708@cons.org> <42BB58AD.1050501@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <42BB58AD.1050501@samsco.org>; from scottl@samsco.org on Thu, Jun 23, 2005 at 06:49:49PM -0600 Cc: Martin Cracauer , freebsd-current@freebsd.org Subject: Re: Driver that works only when module is loaded late, not from loader.conf 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, 15 Jul 2005 20:50:25 -0000 Scott Long wrote on Thu, Jun 23, 2005 at 06:49:49PM -0600: > Martin Cracauer wrote: > > I didn't see a reply but I think this might be be symptom of a larger > > issue that we might have to fix for 6.0. > > > > I found an Ethernet driver which works fine if you load it via kldload > > in a running system but it does not work when loaded in loader.conf. > > > > The bug is http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82497 > > > > Here's the cut'n'paste: > > ----------------------- > > > > > > Release > > -current of today > > Environment > > > > FreeBSD wings.cons.org 6.0-CURRENT FreeBSD 6.0-CURRENT #4: Tue Jun 21 > > 16:37:57 EDT 2005 > > cracauer@wings.cons.org:/usr/src/sys/amd64/compile/WINGS64 amd64 > > > > > > > > Description > > > > I recently got an AMD64 socket 754 board with Via K8T800, an Abit > > K8V-Pro, which has a if_vge Gigabit Ethernet. > > > > This works only when you load the module after the full machine is up. > > > > If you put if_vge_load="YES" into loader.conf you get: > > > > Jun 21 19:32:46 wings kernel: vge0: > > port 0xb8\ > > 00-0xb8ff mem 0xe3014000-0xe30140ff irq 22 at device 14.0 on pci0 > > Jun 21 19:32:46 wings kernel: vge0: MII read timed out > > Jun 21 19:32:46 wings kernel: vge0: failed to start MII autopoll > > Jun 21 19:32:46 wings kernel: vge0: MII without any phy! > > Jun 21 19:32:46 wings kernel: device_attach: vge0 attach returned 6 > > > > If you don't load it from loader.conf it works fine. > > > > I have mii compiled into the kernel. > > > > > > How-To-Repeat > > > > Put if_vge_load="YES" into loader.conf > > > > reboot. > > > > You will not get an interface and you'll have the above message in > > /var/log/messages. > > > > > > Fix > > > > You can work around it by loading the module later. > > > > It is not clear to me what is going on here. Since I have mii > > statically compiled into the kernel it is not a case of just > > forgetting to load a dependency. > > > > What happens if you compile it into the kernel? As I mailed earlier, at the time of my report it worked that way. However, as of today 7.0 sources it does not (both vge and mii compiled in). The error message is different, though: Jul 15 14:44:03 wings kernel: vge0: port 0xb80 0-0xb8ff mem 0xd3014000-0xd30140ff irq 22 at device 14.0 on pci0 Jul 15 14:44:03 wings kernel: vge0: MII read timed out Jul 15 14:44:03 wings kernel: vge0: failed to start MII autopoll Jul 15 14:44:03 wings kernel: vge0: MII without any phy! Jul 15 14:44:03 wings kernel: device_attach: vge0 attach returned 6 Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 20:56:23 2005 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 2F44D16A41C for ; Fri, 15 Jul 2005 20:56:23 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C3D143D48 for ; Fri, 15 Jul 2005 20:56:22 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 69073 invoked by uid 89); 15 Jul 2005 20:55:55 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Jul 2005 20:55:55 -0000 Date: Fri, 15 Jul 2005 22:56:12 +0200 From: Oliver Lehmann To: Mohan Srinivasan Message-Id: <20050715225612.0714cbf7.lehmann@ans-netz.de> In-Reply-To: <20050715154932.58609.qmail@web31806.mail.mud.yahoo.com> References: <20050715164129.1ebeca99.lehmann@ans-netz.de> <20050715154932.58609.qmail@web31806.mail.mud.yahoo.com> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: problems with soft-nfs when the server goes down 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, 15 Jul 2005 20:56:23 -0000 Mohan Srinivasan wrote: > From the tcpdump, it looks like the read reply was sent by > the server and received by the client, but for some reason > not delivered to the waiting process. > > To say why that might have happened, it would really be > good to get a kernel crash dump. > > To get a crash dump, you'd need to drop into KDB and type > in "doadump". That will dump the core. The core will be > saved upon reboot. > > Then you need to point me at the coredump and the corresponding > unstripped kernel image. > > mohan Now, compiled with all the debugging stuff in the kernel, I've seen a LOR: pcm0: on sbc0 pcm0: [GIANT-LOCKED] lock order reversal 1st 0xc12a84c0 sbc0 (sound softc) @ /usr/src/sys/dev/sound/isa/sbc.c:131 2nd 0xc13bf940 pcm0:play:0 (pcm play channel) @ /usr/src/sys/dev/sound/pcm/channel.c:525 KDB: stack backtrace: kdb_backtrace(c06d46d5,c13bf940,c137c7d4,c06c76dc,c06c772a) at kdb_backtrace+0x2e witness_checkorder(c13bf940,9,c06c772a,20d,c5bd2c8c) at witness_checkorder+0x6c3 _mtx_lock_flags(c13bf940,0,c06c772a,20d,c13ee580) at _mtx_lock_flags+0x8a chn_intr(c137c780,c04f8d3a,0,c1295a58,c11a5000) at chn_intr+0x2d ess_intr(c13ee580,c12a88c0,c11a0b00,c5bd2d00,c04eb6c2) at ess_intr+0x18d sbc_intr(c1295a58,0,c06ce58d,220,c5bd2d00) at sbc_intr+0x24 ithread_loop(c11a0b00,c5bd2d38,c06ce384,30d,3c89ffff) at ithread_loop+0x162 fork_exit(c04eb560,c11a0b00,c5bd2d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc5bd2d6c, ebp = 0 --- nfs server 10.0.1.251:/usr: not responding root@curry CURRY> kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_read: invalid address (150011) kgdb: kvm_read: invalid address (bfbfe0f8) kgdb: kvm_read: invalid address (129) kgdb: kvm_read: invalid address (129) doesn't looks like it works.... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:08:58 2005 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 95DBB16A41C for ; Fri, 15 Jul 2005 21:08:58 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE89243D46 for ; Fri, 15 Jul 2005 21:08:57 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 69408 invoked by uid 89); 15 Jul 2005 21:08:30 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Jul 2005 21:08:30 -0000 Date: Fri, 15 Jul 2005 23:08:47 +0200 From: Oliver Lehmann To: mohan_srinivasan@yahoo.com, Message-Id: <20050715230847.20ad114b.lehmann@ans-netz.de> In-Reply-To: <20050715225612.0714cbf7.lehmann@ans-netz.de> References: <20050715164129.1ebeca99.lehmann@ans-netz.de> <20050715154932.58609.qmail@web31806.mail.mud.yahoo.com> <20050715225612.0714cbf7.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: problems with soft-nfs when the server goes down 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, 15 Jul 2005 21:08:58 -0000 Oliver Lehmann wrote: > root@curry CURRY> kgdb kernel.debug /var/crash/vmcore.0 > kgdb: kvm_read: invalid address (150011) > kgdb: kvm_read: invalid address (bfbfe0f8) > kgdb: kvm_read: invalid address (129) > kgdb: kvm_read: invalid address (129) iirc the sources the world is from and the kernel sources are different.. I'll rebuild world.... let's hope thats the cause. Any ideas to the LOR? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:36:41 2005 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 4352D16A41C; Fri, 15 Jul 2005 21:36:41 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C1B43D48; Fri, 15 Jul 2005 21:36:40 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.52.136] (ip-207-145-88-3.nyc.megapath.net [207.145.88.3]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6FLado5026018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jul 2005 14:36:39 -0700 Message-ID: <42D82A7F.4050208@root.org> Date: Fri, 15 Jul 2005 14:28:31 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> <42D2F177.3070101@root.org> <200507121027.14113.jhb@FreeBSD.org> In-Reply-To: <200507121027.14113.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Harry Coin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 15 Jul 2005 21:36:41 -0000 John Baldwin wrote: > On Monday 11 July 2005 06:23 pm, Nate Lawson wrote: > >>John Baldwin wrote: >> >>>Also, can you upload your acpidump somewhere and provide a URL? I'm >>>curious if you have ACPI devices like thermal zones that don't have >>>_HID's and only have _CIDs. In fact, here's a patch to fix >>>acpi_get_logicalid() in that case. Give this a try first and let me know >>>if it fixes it. >> >>I would rather you directly call acpi_isa_get_compatid() rather than >>duplicating its logic here. There's no guarantee that the first CID >>will match the single ID passed in. > > > There is no passed in ID. For the common use of this function in almost all > ISA drivers, it just needs to return != 0 for PNP devices. I really think the driver is broken and the API is fine for this. I don't like the hack of returning a random CID for checks against the HID. Drivers down the road may come to rely on this and then every BIOS that has a different order for CIDs becomes a potential breakage point. Drivers should not rely on isa_get_logicalid() to determine a boolean "is PNP?" -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:39:40 2005 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 22AEC16A41C; Fri, 15 Jul 2005 21:39:40 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C77BC43D46; Fri, 15 Jul 2005 21:39:39 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.52.136] (ip-207-145-88-3.nyc.megapath.net [207.145.88.3]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6FLdco5026080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jul 2005 14:39:39 -0700 Message-ID: <42D82B32.6090707@root.org> Date: Fri, 15 Jul 2005 14:31:30 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4.3.2.7.2.20050712134818.0202b0d0@mail.qconline.com> <4.3.2.7.2.20050712150444.01fb8078@mail.qconline.com> <200507121627.44317.jhb@FreeBSD.org> In-Reply-To: <200507121627.44317.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Harry Coin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 15 Jul 2005 21:39:40 -0000 John Baldwin wrote: > On Tuesday 12 July 2005 04:12 pm, Harry Coin wrote: > >>John, >> >>I am sincerely appreciative the time you have taken. Your test results >>are below. >> >>I haven't processed everything you've written, but I'm not going to hold >>you up waiting as that is going to take a while. >> >>The code just comments out the line you mentioned. pcm0 loads with ACPI on >>in this case. I haven't tested what happens with ACPI off, and have no >>easy way to test what will happen with the other non-pnp chips (or other >>pnp chips) this driver supports. > > > Ok, thanks. > > >>I suggest you send a copy of your comments to whoever fixes up the >>architecture manual, because of evident disagreement regarding best >>practice in the isa non-pnp driver detection method (ISA_PNP_PROBE vs. >>isa_get_logical_id). > > > Well, I think I've just figured out why it says that (the ACPIxxxx devices), > so it looks like I am going to have to go through and fix all the various > drivers to use a probe routine if they attach to ACPI. It looks like several > drivers attach to acpi that probably don't need to as well (ACPI only > enumerates built-in hardware like COM ports, etc. It doesn't enumerate ISA > PnP cards). Thanks for looking into this. I agree that only the PNP-capable probe should attach to acpi. -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:44:33 2005 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 8DC1F16A41C; Fri, 15 Jul 2005 21:44:33 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2CD543D48; Fri, 15 Jul 2005 21:44:32 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Fri, 15 Jul 2005 16:45:16 -0500 Message-Id: <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jul 2005 16:44:22 -0500 To: Nate Lawson ,John Baldwin From: Harry Coin In-Reply-To: <42D82A7F.4050208@root.org> References: <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> <42D2F177.3070101@root.org> <200507121027.14113.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 15 Jul 2005 21:44:33 -0000 At 02:28 PM 7/15/2005 -0700, Nate Lawson wrote: >Drivers should not rely on isa_get_logicalid() to determine a boolean "is >PNP?" The architecture manual specifies ISA_PNP_PROBE in non pnp ISA drivers for that purpose. As I understand it, John doesn't like the ugly nature of passing in a null device list for non-pnp ISA drivers. Hard to argue with that. So why not gin up a tiny little boolean kernel function 'device_is_pnp(dev)) ' that does the right thing for non-pnp isa drivers - once -,right after wherever ISA_PNP_PROBE is defined in the kernel? Harry From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:48:51 2005 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 B69E716A41C; Fri, 15 Jul 2005 21:48:51 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645E443D48; Fri, 15 Jul 2005 21:48:51 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.52.136] (ip-207-145-88-3.nyc.megapath.net [207.145.88.3]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6FLmno5026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jul 2005 14:48:50 -0700 Message-ID: <42D82D59.9060605@root.org> Date: Fri, 15 Jul 2005 14:40:41 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Coin References: <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> <200507111626.25124.jhb@FreeBSD.org> <42D2F177.3070101@root.org> <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 15 Jul 2005 21:48:51 -0000 Harry Coin wrote: > At 02:28 PM 7/15/2005 -0700, Nate Lawson wrote: > >> Drivers should not rely on isa_get_logicalid() to determine a boolean >> "is PNP?" > > > The architecture manual specifies ISA_PNP_PROBE in non pnp ISA drivers > for that purpose. As I understand it, John doesn't like the ugly nature > of passing in a null device list for non-pnp ISA drivers. Hard to > argue with that. > > So why not gin up a tiny little boolean kernel function > 'device_is_pnp(dev)) ' that does the right thing for non-pnp isa drivers > - once -,right after wherever ISA_PNP_PROBE is defined in the kernel? I don't understand how this is needed. ACPI devices are always a superset of PNP. If a probe method is not PNP capable, it should never attach to the ACPI bus. I think that's what his fix changes, and I think it's sufficient. -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 21:58:55 2005 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 F3AF216A41C for ; Fri, 15 Jul 2005 21:58:54 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54C3F43D45 for ; Fri, 15 Jul 2005 21:58:51 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost (localhost [127.0.0.1]) by lapdance.yazzy.net (8.13.4/8.13.4) with SMTP id j6FLwnFV001641 for ; Fri, 15 Jul 2005 23:58:49 +0200 (CEST) (envelope-from lists@yazzy.org) Date: Fri, 15 Jul 2005 23:58:49 +0200 From: Marcin Jessa To: FreeBSD-Current Message-Id: <20050715235849.39e94911.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: ping: sendto: No buffer space available 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, 15 Jul 2005 21:58:55 -0000 Hi guys. After upgrade to 7.0 I've problems with my iwi nic. It's unable to connect to my AP. I can't really see any errors. Setting it up now the same way as on 6.0 and trying to ping an IP gives me: ping: sendto: No buffer space available Running tcpdump -i iwi0 -n -e -y IEEE802_11 shows avaliable APs, e.g: 23:49:01.222319 BSSID:00:40:05:cc:78:f8 DA:ff:ff:ff:ff:ff:ff SA:00:40:05:cc:78:f8 Beacon (Lia13F) [1.0* 2.0* 5.5* 11.0* 22.0* Mbit] ESS CH: 6 23:49:01.253009 BSSID:00:40:05:cc:78:f8 DA:00:12:f0:12:29:b3 SA:00:40:05:cc:78:f8 Probe Response (Lia13F) [1.0* 2.0* 5.5* 11.0* 22.0* Mbit] CH: 6 It worked reasonably fine on 6.0 Cheers, Marcin Jessa From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 00:21:50 2005 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 5B05716A41C for ; Sat, 16 Jul 2005 00:21:50 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10D4443D48 for ; Sat, 16 Jul 2005 00:21:49 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IJP00E902CCKN@VL-MO-MR001.ip.videotron.ca> for freebsd-current@freebsd.org; Fri, 15 Jul 2005 20:21:49 -0400 (EDT) Date: Fri, 15 Jul 2005 20:21:34 -0400 From: Nicolas Blais To: freebsd-current@freebsd.org Message-id: <200507152021.47403.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart1435370.b2uXdudoPA Content-transfer-encoding: 7bit User-Agent: KMail/1.8.1 Subject: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 00:21:50 -0000 --nextPart1435370.b2uXdudoPA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now=20 whenever i try to play a movie with mplayer, my system crashes with : =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x1c fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc06a0bc3 stack pointer =3D 0x28:0xe502fc88 frame pointer =3D 0x28:0xe502fcc8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 28 (swi4: clock sio) trap number =3D 12 panic: page fault Uptime: 7m49s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort)=20 and a 1gb dump. That same system was fine on 6-CURRENT from July 8th so=20 something in between breaks it. The crash message is always the same. I tri= ed=20 recompiling mplayer which did no good. Please help, Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #0: Fri Jul 15 17:16:58 EDT 2005 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart1435370.b2uXdudoPA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2FMbz38ton5LGeIRAsBuAJ493MLY73PDuB8Nt2uLA2Qg62M8iACdEPwZ Gl0z7M6ttvx1NbppG2TFSTY= =IpIX -----END PGP SIGNATURE----- --nextPart1435370.b2uXdudoPA-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 00:40:35 2005 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 47FEE16A41C for ; Sat, 16 Jul 2005 00:40:35 +0000 (GMT) (envelope-from mail@maeko.hayai.de) Received: from maeko.hayai.de (maeko.hayai.de [217.172.178.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1CC043D46 for ; Sat, 16 Jul 2005 00:40:34 +0000 (GMT) (envelope-from mail@maeko.hayai.de) Received: from maeko.hayai.de (IDENT:ident@localhost [127.0.0.1]) by maeko.hayai.de (8.12.11/8.12.11) with ESMTP id j6G0eXFX004627 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 16 Jul 2005 02:40:33 +0200 Received: (from mail@localhost) by maeko.hayai.de (8.12.11/8.12.11/Submit) id j6G0eXgm004626 for freebsd-current@freebsd.org; Sat, 16 Jul 2005 02:40:33 +0200 Date: Sat, 16 Jul 2005 02:40:33 +0200 From: Marco Wertejuk To: freebsd-current@freebsd.org Message-ID: <20050716004033.GA4447@maeko.hayai.de> Mail-Followup-To: freebsd-current@freebsd.org References: <20050711215828.GA6481@xavier.isds.duke.edu> <42D3C350.4060308@ultra-secure.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D3C350.4060308@ultra-secure.de> User-Agent: Mutt/1.5.4i Subject: BETA1 as vmware5 guest 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, 16 Jul 2005 00:40:35 -0000 Unfortunately this panic still occurs with beta1 iso images during installation but not when updating 5.4 to 6.0 from source. The panic message is: panic: Duplicate free of item 0xc1ae9ce4 from zone 0xc144adc0(g_bio) cpuid = 0 KDB: enter: panic [thread pid 3 tid 100034 ] Stopped at kdb_enter+0x2b: nop db> -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting & Internet Solutions From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 01:46:53 2005 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 0977716A41C for ; Sat, 16 Jul 2005 01:46:53 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF5B643D46 for ; Sat, 16 Jul 2005 01:46:52 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR007.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IJP002H66A4N0@VL-MO-MR007.ip.videotron.ca> for freebsd-current@freebsd.org; Fri, 15 Jul 2005 21:46:52 -0400 (EDT) Date: Fri, 15 Jul 2005 21:46:19 -0400 From: Nicolas Blais In-reply-to: <200507152021.47403.nb_root@videotron.ca> To: freebsd-current@freebsd.org Message-id: <200507152146.51668.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart1137251.B5diAKMZVH Content-transfer-encoding: 7bit User-Agent: KMail/1.8.1 References: <200507152021.47403.nb_root@videotron.ca> Subject: Re: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 01:46:53 -0000 --nextPart1137251.B5diAKMZVH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On July 15, 2005 08:21 pm, Nicolas Blais wrote: > Hi, > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now > whenever i try to play a movie with mplayer, my system crashes with : > > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x1c > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc06a0bc3 > stack pointer =3D 0x28:0xe502fc88 > frame pointer =3D 0x28:0xe502fcc8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 28 (swi4: clock sio) > trap number =3D 12 > panic: page fault > Uptime: 7m49s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8th so > something in between breaks it. The crash message is always the same. I > tried recompiling mplayer which did no good. > > Please help, > Nicolas. If this is any help to anyone: [nicblais] ~> nm -n /boot/kernel/* | grep c06a0 c06a0120 T kern_setitimer c06a0470 T setitimer c06a0510 T clock_gettime c06a0730 T ratecheck c06a07b0 T ppsratecheck c06a0830 T kern_timeout_callwheel_alloc c06a08a0 T callout_init c06a08f0 T kern_timeout_callwheel_init c06a09f0 T softclock c06a0ee0 T callout_reset =2D-=20 =46reeBSD 7.0-CURRENT #0: Fri Jul 15 17:16:58 EDT 2005 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart1137251.B5diAKMZVH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2GcLz38ton5LGeIRAqXQAJsEfA6eHfgY8gfCScdmm8jO35Rv8wCeLVdd 2b6KrDh6HrVLda9OrEyoklM= =5Rjo -----END PGP SIGNATURE----- --nextPart1137251.B5diAKMZVH-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 02:52:35 2005 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 A326916A41C for ; Sat, 16 Jul 2005 02:52:35 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B1BC43D46 for ; Sat, 16 Jul 2005 02:52:35 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id E0F52BE22D; Fri, 15 Jul 2005 22:53:26 -0400 (EDT) Date: Fri, 15 Jul 2005 22:53:26 -0400 From: James Snow To: Kevin Oberman Message-ID: <20050716025326.GA98030@teardrop.org> References: <20050714182136.071B35D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714182136.071B35D07@ptavv.es.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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, 16 Jul 2005 02:52:35 -0000 On Thu, Jul 14, 2005 at 11:21:36AM -0700, Kevin Oberman wrote: > > When I switch to wireless, dhclient no longer replaces the default > route. I need to take down my wired connection and flush routes before > starting dhclient. Not a big deal, but an annoyance. I also have an issue with default routes. In my case, I boot my laptop at one of any number of sites, some wired, some wireless. wpa_supplicant & dhclient work pretty well for me in the wireless cases. The problem I have is when I boot on a wired network with no wireless network present. (I've never tried booting with both present.) dhclient will get started on the wired interface, and it will get an IP. wpa_supplicant will also start and eventually dhclient will start on the wireless interface as well. There's no address for it to find, but somehow I wind up with no default route, rendering the wired interface useless. In these circumstances I've been killing wpa_supplicant, stopping dhclient on both my ath0 and em0 interfaces, and then restarting dhclient on em0. I keep wondering if I'm doing something wrong in my rc.conf: ifconfig_em0="DHCP" ifconfig_ath0="WPA DHCP" I also had to do this in /etc/dhclient.conf to keep the boot from taking forever when there was no wireless network present: interface "ath0" { # Let us boot up quickly timeout 5; } -Snow From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 02:57:11 2005 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 A7F2116A41C for ; Sat, 16 Jul 2005 02:57:11 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AFB043D45 for ; Sat, 16 Jul 2005 02:57:11 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.101] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0) by crumpet.united-ware.com (8.12.8p2/8.12.8) with ESMTP id j6G2sUwj073297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Jul 2005 22:54:30 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Fri, 15 Jul 2005 22:56:37 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4303584.9NSfapppeG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507152256.45966.mistry.7@osu.edu> X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_99,MYFREEBSD2 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com Subject: 6 and ULE 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, 16 Jul 2005 02:57:11 -0000 --nextPart4303584.9NSfapppeG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Since there still seems to be issues with 6 and ULE on multiprocessor=20 systems according to what I see on the list and the release todo is=20 there anything we can do help out? Basically I've got a dual opteron=20 server that I'd be willing to do some testing on since it won't be=20 put into production for at least 2 months for various reasons. So=20 right now it's just sitting here doing nothing :(. Thanks, =2D-=20 Anish Mistry --nextPart4303584.9NSfapppeG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2HdtxqA5ziudZT0RAu20AJ4nSl8RI58PuQJBdUiIKytR06OGqACeKQaG xmESbmeOFOaGbTdZM4dRsEg= =+iNq -----END PGP SIGNATURE----- --nextPart4303584.9NSfapppeG-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 05:31:28 2005 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 C0EEB16A41C for ; Sat, 16 Jul 2005 05:31:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AFB343D49 for ; Sat, 16 Jul 2005 05:31:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id C3FE44CE8EA for ; Fri, 15 Jul 2005 22:31:27 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60191-10 for ; Fri, 15 Jul 2005 22:31:27 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 452E94CE7F2 for ; Fri, 15 Jul 2005 22:31:27 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 1CD647A403 for ; Fri, 15 Jul 2005 22:31:27 -0700 (PDT) Message-ID: <42D89BAE.2050009@elischer.org> Date: Fri, 15 Jul 2005 22:31:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Subject: static binaries, jails and compat x 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, 16 Jul 2005 05:31:28 -0000 Now that we have dynamic binaries everywhere I'm discovering all those places where this breaks.. FreeBSD 5 or 6 machine. (needed because freeBSD 4 can't run on the new hardware) freeBSD 4 jail to run a legacy app. ps top and netstat (and friends) don't work (not surprisingly) ps I can get from /rescue but top and netstat are only available in dynamic form. So I will have to recompile static version myself. I'm just asking that if anyone has plans to make it actually impossible to make static binaries.. don't.... I could throw a few 6.x dynalic libraries in the machine but for example libkvm has the same number in 4.x as it does in fbsd6 libkvm.so.2 (maybe we should have changed that.. (maybe we still can for 6.x?) and libncurses does too so top can't have its own copy. possibly we could kick the revision number on a few of the basic libraries (e.g. neded for top and netstat etc). so that we can run them in jails based around lower revisions of the OS. and what about ld.so and ld_elf.so.1 might it be worth being possible to have one for native binaries and one for binaries that are of the revision that the jail is.. alternatively how about making it possible to have a /compat/FreeBSD4/ like we do for linux. and allow the OS to be able to identify the revision of th ebinary and do path tricks liek we do for linux..? From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 06:52:01 2005 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 C665D16A41C for ; Sat, 16 Jul 2005 06:52:01 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 675F443D45 for ; Sat, 16 Jul 2005 06:52:01 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id B35B4C013; Sat, 16 Jul 2005 08:51:59 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6G6ps32024041; Sat, 16 Jul 2005 08:51:57 +0200 (CEST) From: Thierry Herbelot To: bzeeb+freebsd+lor@zabbadoz.net Date: Sat, 16 Jul 2005 08:51:45 +0200 User-Agent: KMail/1.8.1 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200507160851.47433.thierry@herbelot.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 16 Jul 2005 06:52:01 -0000 Hello, I just had a look a the list of LOR you maintain and I did not see this one : (on a very recent -Current, on an SMP machine, with a straight GENERIC kernel) lock order reversal 1st 0xc097aaa0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1485 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_kern.c:295 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c092fbb8,c092fcf8,c08ba5a4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c0870b58,127) at witness_checkorder+0x564 _mtx_lock_flags(c1060144,0,c0870b58,127) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c0870b58,127) at _vm_map_lock+0x26 kmem_malloc(c10600c0,1000,1,c6d03ba4,c077df3d) at kmem_malloc+0x32 page_alloc(c104a5a0,1000,c6d03b97,1,c0653410) at page_alloc+0x1a slab_zalloc(c104a5a0,1,0,c1458680,c10492f8) at slab_zalloc+0xa1 uma_zone_slab(c104a5a0,1,1,e,31bb) at uma_zone_slab+0xe8 uma_zalloc_bucket(c104a5a0,1) at uma_zalloc_bucket+0x130 uma_zalloc_arg(c104a5a0,0,1) at uma_zalloc_arg+0x2d8 malloc(200,c08f4d00,1,43,c1044460) at malloc+0xae hash_alloc(c6d03c74,c1044468,0,c086fe11,1a4) at hash_alloc+0x29 zone_timeout(c1041b40) at zone_timeout+0x7e zone_foreach(c077d778,c6d03ce8,c063d21f,0,c077d744) at zone_foreach+0x37 uma_timeout(0) at uma_timeout+0x12 softclock(0) at softclock+0x1e7 ithread_loop(c1270400,c6d03d38,c1270400,c061f820,0) at ithread_loop+0x11c fork_exit(c061f820,c1270400,c6d03d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc6d03d6c, ebp = 0 --- CVS idents : /usr/src/sys/vm/uma_core.c: $FreeBSD: src/sys/vm/uma_core.c,v 1.122 2005/07/14 16:35:13 rwatson Exp $ /usr/src/sys/vm/vm_kern.c: $FreeBSD: src/sys/vm/vm_kern.c,v 1.122 2005/01/07 02:29:27 imp Exp $ Cheers TfH From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 09:16:36 2005 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 C673716A41C for ; Sat, 16 Jul 2005 09:16:36 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73AEE43D48 for ; Sat, 16 Jul 2005 09:16:36 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id C90DDBC89 for ; Sat, 16 Jul 2005 09:16:34 +0000 (UTC) To: current@freebsd.org From: Poul-Henning Kamp Date: Sat, 16 Jul 2005 11:16:34 +0200 Message-ID: <17725.1121505394@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Subject: modules/acpi/acpi fails in make universe 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, 16 Jul 2005 09:16:36 -0000 When building i386/LINT in "make universe", the acpi/acpi module fails to build: ===> acpi/acpi (depend) Warning: Object directory not changed from original /usr/obj/bang/src0/src/sys/L INT cc -O2 -fno-strict-aliasing -pipe -I. -I@ -c /bang/src0/src/sys/i386/acpica/ac pi_wakecode.S /bang/src0/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such file or d irectory /bang/src0/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: /bang/src0/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or operands in valid for `ljmp' *** Error code 1 1 error *** Error code 2 @ -> /bang/src0/src/sys Ad far as I can tell, this bit of sys/modules/acpi/acpi/Makefile is the offending stuff, but I can't tell what's wrong: acpi_wakecode.h: acpi_wakecode.S assym.s ${MAKE} -f ${.CURDIR}/../../../${MACHINE_ARCH}/acpica/Makefile \ MAKESRCPATH=${.CURDIR}/../../../${MACHINE_ARCH}/acpica -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 09:17:21 2005 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 0BAB916A41C for ; Sat, 16 Jul 2005 09:17:21 +0000 (GMT) (envelope-from sledgehammer@revier.net) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id EB96343D55 for ; Sat, 16 Jul 2005 09:17:19 +0000 (GMT) (envelope-from sledgehammer@revier.net) Received: (qmail 30048 invoked by uid 513); 16 Jul 2005 09:17:20 -0000 Received: from 195.62.97.190 by dsl-mail (envelope-from , uid 89) with qmail-scanner-1.24 (clamdscan: 0.80/609. spamassassin: 2.60. Clear:RC:1(195.62.97.190):. Processed in 0.026013 secs); 16 Jul 2005 09:17:20 -0000 Received: from webmail.mail2.kamp.net (HELO webmail.kamp-dsl.de) (195.62.97.190) by dsl-mail.kamp.net with SMTP; 16 Jul 2005 09:17:20 -0000 Received: from 82.141.44.113 (SquirrelMail authenticated user sledgehammer%revier.net) by webmail.kamp-dsl.de with HTTP; Sat, 16 Jul 2005 11:17:14 +0200 (CEST) Message-ID: <33107.82.141.44.113.1121505434.squirrel@webmail.kamp-dsl.de> Date: Sat, 16 Jul 2005 11:17:14 +0200 (CEST) From: sledgehammer@revier.net To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: 82801FB/FR/FW/FRW Intel High Definition Audio Controller 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, 16 Jul 2005 09:17:21 -0000 Hello. In June I posted the output of my pciconf, see below. I can't get my soundcard to work in FreeBSD. I upgraded to FreeBSD 7.0 current just yesterday and it's up to date but it still won't work...are there any plans to give support for the Intel High Definition Audio Controller, it's kind of sad if I can't watch video, listen to music on my new Siemens PC. Everything else seems to be working just fine now...thanks. .... $ uname -psr FreeBSD 7.0-CURRENT i386 ....... -------------- next part -------------- hostb0 at pci0:0:0: class=0x060000 card=0x25808086 chip=0x25808086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '915G/915P/925X Host Bridge / DRAM Controller' class = bridge subclass = HOST-PCI pcib1 at pci0:1:0: class=0x060400 card=0x00000088 chip=0x25818086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '915G/915P/925X Host-PCI Express Bridge' class = bridge subclass = PCI-PCI none0 at pci0:27:0: class=0x040300 card=0x814e1043 chip=0x26688086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW Intel High Deficition Audio Controller' class = multimedia pcib2 at pci0:28:0: class=0x060400 card=0x00000040 chip=0x26608086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 1' class = bridge subclass = PCI-PCI pcib3 at pci0:28:1: class=0x060400 card=0x00000040 chip=0x26628086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 2' class = bridge subclass = PCI-PCI pcib4 at pci0:28:2: class=0x060400 card=0x00000040 chip=0x26648086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 3' class = bridge subclass = PCI-PCI pcib5 at pci0:28:3: class=0x060400 card=0x00000040 chip=0x26668086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 4' class = bridge subclass = PCI-PCI uhci0 at pci0:29:0: class=0x0c0300 card=0x80a61043 chip=0x26588086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci1 at pci0:29:1: class=0x0c0300 card=0x80a61043 chip=0x26598086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci2 at pci0:29:2: class=0x0c0300 card=0x80a61043 chip=0x265a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci3 at pci0:29:3: class=0x0c0300 card=0x80a61043 chip=0x265b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB none1 at pci0:29:7: class=0x0c0320 card=0x80a61043 chip=0x265c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB 2.0 EHCI Controller' class = serial bus subclass = USB pcib6 at pci0:30:0: class=0x060401 card=0x00000050 chip=0x244e8086 rev=0xd3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER (ICH2/3/4/4-L/5/5R), 6300ESB Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0 at pci0:31:0: class=0x060100 card=0x00000000 chip=0x26408086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR ICH6/ICH6R LPC Controller' class = bridge subclass = PCI-ISA atapci0 at pci0:31:1: class=0x01018a card=0x80a61043 chip=0x266f8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB ICH6 Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1 at pci0:31:2: class=0x01018f card=0x26011043 chip=0x26518086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FW ICH6/ICH6W SATA Controller' class = mass storage subclass = ATA none2 at pci0:31:3: class=0x0c0500 card=0x80a61043 chip=0x266a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW SMBus Controller' class = serial bus subclass = SMBus none3 at pci6:0:0: class=0x030000 card=0x0500174b chip=0x5b601002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc.' class = display subclass = VGA none4 at pci6:0:1: class=0x038000 card=0x0501174b chip=0x5b701002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc.' class = display none5 at pci1:3:0: class=0x078000 card=0x200014f1 chip=0x2f2014f1 rev=0x00 hdr=0x00 vendor = 'Conexant Systems, Inc' class = simple comms fwohci0 at pci1:4:0: class=0x0c0010 card=0x808b1043 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB22/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class = serial bus subclass = FireWire rl0 at pci1:9:0: class=0x020000 card=0x80b31043 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet none6 at pci1:10:0: class=0x048000 card=0x002d11bd chip=0x71341131 rev=0x01 hdr=0x00 vendor = 'Philips Semiconductors' device = 'SAA7134HL Multi Media Capture Device' class = multimedia From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:13:01 2005 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 4BA3716A41C; Sat, 16 Jul 2005 13:13:01 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7DA843D46; Sat, 16 Jul 2005 13:13:00 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D1A6.dip.t-dialin.net [84.163.209.166] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML29c-1DtmTT0NvJ-0003Tj; Sat, 16 Jul 2005 15:12:59 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Sat, 16 Jul 2005 15:12:49 +0200 User-Agent: KMail/1.8 References: <200507061624.09477.max@love2party.net> <200507142116.42991.max@love2party.net> In-Reply-To: <200507142116.42991.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1416782.Sa0JntOn4s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507161512.57626.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-hackers@freebsd.org Subject: LAST: Call for FreeBSD status reports 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, 16 Jul 2005 13:13:01 -0000 --nextPart1416782.Sa0JntOn4s Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, turn-out is steadily increasing. We are still waiting for a couple of late= =20 entries. If you plan to submit, please do so asap. Thanks a lot! The final deadline is: July 18, 2005 - 20:00 GMT > On Wednesday 06 July 2005 16:24, I wrote: > > All, > > > > Three month of fruitful development have passed since the last round of > > FreeBSD status reports, and the release of FreeBSD 6.0 is on the > > doorstep. =A0We hope that you made good progress on your projects and h= ave > > interesting news to share. =A0Please do so by sending a status report to > > monthly@freebsd.org Submissions are due by July 15, 2005. > > > > Reports should cover activities during May to June, but may of course > > cover earlier work as well. =A0In addition we encourage you to use the > > "Open Tasks" section to recruit help for your project and point out > > future direction. > > > > Submissions are *not* limited to FreeBSD developers with commit rights! > > =A0It is open to everybody who is doing FreeBSD related work and wants = to > > share progress with the community. =A0The status reports are also a good > > vehicle to gather interested people for you WIP. > > > > We have introduced a new category called "soc" to pool reports related = to > > Google Summer of Code. =A0We hope for interesting news from that corner! > > > > To help you with fileing your report you will find a webform or > > xml-template linked from http://www.freebsd.org/news/status/ (as soon as > > the www build completes). > > > > Submissions are due on July 15. =A0Thanks a lot, and we are hoping for a > > big turn-out. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1416782.Sa0JntOn4s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2QfZXyyEoT62BG0RAu4pAJ9XZwlbBXbzlCwKEYzYGtcLuSNqegCfY7UE /m6/CCRiSNGoK+UEJmsbqFs= =9iXt -----END PGP SIGNATURE----- --nextPart1416782.Sa0JntOn4s-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:26:19 2005 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 CEF9F16A41C for ; Sat, 16 Jul 2005 13:26:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 589D343D48 for ; Sat, 16 Jul 2005 13:26:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 85A53513EA; Sat, 16 Jul 2005 09:26:18 -0400 (EDT) Date: Sat, 16 Jul 2005 09:26:18 -0400 From: Kris Kennaway To: Nicolas Blais Message-ID: <20050716132618.GA54497@xor.obsecurity.org> References: <200507152021.47403.nb_root@videotron.ca> <200507152146.51668.nb_root@videotron.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <200507152146.51668.nb_root@videotron.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 13:26:19 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 15, 2005 at 09:46:19PM -0400, Nicolas Blais wrote: > On July 15, 2005 08:21 pm, Nicolas Blais wrote: > > Hi, > > > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now > > whenever i try to play a movie with mplayer, my system crashes with : > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x1c > > fault code = supervisor write, page not present > > instruction pointer = 0x20:0xc06a0bc3 > > stack pointer = 0x28:0xe502fc88 > > frame pointer = 0x28:0xe502fcc8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 28 (swi4: clock sio) > > trap number = 12 > > panic: page fault > > Uptime: 7m49s > > Dumping 1023 MB (2 chunks) > > chunk 0: 1MB (159 pages) ... ok > > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8th so > > something in between breaks it. The crash message is always the same. I > > tried recompiling mplayer which did no good. Please obtain the traceback from the dump. Kris --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2Qr6Wry0BWjoQKURAqqxAKC28ESa5KvhnGeCT9Fyh7UPCJavNQCgmTKN Zb5vXnfB3Wg4qIZ+zPrwmLA= =UFoZ -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:26:52 2005 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 B945616A41C for ; Sat, 16 Jul 2005 13:26:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D4943D48 for ; Sat, 16 Jul 2005 13:26:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9006E513F4; Sat, 16 Jul 2005 09:26:51 -0400 (EDT) Date: Sat, 16 Jul 2005 09:26:51 -0400 From: Kris Kennaway To: Anish Mistry Message-ID: <20050716132651.GB54497@xor.obsecurity.org> References: <200507152256.45966.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <200507152256.45966.mistry.7@osu.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: 6 and ULE 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, 16 Jul 2005 13:26:52 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2005 at 10:56:37PM -0400, Anish Mistry wrote: > Since there still seems to be issues with 6 and ULE on multiprocessor=20 > systems according to what I see on the list and the release todo is=20 > there anything we can do help out? Basically I've got a dual opteron=20 > server that I'd be willing to do some testing on since it won't be=20 > put into production for at least 2 months for various reasons. So=20 > right now it's just sitting here doing nothing :(. Testing isn't needed since it's known there are problems. What's needed is someone to fix them :-) Kris --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2QsaWry0BWjoQKURAhScAJ49sFZjBOYN0LSsH8ILheMzJ5HpiACgz9/M 4qksCAqFFHCUyWj4uZUEdfs= =mXws -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:29:35 2005 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 AC27716A41C for ; Sat, 16 Jul 2005 13:29:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5627843D45 for ; Sat, 16 Jul 2005 13:29:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 94CF9513EA; Sat, 16 Jul 2005 09:29:34 -0400 (EDT) Date: Sat, 16 Jul 2005 09:29:34 -0400 From: Kris Kennaway To: Julian Elischer Message-ID: <20050716132934.GC54497@xor.obsecurity.org> References: <42D89BAE.2050009@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: <42D89BAE.2050009@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: static binaries, jails and compat x 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, 16 Jul 2005 13:29:35 -0000 --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2005 at 10:31:26PM -0700, Julian Elischer wrote: >=20 > Now that we have dynamic binaries everywhere I'm discovering all those=20 > places > where this breaks.. >=20 > FreeBSD 5 or 6 machine. (needed because freeBSD 4 can't run on the new=20 > hardware) > freeBSD 4 jail to run a legacy app. > ps top and netstat (and friends) don't work (not surprisingly) > ps I can get from /rescue > but top and netstat are only available in dynamic form. >=20 > So I will have to recompile static version myself. Or just copy in the necessary libs + dynamic linker into /libs in your jail along with the binaries you are already copying in from the host (this is what I do). > I could throw a few 6.x dynalic libraries in the machine but > for example libkvm has the same number in 4.x as it does in fbsd6 >=20 > libkvm.so.2 (maybe we should have changed that.. (maybe we still can for= =20 > 6.x?) This probably isn't a true conflict since 4.x binaries won't be able to run anyway with this library. > and libncurses does too > so top can't have its own copy. 6.x will look in /lib and 4.x will not, so it should again be fine. Kris --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2Qu9Wry0BWjoQKURAjpPAKDLdpl/7Zeww3LeqY7w1G9fu41C+ACfVakd w09bxhhrUfPvzs4VIaA7lSY= =M+yz -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:51:54 2005 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 B528316A41C for ; Sat, 16 Jul 2005 13:51:54 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A08743D4C for ; Sat, 16 Jul 2005 13:51:54 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Sat, 16 Jul 2005 17:51:44 +0400 Date: Sat, 16 Jul 2005 17:51:44 +0400 (MSD) From: "Alexander Polakov" Sender: polachok@narod.ru Message-Id: <42D910F0.000002.00737@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: freebsd-current@freebsd.org X-Source-Ip: 213.158.9.194 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Kernel compiling troubles X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 13:51:54 -0000 cannot build a kernel on today's CURRENT. ... ===> ukbd (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h ln -s /usr/obj/usr/src/sys/PSL2/opt_usb.h opt_usb.h echo "#define KBD_INSTALL_CDEV 1" > opt_kbd.h ln -s /usr/obj/usr/src/sys/PSL2/opt_ukbd.h opt_ukbd.h awk -f @/tools/usbdevs2h.awk @/dev/usb/usbdevs -h make: don't know how to make ukbdmap.h. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/PSL2. *** Error code 1 Stop in /usr/src. *** Error code 1 ... From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:57:47 2005 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 0902016A41C for ; Sat, 16 Jul 2005 13:57:47 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0998743D46 for ; Sat, 16 Jul 2005 13:57:45 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 91783 invoked by uid 89); 16 Jul 2005 13:57:18 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Jul 2005 13:57:18 -0000 Date: Sat, 16 Jul 2005 15:57:36 +0200 From: Oliver Lehmann To: current@freebsd.org Message-Id: <20050716155736.29fe63c4.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ariff Abdullah Subject: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 13:57:47 -0000 Hi, (I'm using http://staff.mybsd.org.my/skywizard/FreeBSD/sound/incoming/snd_HEAD_20050714_009.diff) while booting: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 sbc0: [GIANT-LOCKED] pcm0: on sbc0 pcm0: [GIANT-LOCKED] unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 331706898 Hz quality 800 Timecounters tick every 1.000 msec ad0: 6149MB at ata0-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a sysctl_old_user() with the following non-sleepable locks held: exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc12ada80) locked @ /usr/src/sys/dev/sound/pcm/sound.c:869 KDB: stack backtrace: kdb_backtrace(c077b1bc,ca2bbb50,1,ca2bbb5c,0) at kdb_backtrace+0x2e witness_warn(5,0,c06d33ed,0,ca2bbbfc) at witness_warn+0x1d3 sysctl_old_user(ca2bbbfc,ca2bbb74,4,0,0) at sysctl_old_user+0x55 sysctl_handle_int(c12ad940,ca2bbba4,4,ca2bbbfc,0) at sysctl_handle_int+0x45 sysctl_hw_snd_vchans(c12ad940,c119ea00,4,ca2bbbfc,ca2bbbfc) at sysctl_hw_snd_vchans+0xf0 sysctl_root(0,ca2bbc6c,4,ca2bbbfc,c1306600) at sysctl_root+0x154 userland_sysctl(c1306600,ca2bbc6c,4,bfbfdbb0,bfbfdbf8) at userland_sysctl+0x13c __sysctl(c1306600,ca2bbd04,18,421,6) at __sysctl+0xb7 syscall(bfbf003b,bfbf003b,bfbf003b,bfbfdbf8,bfbfe4c0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280be9ef, esp = 0xbfbfdb5c, ebp = 0xbfbfdb88 --- olivleh1@curry olivleh1> uname -a FreeBSD curry.salatschuessel.net 6.0-BETA FreeBSD 6.0-BETA #1: Sat Jul 16 15:04:23 CEST 2005 olivleh1@curry.salatschuessel.net:/usr/obj/i386-6.0/usr/src/sys/CURRY i386 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:02:59 2005 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 5D06C16A41C for ; Sat, 16 Jul 2005 14:02:59 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0396E43D48 for ; Sat, 16 Jul 2005 14:02:58 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 626A3BC89; Sat, 16 Jul 2005 14:02:57 +0000 (UTC) To: polachok@narod.ru From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 16 Jul 2005 17:51:44 +0400." <42D910F0.000002.00737@camay.yandex.ru> Date: Sat, 16 Jul 2005 16:02:56 +0200 Message-ID: <18689.1121522576@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Kernel compiling troubles 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, 16 Jul 2005 14:02:59 -0000 Fixed. In message <42D910F0.000002.00737@camay.yandex.ru>, "Alexander Polakov" writes: >cannot build a kernel on today's CURRENT. >... >===> ukbd (depend) >@ -> /usr/src/sys >machine -> /usr/src/sys/i386/include >awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h >awk -f @/tools/makeobjops.awk @/kern/device_if.m -h >ln -s /usr/obj/usr/src/sys/PSL2/opt_usb.h opt_usb.h >echo "#define KBD_INSTALL_CDEV 1" > opt_kbd.h >ln -s /usr/obj/usr/src/sys/PSL2/opt_ukbd.h opt_ukbd.h >awk -f @/tools/usbdevs2h.awk @/dev/usb/usbdevs -h >make: don't know how to make ukbdmap.h. Stop >*** Error code 2 > >Stop in /usr/src/sys/modules. >*** Error code 1 > >Stop in /usr/obj/usr/src/sys/PSL2. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 >... >_______________________________________________ >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" > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:17:46 2005 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 BA76816A41C for ; Sat, 16 Jul 2005 14:17:46 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (duke.voidnetwork.com [202.157.186.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38A9A43D48 for ; Sat, 16 Jul 2005 14:17:44 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 51C5F6CC20; Sat, 16 Jul 2005 22:23:41 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (duke.voidnetwork.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00172-10; Sat, 16 Jul 2005 22:23:39 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [60.48.104.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 3D1F46CC70; Sat, 16 Jul 2005 22:23:38 +0800 (MYT) Date: Sat, 16 Jul 2005 22:18:07 +0800 From: Ariff Abdullah To: Oliver Lehmann Message-Id: <20050716221807.21176fa5.skywizard@MyBSD.org.my> In-Reply-To: <20050716155736.29fe63c4.lehmann@ans-netz.de> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 14:17:46 -0000 On Sat, 16 Jul 2005 15:57:36 +0200 Oliver Lehmann wrote: > Hi, > > (I'm using > http://staff.mybsd.org.my/skywizard/FreeBSD/sound/incoming/snd_HEAD_20050714_009.diff) > > while booting: > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 > drq 1,0 on isa0 sbc0: [GIANT-LOCKED] > pcm0: on sbc0 > pcm0: [GIANT-LOCKED] > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > Timecounter "TSC" frequency 331706898 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 6149MB at ata0-master UDMA33 > Trying to mount root from ufs:/dev/ad0s1a > sysctl_old_user() with the following non-sleepable locks held: > exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc12ada80) locked @ > /usr/src/sys/dev/sound/pcm/sound.c:869 KDB: stack backtrace: > kdb_backtrace(c077b1bc,ca2bbb50,1,ca2bbb5c,0) at kdb_backtrace+0x2e > witness_warn(5,0,c06d33ed,0,ca2bbbfc) at witness_warn+0x1d3 > sysctl_old_user(ca2bbbfc,ca2bbb74,4,0,0) at sysctl_old_user+0x55 > sysctl_handle_int(c12ad940,ca2bbba4,4,ca2bbbfc,0) at > sysctl_handle_int+0x45 > sysctl_hw_snd_vchans(c12ad940,c119ea00,4,ca2bbbfc,ca2bbbfc) at > sysctl_hw_snd_vchans+0xf0 > sysctl_root(0,ca2bbc6c,4,ca2bbbfc,c1306600) at sysctl_root+0x154 > userland_sysctl(c1306600,ca2bbc6c,4,bfbfdbb0,bfbfdbf8) at > userland_sysctl+0x13c __sysctl(c1306600,ca2bbd04,18,421,6) at > __sysctl+0xb7 syscall(bfbf003b,bfbf003b,bfbf003b,bfbfdbf8,bfbfe4c0) > at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280be9ef, esp = > 0xbfbfdb5c, ebp = 0xbfbfdb88 --- > > > olivleh1@curry olivleh1> uname -a > FreeBSD curry.salatschuessel.net 6.0-BETA FreeBSD 6.0-BETA #1: Sat > Jul 16 15:04:23 CEST 2005 > olivleh1@curry.salatschuessel.net:/usr/obj/i386-6.0/usr/src/sys/CUR > RY i386 > > > My fault. I'll fix that. Anything from '/incoming/' is considered experimental. Thanks! -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:22:11 2005 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 826B816A41C for ; Sat, 16 Jul 2005 14:22:11 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AD1543D45 for ; Sat, 16 Jul 2005 14:22:11 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR007.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IJQ00IT658KJV@VL-MO-MR007.ip.videotron.ca> for freebsd-current@freebsd.org; Sat, 16 Jul 2005 10:21:56 -0400 (EDT) Date: Sat, 16 Jul 2005 10:21:50 -0400 From: Nicolas Blais In-reply-to: <1121497558.61704.2.camel@renaissance.homeip.net> To: freebsd-current@freebsd.org Message-id: <200507161021.56248.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart14566025.b5WbRHCkLk Content-transfer-encoding: 7bit User-Agent: KMail/1.8.1 References: <200507152021.47403.nb_root@videotron.ca> <200507152146.51668.nb_root@videotron.ca> <1121497558.61704.2.camel@renaissance.homeip.net> Subject: Re: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 14:22:11 -0000 --nextPart14566025.b5WbRHCkLk Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now > > > whenever i try to play a movie with mplayer, my system crashes with : > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address =3D 0x1c > > > fault code =3D supervisor write, page not present > > > instruction pointer =3D 0x20:0xc06a0bc3 > > > stack pointer =3D 0x28:0xe502fc88 > > > frame pointer =3D 0x28:0xe502fcc8 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 28 (swi4: clock sio) > > > trap number =3D 12 > > > panic: page fault > > > Uptime: 7m49s > > > Dumping 1023 MB (2 chunks) > > > chunk 0: 1MB (159 pages) ... ok > > > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > > > > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8th = so > > > something in between breaks it. The crash message is always the same.= I > > > tried recompiling mplayer which did no good. > > > > > > Please help, > > > Nicolas. > > > > If this is any help to anyone: > > > > [nicblais] ~> nm -n /boot/kernel/* | grep c06a0 > > c06a0120 T kern_setitimer > > c06a0470 T setitimer > > c06a0510 T clock_gettime > > c06a0730 T ratecheck > > c06a07b0 T ppsratecheck > > c06a0830 T kern_timeout_callwheel_alloc > > c06a08a0 T callout_init > > c06a08f0 T kern_timeout_callwheel_init > > c06a09f0 T softclock > > c06a0ee0 T callout_reset I've tried on SCHED_4BSD and ULE both causes the same trap. Here's more inf= o=20 (copied from a digital cam shot, since I can't seem to save the output of=20 kgdb) db> where Tracing pid 27 tid 100025 td 0xc22df480 _mtx_unlock_flags(0,0c0906ed0,13b,c29efc00) at _mtx_unlock_flags+0x46 softclock(0,0,c090377f,251,e502cd04) at softclock+0x272 ithread_loop(c2287480,e502cd38,c0903576,30d,c2287480) at ithread_loop+0x152 fork_exit(c0679070,c2287480,e502cd38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 =2D-- trap 0x1, eip =3D 0, esp =3D 0xe502cd6c, ebp =3D 0 --- db>=20 --nextPart14566025.b5WbRHCkLk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2RgEz38ton5LGeIRAnYkAJ4g6uxyIJvtX0mXJS5AmZkN5qhQpACaAn0b r0DsOvn3wDPKPws2Q7VGpi0= =gOJZ -----END PGP SIGNATURE----- --nextPart14566025.b5WbRHCkLk-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:26:39 2005 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 D291616A41C for ; Sat, 16 Jul 2005 14:26:39 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from tide.yandex.ru (tide.yandex.ru [213.180.200.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7017D43D48 for ; Sat, 16 Jul 2005 14:26:39 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (tide.yandex.ru) by mail.yandex.ru id ; Sat, 16 Jul 2005 18:26:26 +0400 Date: Sat, 16 Jul 2005 18:26:26 +0400 (MSD) From: "Alexander Polakov" Sender: polachok@narod.ru Message-Id: <42D91912.000003.02459@tide.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: phk@phk.freebsd.dk In-Reply-To: <18689.1121522576@phk.freebsd.dk> References: <18689.1121522576@phk.freebsd.dk> X-Source-Ip: 213.158.3.68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel compiling troubles X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 14:26:39 -0000 >Fixed. Thanks. -- Alexander Polakov From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:47:24 2005 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 D36EB16A41C for ; Sat, 16 Jul 2005 14:47:24 +0000 (GMT) (envelope-from sledgehammer@revier.net) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 1FEF843D49 for ; Sat, 16 Jul 2005 14:47:23 +0000 (GMT) (envelope-from sledgehammer@revier.net) Received: (qmail 15400 invoked by uid 513); 16 Jul 2005 14:47:27 -0000 Received: from 195.62.97.190 by dsl-mail (envelope-from , uid 89) with qmail-scanner-1.24 (clamdscan: 0.80/609. spamassassin: 2.60. Clear:RC:1(195.62.97.190):. Processed in 0.023614 secs); 16 Jul 2005 14:47:27 -0000 Received: from webmail.mail2.kamp.net (HELO webmail.kamp-dsl.de) (195.62.97.190) by dsl-mail.kamp.net with SMTP; 16 Jul 2005 14:47:27 -0000 Received: from 82.141.44.113 (SquirrelMail authenticated user sledgehammer%revier.net) by webmail.kamp-dsl.de with HTTP; Sat, 16 Jul 2005 16:47:18 +0200 (CEST) Message-ID: <33051.82.141.44.113.1121525238.squirrel@webmail.kamp-dsl.de> In-Reply-To: <20050716091735.53D4C16A428@hub.freebsd.org> References: <20050716091735.53D4C16A428@hub.freebsd.org> Date: Sat, 16 Jul 2005 16:47:18 +0200 (CEST) From: sledgehammer@revier.net To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: re Problems with dhclient 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, 16 Jul 2005 14:47:24 -0000 Hi. I'm having the same problems here in FreeBSD 7.0 current....wired connection only going to a Draytek Vigor 2600 DSL router...I just tried to transfer a couple of GB over my LAN via SSH from my PC running FreeBSD 7.0 to my Mac Mini running Mac OS X 10.4.2 and the connection got lost all of a sudden...FreeBSD wasn't able to connect to the internet either for a while while the Mac had no such problems..here's the part from the log for my SSH transfer: Jul 16 16:28:43 lepus kernel: rl0: discard oversize frame (ether type ffff flags 3 len 5628 > max 1514) When I run a dmesg I get this: I had never seen that in 5.4 $ dmesg | grep rl rl0: port 0x9800-0x98ff mem 0xd7eff800-0xd7eff8ff irq 17 at device 9.0 on pci1 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:11:d8:05:10:ae rl0: discard oversize frame (ether type ffff flags 3 len 5628 > max 1514) rl0: discard oversize frame (ether type f427 flags 3 len 11428 > max 1514) rl0: discard oversize frame (ether type e467 flags 3 len 57295 > max 1514) rl0: discard oversize frame (ether type 80a flags 3 len 20975 > max 1514) $ uname -psr FreeBSD 7.0-CURRENT i386 From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 13:30:17 2005 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 EA8D216A41C; Fri, 15 Jul 2005 13:30:17 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C3C43D48; Fri, 15 Jul 2005 13:30:17 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id 347E22434B; Fri, 15 Jul 2005 15:30:11 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id 313DE2434A; Fri, 15 Jul 2005 15:30:11 +0200 (CEST) Date: Fri, 15 Jul 2005 15:30:11 +0200 (CEST) From: Goran Gajic To: Gleb Smirnoff In-Reply-To: <20050714134405.GE19262@cell.sick.ru> Message-ID: References: <20050714112452.GD17494@cell.sick.ru> <20050714134405.GE19262@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 16 Jul 2005 14:47:34 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: LOR with 6.0 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, 15 Jul 2005 13:30:18 -0000 On Thu, 14 Jul 2005, Gleb Smirnoff wrote: > On Thu, Jul 14, 2005 at 03:41:03PM +0200, Goran Gajic wrote: > G> I haven't saved it :( I have cvsup-ed system to 6.0-BETA. Now I have > G> strange problem. I have to do ifconfig fxp0 down; ifconfig fxp0 up; same > G> for em0 in order to restore network connectivity othervise I can't ping > G> anything except ip addresses of interfaces. Here is also one strane > G> message I have noticed after doing so: > G> Memory modified after free 0xcb3f1800(2048) val=a022c0de @ 0xcb3f1800 > G> Version is: > G> 6.0-BETA FreeBSD 6.0-BETA #8: Wed Jul 13 00:56:35 CEST 2005 > G> and I'm using GENERIC config with options IPFILTER at the end. > G> > G> If I can provide more information I would be glad to. > > To narrow down the scope of problem search, can you boot GENERIC kernel > without ipfilter and try to reproduce the above bugs? > > I did so and for last 24h everything seems to be ok.. What shall I do next? gg. From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 19:11:26 2005 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 2283516A41C; Fri, 15 Jul 2005 19:11:26 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: from isis.sigpipe.cz (fw.sigpipe.cz [62.245.70.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id A77B243D45; Fri, 15 Jul 2005 19:11:24 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id 133C51F87BF4; Fri, 15 Jul 2005 21:11:23 +0200 (CEST) Date: Fri, 15 Jul 2005 21:11:23 +0200 From: Roman Neuhauser To: Craig Boston , Brooks Davis , Robert Watson , freebsd-current@freebsd.org Message-ID: <20050715191122.GA1194@isis.sigpipe.cz> Mail-Followup-To: Craig Boston , Brooks Davis , Robert Watson , freebsd-current@freebsd.org References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <20050714191832.GA7462@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714191832.GA7462@nowhere> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sat, 16 Jul 2005 14:47:34 +0000 Cc: Subject: Re: Problems with OpenBSD dhclient 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, 15 Jul 2005 19:11:26 -0000 # craig@xfoil.gank.org / 2005-07-14 14:18:32 -0500: > On Thu, Jul 14, 2005 at 11:58:51AM -0700, Brooks Davis wrote: > > I'm seeing this as well. I think we're going to need to handle wireless > > and wired interfaces differently since their links work differently. > > If anything, please PLEEEEEASE make it possible to disable this behavior > for ALL interface types. > > There's nothing more annoying (to me) than unplugging a Windows 2000 > machine for half a second to reroute or swap a network cable, then > finding that all the open connections were terminated because it briefly > lost its IP address. The suggestion above got me quite agitated as this behavior of windows is one of the things I abhor in the software, because it (the behavior) cuts down usability of the software. Pull the wrong cable from a switch after you've downloaded most of an iso image, and you'll see how useful this behavior is. The situation gets even worse in wireless networks where you can occasionaly have link down without doing anything to the equipment. All in all, doing too much when the link goes down would be a big mistake. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 19:14:02 2005 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 C084116A41C for ; Fri, 15 Jul 2005 19:14:02 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3290743D46 for ; Fri, 15 Jul 2005 19:14:02 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7E9B31704D; Fri, 15 Jul 2005 21:14:01 +0200 (CEST) Date: Fri, 15 Jul 2005 21:14:01 +0200 From: Ed Schouten To: Fred Gilham Message-ID: <20050715191401.GI36726@hoeg.nl> References: <200507151906.j6FJ6JqP034933@mx1.csl.sri.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uJrvpPjGB3z5kYrA" Content-Disposition: inline In-Reply-To: <200507151906.j6FJ6JqP034933@mx1.csl.sri.com> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sat, 16 Jul 2005 14:47:34 +0000 Cc: FreeBSD Current Subject: Re: Question about su and network 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, 15 Jul 2005 19:14:02 -0000 --uJrvpPjGB3z5kYrA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Fred Gilham wrote: > When my ISDN line was down yesterday, I noticed that su from an xterm > would hang on my FreeBSD box. Logging in as root from a virtual console > would work OK. After the network came back everything went back to > normal. >=20 > Is there a way I can avoid this behavior? I mean the hanging, not the > return to normal operation. :-) This would probably have happened because your DNS server was unreachable (su tries to resolve your hostname for the logfiles). This can be solved by adding your own host to /etc/hosts: 192.168.1.3 myhostname myhostname.mydomain.foo Yours, --=20 Ed Schouten --uJrvpPjGB3z5kYrA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2Ar5mVI4SHXwmhERArEqAKDUFpUV1BLGW2yAHurojlL24D/QpwCfTnY+ qBbrwR2DeVvCONWNZSqShFA= =B+Rd -----END PGP SIGNATURE----- --uJrvpPjGB3z5kYrA-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:56:27 2005 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 0BE2616A41C for ; Sat, 16 Jul 2005 14:56:27 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3650B43D46 for ; Sat, 16 Jul 2005 14:56:25 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 93162 invoked by uid 89); 16 Jul 2005 14:55:58 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Jul 2005 14:55:58 -0000 Date: Sat, 16 Jul 2005 16:56:16 +0200 From: Oliver Lehmann To: freebsd-current@freebsd.org Message-Id: <20050716165616.4d859842.lehmann@ans-netz.de> In-Reply-To: <20050716221807.21176fa5.skywizard@MyBSD.org.my> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 14:56:27 -0000 Ariff Abdullah wrote: > My fault. I'll fix that. Anything from '/incoming/' is considered > experimental. Thanks! Yeah, no problem. Let me know when you fixed it and I'll try again. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 15:03:28 2005 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 6852116A42F for ; Sat, 16 Jul 2005 15:03:28 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 124C343D46 for ; Sat, 16 Jul 2005 15:03:28 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IJQ001DT75RXV@VL-MO-MR011.ip.videotron.ca> for freebsd-current@freebsd.org; Sat, 16 Jul 2005 11:03:27 -0400 (EDT) Date: Sat, 16 Jul 2005 11:03:14 -0400 From: Nicolas Blais In-reply-to: <200507152021.47403.nb_root@videotron.ca> To: freebsd-current@freebsd.org Message-id: <200507161103.27053.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart11344700.yUE6NGbcLn Content-transfer-encoding: 7bit User-Agent: KMail/1.8.1 References: <200507152021.47403.nb_root@videotron.ca> Subject: FIXED: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 15:03:28 -0000 --nextPart11344700.yUE6NGbcLn Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On July 15, 2005 08:21 pm, Nicolas Blais wrote: > Hi, > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now > whenever i try to play a movie with mplayer, my system crashes with : > > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x1c > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc06a0bc3 > stack pointer =3D 0x28:0xe502fc88 > frame pointer =3D 0x28:0xe502fcc8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 28 (swi4: clock sio) > trap number =3D 12 > panic: page fault > Uptime: 7m49s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8th so > something in between breaks it. The crash message is always the same. I > tried recompiling mplayer which did no good. > > Please help, > Nicolas. I found a fix for my problem !=20 I had HZ=3D1160 in my kernel and WITH_RTC enabled in mplayer.=20 =46or some reason, latest kernel code doesn't like the option and panics. I= =20 removed both HZ=3D1160 and WITH_RTC and now mplayer works like a charm. So either mplayer (or rtc-2004.02.24.1_4) doesn't like something added in t= he=20 kernel between july 8th and today, or the kernel doesn't like the way mplay= er=20 (or rtc) syncs up with the clock. =2D-=20 =46reeBSD 7.0-CURRENT #3: Sat Jul 16 09:43:08 EDT 2005 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart11344700.yUE6NGbcLn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2SG/z38ton5LGeIRAg8RAJ4iw/rnsi/0Z0HqGAKgcrBr6Uu7vwCcDYxe 9R6Wf5VkyDWdNjAXNBmCSWw= =Tah2 -----END PGP SIGNATURE----- --nextPart11344700.yUE6NGbcLn-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 15:40:10 2005 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 B119216A41C for ; Sat, 16 Jul 2005 15:40:10 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (duke.voidnetwork.com [202.157.186.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C35843D46 for ; Sat, 16 Jul 2005 15:40:09 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 685316CC2B; Sat, 16 Jul 2005 23:46:03 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (duke.voidnetwork.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22141-04; Sat, 16 Jul 2005 23:46:02 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [60.48.108.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id DE6636CC20; Sat, 16 Jul 2005 23:45:57 +0800 (MYT) Date: Sat, 16 Jul 2005 23:40:24 +0800 From: Ariff Abdullah To: Oliver Lehmann Message-Id: <20050716234024.2d536b5a.skywizard@MyBSD.org.my> In-Reply-To: <20050716165616.4d859842.lehmann@ans-netz.de> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 15:40:10 -0000 On Sat, 16 Jul 2005 16:56:16 +0200 Oliver Lehmann wrote: > Ariff Abdullah wrote: > > > My fault. I'll fix that. Anything from '/incoming/' is considered > > experimental. Thanks! > > Yeah, no problem. Let me know when you fixed it and I'll try again. > > I've uploaded latest (revision 012). Hopefully the problem gone forever. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:27:59 2005 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 5038E16A41C for ; Sat, 16 Jul 2005 16:27:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E022943D46 for ; Sat, 16 Jul 2005 16:27:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GGRIuC030565; Sat, 16 Jul 2005 10:27:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 10:27:59 -0600 (MDT) Message-Id: <20050716.102759.08404666.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200507151938.00294.thierry@herbelot.com> References: <200507151938.00294.thierry@herbelot.com> 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: loss of PCMCIA ed(4) interface 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, 16 Jul 2005 16:27:59 -0000 Is the ed card in the system at boot? Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:30:59 2005 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 97B9116A41C; Sat, 16 Jul 2005 16:30:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CFDE43D48; Sat, 16 Jul 2005 16:30:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GGTkvW030585; Sat, 16 Jul 2005 10:29:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 10:30:28 -0600 (MDT) Message-Id: <20050716.103028.04060625.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <42D82D59.9060605@root.org> References: <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> <42D82D59.9060605@root.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, harrycoin@qconline.com Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 16:30:59 -0000 In message: <42D82D59.9060605@root.org> Nate Lawson writes: : Harry Coin wrote: : > At 02:28 PM 7/15/2005 -0700, Nate Lawson wrote: : > : >> Drivers should not rely on isa_get_logicalid() to determine a boolean : >> "is PNP?" : > : > : > The architecture manual specifies ISA_PNP_PROBE in non pnp ISA drivers : > for that purpose. As I understand it, John doesn't like the ugly nature : > of passing in a null device list for non-pnp ISA drivers. Hard to : > argue with that. : > : > So why not gin up a tiny little boolean kernel function : > 'device_is_pnp(dev)) ' that does the right thing for non-pnp isa drivers : > - once -,right after wherever ISA_PNP_PROBE is defined in the kernel? : : I don't understand how this is needed. ACPI devices are always a : superset of PNP. If a probe method is not PNP capable, it should never : attach to the ACPI bus. I think that's what his fix changes, and I : think it's sufficient. Nate's right here. It isn't needed. The ISA_PNP_PROBE is for all devices that have a PNP ID. Thse includes ISA PnP cards, PNP BIOS devices and ACPI devices. So the device_is_pnp() isn't needed at all. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:33:42 2005 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 7496C16A41C for ; Sat, 16 Jul 2005 16:33:42 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97A8F43D46 for ; Sat, 16 Jul 2005 16:33:41 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 95427 invoked by uid 89); 16 Jul 2005 16:33:13 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Jul 2005 16:33:13 -0000 Date: Sat, 16 Jul 2005 18:33:31 +0200 From: Oliver Lehmann To: Ariff Abdullah Message-Id: <20050716183331.5b972d3d.lehmann@ans-netz.de> In-Reply-To: <20050716234024.2d536b5a.skywizard@MyBSD.org.my> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> <20050716234024.2d536b5a.skywizard@MyBSD.org.my> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 16:33:42 -0000 Ariff Abdullah wrote: > > I've uploaded latest (revision 012). Hopefully the problem gone > forever. > It's gone, thanks! -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:36:39 2005 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 447E216A41C for ; Sat, 16 Jul 2005 16:36:39 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66DF343D45 for ; Sat, 16 Jul 2005 16:36:38 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 95488 invoked by uid 89); 16 Jul 2005 16:36:10 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Jul 2005 16:36:10 -0000 Date: Sat, 16 Jul 2005 18:36:28 +0200 From: Oliver Lehmann To: skywizard@MyBSD.org.my Message-Id: <20050716183628.418fde56.lehmann@ans-netz.de> In-Reply-To: <20050716183331.5b972d3d.lehmann@ans-netz.de> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> <20050716234024.2d536b5a.skywizard@MyBSD.org.my> <20050716183331.5b972d3d.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 16:36:39 -0000 Oliver Lehmann wrote: > Ariff Abdullah wrote: > > > > > I've uploaded latest (revision 012). Hopefully the problem gone > > forever. > > > > It's gone, thanks! When I start playing a song (with beep-media-player in that case), I still get one: lock order reversal 1st 0xc12bf0c0 sbc0 (sound softc) @ /usr/src/sys/dev/sound/isa/sbc.c:131 2nd 0xc12ad840 pcm0:play:0 (pcm play channel) @ /usr/src/sys/dev/sound/pcm/channel.c:525 KDB: stack backtrace: kdb_backtrace(c06d6729,c12ad840,c12c4d54,c06c96c9,c06c9717) at kdb_backtrace+0x2e witness_checkorder(c12ad840,9,c06c9717,20d,0) at witness_checkorder+0x6c3 _mtx_lock_flags(c12ad840,0,c06c9717,20d,c1295b00) at _mtx_lock_flags+0x8a chn_intr(c12c4d00,c,c04fab2a,0,c1295ad8) at chn_intr+0x2d ess_intr(c1295b00,c12add80,c11a0b00,c5bd2d00,c04ed4b2) at ess_intr+0x75 sbc_intr(c1295ad8,0,c06d05e1,220,c5bd2d00) at sbc_intr+0x24 ithread_loop(c11a0b00,c5bd2d38,c06d03d8,30d,3c89ffff) at ithread_loop+0x162 fork_exit(c04ed350,c11a0b00,c5bd2d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:50:12 2005 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 177BE16A41C for ; Sat, 16 Jul 2005 16:50:12 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F7343D46 for ; Sat, 16 Jul 2005 16:50:11 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id B7E86C097 for ; Sat, 16 Jul 2005 18:50:10 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6GGnt71008078; Sat, 16 Jul 2005 18:49:58 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 16 Jul 2005 18:49:32 +0200 User-Agent: KMail/1.8.1 References: <200507151938.00294.thierry@herbelot.com> <20050716.102759.08404666.imp@bsdimp.com> In-Reply-To: <20050716.102759.08404666.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507161849.39012.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 16 Jul 2005 16:50:12 -0000 Hello, Le Saturday 16 July 2005 18:27, M. Warner Losh a écrit : > Is the ed card in the system at boot? Yes, the card is always plugged-in (the notebook is used as a kind of tinderbox) - should I try and extract and replug it ? > > Warner TfH From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:00:53 2005 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 C125A16A41C for ; Sat, 16 Jul 2005 17:00:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D1143D48 for ; Sat, 16 Jul 2005 17:00:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GGw7Ok030933; Sat, 16 Jul 2005 10:58:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 10:58:49 -0600 (MDT) Message-Id: <20050716.105849.112624020.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200507161849.39012.thierry@herbelot.com> References: <200507151938.00294.thierry@herbelot.com> <20050716.102759.08404666.imp@bsdimp.com> <200507161849.39012.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: loss of PCMCIA ed(4) interface 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, 16 Jul 2005 17:00:53 -0000 In message: <200507161849.39012.thierry@herbelot.com> Thierry Herbelot writes: : Hello, : = : Le Saturday 16 July 2005 18:27, M. Warner Losh a =E9crit : : > Is the ed card in the system at boot? : = : Yes, the card is always plugged-in (the notebook is used as a kind of= = : tinderbox) - should I try and extract and replug it ? Yes. Please try that. Also, do you have ed compiled into the kernel or are you using a module? Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:11:59 2005 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 3A5F016A41C for ; Sat, 16 Jul 2005 17:11:59 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (duke.voidnetwork.com [202.157.186.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E4B43D45 for ; Sat, 16 Jul 2005 17:11:58 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id DE1836CC57; Sun, 17 Jul 2005 01:17:55 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (duke.voidnetwork.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22141-10; Sun, 17 Jul 2005 01:17:54 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [60.48.108.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 390E16CC20; Sun, 17 Jul 2005 01:17:53 +0800 (MYT) Date: Sun, 17 Jul 2005 01:12:20 +0800 From: Ariff Abdullah To: Oliver Lehmann Message-Id: <20050717011220.2252a5b4.skywizard@MyBSD.org.my> In-Reply-To: <20050716183628.418fde56.lehmann@ans-netz.de> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> <20050716234024.2d536b5a.skywizard@MyBSD.org.my> <20050716183331.5b972d3d.lehmann@ans-netz.de> <20050716183628.418fde56.lehmann@ans-netz.de> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 17:11:59 -0000 On Sat, 16 Jul 2005 18:36:28 +0200 Oliver Lehmann wrote: > Oliver Lehmann wrote: > > > Ariff Abdullah wrote: > > > > > > > > I've uploaded latest (revision 012). Hopefully the problem gone > > > forever. > > > > > > > It's gone, thanks! > > When I start playing a song (with beep-media-player in that case), > I still get one: > > lock order reversal > 1st 0xc12bf0c0 sbc0 (sound softc) @ > /usr/src/sys/dev/sound/isa/sbc.c:131 2nd 0xc12ad840 pcm0:play:0 > (pcm play channel) @ /usr/src/sys/dev/sound/pcm/channel.c:525 > KDB: stack backtrace: > kdb_backtrace(c06d6729,c12ad840,c12c4d54,c06c96c9,c06c9717) at > kdb_backtrace+0x2e witness_checkorder(c12ad840,9,c06c9717,20d,0) at > witness_checkorder+0x6c3 > _mtx_lock_flags(c12ad840,0,c06c9717,20d,c1295b00) at > _mtx_lock_flags+0x8a chn_intr(c12c4d00,c,c04fab2a,0,c1295ad8) at > chn_intr+0x2d ess_intr(c1295b00,c12add80,c11a0b00,c5bd2d00,c04ed4b2) > at ess_intr+0x75 sbc_intr(c1295ad8,0,c06d05e1,220,c5bd2d00) at > sbc_intr+0x24 ithread_loop(c11a0b00,c5bd2d38,c06d03d8,30d,3c89ffff) > at ithread_loop+0x162 fork_exit(c04ed350,c11a0b00,c5bd2d38) at > fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 > > > Try this: http://staff.mybsd.org.my/skywizard/FreeBSD/sound/incoming/ess.c.diff -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:11:59 2005 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 9E41A16A41C; Sat, 16 Jul 2005 17:11:59 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2461143D49; Sat, 16 Jul 2005 17:11:59 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Sat, 16 Jul 2005 12:12:43 -0500 Message-Id: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Jul 2005 12:11:50 -0500 To: "M. Warner Losh" ,nate@root.org From: Harry Coin In-Reply-To: <20050716.103028.04060625.imp@bsdimp.com> References: <42D82D59.9060605@root.org> <200507121027.14113.jhb@FreeBSD.org> <4.3.2.7.2.20050715164008.01f0fdd8@mail.qconline.com> <42D82D59.9060605@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 17:11:59 -0000 At 10:30 AM 7/16/2005 -0600, M. Warner Losh wrote: >Nate's right here. It isn't needed. The ISA_PNP_PROBE is for all >devices that have a PNP ID. Thse includes ISA PnP cards, PNP BIOS >devices and ACPI devices. So the device_is_pnp() isn't needed at all. > >Warner I think all that's needed to wrap this up is for the powers that be to offer clarity about one thing, final decision about the case of arbitrary (beyond com1, etc.) non-pnp ISA devices probe routines. A great many sound chips of various register demands are in this list. (Admittedly older devices, but I ran into serious breakage of an isa pnp device driver because of interactions with the related non-pnp probe routine that supported earlier chipsets in the same family that were largely register compatible with the pnp versions). Seems either 1) Document a way or make an OS change to make certain non-pnp isa probe routines are never called any time while pnp isa resources haven't been put to sleep. So that these probe routines will only be called after the field is clear and they can rummage around the register space looking for their chips -- and they don't accidentally find compatible PCI versions previously or yet to be found by their PCI probe modern driver cousins. The isa part of the architecture manual ought to be updated to reflect how properly to do this. (Are there cases where the non-pnp routines being called in the acpi context pass the currently iffy pnp-gate and find and enable operations of pnp chips that the pnp-routines don't have in their 'acceptable id' list? My hunch in the sound chip world is 'yes'. So this fix might break audio on systems that don't have the pnp ids in the pnp soundchip ISA_PROBE roster as yet.) or 2) change non-pnp isa drivers to do as the architecture manual currently suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list then continue only if no pnp id for the device). or 3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then update the architecture manual for isa drivers and also the isa drivers themselves. or 4) I can't think of a 4, but I'm sure there is a 4. There's always a 4. Please pick and announce! Harry From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:14:44 2005 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 229D716A41C for ; Sat, 16 Jul 2005 17:14:44 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF3E143D46 for ; Sat, 16 Jul 2005 17:14:43 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-2.free.fr (Postfix) with ESMTP id 71563321B26 for ; Sat, 16 Jul 2005 19:14:42 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6GHEXgB007469; Sat, 16 Jul 2005 19:14:34 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 16 Jul 2005 19:14:18 +0200 User-Agent: KMail/1.8.1 References: <200507151938.00294.thierry@herbelot.com> <200507161849.39012.thierry@herbelot.com> <20050716.105849.112624020.imp@bsdimp.com> In-Reply-To: <20050716.105849.112624020.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507161914.23682.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 16 Jul 2005 17:14:44 -0000 Le Saturday 16 July 2005 18:58, M. Warner Losh a écrit : > In message: <200507161849.39012.thierry@herbelot.com> > > Thierry Herbelot writes: > : Hello, > : > : Le Saturday 16 July 2005 18:27, M. Warner Losh a écrit : > : > Is the ed card in the system at boot? > : > : Yes, the card is always plugged-in (the notebook is used as a kind of > : tinderbox) - should I try and extract and replug it ? > > Yes. Please try that. ASAP > Also, do you have ed compiled into the kernel > or are you using a module? it's in the kernel : a straight, simple GENERIC. > > Warner TfH From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:21:58 2005 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 BF0A316A41F; Sat, 16 Jul 2005 17:21:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A8A443D49; Sat, 16 Jul 2005 17:21:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GHLVKu031137; Sat, 16 Jul 2005 11:21:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 11:22:14 -0600 (MDT) Message-Id: <20050716.112214.77059285.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> References: <42D82D59.9060605@root.org> <20050716.103028.04060625.imp@bsdimp.com> <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 17:21:58 -0000 In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> Harry Coin writes: : 1) Document a way or make an OS change to make certain non-pnp isa probe : routines are never called any time while pnp isa resources haven't been put : to sleep. They arne't. The CARDS are put to sleep. However, PNPBIOS devices can't be put to sleep, in general. PCI resources aren't put to sleep. Your probe routine should, in the non-pnp case, only be looking at the hinted resources for that device. : So that these probe routines will only be called after the : field is clear and they can rummage around the register space looking for probe routines aren't supposed to do that. Probe routines are supposed to answer the question 'Is this hardware at the specified location.' identify routines are allowed to go looking, but even they are supposed to only look at 'alternative enumeration techniques' rather than 'probing through the address space'. Such probing was banished in FreeBSD 3.0. : their chips -- and they don't accidentally find compatible PCI versions : previously or yet to be found by their PCI probe modern driver cousins. The : isa part of the architecture manual ought to be updated to reflect how : properly to do this. Where is this manual of which you speak? I'd sure like to change it to be right. : (Are there cases where the non-pnp routines being : called in the acpi context pass the currently iffy pnp-gate and find and : enable operations of pnp chips that the pnp-routines don't have in their : 'acceptable id' list? My hunch in the sound chip world is 'yes'. So this : fix might break audio on systems that don't have the pnp ids in the pnp : soundchip ISA_PROBE roster as yet.) I don't understand what you are suggesting here. : 2) change non-pnp isa drivers to do as the architecture manual currently : suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list : then continue only if no pnp id for the device). I don't understand this either. Please be more specific. I'm coming to the conversation late. : 3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then : update the architecture manual for isa drivers and also the isa drivers : themselves. I've already said that this isn't needed, and likely indicates some abuse of the model. I suspect that the abuse is that the probe routine bogusly goes and looks for resources not assigned to it in the hopes of finding hardware. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:24:54 2005 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 392C216A41C for ; Sat, 16 Jul 2005 17:24:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5B1D43D46 for ; Sat, 16 Jul 2005 17:24:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GHNT1f031167; Sat, 16 Jul 2005 11:23:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 11:24:11 -0600 (MDT) Message-Id: <20050716.112411.52164710.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200507161914.23682.thierry@herbelot.com> References: <200507161849.39012.thierry@herbelot.com> <20050716.105849.112624020.imp@bsdimp.com> <200507161914.23682.thierry@herbelot.com> 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: loss of PCMCIA ed(4) interface 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, 16 Jul 2005 17:24:54 -0000 In message: <200507161914.23682.thierry@herbelot.com> Thierry Herbelot writes: : > Also, do you have ed compiled into the kernel : > or are you using a module? : : it's in the kernel : a straight, simple GENERIC. OK. I always use modules. I'll see if something is broken with generic. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:25:16 2005 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 8168716A41C for ; Sat, 16 Jul 2005 17:25:16 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [84.234.16.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 114A343D45 for ; Sat, 16 Jul 2005 17:25:16 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.51 (FreeBSD)) id 1DtqPT-000EY8-MC for freebsd-current@freebsd.org; Sat, 16 Jul 2005 18:25:07 +0100 Date: Sat, 16 Jul 2005 18:25:07 +0100 From: Tim Bishop To: freebsd-current@freebsd.org Message-ID: <20050716172507.GA38651@carrick.bishnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.9i X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.514, required 5, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60, TW_BF 0.08, TW_EB 0.08, TW_KD 0.08, TW_XB 0.08, TW_XD 0.08) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net Subject: Panic on RELENG_6 (in kqueue?) 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, 16 Jul 2005 17:25:16 -0000 Had a crash on RELENG_6: Memory modified after free 0xc1db0800(1020) val=c22af3ac @ 0xc1db0b04 panic: Most recently used by kqueue cpuid = 0 KDB: enter: panic [thread pid 6939 tid 100087 ] Stopped at kdb_enter+0x2b: nop db> db> where Tracing pid 6939 tid 100087 td 0xc2190000 kdb_enter(c0854b84) at kdb_enter+0x2b panic(c086f463,c0851e37,c086f434,c1db0800,3fc) at panic+0x127 mtrash_ctor(c1db0800,400,0,1) at mtrash_ctor+0x4d uma_zalloc_arg(c105ac60,0,1) at uma_zalloc_arg+0x10f malloc(400,c08b6920,1,df653bcc,df653bf4) at malloc+0xae kqueue_expand(c2ddb500,c08b69e0,4,0) at kqueue_expand+0x69 kqueue_register(c2ddb500,df653bf4,c2190000,1,0) at kqueue_register+0x1b8 kern_kevent(c2190000,3,1,1,df653cc8) at kern_kevent+0xc9 kevent(c2190000,df653d04,6,11,296) at kevent+0x55 syscall(3b,3b,bfbf003b,bfbfb6a0,bfbfb688) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x28271d67, esp = 0xbfbfb5fc, ebp = 0xbfbfbcd8 --- Output from kgdb: kgdb: kvm_read: invalid address (0xc1bff900) kgdb: kvm_read: invalid address (0xc1bff780) kgdb: kvm_read: invalid address (0xc1bff600) kgdb: kvm_read: invalid address (0xc1bff480) kgdb: kvm_read: invalid address (0xc1bff300) kgdb: kvm_read: invalid address (0xc1bff180) kgdb: kvm_read: invalid address (0xc1bffd80) kgdb: kvm_read: invalid address (0xc1bffc00) kgdb: kvm_read: invalid address (0xc1bffa80) kgdb: kvm_read: invalid address (0xc1bff000) [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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:165 #1 0xc0468e13 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xdf653950 "|9eß,õ|Àh9eßl9eß\220\a") at /usr/src/sys/ddb/db_command.c:489 #2 0xc0468c18 in db_command (last_cmdp=0xc0902a84, cmd_table=0x0, aux_cmd_tablep=0xc0880068, aux_cmd_tablep_end=0xc0880084) at /usr/src/sys/ddb/db_command.c:349 #3 0xc0468ce0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc046a881 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0649a9c in kdb_trap (type=3, code=0, tf=0xdf653a94) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc07ec5fc in trap (frame= {tf_fs = -547028984, tf_es = -1067188184, tf_ds = -1065025496, tf_edi = -1064897437, tf_esi = 1, tf_ebp = -547013932, tf_isp = -547013952, tf_ebx = -547013888, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067149309, tf_cs = 32, tf_eflags = 662, tf_esp = -547013900, tf_ss = -1067246597}) at /usr/src/sys/i386/i386/trap.c:600 #7 0xc07da09a in calltrap () at /usr/src/sys/i386/i386/exception.s:137 #8 0xdf650008 in ?? () #9 0xc0640028 in link_elf_load_file (cls=0xc0854b84, filename=0x100
, result=0x0) at /usr/src/sys/kern/link_elf.c:640 #10 0xc0631bfb in panic (fmt=0x296
) at /usr/src/sys/kern/kern_shutdown.c:537 #11 0xc0780329 in mtrash_ctor (mem=0xc1db0800, size=0, arg=0x0, flags=1) at /usr/src/sys/vm/uma_dbg.c:138 #12 0xc077ec7f in uma_zalloc_arg (zone=0xc105ac60, udata=0x0, flags=1) at /usr/src/sys/vm/uma_core.c:1839 #13 0xc06283c2 in malloc (size=1024, mtp=0xc08b6920, flags=1) at uma.h:276 #14 0xc061954d in kqueue_expand (kq=0xc2ddb500, fops=0x0, ident=4, waitok=0) at /usr/src/sys/kern/kern_event.c:1047 #15 0xc0618d38 in kqueue_register (kq=0xc2ddb500, kev=0xdf653bf4, td=0xc2190000, waitok=1) at /usr/src/sys/kern/kern_event.c:790 #16 0xc06188a5 in kern_kevent (td=0xc2190000, fd=3, nchanges=1, nevents=1, k_ops=0xdf653cc8, timeout=0xdf653cc0) at /usr/src/sys/kern/kern_event.c:637 #17 0xc0618749 in kevent (td=0xc2190000, uap=0xdf653d04) at /usr/src/sys/kern/kern_event.c:571 #18 0xc07ecde7 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = -1078001605, tf_edi = -1077954912, tf_esi = -1077954936, tf_ebp = -1077953320, tf_isp = -547013276, tf_ebx = 674182372, tf_edx = 4, tf_ecx = 4, tf_eax = 363, tf_trapno = 0, tf_err = 2, tf_eip = 673652071, tf_cs = 51, tf_eflags = 662, tf_esp = -1077955076, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:985 #19 0xc07da0ef in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:198 #20 0x0000003b in ?? () #21 0x0000003b in ?? () #22 0xbfbf003b in ?? () #23 0xbfbfb6a0 in ?? () #24 0xbfbfb688 in ?? () #25 0xbfbfbcd8 in ?? () #26 0xdf653d64 in ?? () #27 0x282f34e4 in ?? () #28 0x00000004 in ?? () #29 0x00000004 in ?? () #30 0x0000016b in ?? () #31 0x00000000 in ?? () #32 0x00000002 in ?? () #33 0x28271d67 in ?? () #34 0x00000033 in ?? () #35 0x00000296 in ?? () #36 0xbfbfb5fc in ?? () #37 0x0000003b in ?? () #38 0xd0d0d0d0 in ?? () #39 0xd0d0d0d0 in ?? () #40 0xd0d0d0d0 in ?? () #41 0xd0d0d0d0 in ?? () #42 0x2726e000 in ?? () #43 0xc2197624 in ?? () #44 0xc2190000 in ?? () #45 0xdf653844 in ?? () #46 0xdf65382c in ?? () #47 0xc1bfe300 in ?? () #48 0xc0641fc3 in sched_switch (td=0xbfbfb688, newtd=0x282f34e4, flags=Cannot access memory at address 0xbfbfbce8 ) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) (kgdb) Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:30:56 2005 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 1F35416A41C for ; Sat, 16 Jul 2005 17:30:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B675643D45 for ; Sat, 16 Jul 2005 17:30:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GHUHBP031276; Sat, 16 Jul 2005 11:30:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 11:30:59 -0600 (MDT) Message-Id: <20050716.113059.82101301.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> References: <42D82D59.9060605@root.org> <20050716.103028.04060625.imp@bsdimp.com> <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 17:30:56 -0000 In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> Harry Coin writes: : I think all that's needed to wrap this up is for the powers that be to : offer clarity about one thing, final decision about the case of arbitrary : (beyond com1, etc.) non-pnp ISA devices probe routines. As far as I kow, there's nothing wrong with them. Please state the problem. They work and work well today. Without a clear problem statement, it is hard to know what you are complaining about. : A great many sound : chips of various register demands are in this list. (Admittedly older : devices, but I ran into serious breakage of an isa pnp device driver : because of interactions with the related non-pnp probe routine that : supported earlier chipsets in the same family that were largely register : compatible with the pnp versions). I just took a look at mss. I'm not at all sure what you are talking about. mss.c specifically doesn't probe devices that aren't PNP for its identify the device case. pnpmss does only pnp devices. The mss_probe routine won't look anywhere other than it has been specifically instructed to look by the hints mechanism. Can you be more specific about the exact breakage? Vague statements like the above don't convey the information that I need to help you solve your problem. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:30:59 2005 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 019E616A421 for ; Sat, 16 Jul 2005 17:30:59 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2075643D45 for ; Sat, 16 Jul 2005 17:30:57 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 96664 invoked by uid 89); 16 Jul 2005 17:30:30 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Jul 2005 17:30:30 -0000 Date: Sat, 16 Jul 2005 19:30:48 +0200 From: Oliver Lehmann To: Ariff Abdullah Message-Id: <20050716193048.1554ee90.lehmann@ans-netz.de> In-Reply-To: <20050717011220.2252a5b4.skywizard@MyBSD.org.my> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> <20050716234024.2d536b5a.skywizard@MyBSD.org.my> <20050716183331.5b972d3d.lehmann@ans-netz.de> <20050716183628.418fde56.lehmann@ans-netz.de> <20050717011220.2252a5b4.skywizard@MyBSD.org.my> X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 17:30:59 -0000 Ariff Abdullah wrote: > Try this: > > http://staff.mybsd.org.my/skywizard/FreeBSD/sound/incoming/ess.c.diff that fixed it! :) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:38:03 2005 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 CD3FD16A41C for ; Sat, 16 Jul 2005 17:38:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50AA743D46 for ; Sat, 16 Jul 2005 17:38:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 23385513BA; Sat, 16 Jul 2005 13:38:02 -0400 (EDT) Date: Sat, 16 Jul 2005 13:38:01 -0400 From: Kris Kennaway To: Nicolas Blais Message-ID: <20050716173801.GA29355@xor.obsecurity.org> References: <200507152021.47403.nb_root@videotron.ca> <200507152146.51668.nb_root@videotron.ca> <1121497558.61704.2.camel@renaissance.homeip.net> <200507161021.56248.nb_root@videotron.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <200507161021.56248.nb_root@videotron.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Latest cvsup to 7.0 causes mplayer to crash my system 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, 16 Jul 2005 17:38:03 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2005 at 10:21:50AM -0400, Nicolas Blais wrote: > > > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and = now > > > > whenever i try to play a movie with mplayer, my system crashes with= : > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address =3D 0x1c > > > > fault code =3D supervisor write, page not present > > > > instruction pointer =3D 0x20:0xc06a0bc3 > > > > stack pointer =3D 0x28:0xe502fc88 > > > > frame pointer =3D 0x28:0xe502fcc8 > > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > > current process =3D 28 (swi4: clock sio) > > > > trap number =3D 12 > > > > panic: page fault > > > > Uptime: 7m49s > > > > Dumping 1023 MB (2 chunks) > > > > chunk 0: 1MB (159 pages) ... ok > > > > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > > > > > > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8t= h so > > > > something in between breaks it. The crash message is always the sam= e. I > > > > tried recompiling mplayer which did no good. > > > > > > > > Please help, > > > > Nicolas. > > > > > > If this is any help to anyone: > > > > > > [nicblais] ~> nm -n /boot/kernel/* | grep c06a0 > > > c06a0120 T kern_setitimer > > > c06a0470 T setitimer > > > c06a0510 T clock_gettime > > > c06a0730 T ratecheck > > > c06a07b0 T ppsratecheck > > > c06a0830 T kern_timeout_callwheel_alloc > > > c06a08a0 T callout_init > > > c06a08f0 T kern_timeout_callwheel_init > > > c06a09f0 T softclock > > > c06a0ee0 T callout_reset >=20 > I've tried on SCHED_4BSD and ULE both causes the same trap. Here's more i= nfo=20 > (copied from a digital cam shot, since I can't seem to save the output of= =20 > kgdb) Run kgdb under script(1) Kris --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2UX5Wry0BWjoQKURAkWcAJ0WqBUgJRwleDRYbuhB9YxC4/OizACguAVX /erDpPi9Y+eobYH5zGdRRAg= =zHCD -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:38:57 2005 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 E9F7C16A41C for ; Sat, 16 Jul 2005 17:38:57 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (duke.voidnetwork.com [202.157.186.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B0343D48 for ; Sat, 16 Jul 2005 17:38:57 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 9C67A6CC5B; Sun, 17 Jul 2005 01:44:55 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (duke.voidnetwork.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31878-02; Sun, 17 Jul 2005 01:44:53 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [60.48.108.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 8E9006CC57; Sun, 17 Jul 2005 01:44:52 +0800 (MYT) Date: Sun, 17 Jul 2005 01:39:20 +0800 From: Ariff Abdullah To: Oliver Lehmann Message-Id: <20050717013920.7c5b5882.skywizard@MyBSD.org.my> In-Reply-To: <20050716193048.1554ee90.lehmann@ans-netz.de> References: <20050716155736.29fe63c4.lehmann@ans-netz.de> <20050716221807.21176fa5.skywizard@MyBSD.org.my> <20050716165616.4d859842.lehmann@ans-netz.de> <20050716234024.2d536b5a.skywizard@MyBSD.org.my> <20050716183331.5b972d3d.lehmann@ans-netz.de> <20050716183628.418fde56.lehmann@ans-netz.de> <20050717011220.2252a5b4.skywizard@MyBSD.org.my> <20050716193048.1554ee90.lehmann@ans-netz.de> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: freebsd-current@freebsd.org, mat@cnd.mcgill.ca Subject: Re: LOR - sound.c:869 - 6.0 - using snd_HEAD_20050714_009.diff 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, 16 Jul 2005 17:38:58 -0000 On Sat, 16 Jul 2005 19:30:48 +0200 Oliver Lehmann wrote: > Ariff Abdullah wrote: > > > Try this: > > > > http://staff.mybsd.org.my/skywizard/FreeBSD/sound/incoming/ess.c.diff > > that fixed it! :) > Good :) Oo my.. looks like there are few other places within isa need to be fixed as well :) -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 17:40:01 2005 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 B6E0816A41C for ; Sat, 16 Jul 2005 17:40:01 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76EE443D53 for ; Sat, 16 Jul 2005 17:39:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6BA5B51522; Sat, 16 Jul 2005 13:39:57 -0400 (EDT) Date: Sat, 16 Jul 2005 13:39:56 -0400 From: Kris Kennaway To: Tim Bishop Message-ID: <20050716173956.GB29355@xor.obsecurity.org> References: <20050716172507.GA38651@carrick.bishnet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <20050716172507.GA38651@carrick.bishnet.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Panic on RELENG_6 (in kqueue?) 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, 16 Jul 2005 17:40:01 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2005 at 06:25:07PM +0100, Tim Bishop wrote: > Had a crash on RELENG_6: >=20 > Memory modified after free 0xc1db0800(1020) val=3Dc22af3ac @ 0xc1db0b04 > panic: Most recently used by kqueue Configure DEBUG_MEMGUARD with the M_KQUEUE malloc type and it will panic when the error occurs, not some time later when it is difficult to diagnose. Kris --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2UZsWry0BWjoQKURAjj7AJ9CwntrmfTjlPUxE8TuqHSNMF+CcwCgxnhv JJkQoVkgnmZ5nAdYh9yG6Lc= =bbFX -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 18:04:59 2005 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 8659616A41C for ; Sat, 16 Jul 2005 18:04:59 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id B879943D48 for ; Sat, 16 Jul 2005 18:04:58 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Sat, 16 Jul 2005 13:05:43 -0500 Message-Id: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Jul 2005 13:04:50 -0500 To: "M. Warner Losh" From: Harry Coin In-Reply-To: <20050716.113059.82101301.imp@bsdimp.com> References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <42D82D59.9060605@root.org> <20050716.103028.04060625.imp@bsdimp.com> <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 18:04:59 -0000 Warner, Thanks for engaging. Responses within. At 11:30 AM 7/16/2005 -0600, M. Warner Losh wrote: >In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> > Harry Coin writes: >: I think all that's needed to wrap this up is for the powers that be to >: offer clarity about one thing, final decision about the case of arbitrary >: (beyond com1, etc.) non-pnp ISA devices probe routines. > >As far as I kow, there's nothing wrong with them. Please state the >problem. They work and work well today. Without a clear problem >statement, it is hard to know what you are complaining about. There is significant comment upstream, and certainly a significant issue that didn't work at all today, nor in the past (many unanswered bugs relating to 'attach returned 6' and soundcards in the freebsd history). The issue arose in mss.c that has both a pnp and a non pnp probe routine for drives that share other routines. >: A great many sound >: chips of various register demands are in this list. (Admittedly older >: devices, but I ran into serious breakage of an isa pnp device driver >: because of interactions with the related non-pnp probe routine that >: supported earlier chipsets in the same family that were largely register >: compatible with the pnp versions). > >I just took a look at mss. I'm not at all sure what you are talking >about. mss.c specifically doesn't probe devices that aren't PNP for >its identify the device case. pnpmss does only pnp devices. The >mss_probe routine won't look anywhere other than it has been >specifically instructed to look by the hints mechanism. > >Can you be more specific about the exact breakage? Vague statements >like the above don't convey the information that I need to help you >solve your problem. There is extensive comment upstream, I hesitate to repeat it all. The short story is that from the freebsd architecture manual on the subect we have: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html ...That means that absolutely every driver, even the ones not supporting any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table to return failure on unknown PnP devices.... is violated in mss_probe, which uses another way to detect whether a device is pnp and so avoid the non pnp probe. That alternate call fails in the case the bus parent is acpi, causing mss_probe to succeed, mss_attach to fail, the pcmx count to ratchet up x, and then, depending, you get a pcm3 without a pcm0, pcm1 or pcm2 if the isa bus probes eventually find it. John was dismayed by this because the alternate way is employed in many isa drivers. John Baldwin has offered that the architecture manuals suggestion is not a good course to follow for elegance reasons. However if mss_probe is changed to employ that the problem goes away. John discovered a tension in the OS calls related to the various detection alternatives and ACPI. He also suggested removing the mss routines from the acpi class, which too avoided the problem on the system that I have, but may or may not cause breakage with other systems. In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> Harry Coin writes: : 1) Document a way or make an OS change to make certain non-pnp isa probe : routines are never called any time while pnp isa resources haven't been put : to sleep. They arne't. The CARDS are put to sleep. However, PNPBIOS devices can't be put to sleep, in general. PCI resources aren't put to sleep. Your probe routine should, in the non-pnp case, only be looking at the hinted resources for that device. Thank you. I should have been more clear. I'm aware of this. The driver in question is the mss.c which indeed has a mss_probe non pnp routine called, and which succeeds, with acpi as a parent -- which when the following attach call is made fails. Extensive documentation is upstream. : So that these probe routines will only be called after the : field is clear and they can rummage around the register space looking for probe routines aren't supposed to do that. Probe routines are supposed to answer the question 'Is this hardware at the specified location.' identify routines are allowed to go looking, but even they are supposed to only look at 'alternative enumeration techniques' rather than 'probing through the address space'. Such probing was banished in FreeBSD 3.0. mss.c's non pnp probe routine seems to rather crowd the above. It isn't my routine per se. I am adding support for CS4236B to work as an audio source (the included code fails to adjust the mixer properly. While I'm at it I'm exposing the various resources of the chip in mode 3, allowing for different record and playback rates and formats, and clearly knowable amplification settings throughout the audio path in and out.) : their chips -- and they don't accidentally find compatible PCI versions : previously or yet to be found by their PCI probe modern driver cousins. The : isa part of the architecture manual ought to be updated to reflect how : properly to do this. Where is this manual of which you speak? I'd sure like to change it to be right. Certainly: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html ...That means that absolutely every driver, even the ones not supporting any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table to return failure on unknown PnP devices.... : (Are there cases where the non-pnp routines being : called in the acpi context pass the currently iffy pnp-gate and find and : enable operations of pnp chips that the pnp-routines don't have in their : 'acceptable id' list? My hunch in the sound chip world is 'yes'. So this : fix might break audio on systems that don't have the pnp ids in the pnp : soundchip ISA_PROBE roster as yet.) I don't understand what you are suggesting here. My thought is, if the current roster of non pnp isa drivers is not to be touched, then the OS ought to avoid to call their probe routines unless the pnp cards are all sleeping whether by acpi or whatever. Also it is my experience that there are quite a good many sound chips out there that are pnp but are not in the roster of pnp devices in the pnp mss detect driver. The current setup will allow these devices to be probed and to operate (maybe not as pcm0) via the non-pnp detect routine called from the acpi. A lucky side effect that helps some folk but which will go away if this issue is cleaned up I fear. : 2) change non-pnp isa drivers to do as the architecture manual currently : suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list : then continue only if no pnp id for the device). I don't understand this either. Please be more specific. I'm coming to the conversation late. Never fear, there is extensive dmesg and dialogue on freebsd-current , this subject line upstream. : 3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then : update the architecture manual for isa drivers and also the isa drivers : themselves. I've already said that this isn't needed, and likely indicates some abuse of the model. I suspect that the abuse is that the probe routine bogusly goes and looks for resources not assigned to it in the hopes of finding hardware. Warner That is part of the problem, yes. Hope this helps Harry From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 18:54:58 2005 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 EA09216A41C for ; Sat, 16 Jul 2005 18:54:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B47243D46 for ; Sat, 16 Jul 2005 18:54:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GIqjpf031820; Sat, 16 Jul 2005 12:52:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 12:53:27 -0600 (MDT) Message-Id: <20050716.125327.85414312.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 18:54:58 -0000 In message: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> Harry Coin writes: : Warner, : : Thanks for engaging. Responses within. : : At 11:30 AM 7/16/2005 -0600, M. Warner Losh wrote: : >In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> : > Harry Coin writes: : >: I think all that's needed to wrap this up is for the powers that be to : >: offer clarity about one thing, final decision about the case of arbitrary : >: (beyond com1, etc.) non-pnp ISA devices probe routines. : > : >As far as I kow, there's nothing wrong with them. Please state the : >problem. They work and work well today. Without a clear problem : >statement, it is hard to know what you are complaining about. : : There is significant comment upstream, and certainly a significant issue : that didn't work at all today, nor in the past (many unanswered bugs : relating to 'attach returned 6' and soundcards in the freebsd : history). The issue arose in mss.c that has both a pnp and a non pnp probe : routine for drives that share other routines. ??? : There is extensive comment upstream, I hesitate to repeat it all. The : short story is that from the freebsd architecture manual on the subect we : have: : http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html : ...That means that absolutely every driver, even the ones not supporting : any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID : table to return failure on unknown PnP devices.... No. That's not true. They can call isa_get_logicalid() and return if it is not zero. For example, sn: static int sn_isa_probe (device_t dev) { if (isa_get_logicalid(dev)) /* skip PnP probes */ return (ENXIO); if (sn_probe(dev) != 0) return (ENXIO); return (0); } This has always been the way. The isa-driver-config.html is mistaken if it says otherwise. This has been the recommended way to avoid pnp probes since 3.0 (I know I've added it to a bunch of drivers). : is violated in mss_probe, which uses another way to detect whether a device : is pnp and so avoid the non pnp probe. That alternate call fails in the : case the bus parent is acpi, causing mss_probe to succeed, mss_attach to : fail, the pcmx count to ratchet up x, and then, depending, you get a pcm3 : without a pcm0, pcm1 or pcm2 if the isa bus probes eventually find : it. John was dismayed by this because the alternate way is employed in : many isa drivers. John's misremembering things. This has always been the case. ACPI should return non-zero always (since it has no non-pnp devices). ACPI is at fault here, for not returning PNP information that it has. If it is trying to 'cheat' by using the 'isa' attachments, then it has to follow the old isa rules. Looking at mss.c, mss_probe shouldn't be called in the acpi case. There's no 'acpi' attachment for it Why is it being called at all? : John Baldwin has offered that the architecture manuals suggestion is not a : good course to follow for elegance reasons. However if mss_probe is : changed to employ that the problem goes away. John discovered a tension in : the OS calls related to the various detection alternatives and ACPI. He : also suggested removing the mss routines from the acpi class, which too : avoided the problem on the system that I have, but may or may not cause : breakage with other systems. I think this points out a fundamental problem. Can you send me devinfo -v for your machine and/or a dmesg (or a pointer to the message that has it in it)? mss_probe should only be called for isa bus, and it should only make it pass its resource allocation if you have mss hints in your /boot/device.hints. If acpi is behaving otherwise, then that's an acpi bug. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:00:58 2005 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 D68D616A41C for ; Sat, 16 Jul 2005 19:00:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68C4143D4C for ; Sat, 16 Jul 2005 19:00:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GIvgSx031877; Sat, 16 Jul 2005 12:57:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 12:58:24 -0600 (MDT) Message-Id: <20050716.125824.48530425.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 19:00:59 -0000 : dmesg excerpt ... : mss_probe: bus acpi0 is probing device pcm0 : mss_probe: isa_get_logicalid() returned 0! This is the problem. It shouldn't be probing there. It doesn't in current. Chances are John beat me to it and we're arguing over something that's been fixed... Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:13:19 2005 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 C09FE16A41C for ; Sat, 16 Jul 2005 19:13:19 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D7443D91 for ; Sat, 16 Jul 2005 19:13:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GJAYLI031986; Sat, 16 Jul 2005 13:10:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 13:11:17 -0600 (MDT) Message-Id: <20050716.131117.23013098.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 19:13:19 -0000 In message: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> Harry Coin writes: : Thank you. I should have been more clear. I'm aware of this. The driver : in question is the mss.c which indeed has a mss_probe non pnp routine : called, and which succeeds, with acpi as a parent -- which when the : following attach call is made fails. Extensive documentation is upstream. Yes. Just read the thread. Please delete the line that John suggests, as has already been committed to current. If there are PNP ids we need to add to the pnp probe, we should add those and not kludge around it. : My thought is, if the current roster of non pnp isa drivers is not to be : touched, then the OS ought to avoid to call their probe routines unless the : pnp cards are all sleeping whether by acpi or whatever. Also it is my : experience that there are quite a good many sound chips out there that are : pnp but are not in the roster of pnp devices in the pnp mss detect : driver. The current setup will allow these devices to be probed and to : operate (maybe not as pcm0) via the non-pnp detect routine called from the : acpi. A lucky side effect that helps some folk but which will go away if : this issue is cleaned up I fear. Ummm, that's not the way things should work. Sorry to disappoint you, but John and I are telling you the same thing: don't have acpi attachments that use isa_get_logicalid(). I've taken a look at the other drivers. gusc and esscontrol seem to also have this problem. Of course, we should also fix the ACPI layer to do the right thing. The right thing here is for isa_get_logicalid() to always return non-zero because, by definition, all acpi devices have logical ids. That's the real bug here, and the rest of your observations are downstream effects that aren't important. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:18:44 2005 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 D919116A41C for ; Sat, 16 Jul 2005 19:18:44 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52BC843D46 for ; Sat, 16 Jul 2005 19:18:44 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Sat, 16 Jul 2005 14:19:29 -0500 Message-Id: <4.3.2.7.2.20050716141708.01f5f930@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Jul 2005 14:18:36 -0500 To: "M. Warner Losh" From: Harry Coin In-Reply-To: <20050716.131117.23013098.imp@bsdimp.com> References: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 19:18:45 -0000 Warner, Seems you've got it all surrounded, save for this I didn't see a comment upon: We have: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html ...That means that absolutely every driver, even the ones not supporting any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table to return failure on unknown PnP devices.... Which is not the case in mss.c and from John's comments many other non-pnp isa drivers. Seems a project to either fix the doc or the drivers. Harry From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:18:59 2005 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 E546316A41F for ; Sat, 16 Jul 2005 19:18:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F9843D48 for ; Sat, 16 Jul 2005 19:18:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GJGIOp032108; Sat, 16 Jul 2005 13:16:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 13:17:01 -0600 (MDT) Message-Id: <20050716.131701.124866666.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <20050716.125824.48530425.imp@bsdimp.com> References: <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.125824.48530425.imp@bsdimp.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 19:19:00 -0000 Nate writes: > I really think the driver is broken and the API is fine for this. I > don't like the hack of returning a random CID for checks against the > HID. Drivers down the road may come to rely on this and then every BIOS > that has a different order for CIDs becomes a potential breakage point. They alredy do rely on this. When they support pnp, they call the ISA_PNP_PROBE routine. When they don't then your observation doesn't matter because the order of the IDs doesn't matter: their non-zeroness does. > Drivers should not rely on isa_get_logicalid() to determine a boolean > "is PNP?" Actually, that's the interface. We have to follow it, even if you think it is stupid. It is how we do things. When we don't have a logicalid, we return 0. When drivers don't support pnp devices, it uses the existance of a non-zero pnpid to know the device isn't for them. It has been this way since 3.0. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:45:59 2005 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 0FD4D16A41C for ; Sat, 16 Jul 2005 19:45:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C0D43D48 for ; Sat, 16 Jul 2005 19:45:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GJid5D032315; Sat, 16 Jul 2005 13:44:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 13:45:22 -0600 (MDT) Message-Id: <20050716.134522.98715551.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716141708.01f5f930@mail.qconline.com> References: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.131117.23013098.imp@bsdimp.com> <4.3.2.7.2.20050716141708.01f5f930@mail.qconline.com> 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, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up 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, 16 Jul 2005 19:45:59 -0000 In message: <4.3.2.7.2.20050716141708.01f5f930@mail.qconline.com> Harry Coin writes: : Warner, : : Seems you've got it all surrounded, save for this I didn't see a comment upon: : : We have: : http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html : ...That means that absolutely every driver, even the ones not supporting : any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID : table to return failure on unknown PnP devices.... : : Which is not the case in mss.c and from John's comments many other non-pnp : isa drivers. Seems a project to either fix the doc or the drivers. I'll go fix the docs. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 20:16:12 2005 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 C5CFC16A41C for ; Sat, 16 Jul 2005 20:16:12 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E0543D46 for ; Sat, 16 Jul 2005 20:16:12 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so797577wra for ; Sat, 16 Jul 2005 13:16:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IvAIo02VC4h6cHQLbYWhB4boC3QxkZ95gN5foQNm0G0dWFbRHZlDSGsqJmlDDtmpSDoHJRBEdHS4BRx/Re0Q/KiODB8ZZqYnDn0dPBZNzmZSpzgQYajfRFs+jTjmIR60oNSHSJfYNIVQqXoc8qQxcbdH+BHYCZdh+fjxEHDCBHE= Received: by 10.54.57.46 with SMTP id f46mr1486302wra; Sat, 16 Jul 2005 13:16:11 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Sat, 16 Jul 2005 13:16:11 -0700 (PDT) Message-ID: <47d0403c050716131672b1d382@mail.gmail.com> Date: Sat, 16 Jul 2005 20:16:11 +0000 From: Ben Kaduk To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: kernel build procedure for 5.4->6.0Beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 20:16:12 -0000 List -- I am in the process of upgrading via source build from 5.4-Release to 6.0Beta, and I am curious about a discrepancy in the kernel build procedure. The handbook has as a normal build procedure for a regular update to "make buildkernel; make installkernel", whereas UPDATING has just "make kernel". UPDATING, of course, has precedence, as stated in the handbook, but I am curious what (if any) difference there is in the two procedures, and why different procedures are preferred for these (seemingly similar) situations. Can anyone enlighten me? Thanks Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 20:21:24 2005 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 8E30D16A41C for ; Sat, 16 Jul 2005 20:21:24 +0000 (GMT) (envelope-from rehsack@liwing.de) Received: from moby.liwing.de (www.liwing.de [82.97.68.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47C5B43D45 for ; Sat, 16 Jul 2005 20:21:23 +0000 (GMT) (envelope-from rehsack@liwing.de) Received: from [80.64.176.27] (helo=[10.62.10.4]) by moby.liwing.de with esmtp (Exim 4.50 (FreeBSD)) id 1DttDJ-0009wH-2g for current@freebsd.org; Sat, 16 Jul 2005 20:24:47 +0000 Message-ID: <42D96DCC.9020803@liwing.de> Date: Sat, 16 Jul 2005 20:27:56 +0000 From: Jens Rehsack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050713) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------000302080100030703090408" Cc: Subject: Help needed: Problems get Acer 4401LMi running perfect ... 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, 16 Jul 2005 20:21:24 -0000 This is a multi-part message in MIME format. --------------000302080100030703090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've bought a new notebook - an Acer Travelmate 4401LMi. Most things run fine with RELENG_6, but some things makes still trouble. - The ATI Radeon X700 PCI Express is not detected (not supported?) I've compiled drm and radeondrm into the kernel, but it seems not recognized. - The on-board sound-chip and the on-board wlan isn't detected/supported - Gnome didn't startup well - ACPI shows some mysterious error messages that spam's the kernel log ;) - USB Mouse must be plugged after boot finished to get recognized (Keyboard works fine) - The video-mode in X can't be set to 1400x1050 I know, this is not the place to discuss all problems, but I don't want to cross-post into to many lists. So I hope to solve the problems from the system up to the applications may help get solutions for higher level problems faster. My questions (bootstrapping myself ^^): - How can I check if/why the graphic card isn't supported by the kernel/X11? - How can I check which sound driver is build in and what can be done to support it? - Which kind of problem may prevent the usb-mouse detected during boot-up? (I think usbd didn't find it) - What can be done to stop the acpi system (except disabling acpi) spamming the kernel log? I attach the dmesg, verbose dmesg, kernel conf and pciconf -lv. Thanks for any hint in advance. Best regards, Jens --------------000302080100030703090408 Content-Type: text/plain; name="KERMIT" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="KERMIT" # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.421.2.13 2005/05/10 22:45:14 anholt Exp $ machine amd64 cpu HAMMER ident KERMIT #device mptable # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options MSDOSFS_LARGE options MSDOSFS_ICONV options CD9660 # ISO 9660 Filesystem options CD9660_ICONV options UDF options UDF_ICONV options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_LINUX32 # Compatible with i386 linux binaries options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150) device atpic # 8259A compatability options IPI_PREEMPTION device mptable # Enabling NO_MIXED_MODE gives a performance improvement on some motherboards # but does not work with some boards (mostly nVidia chipset based). #options NO_MIXED_MODE # Don't penalize working chipsets # Linux 32-bit ABI support options LINPROCFS # Cannot be a module yet. options LIBICONV options TTYHOG=8193 options PREEMPTION # Debugging for use in -current options DDB #Enable the DDB Backend options KDB #Enable the kernel debugger options KDB_TRACE options BREAK_TO_DEBUGGER # options INVARIANTS #Enable calls of extra sanity checking # options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS # options WITNESS #Enable checks to detect deadlocks and cycles # options WITNESS_KDB #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed # options DIAGNOSTIC # Bus support. Do not remove isa, even if you have no isa slots device acpi device isa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device atapicam # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets device drm device radeondrm # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device re # RealTek 8139C+/8169/8169S/8110S # Wireless NIC cards device ath device ath_hal device ath_rate_onoe #device ath_rate_amrr #device ath_rate_sample device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device sound device smbus device viapm device nfpm device amdpm device iicsmb device smb device iicbus device iicbb # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) --------------000302080100030703090408 Content-Type: text/plain; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.boot" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #0: Fri Jul 15 22:38:58 UTC 2005 root@kermit.muppets.liwing.de:/usr/obj/usr/src/sys/KERMIT ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 Mobile Technology ML-28 (1600.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 1072300032 (1022 MB) avail memory = 1025826816 (978 MB) ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link1: irq 0 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 0 on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 6.0 on pci0 pci9: on pcib2 pcib3: at device 7.0 on pci0 pci4: on pcib3 ohci0: mem 0xc0000000-0xc0000fff irq 19 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: at device 19.2 (no driver attached) pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8410-0x841f irq 16 at device 20.1 on pci0 ata0: on atapci0 ata1: on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci6: on pcib4 pci6: at device 5.0 (no driver attached) cbb0: at device 6.0 on pci6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xc0208000-0xc02087ff,0xc0200000-0xc0203fff irq 22 at device 6.2 on pci6 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 12:34:56:78:12:34:56:78 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 12:34:56:34:56:78 fwe0: Ethernet address: 12:34:56:34:56:78 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci6: at device 6.3 (no driver attached) pci6: at device 6.4 (no driver attached) re0: port 0xa000-0xa0ff mem 0xc0209400-0xc02094ff irq 23 at device 7.0 on pci6 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:0a:e4:e1:00:fa pci0: at device 20.5 (no driver attached) pci0: at device 20.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0 port 0x2f8-0x2ff irq 3 drq 3 flags 0x10 on acpi0 sio0: type 16550A acpi_cmbat0: on acpi0 ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE acpi_acad0: on acpi0 orm0: at iomem 0xdc000-0xdffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1600011243 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA33 acd0: DVDR at ata1-master UDMA33 ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZS0._TMP] (Node 0xffffff000000d480), AE_NO_HARDWARE_RESPONSE Trying to mount root from ufs:/dev/ad0s1a ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZS1._TMP] (Node 0xffffff000000d200), AE_NO_HARDWARE_RESPONSE ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZSV._TMP] (Node 0xffffff00008ae180), AE_NO_HARDWARE_RESPONSE ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZSV._TMP] (Node 0xffffff00008ae180), AE_NO_HARDWARE_RESPONSE ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZSV._TMP] (Node 0xffffff00008ae180), AE_NO_HARDWARE_RESPONSE ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZSV._TMP] (Node 0xffffff00008ae180), AE_NO_HARDWARE_RESPONSE --------------000302080100030703090408 Content-Type: text/plain; name="dmesg.full" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.full" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #0: Fri Jul 15 22:38:58 UTC 2005 root@kermit.muppets.liwing.de:/usr/obj/usr/src/sys/KERMIT Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8079a000. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193179 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1600010552 Hz CPU: AMD Turion(tm) 64 Mobile Technology ML-28 (1600.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 1072300032 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000897000 - 0x000000003e069fff, 1031614464 bytes (251859 pages) avail memory = 1025826816 (978 MB) APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 21 ioapic0: intpin 9 disabled ioapic0: intpin 21 trigger: level ioapic0: intpin 21 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ath_rate: wlan: <802.11 Link Layer> mem: null: nfslock: pseudo-device random: io:
ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a104 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=59501002) AcpiOsDerivePciId: bus 0 dev 20 func 1 AcpiOsDerivePciId: bus 4 dev 0 func 0 acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: irq 0 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: irq 0 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: irq 0 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: irq 0 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: irq 0 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: irq 0 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: irq 0 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: info: new max delay is 11000 us acpi_ec0: info: new max delay is 101000 us acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1002, dev=0x5950, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a34, revid=0x00 bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a39, revid=0x00 bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4374, revid=0x00 bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type 1, range 32, base c0000000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4375, revid=0x00 bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type 1, range 32, base c0001000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4373, revid=0x00 bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0013, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base c0002000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4372, revid=0x11 bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00008400, size 4, enabled map[14]: type 1, range 32, base c0003000, size 10, enabled found-> vendor=0x1002, dev=0x4376, revid=0x00 bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 MSI supports 1 message map[20]: type 4, range 32, base 00008410, size 4, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4377, revid=0x00 bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4371, revid=0x00 bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4370, revid=0x02 bus=0, slot=20, func=5 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 MSI supports 1 message map[10]: type 1, range 32, base c0003400, size 8, enabled pcib0: matched entry for 0.20.INTB pcib0: slot 20 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4378, revid=0x02 bus=0, slot=20, func=6 class=07-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 MSI supports 1 message map[10]: type 1, range 32, base c0003800, size 8, enabled pcib0: matched entry for 0.20.INTB pcib0: slot 20 INTB hardwired to IRQ 17 found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 2.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x9000-0x9fff pcib1: memory decode 0xc0100000-0xc01fffff pcib1: prefetched decode 0xc8000000-0xcfffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x5653, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 3, range 32, base c8000000, size 27, enabled pcib1: (null) requested memory range 0xc8000000-0xcfffffff: good map[14]: type 4, range 32, base 00009000, size 8, enabled pcib1: (null) requested I/O range 0x9000-0x90ff: in range map[18]: type 1, range 32, base c0100000, size 16, enabled pcib1: (null) requested memory range 0xc0100000-0xc010ffff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 pci1: at device 0.0 (no driver attached) pcib2: at device 7.0 on pci0 pcib2: secondary bus 4 pcib2: subordinate bus 5 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0x0-0x0 pcib2: prefetched decode 0x0-0x0 pci4: on pcib2 pci4: physical bus=4 ohci0: mem 0xc0000000-0xc0000fff irq 19 at device 19.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0000000 ohci0: (New OHCI DeviceId=0x43741002) ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0001000 ohci1: (New OHCI DeviceId=0x43751002) ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: at device 19.2 (no driver attached) pci0:19:2: Transition from D0 to D3 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8410-0x841f irq 16 at device 20.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8410 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: secondary bus 6 pcib3: subordinate bus 6 pcib3: I/O decode 0xa000-0xafff pcib3: memory decode 0xc0200000-0xc02fffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. pci6: on pcib3 pci6: physical bus=6 found-> vendor=0x14e4, dev=0x4318, revid=0x02 bus=6, slot=5, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 1, range 32, base c0204000, size 13, enabled pcib3: (null) requested memory range 0xc0204000-0xc0205fff: good pcib3: matched entry for 6.5.INTA pcib3: slot 5 INTA hardwired to IRQ 21 found-> vendor=0x104c, dev=0x8031, revid=0x00 bus=6, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0x8032, revid=0x00 bus=6, slot=6, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=c, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base c0208000, size 11, enabled pcib3: (null) requested memory range 0xc0208000-0xc02087ff: good map[14]: type 1, range 32, base c0200000, size 14, enabled pcib3: (null) requested memory range 0xc0200000-0xc0203fff: good pcib3: matched entry for 6.6.INTC pcib3: slot 6 INTC hardwired to IRQ 22 found-> vendor=0x104c, dev=0x8033, revid=0x00 bus=6, slot=6, func=3 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base c0206000, size 13, enabled pcib3: (null) requested memory range 0xc0206000-0xc0207fff: good pcib3: matched entry for 6.6.INTA pcib3: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8034, revid=0x00 bus=6, slot=6, func=4 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base c0209000, size 8, enabled pcib3: (null) requested memory range 0xc0209000-0xc02090ff: good map[14]: type 1, range 32, base c0208c00, size 8, enabled pcib3: (null) requested memory range 0xc0208c00-0xc0208cff: good map[18]: type 1, range 32, base c0208800, size 8, enabled pcib3: (null) requested memory range 0xc0208800-0xc02088ff: good pcib3: matched entry for 6.6.INTA pcib3: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x10ec, dev=0x8169, revid=0x10 bus=6, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 8, enabled pcib3: (null) requested I/O range 0xa000-0xa0ff: in range map[14]: type 1, range 32, base c0209400, size 8, enabled pcib3: (null) requested memory range 0xc0209400-0xc02094ff: good pcib3: matched entry for 6.7.INTA pcib3: slot 7 INTA hardwired to IRQ 23 pci6: at device 5.0 (no driver attached) cbb0: at device 6.0 on pci6 pcib3: cbb0 requested memory range 0xc0200000-0xc02fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xc020a000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib3: matched entry for 6.6.INTA pcib3: slot 6 INTA hardwired to IRQ 20 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x8031104c 0x02100007 0x06070000 0x00824010 0x10: 0xc020a000 0x020000a0 0x20080706 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400114 0x40: 0x00801025 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d061 0x02920019 0x001f0000 0x010a1b22 0x90: 0x606402c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=104c, dev=8032 fwohci0: vendor=104c, dev=8032 fwohci0: <1394 Open Host Controller Interface> mem 0xc0208000-0xc02087ff,0xc0200000-0xc0203fff irq 22 at device 6.2 on pci6 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xc0208000 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 12:34:56:78:12:34:56:78 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 12:34:56:34:56:78 fwe0: bpf attached fwe0: Ethernet address: 12:34:56:34:56:78 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci6: at device 6.3 (no driver attached) pci6:6:3: Transition from D0 to D3 pci6: at device 6.4 (no driver attached) re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xa000 pcib3: re0 requested I/O range 0xa000-0xa0ff: in range pcib3: re0 requested I/O range 0xa000-0xa0ff: in range pcib3: re0 requested I/O range 0xa000-0xa0ff: in range pcib3: re0 requested I/O range 0xa000-0xa0ff: in range pcib3: re0 requested I/O range 0xa000-0xa0ff: in range re0: port 0xa000-0xa0ff mem 0xc0209400-0xc02094ff irq 23 at device 7.0 on pci6 pcib3: re0 requested I/O range 0xa000-0xa0ff: in range miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:0a:e4:e1:00:fa re0: [MPSAFE] pci0: at device 20.5 (no driver attached) pci0: at device 20.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x9 0x1 0x1 sio0 port 0x2f8-0x2ff irq 3 drq 3 flags 0x10 on acpi0 sio0: type 16550A acpi_cmbat0: on acpi0 acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00008d7dc0), AE_NO_HARDWARE_RESPONSE acpi_acad0: on acpi0 atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xdc000-0xdffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered linprocfs registered lapic: Divisor 2, Frequency 100000419 hz Timecounter "TSC" frequency 1600010552 Hz quality 800 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached acpi_cmbat0: battery initialization start acpi_acad0: acline initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: 76319MB at ata0-master UDMA33 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM unknown (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZS1._TMP] (Node 0xffffff000000d200), AE_NO_HARDWARE_RESPONSE acpi_tz1: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\\_TZ_.TZSV._TMP] (Node 0xffffff00008ae180), AE_NO_HARDWARE_RESPONSE acpi_tz2: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE --------------000302080100030703090408 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf.txt" hostb0@pci0:0:0: class=0x060000 card=0x00801025 chip=0x59501002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' class = bridge subclass = HOST-PCI pcib1@pci0:2:0: class=0x060400 card=0x00000050 chip=0x5a341002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' class = bridge subclass = PCI-PCI pcib2@pci0:6:0: class=0x060400 card=0x00000050 chip=0x5a381002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' class = bridge subclass = PCI-PCI pcib3@pci0:7:0: class=0x060400 card=0x00000050 chip=0x5a391002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' class = bridge subclass = PCI-PCI ohci0@pci0:19:0: class=0x0c0310 card=0x00801025 chip=0x43741002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = serial bus subclass = USB ohci1@pci0:19:1: class=0x0c0310 card=0x00801025 chip=0x43751002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = serial bus subclass = USB none0@pci0:19:2: class=0x0c0320 card=0x00801025 chip=0x43731002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = serial bus subclass = USB none1@pci0:20:0: class=0x0c0500 card=0x00801025 chip=0x43721002 rev=0x11 hdr=0x00 vendor = 'ATI Technologies Inc' class = serial bus subclass = SMBus atapci0@pci0:20:1: class=0x01018a card=0x00801025 chip=0x43761002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = mass storage subclass = ATA isab0@pci0:20:3: class=0x060100 card=0x00801025 chip=0x43771002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = bridge subclass = PCI-ISA pcib4@pci0:20:4: class=0x060401 card=0x00000000 chip=0x43711002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' class = bridge subclass = PCI-PCI none2@pci0:20:5: class=0x040100 card=0x00791025 chip=0x43701002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' class = multimedia subclass = audio none3@pci0:20:6: class=0x070300 card=0x00801025 chip=0x43781002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' class = simple comms subclass = generic modem hostb1@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI none4@pci1:0:0: class=0x030000 card=0x00801025 chip=0x56531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'MOBILITY RADEON X700' class = display subclass = VGA none5@pci6:5:0: class=0x028000 card=0x03111468 chip=0x431814e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' class = network cbb0@pci6:6:0: class=0x060700 card=0x00801025 chip=0x8031104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' class = bridge subclass = PCI-CardBus fwohci0@pci6:6:2: class=0x0c0010 card=0x00801025 chip=0x8032104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' class = serial bus subclass = FireWire none6@pci6:6:3: class=0x018000 card=0x00801025 chip=0x8033104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCIxx21 Integrated FlashMedia Controller' class = mass storage none7@pci6:6:4: class=0x080500 card=0x00801025 chip=0x8034104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' class = base peripheral re0@pci6:7:0: class=0x020000 card=0x00791025 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class = network subclass = ethernet --------------000302080100030703090408-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 22:31:09 2005 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 0CDE116A41C for ; Sat, 16 Jul 2005 22:31:09 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1659D43D45 for ; Sat, 16 Jul 2005 22:31:07 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j6GMihGW087643 for ; Sat, 16 Jul 2005 22:44:43 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j6GMihlG087642 for freebsd-current@freebsd.org; Sat, 16 Jul 2005 22:44:43 GMT (envelope-from dunstan) Date: Sat, 16 Jul 2005 22:44:43 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org Message-ID: <20050716224442.GA87607@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [LOR] kqueue() 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, 16 Jul 2005 22:31:09 -0000 Hello, Code needed to reproduce LOR I've expirienced is here: http://FreeBSD.czest.pl/dunstan/kqueuetest.c Compile: [1] gcc kqueuetest.c -o kqueuetest Run with shell's PID: [2] ./kqueuetest $$ [3] Suspend execution with CTRL^Z and move task to background: bg %1 Step [3] is not always needed. Tested on -CURRENT. /usr/src/sys/kern/kern_event.c: __FBSDID("$FreeBSD: src/sys/kern/kern_event.c,v 1.93 2005/07/01 16:28:30 ssouhlal Exp $"); Backtrace.. [..] (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04ad3d3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc04ad6d3 in panic (fmt=0xc0624a08 "mutex %s owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc04a5a10 in _mtx_assert (m=0xc2240100, what=0, file=0xc062200d "/usr/src/sys/kern/kern_event.c", line=1039) at /usr/src/sys/kern/kern_mutex.c:752 #4 0xc04925d2 in kqueue_expand (kq=0xc2240100, fops=0x0, ident=1155, waitok=0) at /usr/src/sys/kern/kern_event.c:1039 #5 0xc0492015 in kqueue_register (kq=0xc2240100, kev=0xd6c97c38, td=0x0, waitok=0) at /usr/src/sys/kern/kern_event.c:828 #6 0xc0491436 in filt_proc (kn=0xc1dc9a18, hint=0) at /usr/src/sys/kern/kern_event.c:413 #7 0xc049346c in knote (list=0xc20b1c80, hint=1073742979, islocked=1) at /usr/src/sys/kern/kern_event.c:1548 #8 0xc0497c07 in fork1 (td=0xc1ec9900, flags=20, pages=0, procp=0xd6c97cd4) at /usr/src/sys/kern/kern_fork.c:696 #9 0xc0496bf0 in fork (td=0xc1ec9900, uap=0xd6c97d04) at /usr/src/sys/kern/kern_fork.c:96 #10 0xc05f9a73 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 672035108, tf_esi = -1077941576, tf_ebp = -1077941768, tf_isp = -691438236, tf_ebx = 672067444, tf_edx = 672090288, tf_ecx = -1077941568, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 672757531, tf_cs = 51, tf_eflags = 642, tf_esp = -1077941796, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:986 #11 0xc05eaadf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0x0000003b in ?? () #15 0x280e7124 in ?? () #16 0xbfbfeab8 in ?? () #17 0xbfbfe9f8 in ?? () #18 0xd6c97d64 in ?? () #19 0x280eef74 in ?? () #20 0x280f48b0 in ?? () #21 0xbfbfeac0 in ?? () #22 0x00000002 in ?? () #23 0x0000000c in ?? () #24 0x00000002 in ?? () #25 0x2819771b in ?? () #26 0x00000033 in ?? () #27 0x00000282 in ?? () #28 0xbfbfe9dc in ?? () #29 0x0000003b in ?? () #30 0xd0d0d0d0 in ?? () #31 0xd0d0d0d0 in ?? () #32 0xd0d0d0d0 in ?? () #33 0xd0d0d0d0 in ?? () #34 0x15c43000 in ?? () #35 0xc20b1ab4 in ?? () #36 0xc1ec9900 in ?? () #37 0xd6c97940 in ?? () #38 0xd6c97928 in ?? () #39 0xc199c780 in ?? () #40 0xc04bdb8f in sched_switch (td=0xbfbfeab8, newtd=0x280eef74, flags=) at /usr/src/sys/kern/sched_4bsd.c:973 (kgdb) quit -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 22:43:04 2005 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 E96CB16A41C for ; Sat, 16 Jul 2005 22:43:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C21B43D45 for ; Sat, 16 Jul 2005 22:43:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GMdmHr010000; Sat, 16 Jul 2005 16:39:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 16:40:31 -0600 (MDT) Message-Id: <20050716.164031.87741040.imp@bsdimp.com> To: minimarmot@gmail.com From: "M. Warner Losh" In-Reply-To: <47d0403c050716131672b1d382@mail.gmail.com> References: <47d0403c050716131672b1d382@mail.gmail.com> 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: kernel build procedure for 5.4->6.0Beta 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, 16 Jul 2005 22:43:05 -0000 In message: <47d0403c050716131672b1d382@mail.gmail.com> Ben Kaduk writes: : List -- I am in the process of upgrading via source build from : 5.4-Release to 6.0Beta, and I am curious about a discrepancy in the : kernel build procedure. The handbook : has as a normal build procedure for a regular update to "make : buildkernel; make installkernel", whereas UPDATING has just "make : kernel". UPDATING, of course, has precedence, as stated in the : handbook, but I am curious what (if any) difference : there is in the two procedures, and why different procedures are : preferred for these (seemingly similar) situations. : Can anyone enlighten me? make kernel is the same thing as make buildkernel installkernel. UPDATING likely got changed after this was noiced, but the handbook didn't. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 23:56:03 2005 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 1027316A41F for ; Sat, 16 Jul 2005 23:56:03 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCCFD43D49 for ; Sat, 16 Jul 2005 23:56:01 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id EA00C8C1D8 for ; Sun, 17 Jul 2005 01:55:58 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 02122-07 for ; Sun, 17 Jul 2005 01:55:54 +0200 (CEST) Received: from [192.168.0.4] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 5E0E78C1D6 for ; Sun, 17 Jul 2005 01:55:53 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: freebsd-current@freebsd.org Date: Sun, 17 Jul 2005 01:57:03 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Q7Z2Cy0LBX/oUI4" Message-Id: <200507170157.04718.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Requests for information/possible donation endpoint. 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, 16 Jul 2005 23:56:03 -0000 --Boundary-00=_Q7Z2Cy0LBX/oUI4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I have recently installed FreeBSD-6.0-BETA on my TOshiba TECRA 900 Laptop. So far it has been running 5.4 but i decided to give the new beta a shot. I'ts quite snappy, and the cpufreq is very nice indeed, together with the passive_cooling patch. However, some things are reluctant to comply - refusing to work most likely due to lack of drivers. The following things are: * Internal most likely win-modem inside of the Toshiba TECRA 900 * SD secure-digital compact flash card-reader drive in the Toshiba * Savage3d drm module (savage.ko) for 3d DRM in X.org in the kernel Also, I dont want to sound "linuxy" here, but it could be nice with a way that ata bus drivers could inform userland programs somehow when the tray of a cd/dvd has closed - so it would be possible to automount stuff like cd's upon closure of tray, and perhaphs upon the pressing of the eject button, automatic unmounts if the medium is not currently used by any process. Has any of the above been ever concidered/thought about during the building of 6.0? It would be great to see Fbsd bloom fully on this laptop, but the lack of drivers is a real pity over certain things. I below attach pciconf -vl info and a brief dmesg. If anyone would find it interesting to help out, I ofcourse provide any further possible debug output that would be required. I would happily donate my money/time for the development of these requests, preferably the first. Cheers, /m. --Boundary-00=_Q7Z2Cy0LBX/oUI4--