From giovanni.trematerra at gmail.com Sat Aug 1 02:43:15 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Sat Aug 1 02:43:21 2009 Subject: [PATCH] Newbus locking In-Reply-To: <200907311919.26913.hselasky@c2i.net> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311818.08481.hselasky@c2i.net> <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com> <200907311919.26913.hselasky@c2i.net> Message-ID: <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> > On Fri, Jul 31, 2009 at 7:19 PM, Hans Petter Selasky wrote: > > I'm not saying that your approach will not work or that it is wrong. I'm > saying that it is not fast enough. Your patch affects the boottime, in a > negative way. > I tested a patch for a while. I didn't notice any slow down in boot time. Well, I haven't measured it but I can't see any noticeable difference even booting from an USB key. I have to be honest, I don't understand the patch but any comments on performance without an evident profiling seems to me a "premature optimization" that is known to be the root of all devils (D. Knuth) -- Giovanni Trematerra From amdmi3 at amdmi3.ru Sat Aug 1 02:53:53 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Sat Aug 1 02:54:08 2009 Subject: panic in ipfw with recent current Message-ID: <20090801022523.GA93222@hades.panopticon> Hi! Just updated to recent current (date=2009.07.30.12.00.00), and had a panic in ipfw with minimal network activity (one time the box was able to get IP via DHCP and panicked on ssh to another host, next time it panicked right while booting). Rebuilding the kernel with nooptions IPFIREWALL works nice as a workaround. Full text available here: http://people.freebsd.org/~amdmi3/ipfw-panic.txt (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04c0049 in db_fncall (dummy1=1, dummy2=0, dummy3=-1059813280, dummy4=0xe58e0558 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04c042e in db_command (last_cmdp=0xc0ca72bc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04c0567 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04c223f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc088922e in kdb_trap (type=12, code=0, tf=0xe58e0784) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc0aea4c6 in trap_fatal (frame=0xe58e0784, eva=28) at /usr/src/sys/i386/i386/trap.c:924 #7 0xc0aea75a in trap_pfault (frame=0xe58e0784, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:846 #8 0xc0aeb137 in trap (frame=0xe58e0784) at /usr/src/sys/i386/i386/trap.c:528 #9 0xc0acf71b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc5f80c1c in ipfw_chk (args=0xe58e0a3c) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:2061 #11 0xc5f815c3 in ipfw_check_in (arg=0x0, m0=0xe58e0b70, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw_pfil.c:135 #12 0xc090a071 in pfil_run_hooks (ph=0xc0ceec20, mp=0xe58e0bc4, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:79 #13 0xc095c93d in ip_input (m=0xc5dcfe00) at /usr/src/sys/netinet/ip_input.c:497 #14 0xc09094f3 in netisr_dispatch_src (proto=1, source=0, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:917 #15 0xc09097a4 in netisr_dispatch (proto=1, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:1004 #16 0xc09031a0 in ether_demux (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:896 #17 0xc09036a2 in ether_input (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:755 #18 0xc053de29 in ale_int_task (arg=0xc55fd000, pending=1) at /usr/src/sys/dev/ale/if_ale.c:2581 #19 0xc089409f in taskqueue_run (queue=0xc574dd00) at /usr/src/sys/kern/subr_taskqueue.c:282 #20 0xc089428d in taskqueue_thread_loop (arg=0xc55fda2c) at /usr/src/sys/kern/subr_taskqueue.c:403 #21 0xc08350a9 in fork_exit (callout=0xc08941d4 , arg=0xc55fda2c, frame=0xe58e0d38) at /usr/src/sys/kern/kern_fork.c:838 #22 0xc0acf790 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From hselasky at c2i.net Sat Aug 1 04:30:28 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Aug 1 04:30:36 2009 Subject: [PATCH] Newbus locking In-Reply-To: <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311919.26913.hselasky@c2i.net> <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> Message-ID: <200908010630.21366.hselasky@c2i.net> On Saturday 01 August 2009 04:17:42 Giovanni Trematerra wrote: > > On Fri, Jul 31, 2009 at 7:19 PM, Hans Petter Selasky > > wrote: > > > > > > I'm not saying that your approach will not work or that it is wrong. I'm > > saying that it is not fast enough. Your patch affects the boottime, in a > > negative way. > > I tested a patch for a while. I didn't notice any slow down in boot time. > Well, I haven't measured it but I can't see any noticeable difference > even booting from an USB key. Hi, We are talking about some seconds. Store the "ticks" varible in "usb_attach()" in sys/dev/usb/controller/usb_controller.c and print out the difference every time "usb_bus_explore()" is called having "if (bus->bus_roothold != NULL)". Different motherboards have different number of ports. Some have just two ports others have seven or more. The boot time is after the proposed newbus lock patch, proportional to the total number of ports including HUBs. I'm gone for the weekend and back on Sunday evening. No e-mails will be answered until then. Attilio: Your newbus_lock() must be moved into usb_probe_and_attach(), and maybe in usb_suspend_resume(). newbus_lock() should be locked always after "udev->default_sx + 1" in usb_device.c. "udev->default_sx + 1" is the lock protecting enumeration on a per-device level. Try on a usb device: usbconfig -u XXX -a YYY set_config 255 Then: usbconfig -u XXX -a YYY set_config 0 And I think you will have a prompt panic, because the newbus lock is not locked. > > I have to be honest, I don't understand the patch but any comments on > performance without an evident profiling seems to me a > "premature optimization" that is known to be the root of all devils (D. > Knuth) BTW: Why do none of the device_get_xxx() functions not have newbus lock assertions in them? --HPS From serenity at exscape.org Sat Aug 1 10:57:39 2009 From: serenity at exscape.org (Thomas Backman) Date: Sat Aug 1 10:57:52 2009 Subject: Samba + ZFS panic w/ DEBUG_VFS_LOCKS Message-ID: <4B49A2A0-2437-48A4-9047-80267BD4148F@exscape.org> I just installed samba (ports/net/samba3) on my test machine to see if some simple media streaming from ZFS would work. It did not; smbd didn't even start before it panicked... At "Starting smdb" I got the following panic: (Note: I haven't tried without DEBUG_VFS_LOCKS yet. I do suppose that it's not supposed to panic even with rigorous debugging enabled, though!) Unread portion of the kernel message buffer: KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a vfs_badlock() at vfs_badlock+0x95 assert_vop_elocked() at assert_vop_elocked+0x64 VOP_PUTPAGES_APV() at VOP_PUTPAGES_APV+0x5b vnode_pager_putpages() at vnode_pager_putpages+0xa9 vm_pageout_flush() at vm_pageout_flush+0xd1 vm_object_page_collect_flush() at vm_object_page_collect_flush+0x2f0 vm_object_page_clean() at vm_object_page_clean+0x143 fsync() at fsync+0x121 syscall() at syscall+0x28f Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (95, FreeBSD ELF64, fsync), rip = 0x801064dac, rsp = 0x7fffffffe5d8, rbp = 0x801336480 --- VOP_PUTPAGES: 0xffffff0007649588 is not exclusive locked but should be KDB: enter: lock violation 0xffffff0007649588: tag zfs, type VREG usecount 2, writecount 1, refcount 3 mountedhere 0 flags (VI_OBJDIRTY) v_object 0xffffff000ee6c000 ref 1 pages 2 lock type zfs: SHARED (count 1) panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 17h10m52s Physical memory: 2034 MB Dumping 1723 MB: ... at /usr/src/sys/amd64/amd64/trap.c:613 #9 0xffffffff8057eda7 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #10 0xffffffff8036c8ad in kdb_enter (why=0xffffffff80613fd5 "vfslock", msg=0xa
) at cpufunc.h:63 #11 0xffffffff803cb3a4 in assert_vop_elocked (vp=0xffffff0007649588, str=0xffffffff80642728 "VOP_PUTPAGES") at /usr/src/sys/kern/vfs_subr.c:3722 #12 0xffffffff805c80eb in VOP_PUTPAGES_APV (vop=0xffffffff807a07c0, a=0xffffff803eb72730) at vnode_if.c:2664 #13 0xffffffff80572cd9 in vnode_pager_putpages (object=0xffffff000ee6c000, m=0xffffff803eb72830, count=8192, sync=12, rtvals=0xffffff803eb727a0) at vnode_if.h:1169 #14 0xffffffff8056d601 in vm_pageout_flush (mc=0xffffff803eb72830, count=2, flags=12) at vm_pager.h:148 #15 0xffffffff80568e30 in vm_object_page_collect_flush ( object=0xffffff000ee6c000, p=Variable "p" is not available. ) at /usr/src/sys/vm/vm_object.c:1032 #16 0xffffffff80569023 in vm_object_page_clean (object=0xffffff000ee6c000, start=0, end=Variable "end" is not available. ) at /usr/src/sys/vm/vm_object.c:844 #17 0xffffffff803d3bd1 in fsync (td=0xffffff0027f45000, uap=Variable "uap" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:3519#18 0xffffffff80598e7f in syscall (frame=0xffffff803eb72c80) at /usr/src/sys/amd64/amd64/ trap.c:984#19 0xffffffff8057f081 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #20 0x0000000801064dac in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xffffffff803cb3a4 in assert_vop_elocked (vp=0xffffff0007649588, str=0xffffffff80642728 "VOP_PUTPAGES") at /usr/src/sys/kern/vfs_subr.c:3722 3722 vfs_badlock("is not exclusive locked but should be", str, vp); (kgdb) p *vp $1 = {v_type = VREG, v_tag = 0xffffffff80b59327 "zfs", v_op = 0xffffffff80b5dee0, v_data = 0xffffff00052cb758, v_mount = 0xffffff00018392f0, v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0xffffff006895b028}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = { lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xffffff00076495e8}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff80b59327 "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0x0}, lk_lock = 17, lk_timo = 51, lk_pri = 80}, v_interlock = {lock_object = { lo_name = 0xffffffff80614670 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock = 0xffffff0007649620, v_holdcnt = 3, v_usecount = 2, v_iflag = 1024, v_vflag = 0, v_writecount = 1, v_freelist = { tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff80614680 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff00076496c0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff00076496e0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff8079d620, bo_bsize = 131072, bo_object = 0xffffff000ee6c000, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff0007649588, __bo_vnode = 0xffffff0007649588}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0xffffff000d402600} (kgdb) fr 17 #17 0xffffffff803d3bd1 in fsync (td=0xffffff0027f45000, uap=Variable "uap" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:3519 3519 vn_finished_write(mp); (kgdb) p *mp $2 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80613905 "struct mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next = 0xffffff0001bf75e0, tqe_prev = 0xffffff0001839608}, mnt_op = 0xffffffff80b5de40, mnt_vfc = 0xffffffff80b5dde0, mnt_vnodecovered = 0xffffff0001ae6000, mnt_syncer = 0xffffff0001be2760, mnt_ref = 14897, mnt_nvnodelist = { tqh_first = 0xffffff0001be2b10, tqh_last = 0xffffff00076495b0}, mnt_nvnodelistsize = 7449, mnt_writeopcount = 1, mnt_kern_flag = 1610612864, mnt_flag = 268439552, mnt_xflag = 0, mnt_noasync = 0, mnt_opt = 0xffffff00017f1830, mnt_optnew = 0x0, mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = 4, f_flags = 268439552, f_bsize = 131072, f_iosize = 131072, f_blocks = 485196, f_bfree = 475793, f_bavail = 475793, f_files = 529171, f_ffree = 475793, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {591198578, -1876274428}}, f_charspare = '\0' , f_fstypename = "zfs", '\0' , f_mntfromname = "tank/usr", '\0' , f_mntonname = "/usr", '\0' }, mnt_cred = 0xffffff0001be0e00, mnt_data = 0xffffff0001a89000, mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 2610436692, mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { lock_object = {lo_name = 0xffffffff80613916 "explock", lo_flags = 91422720, lo_data = 0, lo_witness = 0x0}, lk_lock = 1, lk_timo = 0, lk_pri = 80}} # uname -a FreeBSD chaos.exscape.org 8.0-BETA2 FreeBSD 8.0-BETA2 #7 r195910M: Thu Jul 30 19:03:33 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/src/ sys/DTRACE amd64 As I said, DEBUG_VFS_LOCKS in enabled. Should I disabled DEBUG_VFS_LOCKS and consider this "normal" (if it doesn't still panic, that is), or is this a real issue? (Note that while *mp points to /usr, FWIW, /usr is not shared by samba, nor is any FS below it. Also note that my debugging skills are at an early stage... so the info provided may be useless.) Regards, Thomas From attilio at freebsd.org Sat Aug 1 12:12:03 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 1 12:12:09 2009 Subject: [PATCH] Newbus locking In-Reply-To: <200908010630.21366.hselasky@c2i.net> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311919.26913.hselasky@c2i.net> <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> <200908010630.21366.hselasky@c2i.net> Message-ID: <3bbf2fe10908010512j6aa02d9bk7a99f0f31ae313b2@mail.gmail.com> 2009/8/1 Hans Petter Selasky : > > Attilio: Your newbus_lock() must be moved into usb_probe_and_attach(), and > maybe in usb_suspend_resume(). newbus_lock() should be locked always after > "udev->default_sx + 1" in usb_device.c. "udev->default_sx + 1" is the lock > protecting enumeration on a per-device level. Try on a usb device: > > usbconfig -u XXX -a YYY set_config 255 > > Then: > > usbconfig -u XXX -a YYY set_config 0 > > And I think you will have a prompt panic, because the newbus lock is not > locked. Nice catch, pho just reported that to me. I'm going to fix it now. Thanks. > BTW: Why do none of the device_get_xxx() functions not have newbus lock > assertions in them? Because not all the device_get_ functions need to be locked. Generally the context alredy provide correct locking for them. Attilio -- Peace can only be achieved by understanding - A. Einstein From kostikbel at gmail.com Sat Aug 1 14:53:11 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 1 14:53:24 2009 Subject: Samba + ZFS panic w/ DEBUG_VFS_LOCKS In-Reply-To: <4B49A2A0-2437-48A4-9047-80267BD4148F@exscape.org> References: <4B49A2A0-2437-48A4-9047-80267BD4148F@exscape.org> Message-ID: <20090801145301.GE1884@deviant.kiev.zoral.com.ua> On Sat, Aug 01, 2009 at 12:57:29PM +0200, Thomas Backman wrote: > I just installed samba (ports/net/samba3) on my test machine to see if > some simple media streaming from ZFS would work. It did not; smbd > didn't even start before it panicked... At "Starting smdb" I got the > following panic: > > (Note: I haven't tried without DEBUG_VFS_LOCKS yet. I do suppose that > it's not supposed to panic even with rigorous debugging enabled, > though!) > > Unread portion of the kernel message buffer: > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > vfs_badlock() at vfs_badlock+0x95 > assert_vop_elocked() at assert_vop_elocked+0x64 > VOP_PUTPAGES_APV() at VOP_PUTPAGES_APV+0x5b > vnode_pager_putpages() at vnode_pager_putpages+0xa9 > vm_pageout_flush() at vm_pageout_flush+0xd1 > vm_object_page_collect_flush() at vm_object_page_collect_flush+0x2f0 > vm_object_page_clean() at vm_object_page_clean+0x143 > fsync() at fsync+0x121 > syscall() at syscall+0x28f > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (95, FreeBSD ELF64, fsync), rip = 0x801064dac, rsp = > 0x7fffffffe5d8, rbp = 0x801336480 --- > VOP_PUTPAGES: 0xffffff0007649588 is not exclusive locked but should be > KDB: enter: lock violation > > 0xffffff0007649588: tag zfs, type VREG > usecount 2, writecount 1, refcount 3 mountedhere 0 > flags (VI_OBJDIRTY) > v_object 0xffffff000ee6c000 ref 1 pages 2 > lock type zfs: SHARED (count 1) > panic: from debugger > cpuid = 0 > KDB: stack backtrace: > Uptime: 17h10m52s > Physical memory: 2034 MB > Dumping 1723 MB: ... > > at /usr/src/sys/amd64/amd64/trap.c:613 > #9 0xffffffff8057eda7 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #10 0xffffffff8036c8ad in kdb_enter (why=0xffffffff80613fd5 "vfslock", > msg=0xa
) at cpufunc.h:63 > #11 0xffffffff803cb3a4 in assert_vop_elocked (vp=0xffffff0007649588, > str=0xffffffff80642728 "VOP_PUTPAGES") > at /usr/src/sys/kern/vfs_subr.c:3722 > #12 0xffffffff805c80eb in VOP_PUTPAGES_APV (vop=0xffffffff807a07c0, > a=0xffffff803eb72730) at vnode_if.c:2664 > #13 0xffffffff80572cd9 in vnode_pager_putpages > (object=0xffffff000ee6c000, > m=0xffffff803eb72830, count=8192, sync=12, > rtvals=0xffffff803eb727a0) > at vnode_if.h:1169 > #14 0xffffffff8056d601 in vm_pageout_flush (mc=0xffffff803eb72830, > count=2, > flags=12) at vm_pager.h:148 > #15 0xffffffff80568e30 in vm_object_page_collect_flush ( > object=0xffffff000ee6c000, p=Variable "p" is not available. > ) at /usr/src/sys/vm/vm_object.c:1032 > #16 0xffffffff80569023 in vm_object_page_clean > (object=0xffffff000ee6c000, > start=0, end=Variable "end" is not available. > ) at /usr/src/sys/vm/vm_object.c:844 > #17 0xffffffff803d3bd1 in fsync (td=0xffffff0027f45000, uap=Variable > "uap" is not available. > ) > at /usr/src/sys/kern/vfs_syscalls.c:3519#18 0xffffffff80598e7f in > syscall (frame=0xffffff803eb72c80) at /usr/src/sys/amd64/amd64/ > trap.c:984#19 0xffffffff8057f081 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:373 > #20 0x0000000801064dac in ?? () > Previous frame inner to this frame (corrupt stack?) > > (kgdb) fr 11 > #11 0xffffffff803cb3a4 in assert_vop_elocked (vp=0xffffff0007649588, > str=0xffffffff80642728 "VOP_PUTPAGES") > at /usr/src/sys/kern/vfs_subr.c:3722 > 3722 vfs_badlock("is not exclusive locked but > should be", str, vp); > (kgdb) p *vp > $1 = {v_type = VREG, v_tag = 0xffffffff80b59327 "zfs", v_op = > 0xffffffff80b5dee0, v_data = 0xffffff00052cb758, > v_mount = 0xffffff00018392f0, v_nmntvnodes = {tqe_next = 0x0, > tqe_prev = 0xffffff006895b028}, v_un = {vu_mount = 0x0, vu_socket = 0x0, > vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = > {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = { > lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = > 0xffffff00076495e8}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, > v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = > 0xffffffff80b59327 "zfs", lo_flags = 91947008, lo_data = 0, > lo_witness = 0x0}, lk_lock = 17, lk_timo = 51, lk_pri = 80}, > v_interlock = {lock_object = { > lo_name = 0xffffffff80614670 "vnode interlock", lo_flags = > 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, > v_vnlock = 0xffffff0007649620, v_holdcnt = 3, v_usecount = 2, > v_iflag = 1024, v_vflag = 0, v_writecount = 1, v_freelist = { > tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = > {lock_object = {lo_name = 0xffffffff80614680 "bufobj interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock > = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, > tqh_last = 0xffffff00076496c0}, bv_root = 0x0, bv_cnt = 0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff00076496e0}, > bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > bo_ops = 0xffffffff8079d620, bo_bsize = 131072, > bo_object = 0xffffff000ee6c000, bo_synclist = {le_next = 0x0, > le_prev = 0x0}, bo_private = 0xffffff0007649588, > __bo_vnode = 0xffffff0007649588}, v_pollinfo = 0x0, v_label = > 0x0, v_lockf = 0xffffff000d402600} > > (kgdb) fr 17 > #17 0xffffffff803d3bd1 in fsync (td=0xffffff0027f45000, uap=Variable > "uap" is not available. > ) at /usr/src/sys/kern/vfs_syscalls.c:3519 > 3519 vn_finished_write(mp); > (kgdb) p *mp > $2 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80613905 "struct > mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, > mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next = > 0xffffff0001bf75e0, tqe_prev = 0xffffff0001839608}, mnt_op = > 0xffffffff80b5de40, > mnt_vfc = 0xffffffff80b5dde0, mnt_vnodecovered = > 0xffffff0001ae6000, mnt_syncer = 0xffffff0001be2760, mnt_ref = 14897, > mnt_nvnodelist = { > tqh_first = 0xffffff0001be2b10, tqh_last = 0xffffff00076495b0}, > mnt_nvnodelistsize = 7449, mnt_writeopcount = 1, > mnt_kern_flag = 1610612864, mnt_flag = 268439552, mnt_xflag = 0, > mnt_noasync = 0, mnt_opt = 0xffffff00017f1830, mnt_optnew = 0x0, > mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = > 4, f_flags = 268439552, f_bsize = 131072, f_iosize = 131072, > f_blocks = 485196, f_bfree = 475793, f_bavail = 475793, f_files = > 529171, f_ffree = 475793, f_syncwrites = 0, f_asyncwrites = 0, > f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, > 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {591198578, > -1876274428}}, f_charspare = '\0' , > f_fstypename = "zfs", '\0' , > f_mntfromname = "tank/usr", '\0' , f_mntonname > = "/usr", '\0' }, mnt_cred = 0xffffff0001be0e00, > mnt_data = 0xffffff0001a89000, mnt_time = 0, mnt_iosize_max = > 65536, mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 2610436692, > mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites > = 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = { > lock_object = {lo_name = 0xffffffff80613916 "explock", lo_flags = > 91422720, lo_data = 0, lo_witness = 0x0}, lk_lock = 1, lk_timo = 0, > lk_pri = 80}} > > # uname -a > FreeBSD chaos.exscape.org 8.0-BETA2 FreeBSD 8.0-BETA2 #7 r195910M: Thu > Jul 30 19:03:33 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/src/ > sys/DTRACE amd64 > > As I said, DEBUG_VFS_LOCKS in enabled. > Should I disabled DEBUG_VFS_LOCKS and consider this "normal" (if it > doesn't still panic, that is), or is this a real issue? > (Note that while *mp points to /usr, FWIW, /usr is not shared by > samba, nor is any FS below it. Also note that my debugging skills are > at an early stage... so the info provided may be useless.) It does not matter whether the zfs is accessed by samba. Panic happens when you do fsync(2) on a vnode that has its vm object marked as dirty, and VFS_DEBUG_LOCKS is configured. The workaround is to disable VFS_DEBUG_LOCKS. Since vnode_pager_generic_putpages seems to work with shared vnode lock as far as VOP_WRITE works right with shared lock, change sys/kern/vnode_if.src, line 475 from %% putpages vp E E E to %% putpages vp L L L -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090801/9d38d972/attachment.pgp From kientzle at freebsd.org Sat Aug 1 17:12:12 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Aug 1 17:12:18 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <4A72D946.4090401@jrv.org> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <20090729084723.GD1586@garage.freebsd.pl> <4A7030B6.8010205@icyb.net.ua> <97D5950F-4E4D-4446-AC22-92679135868D@exscape.org> <4A7048A9.4020507@icyb.net.ua> <52AA86CB-6C06-4370-BA73-CE19175467D0@exscape.org> <4A705299.8060504@icyb.net.ua> <4A7054E1.5060402@icyb.net.ua> <5918824D-A67C-43E6-8685-7B72A52B9CAE@exscape.org> <4A705E50.8070307@icyb.net.ua> <4A70728C.7020004@freebsd.org> <6D47A34B-0753-4CED-BF3D-C505B37748FC@exscape.org> <4A708455.5070304@freebsd.org> <86983A55-E5C4-4C04-A4C7-0AE9A9EE37A3@exscape.org> <4A718E03.6030909@freebsd.org> <71A038EC-02B1-4606-96C2-5E84BE80F005@exscape.org> <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org> <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B2DA.9060902@freebsd.org> <4A72D946.4090401@jrv.org> Message-ID: <4A747766.10901@freebsd.org> James R. Van Artsdalen wrote: > Andriy Gapon wrote: >> >> One comment on the patch - I personally don't like bit-wise xor in a logical >> expression. But if otherwise the expression would be huge and ugly, then OK. > > If you're going to code an XOR, use an XOR. Or != which produces the same result for logical values and is sometimes easier to understand. Tim From attilio at freebsd.org Sat Aug 1 18:34:58 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 1 18:35:04 2009 Subject: [PATCH] Newbus locking In-Reply-To: <200908010630.21366.hselasky@c2i.net> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311919.26913.hselasky@c2i.net> <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> <200908010630.21366.hselasky@c2i.net> Message-ID: <3bbf2fe10908011134h760f1c37y694acd8f37c120e6@mail.gmail.com> 2009/8/1 Hans Petter Selasky : > On Saturday 01 August 2009 04:17:42 Giovanni Trematerra wrote: >> > On Fri, Jul 31, 2009 at 7:19 PM, Hans Petter Selasky >> > wrote: >> > >> > >> > I'm not saying that your approach will not work or that it is wrong. I'm >> > saying that it is not fast enough. Your patch affects the boottime, in a >> > negative way. >> >> I tested a patch for a while. I didn't notice any slow down in boot time. >> Well, I haven't measured it but I can't see any noticeable difference >> even booting from an USB key. > > Hi, > > We are talking about some seconds. Store the "ticks" varible in "usb_attach()" > in sys/dev/usb/controller/usb_controller.c and print out the difference every > time "usb_bus_explore()" is called having "if (bus->bus_roothold != NULL)". So, thanks to the precious help of Peter Holm I worked on this patch fixing 3 problems reported by Peter and addressing the Hans' concern: now newbus lock is not held for the whole duration of explore handler, but just acquired and released when needed (really modifying the newbus subtree). I think it can also be faster than the Giant version now. New patch is here: http://www.freebsd.org/~attilio/Yahoo/newbus/newbus_locking4.diff Please let me know if you can note any regressions. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From kitchetech at gmail.com Sun Aug 2 01:40:37 2009 From: kitchetech at gmail.com (matt donovan) Date: Sun Aug 2 01:40:44 2009 Subject: latest svn kernel build seems to be broken Message-ID: <28283d910908011814y7838eedfica94021d65433566@mail.gmail.com> While trying to build the kernel modules I get the following error this is with svn co of 196027 ===> nfscommon (all) make: don't know how to make @/sys/vimage.h. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From julian at elischer.org Sun Aug 2 01:58:57 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 2 01:59:29 2009 Subject: latest svn kernel build seems to be broken Message-ID: <28283d910908011814y7838eedfica94021d65433566@mail.gmail.com> Probably need to clean out the directories. matt donovan wrote: >While trying to build the kernel modules I get the following error this is >with svn co of 196027 > >===> nfscommon (all) >make: don't know how to make @/sys/vimage.h. Stop >*** Error code 2 > >Stop in /usr/src/sys/modules. >*** Error code 1 > >Stop in /usr/obj/usr/src/sys/GENERIC. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >_______________________________________________ >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 fullermd at over-yonder.net Sun Aug 2 08:03:32 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Sun Aug 2 08:03:39 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907301706.n6UH6HrY047414@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200907301706.n6UH6HrY047414@lava.sentex.ca> Message-ID: <20090802074419.GA62454@over-yonder.net> For another datapoint. On Thu, Jul 30, 2009 at 01:09:09PM -0400 I heard the voice of Mike Tancsa, and lo! it spake thus: > Using HEAD from today (July 30) on an AMD64 kernel HEAD yesterday (Aug 1) on amd64 > ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 > chip=0x43911002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 SATA Controller [AHCI mode]' Same device, in an Asus M4A79 Deluxe board. ada0 at ahcich1 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 286168MB (586072368 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at ahcich2 bus 0 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 286168MB (586072368 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled cd0 at ahcich3 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers I haven't done any benchmarking, but it certainly doesn't feel any slower. And as a neat bonus, since my swap is glabel'd and all the filesystems are ZFS, I didn't have to touch anything for the device name changes :) I've hit two issues: 1) `camcontrol inquiry ada0` (inquiry, not identify) seems to lock the box down pretty hard (I haven't tried to reproduce, just did it once in single user, and eventually had to hit the BRS). "Don't Do That Then", and having done it once I know not to do it again, but a bit of a rough edge. 2) Audio CD stuff on the DVD drive gets cranky. - cdrecord doesn't seem to like it anymore. -scanbus says cdrecord: Inappropriate ioctl for device. CAMIOCOMMAND ioctl failed. Cannot open SCSI driver. - Using cdda2wav to try and rip an audio track using the cd0 device scrolls a lot of Sorry, this driver and/or drive does not support cdda reading. and such errors. Guessing the bus/id/lun from the devlist gives what I assume is the same ioctl error from above. This may well be a known and expected "haven't done that yet" of course. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From lists at jpru.de Sun Aug 2 09:27:18 2009 From: lists at jpru.de (Juergen Unger) Date: Sun Aug 2 09:27:32 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090729084723.GD1586@garage.freebsd.pl> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> Message-ID: <20090802092714.GA5813@jpru.ffm.jpru.de> Hi Pawel, On Wed, Jul 29, 2009 at 10:47:23AM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jul 28, 2009 at 12:50:26PM +0300, Andriy Gapon wrote: > > on 27/07/2009 22:58 O. Hartmann said the following: > > > Juergen Unger wrote: > > [snip] > > >>> _sx_xlock(3c,0,874aa28d,70f,8ae9a9f8,...) at _sx_xlock+0x43 > > >>> dmu_buf_update_user(0,8ae9a9f8,0,0,0,...) at dmu_buf_update_user+0x35 > > >>> zfs_znode_dmu_fini(8ae9a9f8,874b312d,1114,110b,879ab000,...) at zfs_znode_dmu_f3 > > >>> zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at zfs_freebsd_reclaim+0 > > >>> VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at VOP_RECLAIM_APV+0xa5 > > >>> vgonel(8ec637c8,0,80c77037,386,0,...) at vgonel+0x1a4 > > >>> vnlru_free(80f2a0f0,0,80c77037,300,3e8,...) at vnlru_free+0x2d5 > > >>> vnlru_proc(0,fcd29d38,80c652bc,33e,871932a8,...) at vnlru_proc+0x80 > > >>> fork_exit(8090d960,0,fcd29d38) at fork_exit+0xb8 > > >>> fork_trampoline() at fork_trampoline+0x8 >[snip] > > P.S. I see that zfs_inactive checks for z_dbuf being NULL and there is the > > following comment: > > /* > > * The fs has been unmounted, or we did a > > * suspend/resume and this file no longer exists. > > */ > > Maybe zfs_freebsd_reclaim should do the same? > > Yes, you might be right. > > Could you guys, who can reproduce it, try this patch: > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch I tried the patch, restarted the whole thing yesterday morning and after less then 24 hours and approximately 3215 zfs-receive jobs it do not crashes anymore, but the last started zfs-receive jobs is hanging, cannot be killed, even not with -9. Even other zfs commands are hanging and cannot be killed, while zpool commands seems to be not affected. root 86397 0.0 0.0 3920 1308 ?? D 3:18AM 0:00.29 zfs receive -Fv zzzz/203 root 5001 0.0 0.0 3920 1208 0 D+ 10:45AM 0:00.00 zfs list -t snapshot root 5477 0.0 0.0 3920 1240 3 D+ 11:08AM 0:00.00 zfs list also the sync command I tried to execute hangs forever: root 5457 0.0 0.0 1528 492 2- D+ 11:05AM 0:00.04 sync Other parts of the system which do not have something todo with zfs are still working well. I will leave the machine running in this state, is there something I can do to retrieve other usefull information for you? thnx in advance, Juergen -- ENOSIG From pjd at FreeBSD.org Sun Aug 2 09:30:01 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Aug 2 09:30:40 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090802092714.GA5813@jpru.ffm.jpru.de> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> Message-ID: <20090802093016.GB3071@garage.freebsd.pl> On Sun, Aug 02, 2009 at 11:27:14AM +0200, Juergen Unger wrote: > Hi Pawel, > > On Wed, Jul 29, 2009 at 10:47:23AM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Jul 28, 2009 at 12:50:26PM +0300, Andriy Gapon wrote: > > > on 27/07/2009 22:58 O. Hartmann said the following: > > > > Juergen Unger wrote: > > > [snip] > > > >>> _sx_xlock(3c,0,874aa28d,70f,8ae9a9f8,...) at _sx_xlock+0x43 > > > >>> dmu_buf_update_user(0,8ae9a9f8,0,0,0,...) at dmu_buf_update_user+0x35 > > > >>> zfs_znode_dmu_fini(8ae9a9f8,874b312d,1114,110b,879ab000,...) at zfs_znode_dmu_f3 > > > >>> zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at zfs_freebsd_reclaim+0 > > > >>> VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at VOP_RECLAIM_APV+0xa5 > > > >>> vgonel(8ec637c8,0,80c77037,386,0,...) at vgonel+0x1a4 > > > >>> vnlru_free(80f2a0f0,0,80c77037,300,3e8,...) at vnlru_free+0x2d5 > > > >>> vnlru_proc(0,fcd29d38,80c652bc,33e,871932a8,...) at vnlru_proc+0x80 > > > >>> fork_exit(8090d960,0,fcd29d38) at fork_exit+0xb8 > > > >>> fork_trampoline() at fork_trampoline+0x8 > >[snip] > > > P.S. I see that zfs_inactive checks for z_dbuf being NULL and there is the > > > following comment: > > > /* > > > * The fs has been unmounted, or we did a > > > * suspend/resume and this file no longer exists. > > > */ > > > Maybe zfs_freebsd_reclaim should do the same? > > > > Yes, you might be right. > > > > Could you guys, who can reproduce it, try this patch: > > > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch > > I tried the patch, restarted the whole thing yesterday morning > and after less then 24 hours and approximately 3215 zfs-receive > jobs it do not crashes anymore, but the last started zfs-receive > jobs is hanging, cannot be killed, even not with -9. Even other > zfs commands are hanging and cannot be killed, while zpool commands > seems to be not affected. > > root 86397 0.0 0.0 3920 1308 ?? D 3:18AM 0:00.29 zfs receive -Fv zzzz/203 > root 5001 0.0 0.0 3920 1208 0 D+ 10:45AM 0:00.00 zfs list -t snapshot > root 5477 0.0 0.0 3920 1240 3 D+ 11:08AM 0:00.00 zfs list > > also the sync command I tried to execute hangs forever: > > root 5457 0.0 0.0 1528 492 2- D+ 11:05AM 0:00.04 sync > > Other parts of the system which do not have something todo with zfs > are still working well. I will leave the machine running in this > state, is there something I can do to retrieve other usefull information > for you? If you can break into debugger and send me 'show alltrace' for starters. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/6f523d0e/attachment.pgp From julian at elischer.org Sun Aug 2 09:53:19 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 2 09:53:26 2009 Subject: puzzling code in pcpu stuff Message-ID: <4A756214.8010002@elischer.org> I simplified the output of the preprocessor for a PCPU_SET(xx, newval) (to look at it). I came down to: (after formatting) for i386.. { __typeof(((struct pcpu *)0)->pc_xx) __val; struct __s { u_char __b[(((sizeof(__val)) < (4)) ? (sizeof(__val)) : (4))]; } __s; __val = (newval); /* aligned */ if (sizeof(__val) == 1 || sizeof(__val) == 2 || sizeof(__val) == 4) { __s = *(struct __s *)(void *)&__val; __asm volatile("mov %1,%%fs:%0" : "=m" (*(struct __s *)(__builtin_offsetof( struct pcpu, pc_xx))) : "r" (__s)); } else { *__extension__ ( { __typeof(__val) *__p; __asm volatile("movl %%fs:%1,%0; addl %2,%0" : "=r" (__p) : "m" (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), "i" (__builtin_offsetof(struct pcpu, pc_xx))); __p; }) = __val; } } having had my brain explode on this several times, I can't figure out exactly what teh clause after the else is doing. anyone better at reading __asm better than me care to explain it in simple words? From fullermd at over-yonder.net Sun Aug 2 10:00:15 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Sun Aug 2 10:00:27 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4a755d11.YH68jo2T1j3qYokP%Joerg.Schilling@fokus.fraunhofer.de> References: <4a755d11.YH68jo2T1j3qYokP%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20090802100011.GB62454@over-yonder.net> On Sun, Aug 02, 2009 at 11:32:01AM +0200 I heard the voice of Joerg Schilling, and lo! it spake thus: > > Did someone iomplement a CAM driver that does not support the ioctl > for sending SCSI commands, or do you have different problems? Well, being as the failure is now that I upgraded and am using the CAM AHCI driver, and it worked before [via ATAPICAM], I'm guessing it's the former (hence posting it in the thread on that driver :). Though I guess there's always the chance that other -CURRENT changes since my last (early June) kernel ate it. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From julian at elischer.org Sun Aug 2 10:23:21 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 2 10:23:28 2009 Subject: possible readability improvement for i386 pcpu macros: Message-ID: <4A75691E.9070401@elischer.org> if you have to ever look at the output of the cpp then this removes a number of things you have to puzzle over in the output of PCPU_SET() and friends. I don't know if it applies to the other architectures. -------------- next part -------------- Index: include/pcpu.h =================================================================== --- include/pcpu.h (revision 196030) +++ include/pcpu.h (working copy) @@ -152,7 +152,7 @@ #define __PCPU_GET(name) __extension__ ({ \ __pcpu_type(name) __res; \ struct __s { \ - u_char __b[MIN(sizeof(__pcpu_type(name)), 4)]; \ + u_char __b[MIN(sizeof(__res), 4)]; \ } __s; \ \ if (sizeof(__res) == 1 || sizeof(__res) == 2 || \ @@ -174,7 +174,7 @@ #define __PCPU_ADD(name, val) do { \ __pcpu_type(name) __val; \ struct __s { \ - u_char __b[MIN(sizeof(__pcpu_type(name)), 4)]; \ + u_char __b[MIN(sizeof(__val), 4)]; \ } __s; \ \ __val = (val); \ @@ -217,7 +217,7 @@ #define __PCPU_SET(name, val) { \ __pcpu_type(name) __val; \ struct __s { \ - u_char __b[MIN(sizeof(__pcpu_type(name)), 4)]; \ + u_char __b[MIN(sizeof(__val), 4)]; \ } __s; \ \ __val = (val); \ From julian at elischer.org Sun Aug 2 10:25:59 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 2 10:26:05 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <4A756214.8010002@elischer.org> References: <4A756214.8010002@elischer.org> Message-ID: <4A7569BC.2060406@elischer.org> Julian Elischer wrote: > I simplified the output of the preprocessor for a PCPU_SET(xx, newval) > (to look at it). > > I came down to: (after formatting) for i386.. > { > __typeof(((struct pcpu *)0)->pc_xx) __val; > struct __s > { > u_char __b[(((sizeof(__val)) < (4)) ? > (sizeof(__val)) : (4))]; > } __s; > > __val = (newval); /* aligned */ > > if (sizeof(__val) == 1 > || sizeof(__val) == 2 > || sizeof(__val) == 4) { > __s = *(struct __s *)(void *)&__val; > __asm volatile("mov %1,%%fs:%0" : "=m" > (*(struct __s *)(__builtin_offsetof( > struct pcpu, pc_xx))) : "r" (__s)); > } else { > *__extension__ ( > { > __typeof(__val) *__p; > __asm volatile("movl %%fs:%1,%0; > addl %2,%0" : "=r" (__p) : "m" > (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), > "i" > (__builtin_offsetof(struct pcpu, pc_xx))); > __p; > }) = __val; > } > } p.s. I looked at the original source but I couldn't really work it out there either. > > having had my brain explode on this several times, > I can't figure out exactly what teh clause after the else is doing. well I know wht it appears to be doing fromt eh source but I can;t work out how.. __asm foo to explain it is missing.. > > anyone better at reading __asm better than me care to explain it in > simple words? (maybe it's just too late at night for me here) > > _______________________________________________ > 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 gary.jennejohn at freenet.de Sun Aug 2 10:30:27 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Aug 2 10:30:34 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <20090802074419.GA62454@over-yonder.net> References: <4A4517BE.9040504@FreeBSD.org> <200907301706.n6UH6HrY047414@lava.sentex.ca> <20090802074419.GA62454@over-yonder.net> Message-ID: <20090802123023.428110e6@ernst.jennejohn.org> On Sun, 2 Aug 2009 02:44:19 -0500 "Matthew D. Fuller" wrote: > 2) Audio CD stuff on the DVD drive gets cranky. > > - cdrecord doesn't seem to like it anymore. -scanbus says > cdrecord: Inappropriate ioctl for device. CAMIOCOMMAND ioctl > failed. Cannot open SCSI driver. > I saw this too. Reinstalling cdrecord (and all dependent ports) fixed it. > - Using cdda2wav to try and rip an audio track using the cd0 device > scrolls a lot of > Sorry, this driver and/or drive does not support cdda reading. > and such errors. Guessing the bus/id/lun from the devlist gives > what I assume is the same ioctl error from above. > Can't speak to this. --- Gary Jennejohn From fullermd at over-yonder.net Sun Aug 2 10:35:30 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Sun Aug 2 10:35:37 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <20090802123023.428110e6@ernst.jennejohn.org> References: <4A4517BE.9040504@FreeBSD.org> <200907301706.n6UH6HrY047414@lava.sentex.ca> <20090802074419.GA62454@over-yonder.net> <20090802123023.428110e6@ernst.jennejohn.org> Message-ID: <20090802103528.GC62454@over-yonder.net> On Sun, Aug 02, 2009 at 12:30:23PM +0200 I heard the voice of Gary Jennejohn, and lo! it spake thus: > > I saw this too. Reinstalling cdrecord (and all dependent ports) > fixed it. Oh, well, good thing I'm in the middle of doing that for the library version bumps anyway. Excellent :) > > - Using cdda2wav [...] > > Can't speak to this. Well, it's the same package, so I assume it's the same resolution. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From christoph.mallon at gmx.de Sun Aug 2 11:00:53 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Aug 2 11:01:00 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <4A756214.8010002@elischer.org> References: <4A756214.8010002@elischer.org> Message-ID: <4A756BA1.90002@gmx.de> Julian Elischer schrieb: > I simplified the output of the preprocessor for a PCPU_SET(xx, newval) > (to look at it). > > I came down to: (after formatting) for i386.. > { > __typeof(((struct pcpu *)0)->pc_xx) __val; > struct __s > { > u_char __b[(((sizeof(__val)) < (4)) ? > (sizeof(__val)) : (4))]; > } __s; > > __val = (newval); /* aligned */ > > if (sizeof(__val) == 1 > || sizeof(__val) == 2 > || sizeof(__val) == 4) { > __s = *(struct __s *)(void *)&__val; > __asm volatile("mov %1,%%fs:%0" : "=m" > (*(struct __s *)(__builtin_offsetof( > struct pcpu, pc_xx))) : "r" (__s)); > } else { > *__extension__ ( > { > __typeof(__val) *__p; > __asm volatile("movl %%fs:%1,%0; > addl %2,%0" : "=r" (__p) : "m" > (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), > "i" > (__builtin_offsetof(struct pcpu, pc_xx))); > __p; > }) = __val; > } > } > > having had my brain explode on this several times, > I can't figure out exactly what teh clause after the else is doing. > > anyone better at reading __asm better than me care to explain it in > simple words? First, ({}) is a statement expression - a GCC extension (not to be confused with expression statement, which is an expression followed by a semicolon). It wraps a compound statement, i.e. {}, and turns it into an expression. The value of the last statement is the value of the expression. In this case it's __p;. The per-cpu information can be accessed in two ways: Either by accessing it in the %fs segment (the then clause does it) or reading its address from %fs:pc_prvspace and then accessing it in the normal (i.e. %ds) segment (the else clause does this). Let's have a closer look at the else clause: The asm reads the pointer to per-cpu information into __p and the statement expression returns it. This pointer gets dereferenced (mind the * before __extension__ - __extension__ does nothing, it just marks that the following is a GCC extension) and __val is assigned. This else clause is for assignment for things which are not 1, 2 or 4 bytes in size. For sizes 1, 2 and 4 better code can be generated for by not first getting the pointer, but directly assigning the value into the %fs mappinf of the per-cpu info. Regards Christoph From kostikbel at gmail.com Sun Aug 2 11:31:49 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Aug 2 11:31:56 2009 Subject: HEAD tty seems to drop characters Message-ID: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> I run a screen(1), where I tried to copy large portion of output and paste it into vi. This resulted in the loss of the characters at random points inside the pasted text. See below: original ... pango-1.24.4 needs updating (port has 1.24.5) policykit-gnome-0.9.2_1 needs updating (port has 0.9.2_2) poppler-gtk-0.10.6 needs updating (port has 0.10.6_1) postgresql-client-8.3.7 needs updating (port has 8.3.7,1) postgresql-contrib-8.3.7_1 needs updating (port has 8.3.7_2) ... pasted ... pango-1.24.4 needs updating (port has 1.24.5) policy8.3.7 needs updating (port has 8.3.7,1) postgresql-contrib-8.3.7_1 needs updating (port has 8.3.7_2) ... The effect is reproducable. System is some days old HEAD, r196002. I think this is quite critical for 8.0. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/aa61997b/attachment.pgp From h.schmalzbauer at omnilan.de Sun Aug 2 11:50:56 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sun Aug 2 11:51:03 2009 Subject: cpufreq on VIA C7 In-Reply-To: <4A7382EF.5050400@grohnwaldt.eu> References: <4A65E6EB.50308@grohnwaldt.eu> <20090722082940.GA18826@asahi.TechFak.Uni-Bielefeld.DE> <4A7327DE.9010305@grohnwaldt.eu> <4A7382EF.5050400@grohnwaldt.eu> Message-ID: <4A757A00.3090903@omnilan.de> Uwe Grohnwaldt schrieb am 01.08.2009 01:49 (localtime): > Hi, > > disabling cpufreq in the kernel configfile works fine. after that it > looks fine: > dev.cpu.0.freq_levels: 2000/20000 1000/10000 800/8000 400/4000 This is done by throttling. Unfortunately it doesn't safe power for me, at least on my E8400 the power consumption raises about a hardly measureable bit. If I'm right the C7 (Eden V4, Esther in my case) supports enhanced speed stepping. I can enable it in my BIOS (along with SpeedStep1) which should enable the cpu to operate with 0.884 Volt. This would safe enourmous power. Unfortunately I can't hack the est driver to attach to C7. Any volunteers? :) Best regards, -Harry P.S.: I'll do some measurings regarding the throttling on the C7 to verify disabling throttling is the right thing ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/3056d1ce/signature.pgp From bruce at cran.org.uk Sun Aug 2 12:12:25 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Sun Aug 2 12:12:32 2009 Subject: Sysinstall - installing the docproj distribution Message-ID: <20090802131209.32afe8a8@gluon.draftnet> I downloaded an 8-CURRENT powerpc snapshot from http://pub.allbsd.org/FreeBSD-snapshots/powerpc/8.0-HEAD-20090731-JPSNAP/cdrom/ yesterday and tried to install it. The installation of the English documentation set failed saying it couldn't find "packages/INDEX" on the CD. The doc directory does exist so it seems it should be possible to install it. Is this a bug in sysinstall? -- Bruce Cran From ed at 80386.nl Sun Aug 2 12:31:09 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Aug 2 12:31:33 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> Message-ID: <20090802123108.GY1292@hoeg.nl> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/df4a2b0c/attachment.pgp From rwatson at FreeBSD.org Sun Aug 2 12:54:18 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 2 12:54:51 2009 Subject: latest svn kernel build seems to be broken In-Reply-To: <28283d910908011814y7838eedfica94021d65433566@mail.gmail.com> References: <28283d910908011814y7838eedfica94021d65433566@mail.gmail.com> Message-ID: On Sat, 1 Aug 2009, matt donovan wrote: > While trying to build the kernel modules I get the following error this is > with svn co of 196027 I assume this is an incremental rebuild as opposed to a full rebuild? What's happened is that an earlier "make depend" has left in a dependency on vimage.h, which has now been removed. You need to do a "make cleandepend" to flush out the stale dependencies. Or a non-incremental rebuild. Robert N M Watson Computer Laboratory University of Cambridge > > ===> nfscommon (all) > make: don't know how to make @/sys/vimage.h. Stop > *** Error code 2 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > _______________________________________________ > 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 rnoland at FreeBSD.org Sun Aug 2 13:02:10 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Aug 2 13:02:16 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802123108.GY1292@hoeg.nl> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> Message-ID: <1249217441.1773.5.camel@balrog.2hip.net> On Sun, 2009-08-02 at 14:31 +0200, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov wrote: > > I run a screen(1), where I tried to copy large portion of output and > > paste it into vi. This resulted in the loss of the characters at random > > points inside the pasted text. > > I already took some time to investigate the issue. I have attached a > patch that should already improve the situation: > > - write() on a pseudo-terminal master also accounted the data that was > read into the kernel, but couldn't be passed to the TTY (which is > likely to happen in non-blocking mode). > > - There was also a small unrelated issue; input on a TTY which has been > configured in block (bypass) mode wouldn't set the input high water > mark. > > For some reason, the data loss doesn't occur when SSHing to myself > multiple times, but still causes screen(1) to drop some bytes later on. > > Even though it's always very easy to blame other applications, I suspect > this may be because I reduced the input buffer size from 8 KB to 2 KB > per pseudo-terminal. Maybe screen(1) can't deal with this. To be > investigated... I'm pretty sure that I've seen this without screen involved. Just trying to cut / paste pkg-plist entries from an xterm or gnome-terminal (IIRC, I tried both) into vi. It worked as long as I took smaller chunks, but corrupted things if I tried to copy the whole plist in one shot. robert. -- Robert Noland FreeBSD From ed at 80386.nl Sun Aug 2 13:10:39 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Aug 2 13:10:45 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <1249217441.1773.5.camel@balrog.2hip.net> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> <1249217441.1773.5.camel@balrog.2hip.net> Message-ID: <20090802131038.GZ1292@hoeg.nl> * Robert Noland wrote: > I'm pretty sure that I've seen this without screen involved. Just > trying to cut / paste pkg-plist entries from an xterm or gnome-terminal > (IIRC, I tried both) into vi. It worked as long as I took smaller > chunks, but corrupted things if I tried to copy the whole plist in one > shot. Yes. This should be fixed by applying this patch. I'm just saying it makes sshd and tmux work properly, but it still has some problems with screen, albeit less often. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/2cddb7c3/attachment.pgp From rnoland at FreeBSD.org Sun Aug 2 13:12:28 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Aug 2 13:12:35 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802131038.GZ1292@hoeg.nl> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> <1249217441.1773.5.camel@balrog.2hip.net> <20090802131038.GZ1292@hoeg.nl> Message-ID: <1249218722.1773.6.camel@balrog.2hip.net> On Sun, 2009-08-02 at 15:10 +0200, Ed Schouten wrote: > * Robert Noland wrote: > > I'm pretty sure that I've seen this without screen involved. Just > > trying to cut / paste pkg-plist entries from an xterm or gnome-terminal > > (IIRC, I tried both) into vi. It worked as long as I took smaller > > chunks, but corrupted things if I tried to copy the whole plist in one > > shot. > > Yes. This should be fixed by applying this patch. I'm just saying it > makes sshd and tmux work properly, but it still has some problems with > screen, albeit less often. Ok, cool... thanks, robert. -- Robert Noland FreeBSD From serenity at exscape.org Sun Aug 2 13:22:37 2009 From: serenity at exscape.org (Thomas Backman) Date: Sun Aug 2 13:22:44 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802123108.GY1292@hoeg.nl> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> Message-ID: <4ACF3F62-44B9-4693-A1D3-8987848100C0@exscape.org> On Aug 2, 2009, at 14:31, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov wrote: >> I run a screen(1), where I tried to copy large portion of output and >> paste it into vi. This resulted in the loss of the characters at >> random >> points inside the pasted text. > > I already took some time to investigate the issue. I have attached a > patch that should already improve the situation: > > - write() on a pseudo-terminal master also accounted the data that was > read into the kernel, but couldn't be passed to the TTY (which is > likely to happen in non-blocking mode). > > - There was also a small unrelated issue; input on a TTY which has > been > configured in block (bypass) mode wouldn't set the input high water > mark. > > For some reason, the data loss doesn't occur when SSHing to myself > multiple times, but still causes screen(1) to drop some bytes later > on. > > Even though it's always very easy to blame other applications, I > suspect > this may be because I reduced the input buffer size from 8 KB to 2 KB > per pseudo-terminal. Maybe screen(1) can't deal with this. To be > investigated... Hmm, so I'm guessing this is the reason I've had trouble with copying/ pasting backtraces the last few days (I ssh into the box, which runs screen). I have, AFAIK, not noticed anything else than newlines dropping, though (I usually end up with lines such as "zfs_suspend_fs() at zfs_suspend_fs+0x2bzfs_ioc_recv() at zfs_ioc_recv +0x28b"). Also, do you know when this issue first appeared? I think I've been experiening this for more than a week or so, probably a lot longer (2-4 weeks? even longer)... could be sketchy memory, though. Regards, Thomas From kostikbel at gmail.com Sun Aug 2 14:05:56 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Aug 2 14:06:07 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802123108.GY1292@hoeg.nl> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> Message-ID: <20090802140530.GJ1884@deviant.kiev.zoral.com.ua> On Sun, Aug 02, 2009 at 02:31:08PM +0200, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov wrote: > > I run a screen(1), where I tried to copy large portion of output and > > paste it into vi. This resulted in the loss of the characters at random > > points inside the pasted text. > > I already took some time to investigate the issue. I have attached a > patch that should already improve the situation: > > - write() on a pseudo-terminal master also accounted the data that was > read into the kernel, but couldn't be passed to the TTY (which is > likely to happen in non-blocking mode). > > - There was also a small unrelated issue; input on a TTY which has been > configured in block (bypass) mode wouldn't set the input high water > mark. > > For some reason, the data loss doesn't occur when SSHing to myself > multiple times, but still causes screen(1) to drop some bytes later on. > > Even though it's always very easy to blame other applications, I suspect > this may be because I reduced the input buffer size from 8 KB to 2 KB > per pseudo-terminal. Maybe screen(1) can't deal with this. To be > investigated... At least, it is an improvement for me. Patch looks good. Please consider this as an approval for the commit. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/0bf6e397/attachment.pgp From dalroi at solfertje.student.utwente.nl Sun Aug 2 14:50:10 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Sun Aug 2 14:50:17 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <4A756BA1.90002@gmx.de> References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> Message-ID: <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> On 2 Aug 2009, at 12:34, Christoph Mallon wrote: > Julian Elischer schrieb: >> I simplified the output of the preprocessor for a PCPU_SET(xx, >> newval) >> (to look at it). >> I came down to: (after formatting) for i386.. >> { >> __typeof(((struct pcpu *)0)->pc_xx) __val; >> struct __s >> { >> u_char __b[(((sizeof(__val)) < (4)) ? >> (sizeof(__val)) : (4))]; >> } __s; >> __val = (newval); /* aligned */ >> if (sizeof(__val) == 1 >> || sizeof(__val) == 2 >> || sizeof(__val) == 4) { >> __s = *(struct __s *)(void *)&__val; >> __asm volatile("mov %1,%%fs:%0" : "=m" >> (*(struct __s *)(__builtin_offsetof( >> struct pcpu, pc_xx))) : "r" (__s)); >> } else { >> *__extension__ ( >> { >> __typeof(__val) *__p; >> __asm volatile("movl %%fs:%1,%0; >> addl %2,%0" : "=r" (__p) : "m" >> (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), >> "i" >> (__builtin_offsetof(struct pcpu, pc_xx))); >> __p; >> }) = __val; >> } >> } >> having had my brain explode on this several times, >> I can't figure out exactly what teh clause after the else is doing. >> anyone better at reading __asm better than me care to explain it in >> simple words? > > First, ({}) is a statement expression - a GCC extension (not to be > confused with expression statement, which is an expression followed > by a semicolon). It wraps a compound statement, i.e. {}, and turns > it into an expression. The value of the last statement is the value > of the expression. In this case it's __p;. Speaking as an outsider I'd better be careful with any criticism, but the first thing I noticed here was the lack of comments. From Julian's question it seems obvious that this function could do with some. I wonder what people would make of this in a couple of years when none of the (then) active developers has any intimate knowledge of the workings of functions like this one? I got from the posted code sample that __extension__ is probably a no- op meant for documentation purposes only. I think it would help to add what extension is being used though, maybe as a comment (but what would be the use of defining __extension__ then) or as a parameter. That's up to you though. Not being familiar with x86 assembly doesn't help me here of course, the last time I touched assembly was on a Z80 a couple of decades back... > Let's have a closer look at the else clause: The asm reads the > pointer to per-cpu information into __p and the statement expression > returns it. This pointer gets dereferenced (mind the * before > __extension__ - __extension__ does nothing, it just marks that the > following is a GCC extension) and __val is assigned. As I read it the value of __val is read into the memory address calculated by the expression in the statement expression (__p internally), am I right? Just chiming in with my opinion. I'm sure you'll do fine without it, but still. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4a75a40e10131514347140! From blackend at freebsd.org Sun Aug 2 15:02:43 2009 From: blackend at freebsd.org (Marc Fonvieille) Date: Sun Aug 2 15:02:50 2009 Subject: Sysinstall - installing the docproj distribution In-Reply-To: <20090802131209.32afe8a8@gluon.draftnet> References: <20090802131209.32afe8a8@gluon.draftnet> Message-ID: <20090802144944.GA50971@abigail.blackend.org> On Sun, Aug 02, 2009 at 01:12:09PM +0100, Bruce Cran wrote: > I downloaded an 8-CURRENT powerpc snapshot from > http://pub.allbsd.org/FreeBSD-snapshots/powerpc/8.0-HEAD-20090731-JPSNAP/cdrom/ > yesterday and tried to install it. The installation of the English > documentation set failed saying it couldn't find "packages/INDEX" on > the CD. The doc directory does exist so it seems it should be possible > to install it. Is this a bug in sysinstall? > Your ISO comes without any packages? I mean you cannot install any packages during installation time with sysinstall? If it's the case, it's normal you got this error: docs are now provided via packages so if packages/INDEXis not available it'll fail. You can install docs after installation time with: pkg_add -rv en-freebsd-doc -- Marc From christoph.mallon at gmx.de Sun Aug 2 15:09:53 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Aug 2 15:10:00 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> Message-ID: <4A75AC3D.6020507@gmx.de> Alban Hertroys schrieb: > On 2 Aug 2009, at 12:34, Christoph Mallon wrote: > >> Julian Elischer schrieb: >>> I simplified the output of the preprocessor for a PCPU_SET(xx, newval) >>> (to look at it). >>> I came down to: (after formatting) for i386.. >>> { >>> __typeof(((struct pcpu *)0)->pc_xx) __val; >>> struct __s >>> { >>> u_char __b[(((sizeof(__val)) < (4)) ? >>> (sizeof(__val)) : (4))]; >>> } __s; >>> __val = (newval); /* aligned */ >>> if (sizeof(__val) == 1 >>> || sizeof(__val) == 2 >>> || sizeof(__val) == 4) { >>> __s = *(struct __s *)(void *)&__val; >>> __asm volatile("mov %1,%%fs:%0" : "=m" >>> (*(struct __s *)(__builtin_offsetof( >>> struct pcpu, pc_xx))) : "r" (__s)); >>> } else { >>> *__extension__ ( >>> { >>> __typeof(__val) *__p; >>> __asm volatile("movl %%fs:%1,%0; >>> addl %2,%0" : "=r" (__p) : "m" >>> (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), >>> "i" >>> (__builtin_offsetof(struct pcpu, pc_xx))); >>> __p; >>> }) = __val; >>> } >>> } >>> having had my brain explode on this several times, >>> I can't figure out exactly what teh clause after the else is doing. >>> anyone better at reading __asm better than me care to explain it in >>> simple words? >> >> First, ({}) is a statement expression - a GCC extension (not to be >> confused with expression statement, which is an expression followed by >> a semicolon). It wraps a compound statement, i.e. {}, and turns it >> into an expression. The value of the last statement is the value of >> the expression. In this case it's __p;. > > Speaking as an outsider I'd better be careful with any criticism, but > the first thing I noticed here was the lack of comments. From Julian's > question it seems obvious that this function could do with some. I > wonder what people would make of this in a couple of years when none of > the (then) active developers has any intimate knowledge of the workings > of functions like this one? > > I got from the posted code sample that __extension__ is probably a no-op > meant for documentation purposes only. I think it would help to add what > extension is being used though, maybe as a comment (but what would be > the use of defining __extension__ then) or as a parameter. That's up to > you though. GCC can be switched into a mode in which it rejects extensions like ({}). If you prepend an extension with __extension__ in this mode, it accepts it. Of course you can do fine here without this extension, just by using a static inline function which returns the per-cpu pointer. > Not being familiar with x86 assembly doesn't help me here of course, the > last time I touched assembly was on a Z80 a couple of decades back... Similarily, if you are not familiar with C, then ++i; will puzzle you. Do you want to add /* add one to the integer variable named i */ everywhere? But you've got one point: There should be a comment added, which states that the if () is just an optimisation. >> Let's have a closer look at the else clause: The asm reads the pointer >> to per-cpu information into __p and the statement expression returns >> it. This pointer gets dereferenced (mind the * before __extension__ - >> __extension__ does nothing, it just marks that the following is a GCC >> extension) and __val is assigned. > > > As I read it the value of __val is read into the memory address > calculated by the expression in the statement expression (__p > internally), am I right? It is __p = GET_PCPU_PTR() + OFFSET_OF_ENTRY_IN_STRUCT(name); *__p = val; The stuff in uppercase is done in the inline asm. Though there is no good reason to do the addition of the offset inside the inline asm. Simpler would be GET_PCPU_PTR()->name (it probably leads to better code, too). I have a diff for this simplification and adding a static inline function to get the pcpu pointer somewhere... Christoph From dalroi at solfertje.student.utwente.nl Sun Aug 2 15:37:40 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Sun Aug 2 15:37:47 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <4A75AC3D.6020507@gmx.de> References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> <4A75AC3D.6020507@gmx.de> Message-ID: On 2 Aug 2009, at 17:09, Christoph Mallon wrote: > Alban Hertroys schrieb: >> Not being familiar with x86 assembly doesn't help me here of >> course, the last time I touched assembly was on a Z80 a couple of >> decades back... > > Similarily, if you are not familiar with C, then ++i; will puzzle > you. Do you want to add /* add one to the integer variable named i > */ everywhere? > But you've got one point: There should be a comment added, which > states that the if () is just an optimisation. Ah sorry, that wasn't meant as a comment on the lack of comments on assembly code but merely as an aside that _I_ can't really comment on assembly code due to my lack of experience with it. I trust that most FreeBSD developers have no issues with reading assembly like this, so there is no real need to add comments there (unless something it does isn't immediately obvious of course). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4a75b2c210131568315957! From julian at elischer.org Sun Aug 2 16:55:38 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 2 16:55:47 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> Message-ID: <4A75C50E.5020203@elischer.org> Alban Hertroys wrote: > On 2 Aug 2009, at 12:34, Christoph Mallon wrote: > >> Julian Elischer schrieb: >>> I simplified the output of the preprocessor for a PCPU_SET(xx, newval) >>> (to look at it). >>> I came down to: (after formatting) for i386.. >>> { >>> __typeof(((struct pcpu *)0)->pc_xx) __val; >>> struct __s >>> { >>> u_char __b[(((sizeof(__val)) < (4)) ? >>> (sizeof(__val)) : (4))]; >>> } __s; >>> __val = (newval); /* aligned */ >>> if (sizeof(__val) == 1 >>> || sizeof(__val) == 2 >>> || sizeof(__val) == 4) { >>> __s = *(struct __s *)(void *)&__val; >>> __asm volatile("mov %1,%%fs:%0" : "=m" >>> (*(struct __s *)(__builtin_offsetof( >>> struct pcpu, pc_xx))) : "r" (__s)); >>> } else { >>> *__extension__ ( >>> { >>> __typeof(__val) *__p; >>> __asm volatile("movl %%fs:%1,%0; >>> addl %2,%0" : "=r" (__p) : "m" >>> (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), >>> "i" >>> (__builtin_offsetof(struct pcpu, pc_xx))); >>> __p; >>> }) = __val; >>> } >>> } >>> having had my brain explode on this several times, >>> I can't figure out exactly what teh clause after the else is doing. >>> anyone better at reading __asm better than me care to explain it in >>> simple words? >> >> First, ({}) is a statement expression - a GCC extension (not to be >> confused with expression statement, which is an expression followed by >> a semicolon). It wraps a compound statement, i.e. {}, and turns it >> into an expression. The value of the last statement is the value of >> the expression. In this case it's __p;. > > Speaking as an outsider I'd better be careful with any criticism, but > the first thing I noticed here was the lack of comments. From Julian's > question it seems obvious that this function could do with some. I > wonder what people would make of this in a couple of years when none of > the (then) active developers has any intimate knowledge of the workings > of functions like this one? there are no comments in this cut-n-paste because it is the output of the C preprocessor.. of course the source doesn't have many comments either.. (in i386/include/pcpu.h) > > I got from the posted code sample that __extension__ is probably a no-op > meant for documentation purposes only. I think it would help to add what > extension is being used though, maybe as a comment (but what would be > the use of defining __extension__ then) or as a parameter. That's up to > you though. > > Not being familiar with x86 assembly doesn't help me here of course, the > last time I touched assembly was on a Z80 a couple of decades back... > >> Let's have a closer look at the else clause: The asm reads the pointer >> to per-cpu information into __p and the statement expression returns >> it. This pointer gets dereferenced (mind the * before __extension__ - >> __extension__ does nothing, it just marks that the following is a GCC >> extension) and __val is assigned. > > > As I read it the value of __val is read into the memory address > calculated by the expression in the statement expression (__p > internally), am I right? > > Just chiming in with my opinion. I'm sure you'll do fine without it, but > still. > > Alban Hertroys > > -- > If you can't see the forest for the trees, > cut the trees and you'll see there is no forest. > > > !DSPAM:929,4a75a40b10131060118257! > From fullermd at over-yonder.net Sun Aug 2 16:56:46 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Sun Aug 2 16:56:54 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <20090802103528.GC62454@over-yonder.net> References: <4A4517BE.9040504@FreeBSD.org> <200907301706.n6UH6HrY047414@lava.sentex.ca> <20090802074419.GA62454@over-yonder.net> <20090802123023.428110e6@ernst.jennejohn.org> <20090802103528.GC62454@over-yonder.net> Message-ID: <20090802165642.GD62454@over-yonder.net> On Sun, Aug 02, 2009 at 05:35:28AM -0500 I heard the voice of Matthew D. Fuller, and lo! it spake thus: > On Sun, Aug 02, 2009 at 12:30:23PM +0200 I heard the voice of > Gary Jennejohn, and lo! it spake thus: > > > > I saw this too. Reinstalling cdrecord (and all dependent ports) > > fixed it. > > Oh, well, good thing I'm in the middle of doing that for the library > version bumps anyway. Excellent :) Well, on the plus side, after the rebuild -scanbus... well, scanned the bus. On the minus, it also killed off all disk IO afterward. An in-progress portupgrade halted in its tracks, editing or tailing files is dead, _exiting_ vi is toast. The scanbus itself took a long time; a minute or two. xconsole is scrolling a bunch of Timeout on slot 's. It's probably been 10 minutes since the scanbus returned now (luckily, this ssh session was already up), and nothing's progressed, so I guess I'll go push the BRS again. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From rwatson at FreeBSD.org Sun Aug 2 17:15:13 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 2 17:15:19 2009 Subject: Sysinstall - installing the docproj distribution In-Reply-To: <20090802144944.GA50971@abigail.blackend.org> References: <20090802131209.32afe8a8@gluon.draftnet> <20090802144944.GA50971@abigail.blackend.org> Message-ID: On Sun, 2 Aug 2009, Marc Fonvieille wrote: > On Sun, Aug 02, 2009 at 01:12:09PM +0100, Bruce Cran wrote: >> I downloaded an 8-CURRENT powerpc snapshot from >> http://pub.allbsd.org/FreeBSD-snapshots/powerpc/8.0-HEAD-20090731-JPSNAP/cdrom/ >> yesterday and tried to install it. The installation of the English >> documentation set failed saying it couldn't find "packages/INDEX" on the >> CD. The doc directory does exist so it seems it should be possible to >> install it. Is this a bug in sysinstall? > > Your ISO comes without any packages? I mean you cannot install any packages > during installation time with sysinstall? If it's the case, it's normal you > got this error: docs are now provided via packages so if packages/INDEXis > not available it'll fail. > > You can install docs after installation time with: > > pkg_add -rv en-freebsd-doc To date, betas have been shipped without packages, but our installer tends to handle that less than gracefully (as I recall, it just pops up error dialogs). Possibly, sysinstall should pop up a message early on saying that there are no packages and then not offer the option to do anything with them. :-) Robert N M Watson Computer Laboratory University of Cambridge From dalroi at solfertje.student.utwente.nl Sun Aug 2 17:20:37 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Sun Aug 2 17:20:45 2009 Subject: puzzling code in pcpu stuff In-Reply-To: <4A75C50E.5020203@elischer.org> References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> <4A75C50E.5020203@elischer.org> Message-ID: <905E6A82-3E1D-4A74-936E-2B2B77C7B147@solfertje.student.utwente.nl> On 2 Aug 2009, at 18:55, Julian Elischer wrote: > Alban Hertroys wrote: >> On 2 Aug 2009, at 12:34, Christoph Mallon wrote: >>> Julian Elischer schrieb: >>>> I simplified the output of the preprocessor for a PCPU_SET(xx, >>>> newval) >>>> (to look at it). >> Speaking as an outsider I'd better be careful with any criticism, >> but the first thing I noticed here was the lack of comments. From >> Julian's question it seems obvious that this function could do with >> some. I wonder what people would make of this in a couple of years >> when none of the (then) active developers has any intimate >> knowledge of the workings of functions like this one? > > there are no comments in this cut-n-paste because it is the output > of the C preprocessor.. of course the source doesn't have many > comments either.. (in i386/include/pcpu.h) Ah, I missed the first line of your message! Yes, looking at the macro definitions that's a lot more like I expected. It's just an assignment to *__PCPU_PTR(name), which is quite clear actually. A bit of a relief I must say :) Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4a75cae310135211110206! From ed at 80386.nl Sun Aug 2 18:29:18 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Aug 2 18:29:25 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802140530.GJ1884@deviant.kiev.zoral.com.ua> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> <20090802140530.GJ1884@deviant.kiev.zoral.com.ua> Message-ID: <20090802182917.GA1292@hoeg.nl> * Kostik Belousov wrote: > At least, it is an improvement for me. Patch looks good. > Please consider this as an approval for the commit. Just for the record, I've committed the patch earlier today. Thanks for testing! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090802/e48fd7d9/attachment.pgp From cattelan at thebarn.com Sun Aug 2 19:29:12 2009 From: cattelan at thebarn.com (Russell Cattelan) Date: Sun Aug 2 19:29:44 2009 Subject: CARP broken on -CURRENT? In-Reply-To: <4A61544E.2050208@delphij.net> References: <4A5F8010.7050504@delphij.net> <4A5F7540.7070201@delphij.net> <4A5EF889.6040604@delphij.net> <4A61544E.2050208@delphij.net> Message-ID: <4A732017.6040805@thebarn.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xin LI wrote: > I got it. It was the cached llentry that preventing ether_output() > to choose the right broadcast/multicast address and use the default > gateway's L2 address. Here is a proposed patch. > > Cheers, Just to add a data point here: this change seems to fix the problem I was seeing with cups via ahavi. The printers would be visible (avahi-browse or Bonjour Browser on the mac) for a minute or so after the system boots up but then would disappear, the machine its self could see the printers but no external machines could. I was possible to get the printer to show up again for a brief period if the arp cache was flushed "arp -da" but would disappear again after about a minute or so. Currently the printers have been visible for the last couple of hours with this change. - -Russell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKcyAXNRmM+OaGhBgRAqNaAJ97TINvOovMjen8zJXqM3ZlI7s7RQCfTTGX Xl10nxZLygjzueZnyWx/SMA= =/x24 -----END PGP SIGNATURE----- From cattelan at thebarn.com Sun Aug 2 19:29:13 2009 From: cattelan at thebarn.com (Russell Cattelan) Date: Sun Aug 2 19:29:44 2009 Subject: small fix to netatalk Message-ID: <4A7320E1.4050308@thebarn.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 starting up netatalk would panic the system with a lock not locked panic. It appears somebody reversed the 2 lock statements in netatalk/at_control.c diff --git a/sys/netatalk/at_control.c b/sys/netatalk/at_control.c index 5193d66..b2d8422 100644 - --- a/sys/netatalk/at_control.c +++ b/sys/netatalk/at_control.c @@ -276,7 +276,7 @@ at_control(struct socket *so, u_long cmd, caddr_t data, struct ifnet *ifp, * If the request is specifying phase 1, then * only look at a phase one address */ - - AT_IFADDR_RUNLOCK(); + AT_IFADDR_RLOCK(); for (oaa = aa; aa; aa = TAILQ_NEXT(aa, aa_link)) { if (aa->aa_ifp == ifp && (aa->aa_flags & AFA_PHASE2) == 0) @@ -286,7 +286,7 @@ at_control(struct socket *so, u_long cmd, caddr_t data, struct ifnet *ifp, ifa_free(&oaa->aa_ifa); if (aa != NULL && oaa != aa) ifa_ref(&aa->aa_ifa); - - AT_IFADDR_RLOCK(); + AT_IFADDR_RUNLOCK(); } else { struct at_ifaddr *oaa; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKcyDhNRmM+OaGhBgRAnDKAJ0Ys2GMVJphbq6Qdgq6cvj85iKShwCfQsAE P95+NxdFPwEjB/r0yQbTris= =K0G2 -----END PGP SIGNATURE----- From oberman at es.net Sun Aug 2 21:11:57 2009 From: oberman at es.net (Kevin Oberman) Date: Sun Aug 2 21:12:05 2009 Subject: cpufreq on VIA C7 In-Reply-To: Your message of "Sun, 02 Aug 2009 13:35:28 +0200." <4A757A00.3090903@omnilan.de> Message-ID: <20090802211156.806431CC31@ptavv.es.net> > Date: Sun, 02 Aug 2009 13:35:28 +0200 > From: Harald Schmalzbauer > Sender: owner-freebsd-current@freebsd.org > > Uwe Grohnwaldt schrieb am 01.08.2009 01:49 (localtime): > > Hi, > > > > disabling cpufreq in the kernel configfile works fine. after that it > > looks fine: > > dev.cpu.0.freq_levels: 2000/20000 1000/10000 800/8000 400/4000 > > This is done by throttling. Unfortunately it doesn't safe power for me, > at least on my E8400 the power consumption raises about a hardly > measureable bit. > If I'm right the C7 (Eden V4, Esther in my case) supports enhanced speed > stepping. I can enable it in my BIOS (along with SpeedStep1) which > should enable the cpu to operate with 0.884 Volt. This would safe > enourmous power. > Unfortunately I can't hack the est driver to attach to C7. > Any volunteers? :) > > Best regards, > > -Harry > > P.S.: I'll do some measurings regarding the throttling on the C7 to > verify disabling throttling is the right thing ;) As I post fairly often, throttling seldom helps power consumption on ANY processor. All throttling (and TCC) do is to skip N of every 8 clock cycles. That means performance is cut exactly the same as power. Running any given job takes almost exactly the same amount of power, just taking longer as the throttling is increased. >From my limited reading of Intel docs, the primitive throttling and more advanced TCC were introduced for thermal management, where they actually do work and not power management, where they don't. TCC is the TLA for Thermal Control Circuit. I have seen it suggested that throttling should be removed from power management and I heartily endorse this. I always disable it (along with TCC). -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From rwatson at FreeBSD.org Sun Aug 2 21:56:10 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 2 21:56:18 2009 Subject: small fix to netatalk In-Reply-To: <4A7320E1.4050308@thebarn.com> References: <4A7320E1.4050308@thebarn.com> Message-ID: On Fri, 31 Jul 2009, Russell Cattelan wrote: > starting up netatalk would panic the system with a lock not locked panic. > > It appears somebody reversed the 2 lock statements in netatalk/at_control.c Indeed -- almost certainly me, although there must be some differences in our netatalk setups as my box didn't panic in testing :-). I'll give it a more thorough spin locally and request RE permission to merge the patch tomorrow. Thanks! Robert N M Watson Computer Laboratory University of Cambridge > > diff --git a/sys/netatalk/at_control.c b/sys/netatalk/at_control.c > index 5193d66..b2d8422 100644 > - --- a/sys/netatalk/at_control.c > +++ b/sys/netatalk/at_control.c > @@ -276,7 +276,7 @@ at_control(struct socket *so, u_long cmd, caddr_t > data, struct ifnet *ifp, > * If the request is specifying phase 1, then > * only look at a phase one address > */ > - - AT_IFADDR_RUNLOCK(); > + AT_IFADDR_RLOCK(); > for (oaa = aa; aa; aa = TAILQ_NEXT(aa, aa_link)) { > if (aa->aa_ifp == ifp && > (aa->aa_flags & AFA_PHASE2) == 0) > @@ -286,7 +286,7 @@ at_control(struct socket *so, u_long cmd, caddr_t > data, struct ifnet *ifp, > ifa_free(&oaa->aa_ifa); > if (aa != NULL && oaa != aa) > ifa_ref(&aa->aa_ifa); > - - AT_IFADDR_RLOCK(); > + AT_IFADDR_RUNLOCK(); > } else { > struct at_ifaddr *oaa; > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFKcyDhNRmM+OaGhBgRAnDKAJ0Ys2GMVJphbq6Qdgq6cvj85iKShwCfQsAE > P95+NxdFPwEjB/r0yQbTris= > =K0G2 > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From slw at zxy.spb.ru Sun Aug 2 22:22:36 2009 From: slw at zxy.spb.ru (Slawa Olhovchenkov) Date: Sun Aug 2 22:22:44 2009 Subject: ath problem w/ WPA2 In-Reply-To: <49E9F782.6080201@freebsd.org> References: <20090417214339.GQ10728%slw@acropolis.ru> <49E9F782.6080201@freebsd.org> Message-ID: <20090802214052.GA25908%slw@acropolis.ru> On Sat, Apr 18, 2009 at 08:53:38AM -0700, Sam Leffler wrote: > Slawa Olhovchenkov wrote: > > ath0: mem 0x88000000-0x8800ffff irq 16 at device 0.0 on cardbus0 > > ath0: [ITHREAD] > > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > > > After 1 hour stable working card lost all traffic. > > This is time of EAP reauthentication period. > > > > When using Intel card -- all works OK. > > > > With very old kernel (~ 1 year old) all works OK. > > > > I can't test intermediate kernel -- on this kernels > > cardbus port don't powered correctly. > > > > Last update to -current -- now. > > > > Known problem that was diagnosed recently on this list (or possibly > mobile@). wpa_supplicant is passing the kernel an unexpected key index. > You can check for the mailing list postings for more information as > noone has submitted a PR. > > Unfortunately I've got no time to look at this for at least a couple of > weeks. Maybe someone else will handle it. > > This is a show stopper for 8.0. 8-current at Aug 2 -- work again. -- Slawa Olhovchenkov From yanefbsd at gmail.com Mon Aug 3 03:35:15 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Aug 3 03:35:22 2009 Subject: HEAD tty seems to drop characters In-Reply-To: <20090802140530.GJ1884@deviant.kiev.zoral.com.ua> References: <20090802105033.GG1884@deviant.kiev.zoral.com.ua> <20090802123108.GY1292@hoeg.nl> <20090802140530.GJ1884@deviant.kiev.zoral.com.ua> Message-ID: <70966B4B-6BEA-4AFB-93D4-2DA8B6E33CD9@gmail.com> On Aug 2, 2009, at 7:05 AM, Kostik Belousov wrote: > On Sun, Aug 02, 2009 at 02:31:08PM +0200, Ed Schouten wrote: >> Hi Kostik, >> >> * Kostik Belousov wrote: >>> I run a screen(1), where I tried to copy large portion of output and >>> paste it into vi. This resulted in the loss of the characters at >>> random >>> points inside the pasted text. >> >> I already took some time to investigate the issue. I have attached a >> patch that should already improve the situation: >> >> - write() on a pseudo-terminal master also accounted the data that >> was >> read into the kernel, but couldn't be passed to the TTY (which is >> likely to happen in non-blocking mode). >> >> - There was also a small unrelated issue; input on a TTY which has >> been >> configured in block (bypass) mode wouldn't set the input high water >> mark. >> >> For some reason, the data loss doesn't occur when SSHing to myself >> multiple times, but still causes screen(1) to drop some bytes later >> on. >> >> Even though it's always very easy to blame other applications, I >> suspect >> this may be because I reduced the input buffer size from 8 KB to 2 KB >> per pseudo-terminal. Maybe screen(1) can't deal with this. To be >> investigated... > At least, it is an improvement for me. Patch looks good. > Please consider this as an approval for the commit. SWEET! You may have fixed the bug that I reported (well, not officially) on #bsdports / #bsddev a while ago... someone else tested it though, and it passed for them so I thought it was just something funky with my setup. I suppose not :). I'll give it a shot too, once I have a chance. It was very easy to reproduce, but wasn't consistent for everyone, and the best way to reproduce it was to paste ~1k chars of text from Firefox to xterm (for instance).. -Garrett From hselasky at c2i.net Mon Aug 3 07:26:14 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 07:26:21 2009 Subject: Patch to address coredump slowdown Message-ID: <200908030926.12472.hselasky@c2i.net> Hi, The following attached patch addresses recently slowed coredumps. http://perforce.freebsd.org/chv.cgi?CH=166957 MD5 (ukbd.c.diff) = 1e3c143942593b0ed4617d306a9d2ee2 cd /usr/src/sys/dev/usb/input/ cat ukbd.c.diff | patch --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: ukbd.c.diff Type: text/x-patch Size: 943 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090803/260a44f7/ukbd.c.bin From franklahm at googlemail.com Mon Aug 3 08:39:22 2009 From: franklahm at googlemail.com (Frank Lahm) Date: Mon Aug 3 08:39:28 2009 Subject: small fix to netatalk Message-ID: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> Hi, I just subscribed here so I can't followup neatly which will break threading, sorry for that. If appropiate please also provide any patches upstream. Thanks! Though I'm not sure _what_ you're really patching here, as the patch doesn't match neither upstream head nor branch-2-0 ? Regards -Frank, Netatalk Developer From rwatson at FreeBSD.org Mon Aug 3 08:44:03 2009 From: rwatson at FreeBSD.org (Robert N. M. Watson) Date: Mon Aug 3 08:44:09 2009 Subject: small fix to netatalk In-Reply-To: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> References: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> Message-ID: <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> On 3 Aug 2009, at 09:11, Frank Lahm wrote: > I just subscribed here so I can't followup neatly which will break > threading, sorry for that. > > If appropiate please also provide any patches upstream. Thanks! > Though I'm not sure _what_ you're really patching here, as the patch > doesn't match neither upstream head nor branch-2-0 ? This is a patch against the kernel netatalk code in FreeBSD, specifically, against address configuration for phase I addresses. Forgive a lack of knowledge of the netatalk project itself, but I had assumed we basically owned the kernel bits and were supposed to make sure they kept working, and you guys owned the userspace bits. If you are maintaining kernel bits, then we should talk about that since I've modified the FreeBSD netatalk kernel code heavily in the last few years during the fine-grained locking work on it. :-) We should probably talk regardless as one of the big things we appear to be missing for the kernel netatalk code is a decent regression suite -- I have some casual local tests, but over the years we've picked up several reports of regressions (8 appears to have regressed with respect to multiple network interfaces being available, for example), and I know very little about the wire protocol. If you guys have any unit tests for kernel netatalk services, that would be excellent, but if not, perhaps you can provide some guidance on what sorts of units tests would be appropriate. Robert From hselasky at c2i.net Mon Aug 3 11:37:17 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 11:37:26 2009 Subject: Patch to address coredump slowdown In-Reply-To: <7d6fde3d0908030424r46188924y6df4fbfd8fcdc8ce@mail.gmail.com> References: <200908030926.12472.hselasky@c2i.net> <7d6fde3d0908030424r46188924y6df4fbfd8fcdc8ce@mail.gmail.com> Message-ID: <200908031337.14144.hselasky@c2i.net> On Monday 03 August 2009 13:24:06 Garrett Cooper wrote: > Could this be what's killing off I/O in general lately? I think no. The code where the DELAY() is called from should only be called when polling from DDB (panic prompt) and the alike. Else there is a bug! --HPS From yanefbsd at gmail.com Mon Aug 3 11:50:11 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Aug 3 11:50:17 2009 Subject: Patch to address coredump slowdown In-Reply-To: <200908030926.12472.hselasky@c2i.net> References: <200908030926.12472.hselasky@c2i.net> Message-ID: <7d6fde3d0908030424r46188924y6df4fbfd8fcdc8ce@mail.gmail.com> On Mon, Aug 3, 2009 at 12:26 AM, Hans Petter Selasky wrote: > Hi, > > The following attached patch addresses recently slowed coredumps. > > http://perforce.freebsd.org/chv.cgi?CH=166957 > > MD5 (ukbd.c.diff) = 1e3c143942593b0ed4617d306a9d2ee2 > > cd /usr/src/sys/dev/usb/input/ > cat ukbd.c.diff | patch Could this be what's killing off I/O in general lately? I used to be able to compile and serve up files via NFS / samba without my desktop/laptop skipping a frame of decent quality video over my gigabit ethernet here at home, but now it appears to have gone downhill a bit (well, that's what I noticed since my last update which was ~14 days ago, e.g. BETA1 -- I just updated tonight so we'll see what happens now...). Thanks HPS! -Garrett From franklahm at googlemail.com Mon Aug 3 13:06:26 2009 From: franklahm at googlemail.com (Frank Lahm) Date: Mon Aug 3 13:06:36 2009 Subject: small fix to netatalk In-Reply-To: <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> References: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> Message-ID: <4242eef70908030606l43c23217r8725a80045dd0cd0@mail.gmail.com> 2009/8/3 Robert N. M. Watson : > > On 3 Aug 2009, at 09:11, Frank Lahm wrote: > >> I just subscribed here so I can't followup neatly which will break >> threading, sorry for that. >> >> If appropiate please also provide any patches upstream. Thanks! >> Though I'm not sure _what_ you're really patching here, as the patch >> doesn't match neither upstream head nor branch-2-0 ? > > This is a patch against the kernel netatalk code in FreeBSD, specifically, > against address configuration for phase I addresses. Forgive a lack of > knowledge of the netatalk project itself, but I had assumed we basically > owned the kernel bits and were supposed to make sure they kept working, and > you guys owned the userspace bits. Yes, of course. I'm sorry to say, but apparently I was too lazy to check the relation between "our" sys/netatalk/*.[c|h] [1] stuff and the FreeBSD stuff. As it turns out we have some very old and very unmaintained code in our repo which was imported way back then when Netatalk was brought to SF.net in the first place. Since then nobody every really has worked on it. Current Netatalk development focuses on userspace stuff. Afaik none of us doing active development has any decent knowledge of the AppleTalk protocol implementations of BSD or Solaris. > We should probably talk regardless as one of the big things we appear to be > missing for the kernel netatalk code is a decent regression suite -- I have > some casual local tests, but over the years we've picked up several reports > of regressions (8 appears to have regressed with respect to multiple network > interfaces being available, for example), and I know very little about the > wire protocol. If you guys have any unit tests ... No, we don't. Only for the userlevel AFP protocol. > ... for kernel netatalk services, ... Fwiw: the usage of the term netatalk for the kernel implementation of the link-layer AppleTalk protocoll is confusing. I guess the naming rules in FreeBSD CVS joined net with atalk to form netatalk, but that's only the name of the directory containg the atalk implementation. > that would be excellent, but if not, perhaps you can provide some guidance > on what sorts of units tests would be appropriate. >From our (or at least my) perspective, we're focusing on the AFP protocol and our ressources are sparse. Also note that Mac OS X 10.6 will ship withouh AppleTalk. The words of dropping AppleTalk support and the userlevel daemons atalkd and papd who use it have already been heared twice on netatalk-dev@sf.net. Few are still using it, fewer know it, nobody maintains it. A year or two back in time I would have been tempted to step up and pick up AT development and would then have asked you for some advice on how to get to know developping networking stuff in the FreeBSD kernel. But that was then. Sorry for the noise. Regards, -Frank [1] http://netatalk.cvs.sourceforge.net/viewvc/netatalk/netatalk/sys/netatalk/ From David.Boyd at insightbb.com Mon Aug 3 15:04:33 2009 From: David.Boyd at insightbb.com (David Boyd) Date: Mon Aug 3 15:04:41 2009 Subject: FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive Message-ID: Can someone "PLEASE" commit this fix. Daniel was kind enough to write it up, but it has not been committed as of 8/3/2009. Thanks. -----Original Message----- From: Daniel O'Connor [mailto:doconnor@gsoft.com.au] Sent: Tuesday, July 21, 2009 8:28 PM To: freebsd-current@freebsd.org Cc: David Boyd Subject: Re: 8.0-BETA2 sysinstall ignoring setting of nonInteractive On Wed, 22 Jul 2009, David Boyd wrote: > With 8.0-BETA(1/2) sysinstall ignores setting of nonInteractive > variable when using USB-based install. > > With or without nonInteractive sysinstall issues message "Using USB > device: da0a" and waits for confirmation. > > This breaks unattended installations using USB device. I think this would fix it, can you test it? Index: media.c =================================================================== --- media.c (revision 195813) +++ media.c (working copy) @@ -262,7 +262,8 @@ mediaDevice = devs[0]; if (mediaDevice) mediaDevice->private = NULL; - msgConfirm("Using USB device: %s", mediaDevice->name); + if (!variable_get(VAR_NONINTERACTIVE)) + msgConfirm("Using USB device: %s", mediaDevice->name); return (mediaDevice ? DITEM_LEAVE_MENU : DITEM_FAILURE); } -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090803/e7a313f5/signature.pgp From rink at FreeBSD.org Mon Aug 3 15:20:22 2009 From: rink at FreeBSD.org (Rink Springer) Date: Mon Aug 3 15:20:29 2009 Subject: FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive In-Reply-To: References: Message-ID: <20090803152202.GB61519@rink.nu> On Mon, Aug 03, 2009 at 11:04:31AM -0400, David Boyd wrote: > Can someone "PLEASE" commit this fix. This fix looks OK to me; I'll ask re@ for permission. Regards, -- Rink P.W. Springer - http://rink.nu "Optimism, Hercules, is the shield of fools." - Dahak From rwatson at freebsd.org Mon Aug 3 15:23:56 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Mon Aug 3 15:24:28 2009 Subject: small fix to netatalk In-Reply-To: <4242eef70908030606l43c23217r8725a80045dd0cd0@mail.gmail.com> References: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> <4242eef70908030606l43c23217r8725a80045dd0cd0@mail.gmail.com> Message-ID: <678AAF56-8778-4B0C-9C74-29CF440123AF@freebsd.org> On 3 Aug 2009, at 14:06, Frank Lahm wrote: >> This is a patch against the kernel netatalk code in FreeBSD, >> specifically, >> against address configuration for phase I addresses. Forgive a lack >> of >> knowledge of the netatalk project itself, but I had assumed we >> basically >> owned the kernel bits and were supposed to make sure they kept >> working, and >> you guys owned the userspace bits. > > Yes, of course. > I'm sorry to say, but apparently I was too lazy to check the relation > between "our" sys/netatalk/*.[c|h] [1] stuff and the FreeBSD stuff. > As it turns out we have some very old and very unmaintained code in > our repo which was imported way back then when Netatalk was brought to > SF.net in the first place. Since then nobody every really has worked > on it. Current Netatalk development focuses on userspace stuff. > Afaik none of > us doing active development has any decent knowledge of the AppleTalk > protocol implementations of BSD or Solaris. This is simplifying from many perspectives -- I should probably check your repo history to see if there were any earlier bug fixes that would be useful to pick up for FreeBSD, but it sounds like we've maintained it much more aggressively. >> We should probably talk regardless as one of the big things we >> appear to be >> missing for the kernel netatalk code is a decent regression suite >> -- I have >> some casual local tests, but over the years we've picked up several >> reports >> of regressions (8 appears to have regressed with respect to >> multiple network >> interfaces being available, for example), and I know very little >> about the >> wire protocol. If you guys have any unit tests ... > > No, we don't. Only for the userlevel AFP protocol. However, that is useful to know: if I can create a VM with a netatalk- enabled FreeBSD kernel and netatalk source package from you, with minimal configuration, can I simply say "make test" or something along those lines and get test results of value? If so that can help us significantly in keeping netatalk working on the platform. >> ... for kernel netatalk services, ... > > Fwiw: > the usage of the term netatalk for the kernel implementation of the > link-layer AppleTalk protocoll is confusing. I guess the naming rules > in FreeBSD CVS joined net with atalk to form netatalk, but that's only > the name of the directory containg the atalk implementation. I think there's a bit more history to it than that. In the original BSD network stack (home of the sockets API, etc), the various directory names were net and net$proto, such as netinet. This naming convention has been continued in the FreeBSD stack - netipx, netinet6, net80211, etc. You can even find the impact of this historic BSD naming convention on systems like Solaris and Linux, where the portable header file names are things like "netinet/in.h". My guess is that the userspace components in today's netatalk project derived their name from this structure, rather than it being a convergence of names. :-) >> that would be excellent, but if not, perhaps you can provide some >> guidance >> on what sorts of units tests would be appropriate. > > From our (or at least my) perspective, we're focusing on the AFP > protocol and our ressources are sparse. Also note that Mac OS X 10.6 > will ship withouh AppleTalk. The words of dropping AppleTalk support > and the userlevel daemons atalkd and papd who use it have already been > heared twice on netatalk-dev@sf.net. Few are still using it, fewer > know it, nobody maintains it. > A year or two back in time I would have been tempted to step up and > pick up AT development and would then have asked you for some advice > on how to get to know developping networking stuff in the FreeBSD > kernel. But that was then. Right. The future of AppleTalk as a protocol is grim, but the reality is that there are moderate number of folks still using it. Or, at least, I usually get a handful of bug reports whenever I break it when sliding support forward to new kernel infrastructure changes, including this most recent one that was fallout from SMP work. :-) We'd like to keep our kernel protocol stack supporting it until our users stop using it. I don't see us doing much in the way of enhancement (although our netatalk code probably will grow support for network stack virtualization in the future, as that's a general infrastructural change appearing throughout the network stack). So in as much as we can rely on, for example, unit testing in the userspace netatalk package telling us when we introduce regressions in the kernel code, that's very helpful. Robert From julian at elischer.org Mon Aug 3 15:52:48 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 3 15:52:58 2009 Subject: small fix to netatalk In-Reply-To: <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> References: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> Message-ID: <4A7707D4.2080604@elischer.org> Robert N. M. Watson wrote: > > On 3 Aug 2009, at 09:11, Frank Lahm wrote: > >> I just subscribed here so I can't followup neatly which will break >> threading, sorry for that. >> >> If appropiate please also provide any patches upstream. Thanks! >> Though I'm not sure _what_ you're really patching here, as the patch >> doesn't match neither upstream head nor branch-2-0 ? > > This is a patch against the kernel netatalk code in FreeBSD, > specifically, against address configuration for phase I addresses. > Forgive a lack of knowledge of the netatalk project itself, but I had > assumed we basically owned the kernel bits and were supposed to make > sure they kept working, and you guys owned the userspace bits. If you > are maintaining kernel bits, then we should talk about that since I've > modified the FreeBSD netatalk kernel code heavily in the last few years > during the fine-grained locking work on it. :-) I did the original port of the netatalk stack to FreeBSD. At that time the netatalk code was floating around the network pretty much unmaintained. Looking at the netatalk site the other day it looked to me as if someone had picked up the pieces and restarted the project. I can't remember exactly what OS was supported before I got to it bit I think it may have been sun-os. In any case I added code to do all the route munging. Atalk uses address ranges rather than address masks but the FreeBSD routing code only supports binary masks. So I had to add code to express any particular range as a combination of masks.. (e.g. 0-10 is 0=7 + 8-10) I think the other BSDs picked netatalk up from FreeBSD. I don't know hte history of Linux netatalk. > > We should probably talk regardless as one of the big things we appear to > be missing for the kernel netatalk code is a decent regression suite -- > I have some casual local tests, but over the years we've picked up > several reports of regressions (8 appears to have regressed with respect > to multiple network interfaces being available, for example), and I know > very little about the wire protocol. If you guys have any unit tests for > kernel netatalk services, that would be excellent, but if not, perhaps > you can provide some guidance on what sorts of units tests would be > appropriate. > > Robert > _______________________________________________ > 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 hselasky at c2i.net Mon Aug 3 15:59:51 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 16:00:09 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> Message-ID: <200908031759.46491.hselasky@c2i.net> On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: > Hans, > So how do you want to proceed with these cache sync issues? We need to > fix this before 8.0. Hi, CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient to update the CPU cache. One reason for this is that USB needs to invalidate the same memory area multiple times. Busdma sync expects paired operation when using the PRE and POST flags, from what I understand. I do not consider this an USB issue, hence Semihalf has got the USB stack working by manually inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution however which modifies the bus_dmamap_sync() flags will break on platforms with more than 4 GByte of memory. Maybe Rafal can give a quick summar to new people at the -current list, or see previous thread on the ARM mailing list. USB needs a solution where it can call a function given a busdma mapping, preferably with an offset and length, which handles the cache sync issue and works with bounce pages on +4GB systems. --HPS From hselasky at c2i.net Mon Aug 3 16:31:49 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 16:31:56 2009 Subject: redundant and contradictory includes for USB In-Reply-To: <200908031816.55299.thierry.herbelot@free.fr> References: <200908031816.55299.thierry.herbelot@free.fr> Message-ID: <200908031831.46884.hselasky@c2i.net> On Monday 03 August 2009 18:16:54 Thierry Herbelot wrote: > /usr/include/usb.h This one is for libusb. The one is dev/usb/xxx is for the kernel interface. --HPS From thierry.herbelot at free.fr Mon Aug 3 16:34:29 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Mon Aug 3 16:34:36 2009 Subject: redundant and contradictory includes for USB Message-ID: <200908031816.55299.thierry.herbelot@free.fr> Hello, Alongside the shiny new USB stack, there are legacy usb include files which most likely should be removed : /usr/include/usb.h seems to be replaced by /usr/include/dev/usb/usb.h maybe /usr/include/usbhid.h should be replaced by /usr/include/dev/usb/usbhid.h Cheers TfH From hselasky at c2i.net Mon Aug 3 16:36:41 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 16:36:53 2009 Subject: redundant and contradictory includes for USB In-Reply-To: <200908031831.46884.hselasky@c2i.net> References: <200908031816.55299.thierry.herbelot@free.fr> <200908031831.46884.hselasky@c2i.net> Message-ID: <200908031836.37694.hselasky@c2i.net> On Monday 03 August 2009 18:31:45 Hans Petter Selasky wrote: > On Monday 03 August 2009 18:16:54 Thierry Herbelot wrote: > > /usr/include/usb.h > > This one is for libusb. The one is dev/usb/xxx is for the kernel interface. Spelling: s/The one is/The other one/ --HPS From hselasky at c2i.net Mon Aug 3 16:36:41 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 16:36:53 2009 Subject: redundant and contradictory includes for USB In-Reply-To: <200908031831.46884.hselasky@c2i.net> References: <200908031816.55299.thierry.herbelot@free.fr> <200908031831.46884.hselasky@c2i.net> Message-ID: <200908031836.37694.hselasky@c2i.net> On Monday 03 August 2009 18:31:45 Hans Petter Selasky wrote: > On Monday 03 August 2009 18:16:54 Thierry Herbelot wrote: > > /usr/include/usb.h > > This one is for libusb. The one is dev/usb/xxx is for the kernel interface. Spelling: s/The one is/The other one/ --HPS From raj at semihalf.com Mon Aug 3 16:52:51 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Aug 3 16:53:08 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908031759.46491.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> Message-ID: On 2009-08-03, at 17:59, Hans Petter Selasky wrote: > On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: >> Hans, >> So how do you want to proceed with these cache sync issues? We need >> to >> fix this before 8.0. > > Hi, > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > suffient > to update the CPU cache. One reason for this is that USB needs to > invalidate It's not only ARM, but some MIPS and PowerPC observe this as well; actually I'd expect any system with non-coherent DMA will suffer from this with current USB stack. > the same memory area multiple times. Busdma sync expects paired > operation when > using the PRE and POST flags, from what I understand. I do not > consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 > GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current > list, or see > previous thread on the ARM mailing list. This issue was discussed already: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=50307+0+archive/2009/freebsd-usb/20090628.freebsd-usb See also the beginning of this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=10461+0+archive/2009/freebsd-arm/20090726.freebsd-arm Rafal From jhb at freebsd.org Mon Aug 3 17:10:45 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 3 17:10:58 2009 Subject: possible readability improvement for i386 pcpu macros: In-Reply-To: <4A75691E.9070401@elischer.org> References: <4A75691E.9070401@elischer.org> Message-ID: <200908031305.25714.jhb@freebsd.org> On Sunday 02 August 2009 6:23:26 am Julian Elischer wrote: > > if you have to ever look at the output of the cpp then this removes a > number of things you have to puzzle over in the output of PCPU_SET() > and friends. > > > I don't know if it applies to the other architectures. It probably applies to amd64. Also, simplifying the amount of code the macros generate can reduce compile time. That is why Peter added __curthread() so that all the curthread references did not have to compile a fully expanded PCPU_GET() macro each time. It gave a noticable reduction in kernel compile time. -- John Baldwin From jhb at freebsd.org Mon Aug 3 17:10:45 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 3 17:10:59 2009 Subject: possible readability improvement for i386 pcpu macros: In-Reply-To: <4A75691E.9070401@elischer.org> References: <4A75691E.9070401@elischer.org> Message-ID: <200908031305.25714.jhb@freebsd.org> On Sunday 02 August 2009 6:23:26 am Julian Elischer wrote: > > if you have to ever look at the output of the cpp then this removes a > number of things you have to puzzle over in the output of PCPU_SET() > and friends. > > > I don't know if it applies to the other architectures. It probably applies to amd64. Also, simplifying the amount of code the macros generate can reduce compile time. That is why Peter added __curthread() so that all the curthread references did not have to compile a fully expanded PCPU_GET() macro each time. It gave a noticable reduction in kernel compile time. -- John Baldwin From julian at elischer.org Mon Aug 3 17:45:41 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 3 17:45:54 2009 Subject: possible readability improvement for i386 pcpu macros: In-Reply-To: <200908031305.25714.jhb@freebsd.org> References: <4A75691E.9070401@elischer.org> <200908031305.25714.jhb@freebsd.org> Message-ID: <4A77224A.9020706@elischer.org> John Baldwin wrote: > On Sunday 02 August 2009 6:23:26 am Julian Elischer wrote: >> if you have to ever look at the output of the cpp then this removes a >> number of things you have to puzzle over in the output of PCPU_SET() >> and friends. >> >> >> I don't know if it applies to the other architectures. > > It probably applies to amd64. Also, simplifying the amount of code the macros > generate can reduce compile time. That is why Peter added __curthread() so > that all the curthread references did not have to compile a fully expanded > PCPU_GET() macro each time. It gave a noticable reduction in kernel compile > time. > turns out it is already in amd64.. From julian at elischer.org Mon Aug 3 17:45:41 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 3 17:45:55 2009 Subject: possible readability improvement for i386 pcpu macros: In-Reply-To: <200908031305.25714.jhb@freebsd.org> References: <4A75691E.9070401@elischer.org> <200908031305.25714.jhb@freebsd.org> Message-ID: <4A77224A.9020706@elischer.org> John Baldwin wrote: > On Sunday 02 August 2009 6:23:26 am Julian Elischer wrote: >> if you have to ever look at the output of the cpp then this removes a >> number of things you have to puzzle over in the output of PCPU_SET() >> and friends. >> >> >> I don't know if it applies to the other architectures. > > It probably applies to amd64. Also, simplifying the amount of code the macros > generate can reduce compile time. That is why Peter added __curthread() so > that all the curthread references did not have to compile a fully expanded > PCPU_GET() macro each time. It gave a noticable reduction in kernel compile > time. > turns out it is already in amd64.. From ed at 80386.nl Mon Aug 3 17:46:19 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Aug 3 17:46:26 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed Message-ID: <20090803174617.GJ1292@hoeg.nl> Hi folks, I just upgraded from 26/07 to today's HEAD and during boot I get the following messages while starting jails with IPv6 addresses: in6_ifinit: insertion failed It won't create the IPv6 addresses, so I can't SSH to my jails using IPv6. I also noticed this LOR between ufs and allprison (can't copy paste the full trace right now): unmount() -> dounmount() -> mountcheckdirs() I have no idea whether this is a known LOR. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090803/96e689a1/attachment.pgp From thierry.herbelot at free.fr Mon Aug 3 17:56:47 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Mon Aug 3 17:56:53 2009 Subject: redundant and contradictory includes for USB In-Reply-To: <200908031836.37694.hselasky@c2i.net> References: <200908031816.55299.thierry.herbelot@free.fr> <200908031831.46884.hselasky@c2i.net> <200908031836.37694.hselasky@c2i.net> Message-ID: <200908031938.09783.thierry.herbelot@free.fr> Le Monday 03 August 2009, Hans Petter Selasky a ?crit : > On Monday 03 August 2009 18:31:45 Hans Petter Selasky wrote: > > On Monday 03 August 2009 18:16:54 Thierry Herbelot wrote: > > > /usr/include/usb.h > > > > This one is for libusb. The one is dev/usb/xxx is for the kernel > > interface. > > Spelling: s/The one is/The other one/ OK, then : my userland application will use /usr/include/usb.h thanks TfH > > --HPS > > > _______________________________________________ > 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 ed at 80386.nl Mon Aug 3 19:09:36 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Aug 3 19:09:44 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed In-Reply-To: <20090803174617.GJ1292@hoeg.nl> References: <20090803174617.GJ1292@hoeg.nl> Message-ID: <20090803190934.GK1292@hoeg.nl> * Ed Schouten wrote: > I just upgraded from 26/07 to today's HEAD and during boot I get the > following messages while starting jails with IPv6 addresses: > > in6_ifinit: insertion failed > > It won't create the IPv6 addresses, so I can't SSH to my jails using > IPv6. I've discussed the matter with bz@ on IRC and it seems to be an ifconfig/IPv6/INET6 problem. bz@ knows the details. ;-) -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090803/d64a3047/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Mon Aug 3 20:05:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Aug 3 20:05:16 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed In-Reply-To: <20090803190934.GK1292@hoeg.nl> References: <20090803174617.GJ1292@hoeg.nl> <20090803190934.GK1292@hoeg.nl> Message-ID: <20090803195455.I93661@maildrop.int.zabbadoz.net> On Mon, 3 Aug 2009, Ed Schouten wrote: Hi, > * Ed Schouten wrote: >> I just upgraded from 26/07 to today's HEAD and during boot I get the >> following messages while starting jails with IPv6 addresses: >> >> in6_ifinit: insertion failed >> >> It won't create the IPv6 addresses, so I can't SSH to my jails using >> IPv6. > > I've discussed the matter with bz@ on IRC and it seems to be an > ifconfig/IPv6/INET6 problem. bz@ knows the details. ;-) Run on console after boot, so if a char is missing - sorry: here's the output: ------------------------------------------------------------------------ dut# sh test.sh fxp0: flags=8802 metric 0 mtu 1500 ifconfig: ioctl (SIOCAIFADDR): File exists 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R 2001:db8::1 2001:db8::1 UH fxp0 fxp0: flags=8843 metric 0 mtu 1500 ------------------------------------------------------------------------ to this script: ------------------------------------------------------------------------ #!/bin/sh iface=fxp0 ifconfig -a inet6 | grep 2001: ndp -a | grep 2001: netstat -rn -f inet6 | grep 2001: ifconfig ${iface} | head -1 ifconfig ${iface} inet6 2001:db8::1/128 alias ifconfig ${iface} inet6 | grep 2001: ndp -a | grep 2001: netstat -rn -f inet6 | grep 2001: ifconfig ${iface} | head -1 ------------------------------------------------------------------------ Note: 1) the interface is UP at the end 2) the address didn't make it to the interface address list but I do have a permanent ndp and a FIB entry for it I then changed the script to s,fxp0,em1,g s,::1,::2,g and re-run: ------------------------------------------------------------------------ dut# sh test.sh 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R 2001:db8::1 2001:db8::1 UH fxp0 em1: flags=8802 metric 0 mtu 1500 ifconfig: ioctl (SIOCAIFADDR): File exists 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R 2001:db8::2 0:e0:81:81:13:9d em1 permanent R 2001:db8::1 2001:db8::1 UH fxp0 2001:db8::2 2001:db8::2 UH em1 em1: flags=8843 metric 0 mtu 1500 ------------------------------------------------------------------------ and a third time with ix0 and as I have test it there before I UPed the interface before to see if it makes a difference, which it didn't: ------------------------------------------------------------------------ dut# ifconfig ix0 | head -1 ix0: flags=8802 metric 0 mtu 1500 dut# ifconfig ix0 up dut# ifconfig ix0 | head -1 ix0: flags=8843 metric 0 mtu 1500 dut# sh test.sh 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R 2001:db8::2 0:e0:81:81:13:9d em1 permanent R 2001:db8::1 2001:db8::1 UH fxp0 2001:db8::2 2001:db8::2 UH em1 ix0: flags=8843 metric 0 mtu 1500 ifconfig: ioctl (SIOCAIFADDR): File exists 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R 2001:db8::2 0:e0:81:81:13:9d em1 permanent R 2001:db8::3 0:1b:21:24:ce:df ix0 permanent R 2001:db8::1 2001:db8::1 UH fxp0 2001:db8::2 2001:db8::2 UH em1 2001:db8::3 2001:db8::3 UH ix0 ix0: flags=8843 metric 0 mtu 1500 ------------------------------------------------------------------------ Strangely enough this is all Intel interfaces but Ed had seen in on bge0 as well. I hadn't seen this on lo0 at any time before. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From lists at jpru.de Mon Aug 3 20:32:32 2009 From: lists at jpru.de (Juergen Unger) Date: Mon Aug 3 20:32:45 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090802093016.GB3071@garage.freebsd.pl> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> Message-ID: <20090803203226.GE5813@jpru.ffm.jpru.de> Hi, On Sun, Aug 02, 2009 at 11:30:16AM +0200, Pawel Jakub Dawidek wrote: [...] > > > Could you guys, who can reproduce it, try this patch: > > > > > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch > > > > I tried the patch, restarted the whole thing yesterday morning > > and after less then 24 hours and approximately 3215 zfs-receive > > jobs it do not crashes anymore, but the last started zfs-receive > > jobs is hanging, cannot be killed, even not with -9. Even other > > zfs commands are hanging and cannot be killed, while zpool commands > > seems to be not affected. > > > > root 86397 0.0 0.0 3920 1308 ?? D 3:18AM 0:00.29 zfs receive -Fv zzzz/203 > > root 5001 0.0 0.0 3920 1208 0 D+ 10:45AM 0:00.00 zfs list -t snapshot > > root 5477 0.0 0.0 3920 1240 3 D+ 11:08AM 0:00.00 zfs list > > > > also the sync command I tried to execute hangs forever: > > > > root 5457 0.0 0.0 1528 492 2- D+ 11:05AM 0:00.04 sync > > > > Other parts of the system which do not have something todo with zfs > > are still working well. I will leave the machine running in this > > state, is there something I can do to retrieve other usefull information > > for you? > > If you can break into debugger and send me 'show alltrace' for starters. hmm, maybe you did not get my last mail. I put the log of this on -Juergen- -- ENOSIG From qing.li at bluecoat.com Mon Aug 3 22:02:59 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Aug 3 22:03:06 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed In-Reply-To: <20090803195455.I93661@maildrop.int.zabbadoz.net> References: <20090803174617.GJ1292@hoeg.nl> <20090803190934.GK1292@hoeg.nl> <20090803195455.I93661@maildrop.int.zabbadoz.net> Message-ID: > > I then changed the script to s,fxp0,em1,g s,::1,::2,g and re-run: > > ----------------------------------------------------------------------- > - > dut# sh test.sh > 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R > 2001:db8::1 2001:db8::1 UH fxp0 > em1: flags=8802 metric 0 mtu 1500 > ifconfig: ioctl (SIOCAIFADDR): File exists > 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R > 2001:db8::2 0:e0:81:81:13:9d em1 permanent R > 2001:db8::1 2001:db8::1 UH fxp0 > 2001:db8::2 2001:db8::2 UH em1 > em1: flags=8843 metric 0 mtu 1500 > ----------------------------------------------------------------------- Your output appears to come from either an outdated in6.c or a custom version. I expect to see something like the following for each interface address from netstat output: Destination Gateway Flags Netif expire ----------------------------------------------------------------------- 2001:db8::1 link#1 UHS lo0 2001:db8::2 link#2 UHS lo0 ----------------------------------------------------------------------- Please verify your source file. --Qing From lists at mawer.org Tue Aug 4 05:35:22 2009 From: lists at mawer.org (Antony Mawer) Date: Tue Aug 4 05:35:34 2009 Subject: 32-bit ports on amd64, ldd32 missing on FreeBSD/amd64 8.0B2 install Message-ID: I've just been tinkering with FreeBSD/amd64 from the 8.0-BETA2 install media. At this stage I'm trying to do a test deployment of a new 8.0-based 64-bit (amd64) system, running ports from an existing 32-bit 6.x system. So far there seems to be very little documentation on running 32-bit applications on amd64, so I am finding my way as I go along... In experimenting with this, I have discovered that "ldd" on amd64 is supposed to be able to automatically spawn ldd32 when run on a 32-bit binary, however even after installing the lib32 distribution I do not appear to have a "ldd32" installed in /usr/bin. Is this an accidental omission somewhere from the installation distributions? From a brief bit of digging it looks as though if I build by hand it should get built and installed, but it doesn't appear to be packaged onto the installation media. I am running: # uname -a FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 15 21:48:41 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Further, if anyone can suggest or comment on if there is a better way to do this... the plan is presently: - Clone my existing installation's /usr/local (+ related files) from a 32-bit 6.x based system to the new 8.0 based 64-bit system - Install the compat6x package - Verify applications are able to start and run per normal Are there any significant "gotchas" I should be aware of in doing this? It is more proof of concept at this stage - eventually we will rebuild all ports on 8.x (probably as 64-bit native), but in the interim I am looking for an easy way to utilise all the available memory without having to rebuild the entire system... I imagine if I ended up building 64-bit ports, their libraries going under /usr/local/lib would conflict with the 32-bit libraries that will be there; however I intend to use exclusively 32-bit packages built on the existing 6.x systems for the moment... Any advice would be appreciated.......... -- Antony From bzeeb-lists at lists.zabbadoz.net Tue Aug 4 05:45:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Aug 4 05:45:17 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed In-Reply-To: References: <20090803174617.GJ1292@hoeg.nl> <20090803190934.GK1292@hoeg.nl> <20090803195455.I93661@maildrop.int.zabbadoz.net> Message-ID: <20090804053838.I93661@maildrop.int.zabbadoz.net> On Mon, 3 Aug 2009, Li, Qing wrote: >> >> I then changed the script to s,fxp0,em1,g s,::1,::2,g and re-run: >> >> > ----------------------------------------------------------------------- >> - >> dut# sh test.sh >> 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R >> 2001:db8::1 2001:db8::1 UH fxp0 >> em1: flags=8802 metric 0 mtu 1500 >> ifconfig: ioctl (SIOCAIFADDR): File exists >> 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R >> 2001:db8::2 0:e0:81:81:13:9d em1 permanent R >> 2001:db8::1 2001:db8::1 UH fxp0 >> 2001:db8::2 2001:db8::2 UH em1 >> em1: flags=8843 metric 0 mtu > 1500 >> > ----------------------------------------------------------------------- > > > Your output appears to come from either an outdated in6.c > or a custom version. I expect to see something like the > following for each interface address from netstat output: > > Destination Gateway Flags Netif > expire > ----------------------------------------------------------------------- > 2001:db8::1 link#1 UHS lo0 > 2001:db8::2 link#2 UHS lo0 > ----------------------------------------------------------------------- Yes I would as well, unless something bad happens(tm). > Please verify your source file. bz@dut:/dut/bz/HEAD.svn% ident sys/netinet6/in6.c sys/netinet6/in6.c: $KAME: in6.c,v 1.259 2002/01/21 11:37:50 keiichi Exp $ $FreeBSD: head/sys/netinet6/in6.c 196019 2009-08-01 19:26:27Z rwatson $ bz@dut:/dut/bz/HEAD.svn% svn status sys/netinet6/in6.c bz@dut:/dut/bz/HEAD.svn% And as you can see the IFF_POINTOPOINT from your last commit are not there anymore: 1193 /* 1194 * Remove the loopback route to the interface address. 1195 * The check for the current setting of "nd6_useloopback" is not needed. 1196 */ 1197 if (!(ia->ia_ifp->if_flags & IFF_LOOPBACK)) { 1776 /* 1777 * add a loopback route to self 1778 */ 1779 if (V_nd6_useloopback && !(ifp->if_flags & IFF_LOOPBACK)) { /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From pjd at FreeBSD.org Tue Aug 4 07:34:00 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 4 07:34:07 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090803203226.GE5813@jpru.ffm.jpru.de> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> Message-ID: <20090804073416.GA4479@garage.freebsd.pl> On Mon, Aug 03, 2009 at 10:32:26PM +0200, Juergen Unger wrote: > Hi, > > On Sun, Aug 02, 2009 at 11:30:16AM +0200, Pawel Jakub Dawidek wrote: > [...] > > > > Could you guys, who can reproduce it, try this patch: > > > > > > > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch > > > > > > I tried the patch, restarted the whole thing yesterday morning > > > and after less then 24 hours and approximately 3215 zfs-receive > > > jobs it do not crashes anymore, but the last started zfs-receive > > > jobs is hanging, cannot be killed, even not with -9. Even other > > > zfs commands are hanging and cannot be killed, while zpool commands > > > seems to be not affected. > > > > > > root 86397 0.0 0.0 3920 1308 ?? D 3:18AM 0:00.29 zfs receive -Fv zzzz/203 > > > root 5001 0.0 0.0 3920 1208 0 D+ 10:45AM 0:00.00 zfs list -t snapshot > > > root 5477 0.0 0.0 3920 1240 3 D+ 11:08AM 0:00.00 zfs list > > > > > > also the sync command I tried to execute hangs forever: > > > > > > root 5457 0.0 0.0 1528 492 2- D+ 11:05AM 0:00.04 sync > > > > > > Other parts of the system which do not have something todo with zfs > > > are still working well. I will leave the machine running in this > > > state, is there something I can do to retrieve other usefull information > > > for you? > > > > If you can break into debugger and send me 'show alltrace' for starters. > > hmm, maybe you did not get my last mail. > I put the log of this on I did get it, sorry for the delay, I'm quite busy with other stuff. I need to setup machine for HEAD testing, as my current test box is running perforce version. I'd also need 'show lock 0x87aac290' from this machine if its not too late. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090804/c2e17ae9/attachment.pgp From lists at jpru.de Tue Aug 4 07:53:31 2009 From: lists at jpru.de (Juergen Unger) Date: Tue Aug 4 07:53:44 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090804073416.GA4479@garage.freebsd.pl> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> Message-ID: <20090804075329.GI5813@jpru.ffm.jpru.de> Hi Pawel, On Tue, Aug 04, 2009 at 09:34:16AM +0200, Pawel Jakub Dawidek wrote: [...] > > > If you can break into debugger and send me 'show alltrace' for starters. > > > > hmm, maybe you did not get my last mail. > > I put the log of this on > > I did get it, sorry for the delay, I'm quite busy with other stuff. I > need to setup machine for HEAD testing, as my current test box is > running perforce version. > > I'd also need 'show lock 0x87aac290' from this machine if its not too > late. testbox# sysctl debug.kdb.enter=1 KDB: enter: sysctl debug.kdb.enter [thread pid 11635 tid 100472 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> show lock 0x87aac290 class: sx name: dp->dp_config_rwlock state: XLOCK: 0x879e8480 (tid 100130, pid 172, "txg_thread_enter") waiters: shared db> bye, -Juergen- -- ENOSIG From franklahm at googlemail.com Tue Aug 4 09:45:48 2009 From: franklahm at googlemail.com (Frank Lahm) Date: Tue Aug 4 09:45:55 2009 Subject: small fix to netatalk In-Reply-To: <678AAF56-8778-4B0C-9C74-29CF440123AF@freebsd.org> References: <4242eef70908030111r79618d8fhaa5ea4a95f82d781@mail.gmail.com> <9A5E9B43-92EF-4D91-9ACC-5EEE4AF84289@FreeBSD.org> <4242eef70908030606l43c23217r8725a80045dd0cd0@mail.gmail.com> <678AAF56-8778-4B0C-9C74-29CF440123AF@freebsd.org> Message-ID: <4242eef70908040245s1d99c982i56c9a9f7cc4db02d@mail.gmail.com> 2009/8/3 Robert N. M. Watson : > > On 3 Aug 2009, at 14:06, Frank Lahm wrote: > >>> This is a patch against the kernel netatalk code in FreeBSD, >>> specifically, >>> against address configuration for phase I addresses. Forgive a lack of >>> knowledge of the netatalk project itself, but I had assumed we basically >>> owned the kernel bits and were supposed to make sure they kept working, >>> and >>> you guys owned the userspace bits. >> >> Yes, of course. >> I'm sorry to say, but apparently I was too lazy to check the relation >> between "our" sys/netatalk/*.[c|h] [1] stuff and the FreeBSD stuff. >> As it turns out we have some very old and very unmaintained code in >> our repo which was imported way back then when Netatalk was brought to >> SF.net in the first place. Since then nobody every really has worked >> on it. Current Netatalk development focuses on userspace stuff. Afaik none >> of >> us doing active development has any decent knowledge of the AppleTalk >> protocol implementations of BSD or Solaris. > > This is simplifying from many perspectives -- ?? > I should probably check your > repo history to see if there were any earlier bug fixes that would be useful > to pick up for FreeBSD, ... As said: >> As it turns out we have some very old and very unmaintained code in >> our repo which was imported way back then when Netatalk was brought to >> SF.net in the first place. Since then nobody every really has worked >> on it. > ...but it sounds like we've maintained it much more aggressively. Indeed. You have maintained it, we haven't. >>> We should probably talk regardless as one of the big things we appear to >>> be >>> missing for the kernel netatalk code is a decent regression suite -- I >>> have >>> some casual local tests, but over the years we've picked up several >>> reports >>> of regressions (8 appears to have regressed with respect to multiple >>> network >>> interfaces being available, for example), and I know very little about >>> the >>> wire protocol. If you guys have any unit tests ... >> >> No, we don't. Only for the userlevel AFP protocol. > > However, that is useful to know: if I can create a VM with a > netatalk-enabled ... Again: please in order to prevent confusion imo we should follow the naming scheme in use at every other place. The AppleTalk kernel module is called just that. Calling it the netatalk kernel module will cause confusion. Really, it confuses myself while we're talkink about it. I'm not trying to nitpick here, I'm sorry if you got that impression. > ... FreeBSD kernel and netatalk source package from you, with > minimal configuration, can I simply say "make test" or something along those > lines and get test results of value? If so that can help us significantly in > keeping netatalk working on the platform. As said: we have this for testing Netatalk's afpd against the AFP (over IP) specs [1]. Having a test suit for testing the AppleTalk stack on a platform would be nice, but as said none of the current Netatalk developers has time or interest in doing this as we're focusing on other stuff. >>> ... for kernel netatalk services, ... >> >> Fwiw: >> the usage of the term netatalk for the kernel implementation of the >> link-layer AppleTalk protocoll is confusing. I guess the naming rules >> in FreeBSD CVS joined net with atalk to form netatalk, but that's only >> the name of the directory containg the atalk implementation. > > I think there's a bit more history to it than that. In the original BSD > network stack (home of the sockets API, etc), the various directory names > were net and net$proto, such as netinet. This naming convention has been > continued in the FreeBSD stack - netipx, netinet6, net80211, etc. You can > even find the impact of this historic BSD naming convention on systems like > Solaris and Linux, where the portable header file names are things like > "netinet/in.h". My guess is that the userspace components in today's > netatalk project derived their name from this structure, rather than it > being a convergence of names. :-) Probably. ;o) >>> that would be excellent, but if not, perhaps you can provide some >>> guidance >>> on what sorts of units tests would be appropriate. >> >> From our (or at least my) perspective, we're focusing on the AFP >> protocol and our ressources are sparse. Also note that Mac OS X 10.6 >> will ship withouh AppleTalk. The words of dropping AppleTalk support >> and the userlevel daemons atalkd and papd who use it have already been >> heared twice on netatalk-dev@sf.net. Few are still using it, fewer >> know it, nobody maintains it. >> A year or two back in time I would have been tempted to step up and >> pick up AT development and would then have asked you for some advice >> on how to get to know developping networking stuff in the FreeBSD >> kernel. But that was then. > > Right. The future of AppleTalk as a protocol is grim, but the reality is > that there are moderate number of folks still using it. Or, at least, I > usually get a handful of bug reports whenever I break it when sliding > support forward to new kernel infrastructure changes, including this most > recent one that was fallout from SMP work. :-) > > We'd like to keep our kernel protocol stack supporting it until our users > stop using it. I don't see us doing much in the way of enhancement (although > our netatalk code probably will grow support for network stack > virtualization in the future, as that's a general infrastructural change > appearing throughout the network stack). So in as much as we can rely on, > for example, unit testing in the userspace netatalk package telling us when > we introduce regressions in the kernel code, that's very helpful. I highly appreciate your and anybody elses work on the AppleTalk kernel module in FreeBSD. As it stands the recommended platform for Netatalk for folks still using AT is FreeBSD, as Linux AppleTalk kernel module is broken (e.g. it generates broken RTMP packets) and the Solaris one (which lives in the Netatalk repo) is loadable but unmaintained. Regards -Frank [1] From pjd at FreeBSD.org Tue Aug 4 09:49:32 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 4 09:49:40 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090804075329.GI5813@jpru.ffm.jpru.de> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> <20090804075329.GI5813@jpru.ffm.jpru.de> Message-ID: <20090804094950.GD4479@garage.freebsd.pl> On Tue, Aug 04, 2009 at 09:53:29AM +0200, Juergen Unger wrote: > Hi Pawel, > > On Tue, Aug 04, 2009 at 09:34:16AM +0200, Pawel Jakub Dawidek wrote: > [...] > > > > If you can break into debugger and send me 'show alltrace' for starters. > > > > > > hmm, maybe you did not get my last mail. > > > I put the log of this on > > > > I did get it, sorry for the delay, I'm quite busy with other stuff. I > > need to setup machine for HEAD testing, as my current test box is > > running perforce version. > > > > I'd also need 'show lock 0x87aac290' from this machine if its not too > > late. > > testbox# sysctl debug.kdb.enter=1 > KDB: enter: sysctl debug.kdb.enter > [thread pid 11635 tid 100472 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> show lock 0x87aac290 > class: sx > name: dp->dp_config_rwlock > state: XLOCK: 0x879e8480 (tid 100130, pid 172, "txg_thread_enter") > waiters: shared > db> Could you also try something like the following from DDB: x/bx 0x879ad8a0,52 -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090804/8451cd5b/attachment.pgp From lists at jpru.de Tue Aug 4 09:56:50 2009 From: lists at jpru.de (Juergen Unger) Date: Tue Aug 4 09:56:57 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090804094950.GD4479@garage.freebsd.pl> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> <20090804075329.GI5813@jpru.ffm.jpru.de> <20090804094950.GD4479@garage.freebsd.pl> Message-ID: <20090804095648.GL5813@jpru.ffm.jpru.de> On Tue, Aug 04, 2009 at 11:49:50AM +0200, Pawel Jakub Dawidek wrote: > > testbox# sysctl debug.kdb.enter=1 > > KDB: enter: sysctl debug.kdb.enter > > [thread pid 11635 tid 100472 ] > > Stopped at kdb_enter+0x3a: movl $0,kdb_why > > db> show lock 0x87aac290 > > class: sx > > name: dp->dp_config_rwlock > > state: XLOCK: 0x879e8480 (tid 100130, pid 172, "txg_thread_enter") > > waiters: shared > > db> > > Could you also try something like the following from DDB: > > x/bx 0x879ad8a0,52 db> x/bx 0x879ad8a0,52 0x879ad8a0: 82 1a 4b 87 0 0 71 2 0 0 0 0 0 0 0 0 0x879ad8b0: 1 0 0 0 91 1a 4b 87 4 0 0 0 40 92 cb 87 0x879ad8c0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0x879ad8d0: 0 0 0 0 9 1f 4b 87 0 0 71 2 0 0 0 0 0x879ad8e0: 0 0 0 0 40 92 cb 87 e8 0 0 0 c8 0 0 0 0x879ad8f0: a8 bb db> -Juergen- -- ENOSIG From lstewart at freebsd.org Tue Aug 4 15:18:08 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Tue Aug 4 15:18:14 2009 Subject: [follow-up] FreeBSD/amd64 r195146 to r195848, fatal trap 12 under network load In-Reply-To: <4A724BA1.7050303@haruhiism.net> References: <4A6F0A35.7050809@haruhiism.net> <4A724BA1.7050303@haruhiism.net> Message-ID: <4A785110.9060705@freebsd.org> Kamigishi Rei wrote: > Kamigishi Rei wrote: >> Revisions mentioned are those which were tested by me; r195849+ has >> the corruption padded somewhere else so it might produce a panic with >> a different set of options. For reference, my test kernel uses a >> GENERIC config from May 09 snapshot without WITNESS and with >> IPFIREWALL, IPFIREWALL_DEFAULT_TO_ACCEPT and DEVICE_POLLING enabled. > r195981 (latest checkout) traps with the *GENERIC* kernel (with WITNESS > enabled). Same backtrace, same cause, and UP systems are not affected > again. > Apparently, my diagnostics patch from the previous message seems to pad > the corruption somewhere, so I can't use it to check lo_witness or other > fields of nws_mtx at the time when mtx_lock gets corrupted. > > Trap can be triggered with "ping -f -s 65507 localhost", iperf (just > "iperf -c localhost" works for me), or by generating some high-speed > network throughput (even a mysql query over localhost will do as we have > a race here). Running ping will mostly trigger the trap inside > swi_net(); iperf - inside netisr_queue_internal(). > > I will be grateful if someone could provide me some information on how > to further debug it. Currently, I suspect that there's something about > handling modspace (incorrect dereference somewhere, or something like > that). For the benefit of the list, we've finally got this reproduced on a netperf cluster node after much gnashing of teeth. Stay tuned for updates. Cheers, Lawrence From hselasky at c2i.net Tue Aug 4 15:54:53 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 4 15:55:01 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <4A7848A0.4080905@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> Message-ID: <200908041754.50244.hselasky@c2i.net> On Tuesday 04 August 2009 16:41:36 Grzegorz Bernacki wrote: > Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > > suffient to update the CPU cache. One reason for this is that USB needs > > to invalidate the same memory area multiple times. Busdma sync expects > > paired operation when using the PRE and POST flags, from what I > > understand. I do not consider this an USB issue, hence Semihalf has got > > the USB stack working by manually inserting CPU flush/invalidate calls > > into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution > > however which modifies the bus_dmamap_sync() flags will break on > > platforms with more than 4 GByte of memory. > > > > Maybe Rafal can give a quick summar to new people at the -current list, > > or see previous thread on the ARM mailing list. > > > > USB needs a solution where it can call a function given a busdma mapping, > > preferably with an offset and length, which handles the cache sync issue > > and works with bounce pages on +4GB systems. > > Hi Hans, > > New USB stack uses busdma in a little unconventional way. As you > mentioned in one of previous mails your assumptions are: > > XXX_PREXXX functions should be used prior to read/write device access. > In other words, PRE has to be a flush operation. > > XXX_POSTXXX functions should be used after read/write device access. > In other words, POST has to be an invalidate operation. > > Generally it is true, but if you look at ARM code you will find out that > it is not that simple. You assumed that after > bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there > will be no data in cache, but it that's not true. > > Cache operation are performed on cache lines (32 bytes on our ARM > device). Let's say you want to invalidate buffer with size 10 bytes. In > this case first whole cache line is invalidated ( and now all > requirements related to busdma synchronization are fulfilled, old > contents of cache is gone). The second step is to restore back into > cache 22 bytes of data which were not a part of buffer. After this > second step data are loaded into cache line (it is because our device > uses write allocate feature). > So busdma on ARM "Perform any synchronization required after an update > of host memory by the device", but we still end up with not invalidated > flush. > It is hard to fix it. We cannot just invalidate whole cache line. We > cannot also use cpu_dcache_wbinv, because this function is called after > buffer was used by device so we dont want to overwrite those data with > old cache contents. > > One possible solution is to call first > bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then > bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but > this is ugly workaround which applies probably only to ARM case. > > The second problem is that you cannot use cpu_dcache_wb(inv) function > directly because you need to handle bounce pages in USB code. I think > that duplication of busdma code makes no sense. Probably it takes less > work to add bus_dmamap_sync() before/after each transaction. > > Could you give us a quick overview of buffer handling in USB stack? I > want to understand what is the relation between > usb_pc_cpu_invalidate/flush() functions and reading/writing to USB > device? From yours previous mail I understand that invalidate is called > *before* reading and flush *before* writing. Is that true? Can we add a > functions which will be called *after* reading/writing? Hi, There are two kinds of DMA memory in USB regard: 1) Transfer descriptors are allocated in coherent DMA memory. Operation logic: 1.a) Write to descriptor. 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. 1.b.1) Write more fields to descriptor. 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. 1.c) Call usb_pc_cpu_invalidate() to clear cache. 1.d) Read status field. If not complete goto 1.c) 2) Any kernel virtual memory (which might not be coherent) 2.a.0) CPU read case: 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any data in cache for this buffer. 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. 2.b.0) CPU write case: 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data in cache to RAM for this buffer. 2.b.2) After transfer completion there is no cache operation. Anything unclear? --HPS > > If you have any questions regarding cache operation on ARM. please let > me know, I will try to answer them. > > regards, > Grzesiek From ota at j.email.ne.jp Tue Aug 4 17:46:28 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Tue Aug 4 17:46:35 2009 Subject: Annoying whitenoise sound coming from snd_hda enabled chipset In-Reply-To: <47d0403c0907291606v3dd8857bo1fd9d49b10e2555f@mail.gmail.com> References: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> <558ffc2b0907231623v2bad80bbref035bd1fd950d39@mail.gmail.com> <20090728224331.4fc5ed50.ota@j.email.ne.jp> <47d0403c0907291606v3dd8857bo1fd9d49b10e2555f@mail.gmail.com> Message-ID: <20090804134615.be30680f.ota@j.email.ne.jp> On Wed, 29 Jul 2009 19:06:27 -0400 Ben Kaduk wrote: > 2009/7/28 Yoshihiro Ota : > > On Fri, 24 Jul 2009 01:23:18 +0200 > > St?le Lyngaas wrote: > > > >> On Sat, Feb 21, 2009 at 11:01 AM, Garrett Cooper wrote: > >> > I don't know how else to describe it, but when I turn up my > >> > speakers enough (50%+) and don't have any sound playing, I hear a > >> > whitenoise hiss coming out of them. When I change webpages (nvidia > >> > driver is GIANT locked) or do something else kernel intensive it stops > >> > for a brief second, but apart from that it's an annoying trill sound > >> > almost like a mosquito humming around me waiting to be swatted. > >> > >> I suspect this is due to the CPU executing the HLT instruction. > >> > >> Try running the following command: > >> sysctl machdep.cpu_idle_hlt=0 > >> > >> -- > >> St?le Lyngaas > > > > I couldn't find such a sysctl. > > The close one was machdep.cpu_hlt. > > Setting machdep.idle from acpi to spin make my problems go away. > (None of the other options (mwait, mwait_hlt, hlt, acpi) helped.) > > -Ben Kaduk After machdep.idle, the sound went away here, too. The laptop just got hotter, however. It looks this sound only comes from one of two laptop I have. I probabry live with the sound as it is the mid. summer now. Thanks for your info, though. Hiro From pjd at FreeBSD.org Tue Aug 4 19:50:55 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 4 19:51:07 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090804095648.GL5813@jpru.ffm.jpru.de> References: <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> <20090804075329.GI5813@jpru.ffm.jpru.de> <20090804094950.GD4479@garage.freebsd.pl> <20090804095648.GL5813@jpru.ffm.jpru.de> Message-ID: <20090804195112.GB2181@garage.freebsd.pl> On Tue, Aug 04, 2009 at 11:56:48AM +0200, Juergen Unger wrote: > On Tue, Aug 04, 2009 at 11:49:50AM +0200, Pawel Jakub Dawidek wrote: > > > testbox# sysctl debug.kdb.enter=1 > > > KDB: enter: sysctl debug.kdb.enter > > > [thread pid 11635 tid 100472 ] > > > Stopped at kdb_enter+0x3a: movl $0,kdb_why > > > db> show lock 0x87aac290 > > > class: sx > > > name: dp->dp_config_rwlock > > > state: XLOCK: 0x879e8480 (tid 100130, pid 172, "txg_thread_enter") > > > waiters: shared > > > db> > > > > Could you also try something like the following from DDB: > > > > x/bx 0x879ad8a0,52 > > db> x/bx 0x879ad8a0,52 > 0x879ad8a0: 82 1a 4b 87 0 0 71 2 0 0 0 0 0 0 0 0 > 0x879ad8b0: 1 0 0 0 91 1a 4b 87 4 0 0 0 40 92 cb 87 > 0x879ad8c0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0x879ad8d0: 0 0 0 0 9 1f 4b 87 0 0 71 2 0 0 0 0 > 0x879ad8e0: 0 0 0 0 40 92 cb 87 e8 0 0 0 c8 0 0 0 > 0x879ad8f0: a8 bb > db> This is dump of ZFS-specific rrwlock that some threads are waiting for. We can see here that thread owning the lock is 0x87cb9240, which is pid 86397 (zfs recv process). I don't think we will be able to gather more info from here. I'm builing HEAD at the moment and hopefully will be able to reproduce it. Thanks for all the info. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090804/441fced3/attachment.pgp From serenity at exscape.org Tue Aug 4 20:11:44 2009 From: serenity at exscape.org (Thomas Backman) Date: Tue Aug 4 20:12:00 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090804195112.GB2181@garage.freebsd.pl> References: <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> <20090804075329.GI5813@jpru.ffm.jpru.de> <20090804094950.GD4479@garage.freebsd.pl> <20090804095648.GL5813@jpru.ffm.jpru.de> <20090804195112.GB2181@garage.freebsd.pl> Message-ID: On Aug 4, 2009, at 21:51, Pawel Jakub Dawidek wrote: > I'm builing HEAD at the moment and hopefully will be > able to reproduce it. Thanks for all the info. Hey Pawel, Sorry to bother (again!), but... If you're building HEAD, could you please look in to the send -R / zfs recv segfault? http://lists.freebsd.org/pipermail/freebsd-current/2009-July/ 010156.html for the patch by its creator, and I hosted it at http://exscape.org/temp/libzfs_sendrecv.new.patch since spacing (I guess) made the patch not work for me by copying/ pasting. It's a simple patch, fixing a big bug (not being able to replicate whole pools properly!), and it works great. For each day that passes, it feels as if this, (and your equally important zfs_vnops work, which is also pretty vital), won't make it into 8.0... Which is why I keep either reminding or bugging people who both know this stuff and can actually make it happen. ;) Regards (and apologies), Thomas From pjd at FreeBSD.org Tue Aug 4 20:25:12 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 4 20:25:25 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: References: <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> <20090802093016.GB3071@garage.freebsd.pl> <20090803203226.GE5813@jpru.ffm.jpru.de> <20090804073416.GA4479@garage.freebsd.pl> <20090804075329.GI5813@jpru.ffm.jpru.de> <20090804094950.GD4479@garage.freebsd.pl> <20090804095648.GL5813@jpru.ffm.jpru.de> <20090804195112.GB2181@garage.freebsd.pl> Message-ID: <20090804202528.GE2181@garage.freebsd.pl> On Tue, Aug 04, 2009 at 10:10:51PM +0200, Thomas Backman wrote: > > On Aug 4, 2009, at 21:51, Pawel Jakub Dawidek wrote: > >I'm builing HEAD at the moment and hopefully will be > >able to reproduce it. Thanks for all the info. > Hey Pawel, > Sorry to bother (again!), but... If you're building HEAD, could you > please look in to the send -R / zfs recv segfault? > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/ > 010156.html for the patch by its creator, and I hosted it at > http://exscape.org/temp/libzfs_sendrecv.new.patch since spacing (I guess) > made the patch not work for me by copying/ pasting. > > It's a simple patch, fixing a big bug (not being able to replicate > whole pools properly!), and it works great. For each day that passes, > it feels as if this, (and your equally important zfs_vnops work, which > is also pretty vital), won't make it into 8.0... Which is why I keep > either reminding or bugging people who both know this stuff and can > actually make it happen. ;) This patch is one of the reasons I'm building HEAD, stay tuned:) -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090804/829cc82a/attachment.pgp From jhb at freebsd.org Tue Aug 4 21:02:00 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 4 21:02:15 2009 Subject: 32-bit ports on amd64, ldd32 missing on FreeBSD/amd64 8.0B2 install In-Reply-To: References: Message-ID: <200908041701.50397.jhb@freebsd.org> On Tuesday 04 August 2009 1:03:18 am Antony Mawer wrote: > I've just been tinkering with FreeBSD/amd64 from the 8.0-BETA2 install > media. At this stage I'm trying to do a test deployment of a new > 8.0-based 64-bit (amd64) system, running ports from an existing 32-bit > 6.x system. So far there seems to be very little documentation on > running 32-bit applications on amd64, so I am finding my way as I go > along... > > In experimenting with this, I have discovered that "ldd" on amd64 is > supposed to be able to automatically spawn ldd32 when run on a 32-bit > binary, however even after installing the lib32 distribution I do not > appear to have a "ldd32" installed in /usr/bin. Is this an accidental > omission somewhere from the installation distributions? From a brief > bit of digging it looks as though if I build by hand it should get > built and installed, but it doesn't appear to be packaged onto the > installation media. I am running: > > # uname -a > FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 15 21:48:41 UTC 2009 > root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Yes, this is a bug in the lib32-make.sh release script. It also forgets to include the usr/libexec/ld-elf32.so.1 symlink. I've changed the script to use a blacklist instead of a whitelist. Also, the 'find' invocation to purge empty directories from dist's in 'make release' did not work because the '-empty' predicate does not get "updated" when a subdirectory becomes empty as a result of rmdir deleting all its children. I've fixed that by having find delete the directories itself using -delete. This works properly as find can then notice that the directory is now empty. Index: scripts/lib32-make.sh =================================================================== --- scripts/lib32-make.sh (revision 196050) +++ scripts/lib32-make.sh (working copy) @@ -5,4 +5,4 @@ # Clean the dust. cd ${RD}/trees/lib32 && \ - find . ! -path '*/libexec/*' ! -path '*/usr/lib32/*' -delete + find . -path '*/usr/share/*' -o -path '*/usr/lib/*' -delete Index: Makefile =================================================================== --- Makefile (revision 196050) +++ Makefile (working copy) @@ -651,7 +691,7 @@ # Remove all the directories we don't need. -cd ${RD}/trees && \ (find ${OTHER_DISTS} -path '*/var/empty' | xargs chflags noschg; \ - find ${OTHER_DISTS} -depth -type d -empty -print | xargs rmdir) + find ${OTHER_DISTS} -depth -type d -empty -delete) touch ${.TARGET} # -- John Baldwin From kraduk at googlemail.com Tue Aug 4 21:05:51 2009 From: kraduk at googlemail.com (chris scott) Date: Tue Aug 4 21:05:59 2009 Subject: usb pen drive detection - still no joy Message-ID: still no joy getting my corsair voyager detected works fine on laptop (linux) I posted a month or so ago tried all the suggestions but no go I have set hw.usb.ehci.no_hs=1 and the drive detects ok in usb1 mode but isnt really that usable due to the speed usb_alloc_device:1588: set address 4 failed (USB_ERR_TIMEOUT, ignored) usb_alloc_device:1626: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT! usbd_req_re_enumerate:1539: addr=4, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate:1553: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT! usbd_req_re_enumerate:1539: addr=4, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate:1553: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT! ugen4.4: <(null)> at usbus4 (disconnected) uhub_reattach_port:440: could not allocate new device! (root@X)-(21:59:13)-(~) 0 $ usbconfig ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.3: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (root@X)-(21:59:20)-(~) 0 $ pciconf -l -v | grep -i -A 4 usb device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x81791043 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x81791043 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x81791043 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x81791043 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib3@pci0:0:30:0: class=0x060401 card=0x81791043 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge $ uname -a FreeBSD carrera.snaffler.net 8.0-BETA2 FreeBSD 8.0-BETA2 #10: Mon Aug 3 05:16:53 BST 2009 root@X:/usr/obj/usr/src/sys/me amd64 $ dmesg | grep -i "usb\|uhub"| grep irq | sort -u ehci0: mem 0xfe8f7c00-0xfe8f7fff irq 23 at device 29.7 on pci0 uhci0: port 0xc400-0xc41f irq 23 at device 29.0 on pci0 uhci0: port 0xc400-0xc41f irq 23 at device 29.0 on pci0 uhci1: port 0xc480-0xc49f irq 19 at device 29.1 on pci0 uhci1: port 0xc480-0xc49f irq 19 at device 29.1 on pci0 uhci2: port 0xc800-0xc81f irq 18 at device 29.2 on pci0 uhci2: port 0xc800-0xc81f irq 18 at device 29.2 on pci0 uhci3: port 0xc880-0xc89f irq 16 at device 29.3 on pci0 uhci3: port 0xc880-0xc89f irq 16 at device 29.3 on pci0 From attilio at freebsd.org Tue Aug 4 21:45:14 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Aug 4 21:45:26 2009 Subject: spinlock held too long on reboot In-Reply-To: <3bbf2fe10907281943m2392a9f9w7c69303e6c3b91d0@mail.gmail.com> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> <226F1AFF-45D8-4E4C-BE7F-D2EDC35EC8F6@lassitu.de> <3bbf2fe10907281943m2392a9f9w7c69303e6c3b91d0@mail.gmail.com> Message-ID: <3bbf2fe10908041445j2dc4b480kd767f03c62b782c8@mail.gmail.com> 2009/7/29 Attilio Rao : > 2009/5/23 Stefan Bethke : >> I wrote: >> >>> Syncing disks, vnodes remaining...0 done >>> All buffers synced. >>> GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed. >>> Uptime: 6m32s >>> GEOM_MIRROR: Device diesel_root destroyed. >>> Rebooting... >>> cpu_reset: Stopping other CPUs >>> spin lock 0xffffffff8078c900 (sched lock 1) held by 0xffffff00014d4ab0 >>> (tid 100002) too long >>> panic: spin lock held too long >>> cpuid = 0 >>> KDB: enter: panic >>> [thread pid 77 tid 100090 ] >>> Stopped at kdb_enter+0x3d: movq $0,0x48bbd0(%rip) >>> db> bt >>> Tracing pid 77 tid 100090 td 0xffffff000457bab0 >>> kdb_enter() at kdb_enter+0x3d >>> panic() at panic+0x17b >>> _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 >>> _mtx_lock_spin() at _mtx_lock_spin+0x9e >>> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 >>> sched_balance_group() at sched_balance_group+0xc5 >>> sched_balance_group() at sched_balance_group+0x1f8 >>> sched_balance() at sched_balance+0xa2 >>> sched_clock() at sched_clock+0xf6 >>> statclock() at statclock+0xbd >>> lapic_handle_timer() at lapic_handle_timer+0x197 >>> Xtimerint() at Xtimerint+0x8c >>> --- interrupt, rip = 0xffffffff80541cc4, rsp = 0xffffff80771dba90, rbp = >>> 0xffffff80771dbab0 --- >>> DELAY() at DELAY+0x64 >>> cpu_reset() at cpu_reset+0xdd >>> boot() at boot+0x2e6 >>> reboot() at reboot+0x42 >>> syscall() at syscall+0x1a5 >>> Xfast_syscall() at Xfast_syscall+0xd0 >>> --- syscall (55, FreeBSD ELF64, reboot), rip = 0x800788eec, rsp = >>> 0x7fffffffeca8, rbp = 0 --- >> >> >> I've only seen this once. If I should encounter it again, is there >> something you'd like me to look at? > > [ Sorry, trying to add anyone who alredy reported such a problem even > if I know many of you experienced it on -STABLE] If you are experiencing this problem, you would like to test this port from rink@ on 7.2 of the new version of the patch: http://people.freebsd.org/~rink/tmp/ipi_7stable.diff while the -CURRENT version that probabilly is going to be committed soon is here: http://www.freebsd.org/~attilio/stop_nmi2.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From np at FreeBSD.org Tue Aug 4 22:58:07 2009 From: np at FreeBSD.org (Navdeep Parhar) Date: Tue Aug 4 22:58:14 2009 Subject: reproducible panic in netisr Message-ID: <20090804225806.GA54680@hub.freebsd.org> This occurs on today's HEAD + some unrelated patches. That makes it 8.0BETA2+ code. I haven't tried older builds. The system panics everytime I try to run netpipe on localhost: # NPtcp & # NPtcp -h localhost Here are the details: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x318 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80575aea stack pointer = 0x28:0xffffff803e1b65a0 frame pointer = 0x28:0xffffff803e1b65f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1093 (NPtcp) (kgdb) where #0 doadump () at pcpu.h:223 #1 0xffffffff801f424c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f4581 in db_command (last_cmdp=0xffffffff80c1e920, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f47c9 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801f6657 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805b2b22 in kdb_trap (type=12, code=0, tf=0xffffff803e1b64f0) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8085ba1e in trap_fatal (frame=0xffffff803e1b64f0, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff8085c701 in trap (frame=0xffffff803e1b64f0) at /usr/src/sys/amd64/amd64/trap.c:345 #8 0xffffffff80843327 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff80575aea in _mtx_lock_sleep (m=0xffffffff8144d867, tid=18446742974247061280, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #10 0xffffffff80575d51 in _mtx_lock_flags (m=0xffffffff8144d867, opts=0, file=0xffffffff8096b355 "/usr/src/sys/net/netisr.c", line=830) at /usr/src/sys/kern/kern_mutex.c:203 #11 0xffffffff8063430d in netisr_queue_internal (proto=1, m=0xffffff0011b19d00, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:830 #12 0xffffffff806343e8 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:860 #13 0xffffffff806306a4 in if_simloop (ifp=0xffffff0002705800, m=0xffffff0011b19d00, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:368 #14 0xffffffff806307b9 in looutput (ifp=0xffffff0002705800, m=0xffffff0011b19d00, dst=0xffffff803e1b67a0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:265 #15 0xffffffff80691158 in ip_output (m=0xffffff0011b19d00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:618 #16 0xffffffff806f46d2 in tcp_output (tp=0xffffff00119db370) at /usr/src/sys/netinet/tcp_output.c:1187 #17 0xffffffff80700b08 in tcp_usr_send (so=0xffffff0011bbf7f8, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:282 #18 0xffffffff805ea734 in sosend_generic (so=0xffffff0011bbf7f8, addr=0x0, uio=0xffffff803e1b6b00, top=0xffffff000273ee00, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1259 #19 0xffffffff805ce1de in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #20 0xffffffff805c783c in dofilewrite (td=0xffffff0002edc720, fd=3, fp=0xffffff0002b05550, auio=0xffffff803e1b6b00, offset=Variable "offset" is not available. ) at file.h:239 #21 0xffffffff805c8cf5 in kern_writev (td=0xffffff0002edc720, fd=3, auio=0xffffff803e1b6b00) at /usr/src/sys/kern/sys_generic.c:446 #22 0xffffffff805c8de0 in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:362 #23 0xffffffff8085bf5a in syscall (frame=0xffffff803e1b6c80) at /usr/src/sys/amd64/amd64/trap.c:984 #24 0xffffffff80843601 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #25 0x000000080073046c in ?? () (kgdb) f 9 #9 0xffffffff80575aea in _mtx_lock_sleep (m=0xffffffff8144d867, tid=18446742974247061280, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 407 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) info locals ts = (struct turnstile *) 0xffffff0002edda80 v = 144 owner = (volatile struct thread *) 0x90 spin_cnt = 1 sleep_cnt = 0 sleep_time = 0 (kgdb) p *m $18 = { lock_object = { lo_name = 0xffffffff8096b331 "netisr_mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff800021f680 }, mtx_lock = 4 } The fault address makes sense. TD_IS_RUNNING() accesses owner->td_state (0x90 + 0x288) = 0x318. But I'm not sure why v, which was read earlier on line 388 (v = m->mtx_lock), would ever be 0x90. My reading is that it can only be a tid or some combo of the 3 least significant bits (going by MTX_FLAGMASK). At the point of the dump, m->mtx_lock is 4 (MTX_UNOWNED). Regards, Navdeep From qing.li at bluecoat.com Tue Aug 4 23:29:35 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Aug 4 23:29:44 2009 Subject: Problem with latest HEAD and IPv6: in6_ifinit: insertion failed In-Reply-To: <20090804053838.I93661@maildrop.int.zabbadoz.net> References: <20090803174617.GJ1292@hoeg.nl> <20090803190934.GK1292@hoeg.nl> <20090803195455.I93661@maildrop.int.zabbadoz.net> <20090804053838.I93661@maildrop.int.zabbadoz.net> Message-ID: I have a patch ready, which will be committed as soon as it is approved by the release team. --Qing > -----Original Message----- > From: Bjoern A. Zeeb [mailto:bzeeb-lists@lists.zabbadoz.net] > Sent: Monday, August 03, 2009 10:45 PM > To: Li, Qing > Cc: FreeBSD Current; Qing Li > Subject: RE: Problem with latest HEAD and IPv6: in6_ifinit: insertion > failed > > On Mon, 3 Aug 2009, Li, Qing wrote: > > >> > >> I then changed the script to s,fxp0,em1,g s,::1,::2,g and re-run: > >> > >> > > --------------------------------------------------------------------- > -- > >> - > >> dut# sh test.sh > >> 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R > >> 2001:db8::1 2001:db8::1 UH fxp0 > >> em1: flags=8802 metric 0 mtu 1500 > >> ifconfig: ioctl (SIOCAIFADDR): File exists > >> 2001:db8::1 0:e0:81:81:13:ad fxp0 permanent R > >> 2001:db8::2 0:e0:81:81:13:9d em1 permanent R > >> 2001:db8::1 2001:db8::1 UH fxp0 > >> 2001:db8::2 2001:db8::2 UH em1 > >> em1: flags=8843 metric 0 mtu > > 1500 > >> > > --------------------------------------------------------------------- > -- > > > > > > Your output appears to come from either an outdated in6.c > > or a custom version. I expect to see something like the > > following for each interface address from netstat output: > > > > Destination Gateway Flags Netif > > expire > > --------------------------------------------------------------------- > -- > > 2001:db8::1 link#1 UHS lo0 > > 2001:db8::2 link#2 UHS lo0 > > --------------------------------------------------------------------- > -- > > Yes I would as well, unless something bad happens(tm). > > > Please verify your source file. > > bz@dut:/dut/bz/HEAD.svn% ident sys/netinet6/in6.c > sys/netinet6/in6.c: > $KAME: in6.c,v 1.259 2002/01/21 11:37:50 keiichi Exp $ > $FreeBSD: head/sys/netinet6/in6.c 196019 2009-08-01 19:26:27Z > rwatson $ > bz@dut:/dut/bz/HEAD.svn% svn status sys/netinet6/in6.c > bz@dut:/dut/bz/HEAD.svn% > > And as you can see the IFF_POINTOPOINT from your last commit are not > there > anymore: > > 1193 /* > 1194 * Remove the loopback route to the interface address. > 1195 * The check for the current setting of > "nd6_useloopback" is not needed. > 1196 */ > 1197 if (!(ia->ia_ifp->if_flags & IFF_LOOPBACK)) { > > 1776 /* > 1777 * add a loopback route to self > 1778 */ > 1779 if (V_nd6_useloopback && !(ifp->if_flags & > IFF_LOOPBACK)) { > > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. From jamesbrandongooch at gmail.com Wed Aug 5 04:09:17 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Wed Aug 5 04:09:24 2009 Subject: ipfw module panic on kldunload Message-ID: <179b97fb0908042048w44c8b30fp4cf819374f1dd5e9@mail.gmail.com> When unloading ipfw module, I see this: # kldunload ifpw IP firewall unloaded panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:3594 cpuid = 0 KDB: enter: panic exclusive rw IPFW static rules (IPFW static rules) r = 0 (0xffffffff8104de18) locked @ /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:4754 exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff80798700) locked @ /usr/src/sys/kern/kern_linker.c:274 ...backtrace from ddb.txt db:0:kdb.enter.panic> bt Tracing pid 1149 tid 100051 td 0xffffff000188c720 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_flags() at _mtx_lock_flags+0x135 remove_rule() at remove_rule+0x47 free_chain() at free_chain+0x3b vnet_ipfw_uninit() at vnet_ipfw_uninit+0x69 linker_file_unload() at linker_file_unload+0x4a6 kern_kldunload() at kern_kldunload+0xf3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (444, FreeBSD ELF64, kldunloadf), rip = 0x80069ceec, rsp = 0x7fffffffe328, rbp = 0xc --- I can provide a textdump if required. -Brandon From bz at FreeBSD.org Wed Aug 5 05:45:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Aug 5 05:45:15 2009 Subject: reproducible panic in netisr In-Reply-To: <20090804225806.GA54680@hub.freebsd.org> References: <20090804225806.GA54680@hub.freebsd.org> Message-ID: <20090805054115.O93661@maildrop.int.zabbadoz.net> On Tue, 4 Aug 2009, Navdeep Parhar wrote: Hi, > This occurs on today's HEAD + some unrelated patches. That makes it > 8.0BETA2+ code. I haven't tried older builds. We have finally been able to reproduce this ourselves yesterday and I might have a patch that I need to discuss with the relevant parties first, to confirm that it's correct before circulating another bug as patchh, as well as confirm some things with objdump. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From pjd at FreeBSD.org Wed Aug 5 06:50:07 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Aug 5 06:50:15 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: References: <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org> <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> Message-ID: <20090805065022.GI2181@garage.freebsd.pl> On Fri, Jul 31, 2009 at 11:05:01AM +0200, Thomas Backman wrote: > I'm able to reliably reproduce this panic, by having zfs recv destroy > a filesystem on the receiving end. > > 1) Use DDEBUG=1, I guess > 2) Create a FS on the source pool you don't care about: zfs create -o > mountpoint=/testfs source/testfs > 3) Clone a pool to another: zfs snapshot -r source@snap && zfs send -R > source@snap | zfs recv -Fvd target > 4) zfs destroy -r source/testfs > 4) zfs snapshot -r source@snap2 && zfs send -R -I snap source@snap2 | > zfs recv -Fvd target > 5) ^ Panic while receiving the FS the destroyed one is mounted under. > In my case, this was tank/root three times out of three; I then tried > creating testfs under /tmp (tank/tmp/testfs), *mounting* it under /usr/ > testfs, and it panics on receiving tank/usr: [...] I repeated precisevly those steps and it doesn't panic for me. Could you confirm that you use this patch? http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch If so, could you give me exact steps and all of them how to reproduce it? Starting with pool creation. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090805/293dfb77/attachment.pgp From hselasky at c2i.net Wed Aug 5 06:56:48 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 06:56:56 2009 Subject: usb pen drive detection - still no joy In-Reply-To: References: Message-ID: <200908050856.45748.hselasky@c2i.net> On Tuesday 04 August 2009 23:05:48 chris scott wrote: > still no joy getting my corsair voyager detected works fine on laptop > (linux) I posted a month or so ago tried all the suggestions but no go > > I have set hw.usb.ehci.no_hs=1 and the drive detects ok in usb1 mode > but isnt really that usable due to the speed > > > > usb_alloc_device:1588: set address 4 failed (USB_ERR_TIMEOUT, ignored) > usb_alloc_device:1626: getting device descriptor at addr 4 failed, > USB_ERR_TIMEOUT! > usbd_req_re_enumerate:1539: addr=4, set address failed! > (USB_ERR_TIMEOUT, ignored) > usbd_req_re_enumerate:1553: getting device descriptor at addr 4 > failed, USB_ERR_TIMEOUT! > usbd_req_re_enumerate:1539: addr=4, set address failed! > (USB_ERR_TIMEOUT, ignored) > usbd_req_re_enumerate:1553: getting device descriptor at addr 4 > failed, USB_ERR_TIMEOUT! > ugen4.4: <(null)> at usbus4 (disconnected) > uhub_reattach_port:440: could not allocate new device! > (root@X)-(21:59:13)-(~) 0 > $ usbconfig > ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST > spd=HIGH > (480Mbps) pwr=ON > ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 > md=HOST > spd=HIGH (480Mbps) pwr=SAVE > ugen4.3: at usbus4, cfg=0 md=HOST spd=LOW > (1.5Mbps) pwr=ON > (root@X)-(21:59:20)-(~) 0 > $ pciconf -l -v | grep -i -A 4 usb > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci1@pci0:0:29:1: class=0x0c0300 card=0x81791043 chip=0x27c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci2@pci0:0:29:2: class=0x0c0300 card=0x81791043 chip=0x27ca8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci3@pci0:0:29:3: class=0x0c0300 card=0x81791043 chip=0x27cb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > ehci0@pci0:0:29:7: class=0x0c0320 card=0x81791043 chip=0x27cc8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' > class = serial bus > subclass = USB > pcib3@pci0:0:30:0: class=0x060401 card=0x81791043 chip=0x244e8086 > rev=0xe1 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub > Interface to PCI Bridge' > class = bridge > > $ uname -a > FreeBSD carrera.snaffler.net 8.0-BETA2 FreeBSD 8.0-BETA2 #10: Mon Aug > 3 05:16:53 BST 2009 root@X:/usr/obj/usr/src/sys/me amd64 > > Have you tried an external USB HUB. How about another computer and other USB sticks? --HPS From nparhar at gmail.com Wed Aug 5 07:03:56 2009 From: nparhar at gmail.com (Navdeep Parhar) Date: Wed Aug 5 07:04:03 2009 Subject: reproducible panic in netisr In-Reply-To: <20090805054115.O93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> Message-ID: <20090805063417.GA10969@doormat.home> On Wed, Aug 05, 2009 at 05:43:17AM +0000, Bjoern A. Zeeb wrote: > On Tue, 4 Aug 2009, Navdeep Parhar wrote: > > Hi, > > >This occurs on today's HEAD + some unrelated patches. That makes it > >8.0BETA2+ code. I haven't tried older builds. > > We have finally been able to reproduce this ourselves yesterday and Well, it happens every single time on all of my amd64 machines. After I'd already sent my email I noticed that the netisr mutex has an odd address (pun intended :-)) m=0xffffffff8144d867 It's a bit unusual for the mutex struct to start at a completely unaligned address. I hope things are better on sparc64 etc., not everyone is as forgiving as amd64. The mutex led me to some DPCPU stuff that I didn't quite get. (kgdb) p/x dpcpu_off $2 = {0x8407d7, 0xffffff807f4037d7, 0x0 } (kgdb) p dpcpu $3 = (void *) 0xffffff8000010000 (kgdb) p &__start_set_pcpu $4 = (uintptr_t **) 0xffffffff80c0c829 (kgdb) p/x 0xffffff8000010000 - 0xffffffff80c0c829 $5 = 0xffffff807f4037d7 It's not clear why we prefer to store offsets from DPCPU_START, instead of the base address of the dpcpu area directly. On amd64, the dpcpu area for cpu 0 is above kernbase (immediately after kernbase + thread0's stack). For the other CPUs it's below kernbase. This makes the pointer arithmetic that calculates offsets more "interesting." Why have a dpcpu_off[] instead of a dpcpu_base[]? > I might have a patch that I need to discuss with the relevant parties > first, to confirm that it's correct before circulating another bug as > patchh, as well as confirm some things with objdump. I should be able to test it. As I mentioned I get a page fault everytime I run NPtcp -h localhost. Regards, Navdeep > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. > _______________________________________________ > 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 serenity at exscape.org Wed Aug 5 07:09:35 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed Aug 5 07:09:42 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090805065022.GI2181@garage.freebsd.pl> References: <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org> <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> <20090805065022.GI2181@garage.freebsd.pl> Message-ID: <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> On Aug 5, 2009, at 08:50, Pawel Jakub Dawidek wrote: > On Fri, Jul 31, 2009 at 11:05:01AM +0200, Thomas Backman wrote: >> I'm able to reliably reproduce this panic, by having zfs recv destroy >> a filesystem on the receiving end. >> >> 1) Use DDEBUG=1, I guess >> 2) Create a FS on the source pool you don't care about: zfs create -o >> mountpoint=/testfs source/testfs >> 3) Clone a pool to another: zfs snapshot -r source@snap && zfs send >> -R >> source@snap | zfs recv -Fvd target >> 4) zfs destroy -r source/testfs >> 4) zfs snapshot -r source@snap2 && zfs send -R -I snap source@snap2 | >> zfs recv -Fvd target >> 5) ^ Panic while receiving the FS the destroyed one is mounted under. >> In my case, this was tank/root three times out of three; I then tried >> creating testfs under /tmp (tank/tmp/testfs), *mounting* it under / >> usr/ >> testfs, and it panics on receiving tank/usr: > [...] > > I repeated precisevly those steps and it doesn't panic for me. > Could you confirm that you use this patch? > > http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch > > If so, could you give me exact steps and all of them how to > reproduce it? > Starting with pool creation. Yup, I'm using that patch (I diffed the diffs, heh). I'll try to write a script to recreate the panic; I hope it's as easy as in real-world conditions though. Regards, Thomas From serenity at exscape.org Wed Aug 5 07:21:27 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed Aug 5 07:21:39 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> References: <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org> <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> <20090805065022.GI2181@garage.freebsd.pl> <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> Message-ID: <3ECC4BA0-F1EF-4039-9F39-68532851B572@exscape.org> On Aug 5, 2009, at 09:09, Thomas Backman wrote: > > On Aug 5, 2009, at 08:50, Pawel Jakub Dawidek wrote: > >> On Fri, Jul 31, 2009 at 11:05:01AM +0200, Thomas Backman wrote: >>> I'm able to reliably reproduce this panic, by having zfs recv >>> destroy >>> a filesystem on the receiving end. >>> >>> 1) Use DDEBUG=1, I guess >>> 2) Create a FS on the source pool you don't care about: zfs create >>> -o >>> mountpoint=/testfs source/testfs >>> 3) Clone a pool to another: zfs snapshot -r source@snap && zfs >>> send -R >>> source@snap | zfs recv -Fvd target >>> 4) zfs destroy -r source/testfs >>> 4) zfs snapshot -r source@snap2 && zfs send -R -I snap >>> source@snap2 | >>> zfs recv -Fvd target >>> 5) ^ Panic while receiving the FS the destroyed one is mounted >>> under. >>> In my case, this was tank/root three times out of three; I then >>> tried >>> creating testfs under /tmp (tank/tmp/testfs), *mounting* it under / >>> usr/ >>> testfs, and it panics on receiving tank/usr: >> [...] >> >> I repeated precisevly those steps and it doesn't panic for me. >> Could you confirm that you use this patch? >> >> http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch >> >> If so, could you give me exact steps and all of them how to >> reproduce it? >> Starting with pool creation. > Yup, I'm using that patch (I diffed the diffs, heh). I'll try to > write a script to recreate the panic; I hope it's as easy as in real- > world conditions though. Oh! I noticed that I actually finised my test case for this panic; I thought I stopped midway, but that was something else. Here are all the details: http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006585.html (If you have the libzfs_sendrecv patch, your own vnops patch and DDEBUG=1, there's no need to patch anything at all.) Regards, Thomas From spambox at haruhiism.net Wed Aug 5 07:26:01 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Aug 5 07:26:09 2009 Subject: reproducible panic in netisr In-Reply-To: <20090805063417.GA10969@doormat.home> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: <4A793408.8030403@haruhiism.net> Navdeep Parhar wrote: > I should be able to test it. As I mentioned I get a page fault > everytime I run NPtcp -h localhost. > I'd like to point out that this has been going on for at least one month. It triggers on iperf, or ping -f, or just on mysql/pgsql queries and/or fastcgi requests for me. You must have missed the relevant posts on the lists. -- Kamigishi Rei KREI-RIPE From pjd at FreeBSD.org Wed Aug 5 09:38:07 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Aug 5 09:38:15 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <3ECC4BA0-F1EF-4039-9F39-68532851B572@exscape.org> References: <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> <20090805065022.GI2181@garage.freebsd.pl> <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> <3ECC4BA0-F1EF-4039-9F39-68532851B572@exscape.org> Message-ID: <20090805093825.GC1784@garage.freebsd.pl> On Wed, Aug 05, 2009 at 09:20:58AM +0200, Thomas Backman wrote: > Oh! I noticed that I actually finised my test case for this panic; I > thought I stopped midway, but that was something else. > Here are all the details: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006585.html > (If you have the libzfs_sendrecv patch, your own vnops patch and > DDEBUG=1, there's no need to patch anything at all.) I belive it is safe to do the following: http://people.freebsd.org/~pjd/patches/zfs_vfsops.c.2.patch Could you give it a try? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090805/907a0bdb/attachment.pgp From lwindschuh at googlemail.com Wed Aug 5 09:58:58 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Wed Aug 5 09:59:04 2009 Subject: uaudio attach panic: Giant not locked Message-ID: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> Hi. It's amazing how fast the FreeBSD 8 release process moves forward. Wow. So I updated my machine to CURRENT r196062 and use a USB audio converter. Attaching it to the machine leads to a kernel panic: ugen7.8: at usbus7 uaudio0: on usbus7 panic: lock (sleep mutex) Giant not locked @ /usr/src/sys/dev/usb/usb_request.c:312 cpuid = 1 KDB: enter: panic exclusive sx 23456789ABCDEF - USB config SX lock (23456789ABCDEF - USB config SX lock) r = 0 (0xc69a5c3c) locked @ /usr/src/sys/dev/usb/usb_device.c:1237 exclusive sx newbus (newbus) r = 0 (0xc0a9ad00) locked @ /usr/src/sys/kern/subr_bus.c:219 exclusive sx 23456789ABCDEF - USB config SX lock (23456789ABCDEF - USB config SX lock) r = 0 (0xc69a5c3c) locked @ /usr/src/sys/dev/usb/usb_device.c:1237 exclusive sx newbus (newbus) r = 0 (0xc0a9ad00) locked @ /usr/src/sys/kern/subr_bus.c:219 db:1:locks> show alllocks Process 45 (usbus7) thread 0xc6b59900 (100073) db:0:kdb.enter.default> show pcpu cpuid = 1 dynamic pcpu = 0x57b1e12 curthread = 0xc6b59900: pid 45 "usbus7" curpcb = 0xe8e99d90 fpcurthread = none idlethread = 0xc6573d80: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db:0:kdb.enter.default> bt Tracing pid 45 tid 100073 td 0xc6b59900 kdb_enter(c09cc469,c09cc469,c09d2085,e8e995f8,1,...) at kdb_enter+0x3a panic(c09d2085,c09f3eb7,c09ed67c,c09bbeff,138,...) at panic+0x136 witness_unlock(c0a896b0,8,c09bbeff,138,0,...) at witness_unlock+0xf8 _mtx_unlock_flags(c0a896b0,0,c09bbeff,138,c7a81000,...) at _mtx_unlock_flags+0xbc usbd_do_request_flags(c69a5c00,c0a896b0,e8e996d8,e8e996e0,0,...) at usbd_do_request_flags+0x11c uaudio_mixer_get(e8e99720,c05c3a60,150,c7b764a4,e8e99720,...) at uaudio_mixer_get+0x87 uaudio_mixer_add_ctl(e8e999a4,150,102,1,c0997fc8,...) at uaudio_mixer_add_ctl+0xbc uaudio_attach(c7ac1c00,c681005c,c0a37ff8,c09bca92,80000000,...) at uaudio_attach+0x1dea device_attach(c7ac1c00,4,c09ced90,a23) at device_attach+0x3a7 device_probe_and_attach(c7ac1c00,e8e99bb8,ffffffff,c69a5c00,0,...) at device_probe_and_attach+0x5c usb_probe_and_attach_sub(c69a5c00,0,c09ba6a0,4d5,c0bc9ca8,...) at usb_probe_and_attach_sub+0xde usb_probe_and_attach(c69a5c00,ff,c6988400,2,3,...) at usb_probe_and_attach+0x1d0 uhub_explore(c6988400,ff,c6bd5400,1,1,...) at uhub_explore+0x787 uhub_explore(c6bd5400,0,c09b9b29,e3,c695dd34,...) at uhub_explore+0x7b9 usb_bus_explore(c695dd34,c695ddac,c09bbde1,67,c0a8dc80,...) at usb_bus_explore+0x97 usb_process(c695dcd4,e8e99d38,c09c7984,33e,c6b42aa0,...) at usb_process+0xde fork_exit(c05fc7c0,c695dcd4,e8e99d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe8e99d70, ebp = 0 --- ... The textdump is available here: http://sites.google.com/site/lwfreebsd/Home/files/uaudio-panic.tar.gz?attredirects=0 If needed, I can produce a real coredump on a different machine or provide more information. Any ideas to solve this problem? Lucius From serenity at exscape.org Wed Aug 5 10:37:09 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed Aug 5 10:37:21 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090805093825.GC1784@garage.freebsd.pl> References: <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> <20090805065022.GI2181@garage.freebsd.pl> <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> <3ECC4BA0-F1EF-4039-9F39-68532851B572@exscape.org> <20090805093825.GC1784@garage.freebsd.pl> Message-ID: <1DA8C406-D35E-4AF3-990F-58753F305444@exscape.org> On Aug 5, 2009, at 11:38, Pawel Jakub Dawidek wrote: > On Wed, Aug 05, 2009 at 09:20:58AM +0200, Thomas Backman wrote: >> Oh! I noticed that I actually finised my test case for this panic; I >> thought I stopped midway, but that was something else. >> Here are all the details: >> http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006585.html >> (If you have the libzfs_sendrecv patch, your own vnops patch and >> DDEBUG=1, there's no need to patch anything at all.) > > I belive it is safe to do the following: > > http://people.freebsd.org/~pjd/patches/zfs_vfsops.c.2.patch > > Could you give it a try? Not right now (today), I'm afraid. I'll look in to it as soon as I can (likely tomorrow), though. Regards, Thomas From ed at 80386.nl Wed Aug 5 11:12:48 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Aug 5 11:12:55 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> Message-ID: <20090805111247.GA1292@hoeg.nl> * Lucius Windschuh wrote: > So I updated my machine to CURRENT r196062 and use a USB audio > converter. Attaching it to the machine leads to a kernel panic: > > I suspect this has something to do with the Newbus locking, which causes some pieces of code to run without Giant held, while they previously did. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090805/e04a1801/attachment.pgp From rwatson at FreeBSD.org Wed Aug 5 11:43:13 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 5 11:43:19 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <20090805111247.GA1292@hoeg.nl> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> Message-ID: On Wed, 5 Aug 2009, Ed Schouten wrote: > * Lucius Windschuh wrote: >> So I updated my machine to CURRENT r196062 and use a USB audio >> converter. Attaching it to the machine leads to a kernel panic: >> >> > > I suspect this has something to do with the Newbus locking, which causes > some pieces of code to run without Giant held, while they previously did. There's a patch in the re@ queue to re-add Giant around newbus attachment, per John Baldwin's request. However, committing that patch is stalled while issues with the svn->cvs export of the new RELENG_8 branch are resolved. I expect to see the patch go into the tree RSN. Robert N M Watson Computer Laboratory University of Cambridge From serenity at exscape.org Wed Aug 5 12:07:17 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed Aug 5 12:07:28 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090805093825.GC1784@garage.freebsd.pl> References: <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> <4A71B239.8060007@freebsd.org> <3AA3C1CB-CEF7-46CC-A9C7-1648093D679E@exsca!pe.org> <4A71BED8.7050300@freebsd.org> <20090805065022.GI2181@garage.freebsd.pl> <7C3499A8-A389-4F28-A800-B6C31B9E09C4@exscape.org> <3ECC4BA0-F1EF-4039-9F39-68532851B572@exscape.org> <20090805093825.GC1784@garage.freebsd.pl> Message-ID: <4F8F7C4A-A760-427A-A97B-92C548DA7BEE@exscape.org> On Aug 5, 2009, at 11:38, Pawel Jakub Dawidek wrote: > On Wed, Aug 05, 2009 at 09:20:58AM +0200, Thomas Backman wrote: >> Oh! I noticed that I actually finised my test case for this panic; I >> thought I stopped midway, but that was something else. >> Here are all the details: >> http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006585.html >> (If you have the libzfs_sendrecv patch, your own vnops patch and >> DDEBUG=1, there's no need to patch anything at all.) > > I belive it is safe to do the following: > > http://people.freebsd.org/~pjd/patches/zfs_vfsops.c.2.patch > > Could you give it a try? OK, I was wrong, I could give it a try now. :) It seems to work! -DDEBUG=1 and no panic. Just to be sure I tried to revert the patch, and sure enough, solaris assert panic at that line. The backup script (aka. real world test) also did not panic, which it did before. Regards, Thomas From hselasky at c2i.net Wed Aug 5 13:49:48 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 13:50:00 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <4A79865E.3060206@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> Message-ID: <200908051549.43890.hselasky@c2i.net> On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > Below is the patch with that solution. I tested it on ARM and PowerPC > and it fixes the problem. Please test it on other platforms you have to > see if there is no regression. Hi, Your patch look Ok. I will do some more testing and then commit it to USB P4. Thank you! --HPS From hselasky at c2i.net Wed Aug 5 14:03:38 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 14:03:50 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> Message-ID: <200908051603.35169.hselasky@c2i.net> On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: > On Wed, 5 Aug 2009, Ed Schouten wrote: > > * Lucius Windschuh wrote: > >> So I updated my machine to CURRENT r196062 and use a USB audio > >> converter. Attaching it to the machine leads to a kernel panic: > >> > >> > > > > I suspect this has something to do with the Newbus locking, which causes > > some pieces of code to run without Giant held, while they previously did. > > There's a patch in the re@ queue to re-add Giant around newbus attachment, > per John Baldwin's request. However, committing that patch is stalled > while issues with the svn->cvs export of the new RELENG_8 branch are > resolved. I expect to see the patch go into the tree RSN. > Try this patch: http://perforce.freebsd.org/chv.cgi?CH=167030 --HPS From hselasky at c2i.net Wed Aug 5 14:03:38 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 14:03:51 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> Message-ID: <200908051603.35169.hselasky@c2i.net> On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: > On Wed, 5 Aug 2009, Ed Schouten wrote: > > * Lucius Windschuh wrote: > >> So I updated my machine to CURRENT r196062 and use a USB audio > >> converter. Attaching it to the machine leads to a kernel panic: > >> > >> > > > > I suspect this has something to do with the Newbus locking, which causes > > some pieces of code to run without Giant held, while they previously did. > > There's a patch in the re@ queue to re-add Giant around newbus attachment, > per John Baldwin's request. However, committing that patch is stalled > while issues with the svn->cvs export of the new RELENG_8 branch are > resolved. I expect to see the patch go into the tree RSN. > Try this patch: http://perforce.freebsd.org/chv.cgi?CH=167030 --HPS From attilio at freebsd.org Wed Aug 5 14:13:33 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Aug 5 14:13:40 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <200908051603.35169.hselasky@c2i.net> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> <200908051603.35169.hselasky@c2i.net> Message-ID: <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> 2009/8/5 Hans Petter Selasky : > On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: >> On Wed, 5 Aug 2009, Ed Schouten wrote: >> > * Lucius Windschuh wrote: >> >> So I updated my machine to CURRENT r196062 and use a USB audio >> >> converter. Attaching it to the machine leads to a kernel panic: >> >> >> >> >> > >> > I suspect this has something to do with the Newbus locking, which causes >> > some pieces of code to run without Giant held, while they previously did. >> >> There's a patch in the re@ queue to re-add Giant around newbus attachment, >> per John Baldwin's request. However, committing that patch is stalled >> while issues with the svn->cvs export of the new RELENG_8 branch are >> resolved. I expect to see the patch go into the tree RSN. >> > > Try this patch: > > http://perforce.freebsd.org/chv.cgi?CH=167030 Hans, I recall of a similar problem in ukbd. I resolved it by acquiring Giant earlier in ukbd_attach(), but probabilly I could just bring it down and pass a NULL pointer to usbd_do_transfer(), right? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From hselasky at c2i.net Wed Aug 5 14:18:39 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 14:18:47 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <200908051603.35169.hselasky@c2i.net> <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> Message-ID: <200908051618.37902.hselasky@c2i.net> On Wednesday 05 August 2009 16:13:31 Attilio Rao wrote: > 2009/8/5 Hans Petter Selasky : > > On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: > >> On Wed, 5 Aug 2009, Ed Schouten wrote: > >> > * Lucius Windschuh wrote: > >> >> So I updated my machine to CURRENT r196062 and use a USB audio > >> >> converter. Attaching it to the machine leads to a kernel panic: > >> >> > >> >> > >> > > >> > I suspect this has something to do with the Newbus locking, which > >> > causes some pieces of code to run without Giant held, while they > >> > previously did. > >> > >> There's a patch in the re@ queue to re-add Giant around newbus > >> attachment, per John Baldwin's request. However, committing that patch > >> is stalled while issues with the svn->cvs export of the new RELENG_8 > >> branch are resolved. I expect to see the patch go into the tree RSN. > > > > Try this patch: > > > > http://perforce.freebsd.org/chv.cgi?CH=167030 > > Hans, > I recall of a similar problem in ukbd. I resolved it by acquiring > Giant earlier in ukbd_attach(), but probabilly I could just bring it > down and pass a NULL pointer to usbd_do_transfer(), right? Yes, correct. I've changed the Giant mutex to a NULL one in USB P4. Maybe you can fix the rest? http://perforce.freebsd.org/chv.cgi?CH=167032 --HPS From attilio at freebsd.org Wed Aug 5 14:20:10 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Aug 5 14:20:17 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <200908051618.37902.hselasky@c2i.net> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <200908051603.35169.hselasky@c2i.net> <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> <200908051618.37902.hselasky@c2i.net> Message-ID: <3bbf2fe10908050720s18580477qb3e58b066abdffc5@mail.gmail.com> 2009/8/5 Hans Petter Selasky : > On Wednesday 05 August 2009 16:13:31 Attilio Rao wrote: >> 2009/8/5 Hans Petter Selasky : >> > On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: >> >> On Wed, 5 Aug 2009, Ed Schouten wrote: >> >> > * Lucius Windschuh wrote: >> >> >> So I updated my machine to CURRENT r196062 and use a USB audio >> >> >> converter. Attaching it to the machine leads to a kernel panic: >> >> >> >> >> >> >> >> > >> >> > I suspect this has something to do with the Newbus locking, which >> >> > causes some pieces of code to run without Giant held, while they >> >> > previously did. >> >> >> >> There's a patch in the re@ queue to re-add Giant around newbus >> >> attachment, per John Baldwin's request. However, committing that patch >> >> is stalled while issues with the svn->cvs export of the new RELENG_8 >> >> branch are resolved. I expect to see the patch go into the tree RSN. >> > >> > Try this patch: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=167030 >> >> Hans, >> I recall of a similar problem in ukbd. I resolved it by acquiring >> Giant earlier in ukbd_attach(), but probabilly I could just bring it >> down and pass a NULL pointer to usbd_do_transfer(), right? > > Yes, correct. > > I've changed the Giant mutex to a NULL one in USB P4. Maybe you can fix the > rest? > > http://perforce.freebsd.org/chv.cgi?CH=167032 Of course, thanks for the submissions. Attilio -- Peace can only be achieved by understanding - A. Einstein From giovanni.trematerra at gmail.com Wed Aug 5 14:32:01 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Wed Aug 5 14:32:08 2009 Subject: spinlock held too long on reboot In-Reply-To: <3bbf2fe10908041445j2dc4b480kd767f03c62b782c8@mail.gmail.com> References: <746CE32B-BCF8-460A-982D-25341554E8FD@lassitu.de> <3bbf2fe10905221234k12c45932gb1e197143cd74b5d@mail.gmail.com> <20090522230333.X72053@maildrop.int.zabbadoz.net> <3bbf2fe10905221846q7fd1fe9cue744de61f9e12612@mail.gmail.com> <226F1AFF-45D8-4E4C-BE7F-D2EDC35EC8F6@lassitu.de> <3bbf2fe10907281943m2392a9f9w7c69303e6c3b91d0@mail.gmail.com> <3bbf2fe10908041445j2dc4b480kd767f03c62b782c8@mail.gmail.com> Message-ID: <4e6cba830908050731s25408ea2m8bd5c13003e99ef1@mail.gmail.com> On Tue, Aug 4, 2009 at 11:45 PM, Attilio Rao wrote: > > while the -CURRENT version that probabilly is going to be committed > soon is here: > http://www.freebsd.org/~attilio/stop_nmi2.diff I've never experienced such issue but I tested the patch on -CURRENT and no regression on my dual-core notebook. -- Giovanni Trematerra From attilio at freebsd.org Wed Aug 5 14:41:57 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Aug 5 14:42:20 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <200908051603.35169.hselasky@c2i.net> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> <200908051603.35169.hselasky@c2i.net> Message-ID: <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> 2009/8/5 Hans Petter Selasky : > On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: >> On Wed, 5 Aug 2009, Ed Schouten wrote: >> > * Lucius Windschuh wrote: >> >> So I updated my machine to CURRENT r196062 and use a USB audio >> >> converter. Attaching it to the machine leads to a kernel panic: >> >> >> >> >> > >> > I suspect this has something to do with the Newbus locking, which causes >> > some pieces of code to run without Giant held, while they previously did. >> >> There's a patch in the re@ queue to re-add Giant around newbus attachment, >> per John Baldwin's request. However, committing that patch is stalled >> while issues with the svn->cvs export of the new RELENG_8 branch are >> resolved. I expect to see the patch go into the tree RSN. >> > > Try this patch: > > http://perforce.freebsd.org/chv.cgi?CH=167030 Hans, I recall of a similar problem in ukbd. I resolved it by acquiring Giant earlier in ukbd_attach(), but probabilly I could just bring it down and pass a NULL pointer to usbd_do_transfer(), right? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From mike at sentex.net Wed Aug 5 15:12:31 2009 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 5 15:12:38 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A71D739.6040308@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200907301706.n6UH6HrY047414@lava.sentex.ca> <4A71D739.6040308@FreeBSD.org> Message-ID: <200908051509.n75F9V48093785@lava.sentex.ca> I did some other testing of the AHCI driver. Again, using CPU: AMD Phenom(tm) 9950 Quad-Core Processor (2608.81-MHz K8-class CPU) with RAM limited to 2G real memory = 8589934592 (8192 MB) avail memory = 2060632064 (1965 MB) ATI IXP700/800 SATA300 controller Doing some buildworld comparisons the ahci is a very tiny bit slower when a dedicated drive is used as /usr/obj #!/bin/sh cd /usr/src grep -ir blah * > /dev/null for i in `jot 5` do date echo $i newfs /dev/ad10 > /dev/null mount /dev/ad10 /usr/obj sleep 10 date time make -j8 buildworld > /var/log/build.out date sleep 20 sync umount -f /usr/obj done and changing the above to be /dev/ada1 when testing with AHCI 0(freebsd-current2)% strings buildworld.ata | grep real 1484.51 real 4049.46 user 610.31 sys 1520.44 real 4055.02 user 612.02 sys 1500.76 real 4055.16 user 618.19 sys 1494.28 real 4057.88 user 614.68 sys 1498.65 real 4059.30 user 620.87 sys 0(freebsd-current2)% strings buildworld.ahci | grep real 1510.02 real 4069.71 user 614.54 sys 1510.29 real 4071.67 user 623.93 sys 1516.05 real 4070.56 user 626.20 sys 1517.72 real 4072.88 user 624.13 sys 1520.88 real 4072.99 user 625.03 sys REAL N Min Max Median Avg Stddev ata 5 1484.51 1520.44 1498.65 1499.728 13.157529 ahci 5 1510.02 1520.88 1516.05 1514.992 4.7449837 USER N Min Max Median Avg Stddev ata 5 4049.46 4059.3 4055.16 4055.364 3.7695994 ahci 5 4069.71 4072.99 4071.67 4071.562 1.433691 SYS N Min Max Median Avg Stddev ata 5 614.54 626.2 624.13 622.766 4.6850966 ahci 5 614.54 626.2 624.13 622.766 4.6850966 Running the postmark benchmark 5 times with set size 29300 650000 set transactions 20000 set location /mnt/tmp set subdirectories 90 set number 9000 run quit on a dedicated drive that I would newfs between tests, AHCI is consistently better, sometimes wildly so. e.g PostMark v1.51 : 8/14/01 Reading configuration from file '/root/pm.pm' Creating subdirectories...Done Creating files...Done Performing transactions..........Done Deleting files...Done Deleting subdirectories...Done Time: 794 seconds total 678 seconds of transactions (29 per second) Files: 18980 created (23 per second) Creation alone: 9000 files (77 per second) Mixed with transactions: 9980 files (14 per second) 9986 read (14 per second) 10014 appended (14 per second) 18980 deleted (23 per second) Deletion alone: 8960 files (8960 per second) Mixed with transactions: 10020 files (14 per second) Data: 3748.66 megabytes read (4.72 megabytes per second) 7366.29 megabytes written (9.28 megabytes per second) x ata-create + ahci-create N Min Max Median Avg Stddev x 5 43 82 69 66.6 14.808781 + 5 67 86 77 76.8 7.5960516 x ata-create-mixed + ahci-create-mixed N Min Max Median Avg Stddev x 5 10 14 12 12.2 1.7888544 + 5 13 14 13 13.4 0.54772256 x delete-ata + delete-ahci N Min Max Median Avg Stddev x 5 1493 8960 8960 7466.6 3339.3439 + 5 8960 8960 8960 8960 0 x delete-mixed-ata + delete-mixed-ahci N Min Max Median Avg Stddev x 5 10 14 12 12.2 1.7888544 + 5 13 15 13 13.6 0.89442719 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From nox at jelal.kn-bremen.de Wed Aug 5 16:59:41 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Aug 5 16:59:54 2009 Subject: patch: (newusb) cdce failed to attach, was ignoring quirks Message-ID: <20090805165432.GA11383@triton.kn-bremen.de> I'd say the broader matches must come after the specific ones here or the quirks may not be found... (This makes at least my zaurus attach and pingable again.) Index: sys/dev/usb/net/if_cdce.c @@ -197,9 +197,6 @@ }; static const struct usb_device_id cdce_devs[] = { - {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL, 0)}, - {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_MOBILE_DIRECT_LINE_MODEL, 0)}, - {USB_VPI(USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632, CDCE_FLAG_NO_UNION)}, {USB_VPI(USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250, CDCE_FLAG_NO_UNION)}, {USB_VPI(USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX, CDCE_FLAG_NO_UNION)}, @@ -213,6 +210,9 @@ {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLA300, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC700, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC750, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, + + {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL, 0)}, + {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_MOBILE_DIRECT_LINE_MODEL, 0)}, }; static int From hselasky at c2i.net Wed Aug 5 18:00:56 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 18:01:08 2009 Subject: patch: (newusb) cdce failed to attach, was ignoring quirks In-Reply-To: <20090805165432.GA11383@triton.kn-bremen.de> References: <20090805165432.GA11383@triton.kn-bremen.de> Message-ID: <200908052000.54157.hselasky@c2i.net> On Wednesday 05 August 2009 18:54:32 Juergen Lock wrote: > I'd say the broader matches must come after the specific ones here or > the quirks may not be found... (This makes at least my zaurus attach and > pingable again.) Right! Thanks for reporting. Committed to USB P4: http://perforce.freebsd.org/chv.cgi?CH=167039 --HPS From nox at jelal.kn-bremen.de Wed Aug 5 20:02:16 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Aug 5 20:02:29 2009 Subject: patch: (newusb) cdce failed to attach, was ignoring quirks In-Reply-To: <200908052000.54157.hselasky@c2i.net> References: <20090805165432.GA11383@triton.kn-bremen.de> <200908052000.54157.hselasky@c2i.net> Message-ID: <20090805195554.GA5803@triton.kn-bremen.de> On Wed, Aug 05, 2009 at 08:00:53PM +0200, Hans Petter Selasky wrote: > On Wednesday 05 August 2009 18:54:32 Juergen Lock wrote: > > I'd say the broader matches must come after the specific ones here or > > the quirks may not be found... (This makes at least my zaurus attach and > > pingable again.) > > Right! > > Thanks for reporting. > > Committed to USB P4: > > http://perforce.freebsd.org/chv.cgi?CH=167039 You're welcome! Juergen (I was glad I was able to spot the bug myself too, given how little I know about usb... :) From stickybit at gmx.net Wed Aug 5 20:18:09 2009 From: stickybit at gmx.net (Sticky Bit) Date: Wed Aug 5 20:18:23 2009 Subject: [regression] 8.0-CURRENT amd64: SATA disks not attaching, MCP55 controller Message-ID: <200908052217.06935.stickybit@gmx.net> Hello, I have a similar problem with 8.0-CURRENT amd64 like described in PR 128686 and PR 132372 and several older ones. Short: SATA disks will not attach. Some example (please see full logs below): [...] ata3: Identifying devices: 00000001 ata3: New devices: 00000001 ata3: reiniting channel .. ata3: SATA connect time=0ms status=00000123 ata3: reset tp1 mask=01 ostat0=58 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 [...] SATA 300 controller is a MCP55 (ULTRA, not SLI) chip, which is working without any problems for years. Works fine with recent RELENG_7 amd64, but not with RELENG_8 amd64. RELENG_8 i386 seems to attach the disks. So it looks like an amd64 only bug. Should I file a new PR for it? Looks like there is no progress on this matter for months now. Is anyone working on this regression? It would be nice if someone could try to fix it. Thanks in advance! :-) I booted a recent JPSNAP of 8.0-CURRENT livefs FIXIT and saved dmesg output to an usb stick. Below are three verbose boot logs: 1.) 8.0-CURRENT amd64 where SATA disks are not attached 2.) 8.0-CURRENT i386 where SATA disks are attached 3.) 7.2-STABLE amd64 where everything works fine Hope it is useful. If you need more details please let me know. ;-) ******************************************************************************** 1.) 8.0-CURRENT amd64 where SATA disks are not attached ******************************************************************************** Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-HEAD-20090802-JPSNAP #0: Sun Aug 2 04:29:26 UTC 2009 root@build-amd64-fbsd.allbsd.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff813fb000. Preloaded mfs_root "/boot/mfsroot" at 0xffffffff813fb1d0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2612054409 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2612.05-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f 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 = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x000000000142a000 - 0x00000000d7767fff, 3593723904 bytes (877374 pages) 0x0000000100000000 - 0x000000011ffeffff, 536805376 bytes (131056 pages) avail memory = 4108021760 (3917 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf7890 00024 (v2 Nvidia) ACPI: XSDT 0xdfee3100 0004C (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: FACP 0xdfeeac80 000F4 (v3 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: DSDT 0xdfee3280 0798A (v1 NVIDIA AWRDACPI 00001000 MSFT 03000000) ACPI: FACS 0xdfee0000 00040 ACPI: SSDT 0xdfeeaec0 0028A (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xdfeeb1c0 00038 (v1 Nvidia ASUSACPI 42302E31 AWRD 00000098) ACPI: MCFG 0xdfeeb240 0003C (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: APIC 0xdfeeadc0 00098 (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 14, irq 14 MADT: Interrupt override: source 15, irq 15 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.SMCA -> bus 0 dev 1 func 1 acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff800000e000 pa 0x4000 AcpiOsDerivePciId: \\_SB_.PCI0.LEG0.PIO1 -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LEG0.PIRQ -> bus 0 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 5 7 9 10 11 14 15 Validation 0 7 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 17 Validation 0 255 N 0 17 After Disable 0 255 N 0 17 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link33: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link34: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link35: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link36: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link37: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 2 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x0369, revid=0xa2 domain=0, bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0360, revid=0xa3 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0368, revid=0xa3 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 6, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x1c40, size 6, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) pci_link31: Picked IRQ 20 with weight 0 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x036c, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02f000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link27: Picked IRQ 21 with weight 0 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x036d, revid=0xa2 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02e000, size 8, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCL:0) pci_link32: Picked IRQ 22 with weight 0 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x036e, revid=0xa1 domain=0, bus=0, slot=4, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=0 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9f0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbf0, size 2, enabled map[18]: type I/O Port, range 32, base 0x970, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb70, size 2, enabled map[20]: type I/O Port, range 32, base 0xf700, size 4, enabled map[24]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.PCI0.APSI:0) pci_link35: Picked IRQ 23 with weight 0 pcib0: slot 5 INTA routed to irq 23 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=1 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xf200, size 4, enabled map[24]: type Memory, range 32, base 0xfe02c000, size 12, enabled pcib0: matched entry for 0.5.INTB (src \\_SB_.PCI0.APSJ:0) pci_link36: Picked IRQ 20 with weight 1 pcib0: slot 5 INTB routed to irq 20 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=2 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0xf100, size 3, enabled map[14]: type I/O Port, range 32, base 0xf000, size 2, enabled map[18]: type I/O Port, range 32, base 0xef00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xee00, size 2, enabled map[20]: type I/O Port, range 32, base 0xed00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.5.INTC (src \\_SB_.PCI0.ASA2:0) pci_link37: Picked IRQ 21 with weight 1 pcib0: slot 5 INTC routed to irq 21 via \\_SB_.PCI0.ASA2 found-> vendor=0x10de, dev=0x0370, revid=0xa2 domain=0, bus=0, slot=6, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x0a (2500 ns) found-> vendor=0x10de, dev=0x0373, revid=0xa3 domain=0, bus=0, slot=8, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 8 messages, 64 bit, vector masks MSI-X supports 8 messages in maps 0x18 and 0x1c map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled map[18]: type Memory, range 32, base 0xfe029000, size 8, enabled map[1c]: type Memory, range 32, base 0xfe028000, size 4, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.APCH:0) pci_link28: Picked IRQ 22 with weight 1 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x0377, revid=0xa3 domain=0, bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x18 (6000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, 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 domain=0, 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 domain=0, 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 domain=0, bus=0, slot=24, func=3 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) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02f000 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 4.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 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=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata0: [MPSAFE] ata0: [ITHREAD] 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=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xfe02d000-0xfe02dfff irq 23 at device 5.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf700 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02d000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect time=0ms status=00000123 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect time=0ms status=00000123 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xfe02c000-0xfe02cfff irq 20 at device 5.1 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf200 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02c000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect time=0ms status=00000123 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect timeout status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xfe02b000-0xfe02bfff irq 21 at device 5.2 on pci0 atapci3: Reserved 0x10 bytes for rid 0x20 type 4 at 0xed00 atapci3: [MPSAFE] atapci3: [ITHREAD] atapci3: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02b000 ata6: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf100 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf000 ata6: SATA connect timeout status=00000000 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0xef00 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0xee00 ata7: SATA connect timeout status=00000000 ata7: [MPSAFE] ata7: [ITHREAD] pcib1: at device 6.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: prefetched decode 0xfde00000-0xfdefffff pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1102, dev=0x0002, revid=0x07 domain=0, bus=1, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib1: requested I/O range 0xdc00-0xdc1f: in range pcib1: matched entry for 1.6.INTA (src \\_SB_.PCI0.APC1:0) pci_link19: Picked IRQ 16 with weight 0 pcib1: slot 6 INTA routed to irq 16 via \\_SB_.PCI0.APC1 found-> vendor=0x1102, dev=0x7002, revid=0x07 domain=0, bus=1, slot=6, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd800, size 3, enabled pcib1: requested I/O range 0xd800-0xd807: in range found-> vendor=0x109e, dev=0x036e, revid=0x11 domain=0, bus=1, slot=7, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdeff000, size 12, enabled pcib1: requested memory range 0xfdeff000-0xfdefffff: good pcib1: matched entry for 1.7.INTA (src \\_SB_.PCI0.APC2:0) pci_link20: Picked IRQ 17 with weight 0 pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 found-> vendor=0x109e, dev=0x0878, revid=0x11 domain=0, bus=1, slot=7, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdefe000, size 12, enabled pcib1: requested memory range 0xfdefe000-0xfdefefff: good pcib1: matched entry for 1.7.INTA (src \\_SB_.PCI0.APC2:0) pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 pci1: at device 6.0 (no driver attached) pci1: at device 6.1 (no driver attached) pci1: at device 7.0 (no driver attached) pci1: at device 7.1 (no driver attached) nfe0: port 0xec00-0xec07 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 nfe0: Reserved 0x100 bytes for rid 0x18 type 3 at 0xfe029000 nfe0: Reserved 0x10 bytes for rid 0x1c type 3 at 0xfe028000 nfe0: attempting to allocate 8 MSI-X vectors (8 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 55 msi: routing MSI-X IRQ 257 to local APIC 0 vector 56 msi: routing MSI-X IRQ 258 to local APIC 0 vector 57 msi: routing MSI-X IRQ 259 to local APIC 0 vector 58 msi: routing MSI-X IRQ 260 to local APIC 0 vector 59 msi: routing MSI-X IRQ 261 to local APIC 0 vector 60 msi: routing MSI-X IRQ 262 to local APIC 0 vector 61 msi: routing MSI-X IRQ 263 to local APIC 0 vector 62 nfe0: using IRQs 256-263 for MSI-X nfe0: Using 8 MSIX messages miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:1d:60:86:3f:16 nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 15.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xe0000000-0xefffffff pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR0 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x9589, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib2: requested memory range 0xe0000000-0xefffffff: good map[18]: type Memory, range 64, base 0xfdde0000, size 16, enabled pcib2: requested memory range 0xfdde0000-0xfddeffff: good map[20]: type I/O Port, range 32, base 0xcc00, size 8, enabled pcib2: requested I/O range 0xcc00-0xccff: in range pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.APC6:0) pci_link24: Picked IRQ 16 with weight 3 pcib0: slot 15 INTA routed to irq 16 via \\_SB_.PCI0.APC6 pcib2: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0xaa08, revid=0x00 domain=0, bus=2, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfddfc000, size 14, enabled pcib2: requested memory range 0xfddfc000-0xfddfffff: good pcib0: matched entry for 0.15.INTB (src \\_SB_.PCI0.APC7:0) pci_link25: Picked IRQ 16 with weight 9 pcib0: slot 15 INTB routed to irq 16 via \\_SB_.PCI0.APC7 pcib2: slot 0 INTB is routed to irq 16 vgapci0: port 0xcc00-0xccff mem 0xe0000000-0xefffffff,0xfdde0000-0xfddeffff irq 16 at device 0.0 on pci2 pci2: at device 0.1 (no driver attached) acpi_tz0: on acpi0 ACPI Warning: \\_TZ_.THRM._PSL: Return Package type mismatch at index 0 - found [NULL Object Descriptor], expected Reference 20090521 nspredef-1058 atrtc1: port 0x70-0x73 on acpi0 atrtc1: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: 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:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 63 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. atrtc1: removed as time-of-day clock: clock atrtc has higher resolution atrtc0: registered as a time-of-day clock (resolution 1000000us) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 258310 -> 100000 procfs registered lapic: Divisor 2, Frequency 100463634 hz Timecounter "TSC" frequency 2612054409 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00010000 ata0: New devices: 00010000 md0: Preloaded image 4194304 bytes at 0xffffffff80ff9940 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: setting PIO4 on nForce MCP55 chip acd0: setting UDMA33 on nForce MCP55 chip ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR drive at ata0 as master acd0: read 6890KB/s (6890KB/s) write 1722KB/s (1722KB/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, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-RW 120mm data disc ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 uhub0: 10 ports with 10 removable, self powered ata2: reiniting channel .. ata2: SATA connect time=0ms status=00000123 ata2: reset tp1 mask=01 ostat0=58 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 ata2: reiniting channel .. ata2: SATA connect time=0ms status=00000123 ata2: reset tp1 mask=01 ostat0=58 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 ata3: Identifying devices: 00000001 ata3: New devices: 00000001 ata3: reiniting channel .. ata3: SATA connect time=0ms status=00000123 ata3: reset tp1 mask=01 ostat0=58 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 ata3: reiniting channel .. ata3: SATA connect time=0ms status=00000123 ata3: reset tp1 mask=01 ostat0=58 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 uhub1: 10 ports with 10 removable, self powered ata4: Identifying devices: 00000001 ata4: New devices: 00000001 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 ata4: reiniting channel .. ata4: SATA connect time=0ms status=00000123 ata4: reset tp1 mask=01 ostat0=58 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 umass0:0:0:-1: Attached to scbus0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 250MB (512000 512 byte sectors: 64H 32S/T 250C) ata4: reiniting channel .. ata4: SATA connect time=0ms status=00000123 ata4: reset tp1 mask=01 ostat0=58 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 ata5: Identifying devices: 00000000 ata5: New devices: 00000000 ata6: Identifying devices: 00000000 ata6: New devices: 00000000 ata7: Identifying devices: 00000000 ata7: New devices: 00000000 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 51 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 52 msi: Assigning MSI-X IRQ 259 to local APIC 1 vector 53 msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 54 msi: Assigning MSI-X IRQ 263 to local APIC 1 vector 55 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 Trying to mount root from ufs:/dev/md0 ******************************************************************************** 2.) 8.0-CURRENT i386 where SATA disks are attached ******************************************************************************** Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-HEAD-20090803-JPSNAP #0: Mon Aug 3 02:31:54 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc1539000. Preloaded mfs_root "/boot/mfsroot" at 0xc153919c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2612057115 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2612.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Data TLB: 32 entries, fully associative 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 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001826000 - 0x00000000dbf7ffff, 3665141760 bytes (894810 pages) avail memory = 3663675392 (3493 MB) Table 'FACP' at 0xdfeeac80 Table 'SSDT' at 0xdfeeaec0 Table 'HPET' at 0xdfeeb1c0 Table 'MCFG' at 0xdfeeb240 Table 'APIC' at 0xdfeeadc0 MADT: Found table at 0xdfeeadc0 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: disabled MADT: Found CPU APIC ID 3 ACPI ID 3: disabled ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00fb9d0 bios32: Entry = 0xf1e80 (c00f1e80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x1eb0 pnpbios: Found PnP BIOS data at 0xc00fc520 pnpbios: Entry = f0000:c550 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf7890 00024 (v2 Nvidia) ACPI: XSDT 0xdfee3100 0004C (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: FACP 0xdfeeac80 000F4 (v3 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: DSDT 0xdfee3280 0798A (v1 NVIDIA AWRDACPI 00001000 MSFT 03000000) ACPI: FACS 0xdfee0000 00040 ACPI: SSDT 0xdfeeaec0 0028A (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xdfeeb1c0 00038 (v1 Nvidia ASUSACPI 42302E31 AWRD 00000098) ACPI: MCFG 0xdfeeb240 0003C (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) ACPI: APIC 0xdfeeadc0 00098 (v1 Nvidia ASUSACPI 42302E31 AWRD 00000000) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 14, irq 14 MADT: Interrupt override: source 15, irq 15 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.SMCA -> bus 0 dev 1 func 1 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc7478000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.LEG0.PIO1 -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LEG0.PIRQ -> bus 0 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 5 7 9 10 11 14 15 Validation 0 7 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 17 Validation 0 255 N 0 17 After Disable 0 255 N 0 17 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link33: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link34: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link35: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link36: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link37: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 2 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x0369, revid=0xa2 domain=0, bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0360, revid=0xa3 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0368, revid=0xa3 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 6, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x1c40, size 6, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) pci_link31: Picked IRQ 20 with weight 0 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x036c, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02f000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link27: Picked IRQ 21 with weight 0 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x036d, revid=0xa2 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02e000, size 8, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCL:0) pci_link32: Picked IRQ 22 with weight 0 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x036e, revid=0xa1 domain=0, bus=0, slot=4, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=0 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9f0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbf0, size 2, enabled map[18]: type I/O Port, range 32, base 0x970, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb70, size 2, enabled map[20]: type I/O Port, range 32, base 0xf700, size 4, enabled map[24]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.PCI0.APSI:0) pci_link35: Picked IRQ 23 with weight 0 pcib0: slot 5 INTA routed to irq 23 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=1 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xf200, size 4, enabled map[24]: type Memory, range 32, base 0xfe02c000, size 12, enabled pcib0: matched entry for 0.5.INTB (src \\_SB_.PCI0.APSJ:0) pci_link36: Picked IRQ 20 with weight 1 pcib0: slot 5 INTB routed to irq 20 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=2 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0xf100, size 3, enabled map[14]: type I/O Port, range 32, base 0xf000, size 2, enabled map[18]: type I/O Port, range 32, base 0xef00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xee00, size 2, enabled map[20]: type I/O Port, range 32, base 0xed00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.5.INTC (src \\_SB_.PCI0.ASA2:0) pci_link37: Picked IRQ 21 with weight 1 pcib0: slot 5 INTC routed to irq 21 via \\_SB_.PCI0.ASA2 found-> vendor=0x10de, dev=0x0370, revid=0xa2 domain=0, bus=0, slot=6, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x0a (2500 ns) found-> vendor=0x10de, dev=0x0373, revid=0xa3 domain=0, bus=0, slot=8, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 8 messages, 64 bit, vector masks MSI-X supports 8 messages in maps 0x18 and 0x1c map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled map[18]: type Memory, range 32, base 0xfe029000, size 8, enabled map[1c]: type Memory, range 32, base 0xfe028000, size 4, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.APCH:0) pci_link28: Picked IRQ 22 with weight 1 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x0377, revid=0xa3 domain=0, bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x18 (6000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, 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 domain=0, 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 domain=0, 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 domain=0, bus=0, slot=24, func=3 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) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02f000 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 4.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 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=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata0: [MPSAFE] ata0: [ITHREAD] 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=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xfe02d000-0xfe02dfff irq 23 at device 5.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf700 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02d000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect time=0ms status=00000123 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect time=0ms status=00000123 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xfe02c000-0xfe02cfff irq 20 at device 5.1 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf200 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02c000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect time=0ms status=00000123 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect timeout status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xfe02b000-0xfe02bfff irq 21 at device 5.2 on pci0 atapci3: Reserved 0x10 bytes for rid 0x20 type 4 at 0xed00 atapci3: [MPSAFE] atapci3: [ITHREAD] atapci3: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02b000 ata6: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf100 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf000 ata6: SATA connect timeout status=00000000 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0xef00 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0xee00 ata7: SATA connect timeout status=00000000 ata7: [MPSAFE] ata7: [ITHREAD] pcib1: at device 6.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: prefetched decode 0xfde00000-0xfdefffff pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1102, dev=0x0002, revid=0x07 domain=0, bus=1, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib1: requested I/O range 0xdc00-0xdc1f: in range pcib1: matched entry for 1.6.INTA (src \\_SB_.PCI0.APC1:0) pci_link19: Picked IRQ 16 with weight 0 pcib1: slot 6 INTA routed to irq 16 via \\_SB_.PCI0.APC1 found-> vendor=0x1102, dev=0x7002, revid=0x07 domain=0, bus=1, slot=6, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd800, size 3, enabled pcib1: requested I/O range 0xd800-0xd807: in range found-> vendor=0x109e, dev=0x036e, revid=0x11 domain=0, bus=1, slot=7, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdeff000, size 12, enabled pcib1: requested memory range 0xfdeff000-0xfdefffff: good pcib1: matched entry for 1.7.INTA (src \\_SB_.PCI0.APC2:0) pci_link20: Picked IRQ 17 with weight 0 pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 found-> vendor=0x109e, dev=0x0878, revid=0x11 domain=0, bus=1, slot=7, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdefe000, size 12, enabled pcib1: requested memory range 0xfdefe000-0xfdefefff: good pcib1: matched entry for 1.7.INTA (src \\_SB_.PCI0.APC2:0) pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 pci1: at device 6.0 (no driver attached) pci1: at device 6.1 (no driver attached) pci1: at device 7.0 (no driver attached) pci1: at device 7.1 (no driver attached) nfe0: port 0xec00-0xec07 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 nfe0: Reserved 0x100 bytes for rid 0x18 type 3 at 0xfe029000 nfe0: Reserved 0x10 bytes for rid 0x1c type 3 at 0xfe028000 nfe0: attempting to allocate 8 MSI-X vectors (8 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 55 msi: routing MSI-X IRQ 257 to local APIC 0 vector 56 msi: routing MSI-X IRQ 258 to local APIC 0 vector 57 msi: routing MSI-X IRQ 259 to local APIC 0 vector 58 msi: routing MSI-X IRQ 260 to local APIC 0 vector 59 msi: routing MSI-X IRQ 261 to local APIC 0 vector 60 msi: routing MSI-X IRQ 262 to local APIC 0 vector 61 msi: routing MSI-X IRQ 263 to local APIC 0 vector 62 nfe0: using IRQs 256-263 for MSI-X nfe0: Using 8 MSIX messages miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:1d:60:86:3f:16 nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 15.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xe0000000-0xefffffff pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR0 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x9589, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib2: requested memory range 0xe0000000-0xefffffff: good map[18]: type Memory, range 64, base 0xfdde0000, size 16, enabled pcib2: requested memory range 0xfdde0000-0xfddeffff: good map[20]: type I/O Port, range 32, base 0xcc00, size 8, enabled pcib2: requested I/O range 0xcc00-0xccff: in range pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.APC6:0) pci_link24: Picked IRQ 16 with weight 3 pcib0: slot 15 INTA routed to irq 16 via \\_SB_.PCI0.APC6 pcib2: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0xaa08, revid=0x00 domain=0, bus=2, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfddfc000, size 14, enabled pcib2: requested memory range 0xfddfc000-0xfddfffff: good pcib0: matched entry for 0.15.INTB (src \\_SB_.PCI0.APC7:0) pci_link25: Picked IRQ 16 with weight 9 pcib0: slot 15 INTB routed to irq 16 via \\_SB_.PCI0.APC7 pcib2: slot 0 INTB is routed to irq 16 vgapci0: port 0xcc00-0xccff mem 0xe0000000-0xefffffff,0xfdde0000-0xfddeffff irq 16 at device 0.0 on pci2 pci2: at device 0.1 (no driver attached) acpi_tz0: on acpi0 ACPI Warning: \\_TZ_.THRM._PSL: Return Package type mismatch at index 0 - found [NULL Object Descriptor], expected Reference 20090521 nspredef-1058 atrtc1: port 0x70-0x73 on acpi0 atrtc1: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: 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:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 63 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed 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 ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. atrtc1: removed as time-of-day clock: clock atrtc has higher resolution atrtc0: registered as a time-of-day clock (resolution 1000000us) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 230097 -> 100000 procfs registered lapic: Divisor 2, Frequency 100463744 hz Timecounter "TSC" frequency 2612057115 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00010000 ata0: New devices: 00010000 md0: Preloaded image 4423680 bytes at 0xc10ffcbc usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: setting PIO4 on nForce MCP55 chip acd0: setting UDMA33 on nForce MCP55 chip acd0: DVDR drive at ata0 as master acd0: read 6890KB/s (6890KB/s) write 1722KB/s (1722KB/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, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-RW 120mm data disc ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 305245MB at ata2-master SATA300 ad4: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: nVidia check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00000001 ata3: New devices: 00000001 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 305245MB at ata3-master SATA300 ad6: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: nVidia check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ata4: Identifying devices: 00000001 ata4: New devices: 00000001 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 476940MB at ata4-master SATA300 ad8: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: nVidia check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5: Identifying devices: 00000000 ata5: New devices: 00000000 ata6: Identifying devices: 00000000 ata6: New devices: 00000000 ata7: Identifying devices: 00000000 ata7: New devices: 00000000 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 51 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 52 msi: Assigning MSI-X IRQ 259 to local APIC 1 vector 53 msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 54 msi: Assigning MSI-X IRQ 263 to local APIC 1 vector 55 WARNING: WITNESS option enabled, expect reduced performance. ugen0.1: at usbus0 uhub0: on usbus0 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 uhub0: 10 ports with 10 removable, self powered ugen1.1: at usbus1 uhub1: on usbus1 GEOM: new disk ad4 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM: new disk ad6 GEOM: new disk ad8 Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus1 umass0:0:0:-1: Attached to scbus0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 250MB (512000 512 byte sectors: 64H 32S/T 250C) Trying to mount root from ufs:/dev/md0 ******************************************************************************** 3.) 7.2-STABLE amd64 where everything works fine ******************************************************************************** Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #0 r195860: Sat Jul 25 05:28:19 CEST 2009 root@nx01.nexus.local:/usr/obj/usr/src/sys/BEASTIE Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8087b000. Preloaded elf obj module "/boot/kernel/if_nfe.ko" at 0xffffffff8087b1d0. Preloaded elf obj module "/boot/kernel/snd_emu10k1.ko" at 0xffffffff8087b6f8. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff8087bca8. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff8087c310. Preloaded elf obj module "/boot/kernel/amdtemp.ko" at 0xffffffff8087c8f8. Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0xffffffff8087ce20. Preloaded elf obj module "/boot/kernel/radeon.ko" at 0xffffffff8087d490. Preloaded elf obj module "/boot/kernel/drm.ko" at 0xffffffff8087d9f8. Calibrating clock(s) ... i8254 clock: 1193211 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2612055199 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2612.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 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 usable memory = 4285329408 (4086 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x00000000008ab000 - 0x00000000d7767fff, 3605778432 bytes (880317 pages) 0x0000000100000000 - 0x000000011ffeffff, 536805376 bytes (131056 pages) avail memory = 4119957504 (3929 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf7890/0x0024 (v 2 Nvidia) ACPI: XSDT @ 0x0xdfee3100/0x004C (v 1 Nvidia ASUSACPI 0x42302E31 AWRD 0x00000000) ACPI: FACP @ 0x0xdfeeac80/0x00F4 (v 3 Nvidia ASUSACPI 0x42302E31 AWRD 0x00000000) ACPI: DSDT @ 0x0xdfee3280/0x798A (v 1 NVIDIA AWRDACPI 0x00001000 MSFT 0x03000000) ACPI: FACS @ 0x0xdfee0000/0x0040 ACPI: SSDT @ 0x0xdfeeaec0/0x028A (v 1 PTLTD POWERNOW 0x00000001 LTP 0x00000001) ACPI: HPET @ 0x0xdfeeb1c0/0x0038 (v 1 Nvidia ASUSACPI 0x42302E31 AWRD 0x00000098) ACPI: MCFG @ 0x0xdfeeb240/0x003C (v 1 Nvidia ASUSACPI 0x42302E31 AWRD 0x00000000) ACPI: APIC @ 0x0xdfeeadc0/0x0098 (v 1 Nvidia ASUSACPI 0x42302E31 AWRD 0x00000000) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 14, irq 14 MADT: Interrupt override: source 15, irq 15 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: random: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] AcpiOsDerivePciId: \_SB_.PCI0.SMB0.SMCA -> bus 0 dev 1 func 1 acpi0: Power Button (fixed) AcpiOsDerivePciId: \_SB_.PCI0.LEG0.PIO1 -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LEG0.PIRQ -> bus 0 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 5 7 9 10 11 14 15 Validation 0 7 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 9 10 11 14 15 Validation 0 255 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 9 10 11 14 15 Validation 0 5 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 9 10 11 14 15 Validation 0 10 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 14 15 Validation 0 11 N 0 5 7 9 10 11 14 15 After Disable 0 255 N 0 5 7 9 10 11 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 17 Validation 0 255 N 0 17 After Disable 0 255 N 0 17 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link33: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link34: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link35: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link36: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link37: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 2 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x0369, revid=0xa2 domain=0, bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0360, revid=0xa3 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0368, revid=0xa3 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 6, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x1c40, size 6, enabled pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.APCS:0) pci_link31: Picked IRQ 20 with weight 0 pcib0: slot 1 INTA routed to irq 20 via \_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x036c, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02f000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \_SB_.PCI0.APCF:0) pci_link27: Picked IRQ 21 with weight 0 pcib0: slot 2 INTA routed to irq 21 via \_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x036d, revid=0xa2 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02e000, size 8, enabled pcib0: matched entry for 0.2.INTB (src \_SB_.PCI0.APCL:0) pci_link32: Picked IRQ 22 with weight 0 pcib0: slot 2 INTB routed to irq 22 via \_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x036e, revid=0xa1 domain=0, bus=0, slot=4, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=0 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9f0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbf0, size 2, enabled map[18]: type I/O Port, range 32, base 0x970, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb70, size 2, enabled map[20]: type I/O Port, range 32, base 0xf700, size 4, enabled map[24]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.5.INTA (src \_SB_.PCI0.APSI:0) pci_link35: Picked IRQ 23 with weight 0 pcib0: slot 5 INTA routed to irq 23 via \_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=1 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xf200, size 4, enabled map[24]: type Memory, range 32, base 0xfe02c000, size 12, enabled pcib0: matched entry for 0.5.INTB (src \_SB_.PCI0.APSJ:0) pci_link36: Picked IRQ 20 with weight 1 pcib0: slot 5 INTB routed to irq 20 via \_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x037f, revid=0xa3 domain=0, bus=0, slot=5, func=2 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0xf100, size 3, enabled map[14]: type I/O Port, range 32, base 0xf000, size 2, enabled map[18]: type I/O Port, range 32, base 0xef00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xee00, size 2, enabled map[20]: type I/O Port, range 32, base 0xed00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.5.INTC (src \_SB_.PCI0.ASA2:0) pci_link37: Picked IRQ 21 with weight 1 pcib0: slot 5 INTC routed to irq 21 via \_SB_.PCI0.ASA2 found-> vendor=0x10de, dev=0x0370, revid=0xa2 domain=0, bus=0, slot=6, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x0a (2500 ns) found-> vendor=0x10de, dev=0x0373, revid=0xa3 domain=0, bus=0, slot=8, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 8 messages, 64 bit, vector masks MSI-X supports 8 messages in maps 0x18 and 0x1c map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled map[14]: type I/O Port, range 32, base 0xec00, size 3, enabled map[18]: type Memory, range 32, base 0xfe029000, size 8, enabled map[1c]: type Memory, range 32, base 0xfe028000, size 4, enabled pcib0: matched entry for 0.8.INTA (src \_SB_.PCI0.APCH:0) pci_link28: Picked IRQ 22 with weight 1 pcib0: slot 8 INTA routed to irq 22 via \_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x0377, revid=0xa3 domain=0, bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x18 (6000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, 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 domain=0, 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 domain=0, 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 domain=0, bus=0, slot=24, func=3 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) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02f000 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 4.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 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=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] 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=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xfe02d000-0xfe02dfff irq 23 at device 5.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf700 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02d000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect time=0ms ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect time=0ms ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xfe02c000-0xfe02cfff irq 20 at device 5.1 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf200 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02c000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect time=0ms ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xfe02b000-0xfe02bfff irq 21 at device 5.2 on pci0 atapci3: Reserved 0x10 bytes for rid 0x20 type 4 at 0xed00 atapci3: [MPSAFE] atapci3: [ITHREAD] atapci3: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfe02b000 ata6: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf100 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf000 ata6: SATA connect status=00000000 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci3 atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0xef00 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0xee00 ata7: SATA connect status=00000000 ata7: [MPSAFE] ata7: [ITHREAD] pcib1: at device 6.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: prefetched decode 0xfde00000-0xfdefffff pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1102, dev=0x0002, revid=0x07 domain=0, bus=1, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib1: requested I/O range 0xdc00-0xdc1f: in range pcib1: matched entry for 1.6.INTA (src \_SB_.PCI0.APC1:0) pci_link19: Picked IRQ 16 with weight 0 pcib1: slot 6 INTA routed to irq 16 via \_SB_.PCI0.APC1 found-> vendor=0x1102, dev=0x7002, revid=0x07 domain=0, bus=1, slot=6, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd800, size 3, enabled pcib1: requested I/O range 0xd800-0xd807: in range found-> vendor=0x109e, dev=0x036e, revid=0x11 domain=0, bus=1, slot=7, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdeff000, size 12, enabled pcib1: requested memory range 0xfdeff000-0xfdefffff: good pcib1: matched entry for 1.7.INTA (src \_SB_.PCI0.APC2:0) pci_link20: Picked IRQ 17 with weight 0 pcib1: slot 7 INTA routed to irq 17 via \_SB_.PCI0.APC2 found-> vendor=0x109e, dev=0x0878, revid=0x11 domain=0, bus=1, slot=7, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xfdefe000, size 12, enabled pcib1: requested memory range 0xfdefe000-0xfdefefff: good pcib1: matched entry for 1.7.INTA (src \_SB_.PCI0.APC2:0) pcib1: slot 7 INTA routed to irq 17 via \_SB_.PCI0.APC2 pcm0: port 0xdc00-0xdc1f irq 16 at device 6.0 on pci1 pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xdc00 emu: setmap (465a000, 800), nseg=1, error=0 emu: setmap (4659000, 1000), nseg=1, error=0 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features surround DAC pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": ioapic0: routing intpin 16 (PCI IRQ 16) to vector 55 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: clone manager: deadline=750ms flags=0x8000001e emu: setmap (4689000, 1000), nseg=1, error=0 emu: setmap (4687000, 1000), nseg=1, error=0 emu: setmap (4685000, 1000), nseg=1, error=0 emu: setmap (4683000, 1000), nseg=1, error=0 pcm0: sndbuf_setmap 4680000, 1000; 0xffffff0004680000 -> 4680000 pcm0: sndbuf_setmap 467e000, 1000; 0xffffff000467e000 -> 467e000 pci1: at device 7.0 (no driver attached) pci1: at device 7.1 (no driver attached) nfe0: port 0xec00-0xec07 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 nfe0: Reserved 0x100 bytes for rid 0x18 type 3 at 0xfe029000 nfe0: Reserved 0x10 bytes for rid 0x1c type 3 at 0xfe028000 nfe0: attempting to allocate 8 MSI-X vectors (8 supported) msi: routing MSI-X IRQ 256 to vector 56 msi: routing MSI-X IRQ 257 to vector 57 msi: routing MSI-X IRQ 258 to vector 58 msi: routing MSI-X IRQ 259 to vector 59 msi: routing MSI-X IRQ 260 to vector 60 msi: routing MSI-X IRQ 261 to vector 61 msi: routing MSI-X IRQ 262 to vector 62 msi: routing MSI-X IRQ 263 to vector 63 nfe0: using IRQs 256-263 for MSI-X nfe0: Using 8 MSIX messages miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:1d:60:86:3f:16 nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 15.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xe0000000-0xefffffff pcib2: could not get PCI interrupt routing table for \_SB_.PCI0.XVR0 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x9589, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib2: requested memory range 0xe0000000-0xefffffff: good map[18]: type Memory, range 64, base 0xfdde0000, size 16, enabled pcib2: requested memory range 0xfdde0000-0xfddeffff: good map[20]: type I/O Port, range 32, base 0xcc00, size 8, enabled pcib2: requested I/O range 0xcc00-0xccff: in range pcib0: matched entry for 0.15.INTA (src \_SB_.PCI0.APC6:0) pci_link24: Picked IRQ 16 with weight 3 pcib0: slot 15 INTA routed to irq 16 via \_SB_.PCI0.APC6 pcib2: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0xaa08, revid=0x00 domain=0, bus=2, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfddfc000, size 14, enabled pcib2: requested memory range 0xfddfc000-0xfddfffff: good pcib0: matched entry for 0.15.INTB (src \_SB_.PCI0.APC7:0) pci_link25: Picked IRQ 16 with weight 9 pcib0: slot 15 INTB routed to irq 16 via \_SB_.PCI0.APC7 pcib2: slot 0 INTB is routed to irq 16 vgapci0: port 0xcc00-0xccff mem 0xe0000000-0xefffffff,0xfdde0000-0xfddeffff irq 16 at device 0.0 on pci2 drm0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to vector 64 vgapci0: using IRQ 264 for MSI info: [drm] MSI enabled 1 message(s) vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xfdde0000 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 hdac0: mem 0xfddfc000-0xfddfffff irq 16 at device 0.1 on pci2 hdac0: HDA Driver Revision: 20090624_0136 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfddfc000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to vector 65 hdac0: using IRQ 265 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] amdtemp0: on hostb3 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: 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:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 66 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 atkbdc: atkbdc0 already exists; skipping it 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 0xc0000-0xcffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0 failed to probe at port 0x3f8 irq 4 on isa0 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 ums0: on uhub0 ums0: 6 buttons and Z dir. Device configuration finished. Reducing kern.maxvnodes 259045 -> 100000 procfs registered lapic: Divisor 2, Frequency 100463669 hz Timecounter "TSC" frequency 2612055199 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: setting PIO4 on nForce MCP55 chip acd0: setting UDMA33 on nForce MCP55 chip acd0: DVDR drive at ata0 as master acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/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, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 305245MB at ata2-master SATA300 ad4: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 305245MB at ata3-master SATA300 ad6: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire GEOM: new disk ad4 GEOM: new disk ad6 ad8: 476940MB at ata4-master SATA300 ad8: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue hdac0: Probing codec #0... hdac0: HDA Codec #0: ATI R6xx HDMI hdac0: HDA Codec ID: 0x1002aa01 hdac0: Vendor: 0x1002 hdac0: Device: 0xaa01 hdac0: Revision: 0x00 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0xaa081458 hdac0: Found audio FG nid=1 startnode=2 endnode=4 total=2 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x00000000 NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdac0: nid 3 0x18560010 as 1 seq 0 Digital-out Jack jack 6 loc 24 color Unknown misc 0 hdac0: Patched pins configuration: hdac0: nid 3 0x18560010 as 1 seq 0 Digital-out Jack jack 6 loc 24 color Unknown misc 0 hdac0: 1 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=3 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 3 traced to DAC 2 hdac0: Association 0 (1) trace succeeded hdac0: Tracing input monitor hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00020040 hdac0: 16 bits, 48 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x00000201 hdac0: DIGITAL STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00020040 hdac0: 16 bits, 48 KHz hdac0: hdac0: nid: 3 hdac0: Name: pin: Digital-out (Jack) hdac0: Widget cap: 0x00400381 hdac0: DIGITAL UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x00000094 hdac0: PDC OUT hdac0: Pin config: 0x18560010 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000005 pcm1: AC3 PCM pcm1: PCM cap: 0x00020040 pcm1: 16 bits, 48 KHz pcm1: DAC: 2 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=3 [pin: Digital-out (Jack)] pcm1: | pcm1: + <- nid=2 [audio output] [src: pcm] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 11ffb0000, 4000; 0xffffff80761e5000 -> 11ffb0000 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 msi: Assigning MSI-X IRQ 256 to local APIC 1 msi: Assigning MSI-X IRQ 257 to local APIC 0 msi: Assigning MSI-X IRQ 258 to local APIC 1 msi: Assigning MSI-X IRQ 259 to local APIC 0 msi: Assigning MSI-X IRQ 260 to local APIC 1 msi: Assigning MSI-X IRQ 261 to local APIC 0 msi: Assigning MSI-X IRQ 262 to local APIC 1 msi: Assigning MSI-X IRQ 263 to local APIC 0 msi: Assigning MSI IRQ 265 to local APIC 1 GEOM: new disk ad8 GEOM_JOURNAL: Journal 3957365166: ad8p5 contains journal. GEOM_JOURNAL: Journal 3957365166: ad8p6 contains data. GEOM_JOURNAL: Journal ad8p6 clean. GEOM_JOURNAL: Journal 3080637776: ad8p7 contains journal. GEOM_JOURNAL: Journal 3080637776: ad8p8 contains data. GEOM_JOURNAL: Journal ad8p8 clean. GEOM_JOURNAL: Journal 3804427845: ad8p9 contains journal. GEOM_JOURNAL: Journal 3804427845: ad8p10 contains data. GEOM_JOURNAL: Journal ad8p10 clean. GEOM_JOURNAL: Journal 2042519215: ad8p11 contains journal. GEOM_JOURNAL: Journal 2042519215: ad8p12 contains data. GEOM_JOURNAL: Journal ad8p12 clean. GEOM_JOURNAL: Journal 2341797152: ad8p14 contains journal. GEOM_JOURNAL: Journal 2341797152: ad8p15 contains data. GEOM_JOURNAL: Journal ad8p15 clean. GEOM_JOURNAL: Journal 4137560276: ad8p16 contains journal. GEOM_JOURNAL: Journal 4137560276: ad8p17 contains data. GEOM_JOURNAL: Journal ad8p17 clean. GEOM_JOURNAL: Journal 3657364065: ad8p18 contains journal. GEOM_JOURNAL: Journal 3657364065: ad8p19 contains data. GEOM_JOURNAL: Journal ad8p19 clean. Trying to mount root from ufs:/dev/ad8p2 -- Regards From lwindschuh at googlemail.com Wed Aug 5 22:02:00 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Wed Aug 5 22:02:07 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: <200908051618.37902.hselasky@c2i.net> References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <200908051603.35169.hselasky@c2i.net> <3bbf2fe10908050713r79066277hd8822161b78222f@mail.gmail.com> <200908051618.37902.hselasky@c2i.net> Message-ID: <90a5caac0908051453p2250125aq364f5d47f1b6c027@mail.gmail.com> 2009/8/5 Hans Petter Selasky : > On Wednesday 05 August 2009 16:13:31 Attilio Rao wrote: >> 2009/8/5 Hans Petter Selasky : >> > On Wednesday 05 August 2009 13:43:11 Robert Watson wrote: >> >> On Wed, 5 Aug 2009, Ed Schouten wrote: >> >> > * Lucius Windschuh wrote: >> >> >> So I updated my machine to CURRENT r196062 and use a USB audio >> >> >> converter. Attaching it to the machine leads to a kernel panic: >> >> >> >> >> >> >> >> > >> >> > I suspect this has something to do with the Newbus locking, which >> >> > causes some pieces of code to run without Giant held, while they >> >> > previously did. >> >> >> >> There's a patch in the re@ queue to re-add Giant around newbus >> >> attachment, per John Baldwin's request. ?However, committing that patch >> >> is stalled while issues with the svn->cvs export of the new RELENG_8 >> >> branch are resolved. ?I expect to see the patch go into the tree RSN. >> > >> > Try this patch: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=167030 > http://perforce.freebsd.org/chv.cgi?CH=167032 I applied both diffs to the usb_do_request calls and my sound adaptor is usable again. Thanks for the fast reply. Lucius From rwatson at FreeBSD.org Wed Aug 5 23:17:12 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 5 23:17:45 2009 Subject: reproducible panic in netisr In-Reply-To: <20090805063417.GA10969@doormat.home> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: On Tue, 4 Aug 2009, Navdeep Parhar wrote: >>> This occurs on today's HEAD + some unrelated patches. That makes it >>> 8.0BETA2+ code. I haven't tried older builds. >> >> We have finally been able to reproduce this ourselves yesterday and > > Well, it happens every single time on all of my amd64 machines. After I'd > already sent my email I noticed that the netisr mutex has an odd address > (pun intended :-)) > > m=0xffffffff8144d867 Heh, indeed. We just spotted the same result here. In this case it's causing a panic because it leads to a non-atomic read due to mtx_lock spanning a cache line boundary, followed shortly by a panic because it's not a valid thread pointer when it's dereferenced, as we get a fractional pointer. > It's a bit unusual for the mutex struct to start at a completely unaligned > address. I hope things are better on sparc64 etc., not everyone is as > forgiving as amd64. amd64 isn't as forgiving either, it turns out. :-) > The mutex led me to some DPCPU stuff that I didn't quite get. > > (kgdb) p/x dpcpu_off > $2 = {0x8407d7, 0xffffff807f4037d7, 0x0 } > (kgdb) p dpcpu > $3 = (void *) 0xffffff8000010000 > (kgdb) p &__start_set_pcpu > $4 = (uintptr_t **) 0xffffffff80c0c829 > (kgdb) p/x 0xffffff8000010000 - 0xffffffff80c0c829 > $5 = 0xffffff807f4037d7 > > It's not clear why we prefer to store offsets from DPCPU_START, instead of > the base address of the dpcpu area directly. On amd64, the dpcpu area for > cpu 0 is above kernbase (immediately after kernbase + thread0's stack). > For the other CPUs it's below kernbase. This makes the pointer arithmetic > that calculates offsets more "interesting." > > Why have a dpcpu_off[] instead of a dpcpu_base[]? Each field in DPCPU is named with respect to the start of a "master" dpcpu copy, which holds the static initialization. This makes the per-CPU name: (&master_name_for_variable - DPCPU_START) + per-cpu-base What Jeff has done is factor out the DPCPU_START subtraction, since it's a constant subtraction across all DPCPU use, and do it once when calculating dpcpu_off. This should all be fine, the question is why we're losing the alignment during linking of the kernel. netisr is linked into the base kernel, so I guess it's some problem with the way the linker set is being laid out at compile-time. I expect we may have a similar issue with the run-time allocation of DPCPU space as well. Robert N M Watson Computer Laboratory University of Cambridge From oberman at es.net Wed Aug 5 23:28:55 2009 From: oberman at es.net (Kevin Oberman) Date: Wed Aug 5 23:29:01 2009 Subject: Unable to build HEAD Message-ID: <20090805232852.322E51CC34@ptavv.es.net> I want to try out 8.0 and am trying to build it on a quad core Xenon system. I deleted the contents of /usr/obj and most of /usr/src, csup'ed '.', and did a buildworld. gnu99 -fstack-protector -c /usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /usr/src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libcrypto.a. Stop *** Error code 2 Any idea what is causing this? make.conf has nothing except KERNCONF and Perl version lines. make.src is: WITHOUT_ATM="YES" WITHOUT_GPIB="YES" WITHOUT_I4B="YES" WITHOUT_IPX="YES" WITHOUT_LPR="YES" WITHOUT_NCP=YES WITHOUT_NIS=YES WITHOUT_OPENSSH=YES WITHOUT_PF=YES WITHOUT_PROFILE=YES I couldn't find anything like this in the archives. Has anyone seen this? Any idea how to fix? -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From julian at elischer.org Thu Aug 6 01:07:48 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 6 01:07:56 2009 Subject: ipfw module panic on kldunload In-Reply-To: <179b97fb0908042048w44c8b30fp4cf819374f1dd5e9@mail.gmail.com> References: <179b97fb0908042048w44c8b30fp4cf819374f1dd5e9@mail.gmail.com> Message-ID: <4A7A2CF8.5030809@elischer.org> Try the following patch: http://www.freebsd.org/~julian/ipfw-kld.diff From dougb at FreeBSD.org Thu Aug 6 02:41:49 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Aug 6 02:41:56 2009 Subject: Unable to build HEAD In-Reply-To: <20090805232852.322E51CC34@ptavv.es.net> References: <20090805232852.322E51CC34@ptavv.es.net> Message-ID: <4A7A42E3.9040401@FreeBSD.org> Kevin Oberman wrote: > I want to try out 8.0 and am trying to build it on a quad core Xenon > system. > > I deleted the contents of /usr/obj and most of /usr/src, Haven't you just answered most of your own question? :) Seriously though, why would you think it's ok to just delete most of src? Blow away /usr/obj again, move your current source tree out of the way, and check out a clean one. > make.conf has nothing except KERNCONF and Perl version lines. Ok. > make.src is: What is make.src? Are you thinking of src.conf perhaps? Try checking the man page for src.conf if you need more info. A quick check seems to indicate that all of the knobs you have below are valid in any case. hth, Doug > WITHOUT_ATM="YES" > WITHOUT_GPIB="YES" > WITHOUT_I4B="YES" > WITHOUT_IPX="YES" > WITHOUT_LPR="YES" > WITHOUT_NCP=YES > WITHOUT_NIS=YES > WITHOUT_OPENSSH=YES > WITHOUT_PF=YES > WITHOUT_PROFILE=YES -- This .signature sanitized for your protection From oberman at es.net Thu Aug 6 03:02:39 2009 From: oberman at es.net (Kevin Oberman) Date: Thu Aug 6 03:02:45 2009 Subject: Unable to build HEAD In-Reply-To: Your message of "Wed, 05 Aug 2009 19:41:39 PDT." <4A7A42E3.9040401@FreeBSD.org> Message-ID: <20090806030237.390AE1CC31@ptavv.es.net> > Date: Wed, 05 Aug 2009 19:41:39 -0700 > From: Doug Barton > > Kevin Oberman wrote: > > I want to try out 8.0 and am trying to build it on a quad core Xenon > > system. > > > > I deleted the contents of /usr/obj and most of /usr/src, > > Haven't you just answered most of your own question? :) Seriously > though, why would you think it's ok to just delete most of src? Blow > away /usr/obj again, move your current source tree out of the way, and > check out a clean one. OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. While I will have to re-do my kernel config, I prefer to save my old one, > > > make.conf has nothing except KERNCONF and Perl version lines. > > Ok. > > > make.src is: > > What is make.src? Are you thinking of src.conf perhaps? Try checking > the man page for src.conf if you need more info. A quick check seems > to indicate that all of the knobs you have below are valid in any case. Yes, I meant src.conf. And, yes, all of the entries are valid. But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is broken which is a problem since I have to use the ports version of openssh with special options (OpenSC and HPN). I prefer to replace the base version and not have to fight with having two of them. Oh, well. I may try to track down why WITHOUT_OPENSSH breaks the build, but my make-fu is limited and it's probably too late to get it fixed in 8.0. Guess I should have tried V8 a couple of months ago. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From jamesbrandongooch at gmail.com Thu Aug 6 03:22:15 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Thu Aug 6 03:22:22 2009 Subject: ipfw module panic on kldunload In-Reply-To: <4A7A2CF8.5030809@elischer.org> References: <179b97fb0908042048w44c8b30fp4cf819374f1dd5e9@mail.gmail.com> <4A7A2CF8.5030809@elischer.org> Message-ID: <179b97fb0908052022l515e788ar61ac013d8d7483e6@mail.gmail.com> On Thu, Aug 6, 2009 at 1:08 AM, Julian Elischer wrote: > Try the following patch: > > http://www.freebsd.org/~julian/ipfw-kld.diff > It did the trick, thank you so much! -Brandon From sfourman at gmail.com Thu Aug 6 03:32:50 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Aug 6 03:32:57 2009 Subject: iscsi client Message-ID: <11167f520908052032u2d13a9b2iab44a74f1105b25@mail.gmail.com> for some reason I can not get the following to compile on FreeBSD 8 BETA 2 (src from yesterday) ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.2.tar.gz has anyone had any luck getting iscsi to prefrm in a stable manner on FreeBSD 8? Sam Fourman Jr. From dougb at FreeBSD.org Thu Aug 6 03:45:23 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Aug 6 03:45:29 2009 Subject: Unable to build HEAD In-Reply-To: <20090806030237.390AE1CC31@ptavv.es.net> References: <20090806030237.390AE1CC31@ptavv.es.net> Message-ID: <4A7A51C7.3060702@FreeBSD.org> Kevin Oberman wrote: > OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. I'm going to assume that you mean just your conf file there. > While I > will have to re-do my kernel config, I prefer to save my old one, That's fine, just compare it to GENERIC to make sure that all of your entries are valid, and that you're not missing anything important. > But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is > broken which is a problem Agreed. If you want to help debug this problem you could try building with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in src.conf. Then debug from there. This (IMWO) is something that should be fixed before release. > Guess I should have tried V8 a couple of months ago. In the immortal words of Jiminy Cricket, let your conscience be your guide. :) Doug -- This .signature sanitized for your protection From oberman at es.net Thu Aug 6 04:45:48 2009 From: oberman at es.net (Kevin Oberman) Date: Thu Aug 6 04:45:54 2009 Subject: Unable to build HEAD In-Reply-To: Your message of "Wed, 05 Aug 2009 20:45:11 PDT." <4A7A51C7.3060702@FreeBSD.org> Message-ID: <20090806044545.BF7691CC31@ptavv.es.net> > Date: Wed, 05 Aug 2009 20:45:11 -0700 > From: Doug Barton > > Kevin Oberman wrote: > > > OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. > > I'm going to assume that you mean just your conf file there. Yes. > > While I > > will have to re-do my kernel config, I prefer to save my old one, > > That's fine, just compare it to GENERIC to make sure that all of your > entries are valid, and that you're not missing anything important. Yes. I ran HEAD on my laptop since V4 was in the works and I finally stopped after V7.0 was released. It was nice to skip the hassles, but I miss the adventure. > > But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is > > broken which is a problem > > Agreed. If you want to help debug this problem you could try building > with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in > src.conf. Then debug from there. > > This (IMWO) is something that should be fixed before release. I agree, but I don't know if RE will. > > > Guess I should have tried V8 a couple of months ago. > > In the immortal words of Jiminy Cricket, let your conscience be your > guide. :) I have tested a patch from bf and it works. I've asked if he wants to submit the PR or if he wants me to. If I don;t hear from him, I'll submit tomorrow. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From sfourman at gmail.com Thu Aug 6 06:01:04 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Aug 6 06:01:11 2009 Subject: iscsi client In-Reply-To: <11167f520908052032u2d13a9b2iab44a74f1105b25@mail.gmail.com> References: <11167f520908052032u2d13a9b2iab44a74f1105b25@mail.gmail.com> Message-ID: <11167f520908052301r5a92ab5x34e764574e6addaf@mail.gmail.com> On Wed, Aug 5, 2009 at 10:32 PM, Sam Fourman Jr. wrote: > for some reason I can not get the following to compile on FreeBSD 8 > BETA 2 (src from yesterday) > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.2.tar.gz > > has anyone had any luck getting iscsi to prefrm in a stable manner on FreeBSD 8? > > Sam Fourman Jr. Want to add a quick note I get this printed after the iscsi driver loads iscsi: version 2.1.0 xpt_dev_async called Sam Fourman Jr. From sfourman at gmail.com Thu Aug 6 06:36:47 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Aug 6 06:36:54 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4517BE.9040504@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> Message-ID: <11167f520908052336x3fb98290tceb1e984fe9ad6aa@mail.gmail.com> On Fri, Jun 26, 2009 at 1:47 PM, Alexander Motin wrote: > Hi. > > I would like to present for testing and feedback present state of my and > Scott work on extending CAM subsystem to support ATA in addition to > SCSI. At this moment we have Are these patches in FreeBSD BETA2 (src from today) I decided to try the iscsi client on FreeBSD 8 and I noticed that da0 will not attach, but the same setup works on PC-BSD computer aka FreeBSD 7.2 on the FreeBSD 8 i386 machine I get this message after iscsi: version 2.1.0 xpt_dev_async called <-- This is why I am asking if it has anything to do with these patches Sam Fourman Jr. From edhoprima at gmail.com Thu Aug 6 07:32:13 2009 From: edhoprima at gmail.com (Edho P Arief) Date: Thu Aug 6 07:32:20 2009 Subject: Problematic upgrade from 7.2 to 8.0 with ZFS file system In-Reply-To: References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> <4A64F35E.6070501@ish.com.au> Message-ID: On Tue, Jul 21, 2009 at 3:31 PM, chris scott wrote: > how about doing things the opensolaris way. I have a pure zfs system with > the root fs stored on system/root. This could cloned, to system/root-8, the > new world and kernel installed, then the relevant bits tweaked in the > loader.conf and zpool. If all goes wrong you switch the variables back and > switch to system/root. > > It would also be nice to have some option in beastie to select your root fs > for completeness how does this sound? fs structure: rpool/root/freebsd => / (bootfs) rpool/root => /rpool/root rpool/swap => swap rpool/usr => /usr rpool/usr/home => /usr/home rpool/var => /var rpool/var/empty => /var/empty upgrade steps: 1. clone rpool/root/freebsd to rpool/root/freebsd-2 2. mount rpool/root/freebsd-2 somewhere 3. mount nullfs /usr and /var to where rpool/root/freebsd-2 mounted 4. chroot to rpool/root/freebsd-2, do freebsd-update (twice - to upgrade userland too) 5. reinstall bootloader on rpool/root/freebsd-2 (to enable zfs loader) 6. set bootfs to rpool/root/freebsd-2 7. edit fstab in rpool/root/freebsd-2 to reflect change 8. reboot -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From mav at FreeBSD.org Thu Aug 6 07:44:37 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 07:44:44 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <11167f520908052336x3fb98290tceb1e984fe9ad6aa@mail.gmail.com> References: <4A4517BE.9040504@FreeBSD.org> <11167f520908052336x3fb98290tceb1e984fe9ad6aa@mail.gmail.com> Message-ID: <4A7A89DF.9050206@FreeBSD.org> Sam Fourman Jr. wrote: > On Fri, Jun 26, 2009 at 1:47 PM, Alexander Motin wrote: >> I would like to present for testing and feedback present state of my and >> Scott work on extending CAM subsystem to support ATA in addition to >> SCSI. At this moment we have > > Are these patches in FreeBSD BETA2 (src from today) Yes. > I decided to try the iscsi client on FreeBSD 8 and I noticed that > da0 will not attach, but the same setup works on PC-BSD computer > aka FreeBSD 7.2 > > on the FreeBSD 8 i386 machine I get this message after > > iscsi: version 2.1.0 > xpt_dev_async called <-- This is why I am asking if it has anything > to do with these patches What are you doing and how can I reproduce that? -- Alexander Motin From flo at kasimir.com Thu Aug 6 07:47:30 2009 From: flo at kasimir.com (Florian Smeets) Date: Thu Aug 6 07:47:42 2009 Subject: [regression] 8.0-CURRENT amd64: SATA disks not attaching, MCP55 controller In-Reply-To: <200908052217.06935.stickybit@gmx.net> References: <200908052217.06935.stickybit@gmx.net> Message-ID: <4A7A863A.7080608@kasimir.com> On 8/5/09 10:17 PM, Sticky Bit wrote: > Hello, > > I have a similar problem with 8.0-CURRENT amd64 like described in PR 128686 > and PR 132372 and several older ones. Short: SATA disks will not attach. > > Some example (please see full logs below): > > [...] > ata3: Identifying devices: 00000001 > ata3: New devices: 00000001 > ata3: reiniting channel .. > ata3: SATA connect time=0ms status=00000123 > ata3: reset tp1 mask=01 ostat0=58 ostat1=00 > ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata3: reset tp2 stat0=50 stat1=00 devices=0x1 > ata3: reinit done .. > unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > [...] > > SATA 300 controller is a MCP55 (ULTRA, not SLI) chip, which is working without > any problems for years. Works fine with recent RELENG_7 amd64, but not with > RELENG_8 amd64. > > RELENG_8 i386 seems to attach the disks. So it looks like an amd64 only bug. > Hi, i had the same problem with MCP55 on amd64, i tried the new ahci module but to no avail. However if you set hw.pci.mcfg=0 the disks are found by the normal ata driver (this is already mentioned in one of the PRs). Cheers, Florian From lwindschuh at googlemail.com Thu Aug 6 11:12:51 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Thu Aug 6 11:12:58 2009 Subject: reattach 3g0 device: could not allocate new device In-Reply-To: <200908060937.48442.hselasky@c2i.net> References: <89dbfdc30902231031j4407614vdce09e8e58cdc346@mail.gmail.com> <200902241034.31298.hselasky@c2i.net> <90a5caac0908051529x7870e37ds1f154ea8b4fa8bbb@mail.gmail.com> <200908060937.48442.hselasky@c2i.net> Message-ID: <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> Hi Hans. 2009/8/6 Hans Petter Selasky : > On Thursday 06 August 2009 00:29:09 Lucius Windschuh wrote: >> Hi. >> I have a Vodafone-branded "OVATION MC950D (Qualcomm 3G CDMA)" UMTS pen >> here. >> >> I found this thread from some months ago: >> >> 2009/2/24 Hans Petter Selasky : >> > On Tuesday 24 February 2009, Kim Culhan wrote: >> >> On Tue, Feb 24, 2009 at 3:05 AM, Hans Petter Selasky >> > >> > wrote: >> >> > On Monday 23 February 2009, Kim Culhan wrote: >> >> >> On Mon, Feb 23, 2009 at 3:56 PM, Hans Petter Selasky >> >> >> >> >> > >> >> > wrote: >> >> >> > On Monday 23 February 2009, Kim Culhan wrote: >> >> >> >> Running 8.0-CURRENT as of 2-22-09 >> >> >> >> >> >> >> >> The 3g0 device is a Novatel U727 EVDO wireless radio. >> >> >> >> >> >> >> >> If the machine boots with the device attached, dmesg reads: >> >> >> >> >> >> >> >> u3g0: on usbus2 >> >> >> >> >> >> >> >> Remove the device and this is logged: >> >> >> >> >> >> >> >> u3g0: at ushub2, port 2, addr 2 (disconnected) >> >> >> >> >> >> >> >> Reattach the device and there is this message: >> >> >> >> >> >> >> >> uhub_reattach_port:414: could not allocate new device! >> >> Was there any solution for this? >> >> I may provide further debugging information if somebody tells me how >> to obtail useful details. >> >> A sniplet with hw.usb.debug=3: >> usbd_req_set_config:1456: setting config 1 >> usbd_callback_wrapper:2030: case 1-4 >> usbd_do_request_callback:95: st=0 >> usbd_transfer_submit:1397: xfer=0xc72210b0, endpoint=0xc5dd5078, nframes=1, >> dir= read >> usb_dump_endpoint: endpoint=0xc5dd5078 edesc=0xc5dd532c isoc_next=0 >> toggle_next= 0 bEndpointAddress=0x00 >> usb_dump_queue: endpoint=0xc5dd5078 xfer: >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc72210b0 endpoint=0xc5dd5078 sts=0 >> alen=8 , slen=8, afrm=1, nfrm=1 >> usbd_do_request_callback:95: st=1 >> usb_cdev_create:1854: Creating device nodes >> usbd_set_config_index:584: error=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, nframes=1, >> dir= write >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 >> toggle_next= 0 bEndpointAddress=0x09 >> usb_dump_queue: endpoint=0xc71f9024 xfer: >> usbd_transfer_submit:1416: open >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 sts=0 >> alen=3 1, slen=31, afrm=1, nfrm=1 >> usbd_callback_wrapper:2030: case 1-4 >> bbb_data_read_callback:320: max_bulk=64, data_rem=36 >> usbd_transfer_submit:1397: xfer=0xc7223188, endpoint=0xc71f9000, nframes=1, >> dir= read >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 >> toggle_next= 0 bEndpointAddress=0x88 >> usb_dump_queue: endpoint=0xc71f9000 xfer: >> usbd_transfer_submit:1416: open >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc7223188 endpoint=0xc71f9000 sts=0 >> alen=3 6, slen=36, afrm=1, nfrm=1 >> bbb_data_read_callback:320: max_bulk=64, data_rem=0 >> usbd_callback_wrapper:2030: case 1-4 >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, nframes=1, >> dir= read >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 >> toggle_next= 1 bEndpointAddress=0x88 >> usb_dump_queue: endpoint=0xc71f9000 xfer: >> usbd_transfer_submit:1416: open >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 sts=0 >> alen=1 3, slen=13, afrm=1, nfrm=1 >> usbd_callback_wrapper:2030: case 1-4 >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, nframes=1, >> dir= write >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 >> toggle_next= 1 bEndpointAddress=0x09 >> usb_dump_queue: endpoint=0xc71f9024 xfer: >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 sts=0 >> alen=3 1, slen=31, afrm=1, nfrm=1 >> usbd_callback_wrapper:2030: case 1-4 >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, nframes=1, >> dir= read >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 >> toggle_next= 0 bEndpointAddress=0x88 >> usb_dump_queue: endpoint=0xc71f9000 xfer: >> usbd_pipe_enter:1584: enter >> usbd_pipe_start:2416: start >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION >> usbd_callback_wrapper:2030: case 1-4 >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 sts=0 >> alen=1 3, slen=13, afrm=1, nfrm=1 >> usb_test_autoinstall:571: Eject CD command status: >> USB_ERR_NORMAL_COMPLETION usbd_transfer_stop:1691: close >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED >> usbd_transfer_done:2192: not transferring >> usbd_transfer_stop:1691: close >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED >> usbd_transfer_done:2192: not transferring >> usbd_transfer_stop:1691: close >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED >> usbd_transfer_done:2192: not transferring >> usb_alloc_device:1781: Found Huawei auto-install disk! >> usb_alloc_device:1789: new dev (addr 3), udev=0xc5dd5000, >> parent_hub=0xc621b400 ugen0.3: at usbus0 >> usb_set_device_state:2442: udev 0xc5dd5000 state CONFIGURED -> DETACHED >> ugen0.3: at usbus0 (disconnected) >> usb_cdev_free:1906: Freeing device nodes >> usbd_transfer_stop:1691: close >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED >> usbd_transfer_done:2192: not transferring >> uhub_reattach_port:440: could not allocate new device! >> >> *sigh* Unfortunately, I don't understand what is happening here. >> > > Try: > > sysctl hw.usb.ehci.no_hs=1 Sorry, but I get the same messages: $ sysctl hw.usb.ehci.no_hs=1 $ kldload u3g dmesg: usb_test_autoinstall:571: Eject CD command status: USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install disk! ugen0.2: at usbus0 ugen0.2: at usbus0 (disconnected) uhub_reattach_port:440: could not allocate new device! Lucius From bf1783 at googlemail.com Thu Aug 6 11:37:52 2009 From: bf1783 at googlemail.com (b. f.) Date: Thu Aug 6 11:37:58 2009 Subject: Unable to build HEAD In-Reply-To: References: <20090806032725.50B171CC31@ptavv.es.net> Message-ID: On 8/6/09, Kevin Oberman wrote: >I have tested a patch from bf and it works. I've asked if he wants to >submit the PR or if he wants me to. If I don;t hear from him, I'll >submit tomorrow. Slightly revised and augmented patch is in: http://www.freebsd.org/cgi/query-pr.cgi?pr=137483 Regards, b. From Dimanne at ya.ru Thu Aug 6 11:44:48 2009 From: Dimanne at ya.ru (Dimanne@ya.ru) Date: Thu Aug 6 11:44:56 2009 Subject: network problems Message-ID: <5151249558460@webmail6.yandex.ru> I have installed freebsd 8 beta 2 about six days ago, and yestarday began problems with network. -----------ifconfig----------- re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:23:54:ee:05:9c inet 10.55.103.105 netmask 0xfffffe00 broadcast 10.55.103.255 media: Ethernet autoselect (100baseTX ) status: active fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 02:1e:8c:b2:d5:49 ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 0.1e.8c.0.1.b2.d5.49.a.2.ff.fe.0.0.0.0 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 -----------nestat -rn----------- Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10.0.0.0/8 10.55.102.1 UGS 0 40 re0 10.55.102.0/24 10.55.102.1 UGS 0 0 re0 => 10.55.102.0/23 link#1 U 0 0 re0 10.55.103.0/24 10.55.102.1 UGS 0 6 re0 10.55.103.105 link#4 UHS 0 0 lo0 81.5.64.0/20 10.55.102.1 UGS 0 0 re0 81.5.88.0/22 10.55.102.1 UGS 0 0 re0 85.112.113.96/28 10.55.102.1 UGS 0 0 re0 93.182.0.0/18 10.55.102.1 UGS 0 0 re0 127.0.0.1 link#4 UH 0 6 lo0 172.16.0.0/12 10.55.102.1 UGS 0 0 re0 192.168.254.0/24 10.55.102.1 UGS 0 0 re0 192.188.189.0/24 10.55.102.1 UGS 0 0 re0 193.125.142.0/23 10.55.102.1 UGS 0 0 re0 194.85.80.0/22 10.55.102.1 UGS 0 2 re0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#4 U lo0 ff01:4::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 --------------------------------------------------------------------------------- In /etc/rc.conf i disabled all services such as nfs, apache, dbus, samba and so on (may be this problems due to it). When i try ping 10.55.102.1 it says sendto: Invalid argument And in dmesg output very much this lines: ipv4 address: "10.55.102.1" is not on the network ipv4 address: "10.55.102.1" is not on the network arpresolve: can't allocate llinfo for 10.55.102.1 From jhb at freebsd.org Thu Aug 6 12:38:25 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Aug 6 12:38:43 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> Message-ID: <200908060826.16498.jhb@freebsd.org> On Wednesday 05 August 2009 7:43:11 am Robert Watson wrote: > On Wed, 5 Aug 2009, Ed Schouten wrote: > > > * Lucius Windschuh wrote: > >> So I updated my machine to CURRENT r196062 and use a USB audio > >> converter. Attaching it to the machine leads to a kernel panic: > >> > >> > > > > I suspect this has something to do with the Newbus locking, which causes > > some pieces of code to run without Giant held, while they previously did. > > There's a patch in the re@ queue to re-add Giant around newbus attachment, per > John Baldwin's request. However, committing that patch is stalled while > issues with the svn->cvs export of the new RELENG_8 branch are resolved. I > expect to see the patch go into the tree RSN. Err, I think that was just around suspend/resume? -- John Baldwin From jhb at freebsd.org Thu Aug 6 12:38:25 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Aug 6 12:38:44 2009 Subject: uaudio attach panic: Giant not locked In-Reply-To: References: <90a5caac0908050258w1ea85736sac0b66ae5998e7de@mail.gmail.com> <20090805111247.GA1292@hoeg.nl> Message-ID: <200908060826.16498.jhb@freebsd.org> On Wednesday 05 August 2009 7:43:11 am Robert Watson wrote: > On Wed, 5 Aug 2009, Ed Schouten wrote: > > > * Lucius Windschuh wrote: > >> So I updated my machine to CURRENT r196062 and use a USB audio > >> converter. Attaching it to the machine leads to a kernel panic: > >> > >> > > > > I suspect this has something to do with the Newbus locking, which causes > > some pieces of code to run without Giant held, while they previously did. > > There's a patch in the re@ queue to re-add Giant around newbus attachment, per > John Baldwin's request. However, committing that patch is stalled while > issues with the svn->cvs export of the new RELENG_8 branch are resolved. I > expect to see the patch go into the tree RSN. Err, I think that was just around suspend/resume? -- John Baldwin From ler at lerctr.org Thu Aug 6 13:34:43 2009 From: ler at lerctr.org (Larry Rosenman) Date: Thu Aug 6 13:35:41 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: On Thu, 6 Aug 2009, Robert Watson wrote: > On Tue, 4 Aug 2009, Navdeep Parhar wrote: > >>>> This occurs on today's HEAD + some unrelated patches. That makes it >>>> 8.0BETA2+ code. I haven't tried older builds. >>> >>> We have finally been able to reproduce this ourselves yesterday and >> >> Well, it happens every single time on all of my amd64 machines. After I'd >> already sent my email I noticed that the netisr mutex has an odd address >> (pun intended :-)) >> >> m=0xffffffff8144d867 > > Heh, indeed. We just spotted the same result here. In this case it's > causing a panic because it leads to a non-atomic read due to mtx_lock > spanning a cache line boundary, followed shortly by a panic because it's not > a valid thread pointer when it's dereferenced, as we get a fractional > pointer. [snip] Do we have an ETA for a testable patch? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From spambox at haruhiism.net Thu Aug 6 13:38:29 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Thu Aug 6 13:38:36 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: <4A7ADCD1.5030703@haruhiism.net> Larry Rosenman wrote: > Do we have an ETA for a testable patch? > As we're still investigating the cause, it might take a while. -- Kamigishi Rei KREI-RIPE From hselasky at c2i.net Thu Aug 6 13:46:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 6 13:46:59 2009 Subject: reattach 3g0 device: could not allocate new device In-Reply-To: <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> References: <89dbfdc30902231031j4407614vdce09e8e58cdc346@mail.gmail.com> <200908060937.48442.hselasky@c2i.net> <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> Message-ID: <200908061546.38885.hselasky@c2i.net> On Thursday 06 August 2009 13:12:49 Lucius Windschuh wrote: > Hi Hans. > > 2009/8/6 Hans Petter Selasky : > > On Thursday 06 August 2009 00:29:09 Lucius Windschuh wrote: > >> Hi. > >> I have a Vodafone-branded "OVATION MC950D (Qualcomm 3G CDMA)" UMTS pen > >> here. > >> > >> I found this thread from some months ago: > >> > >> 2009/2/24 Hans Petter Selasky : > >> > On Tuesday 24 February 2009, Kim Culhan wrote: > >> >> On Tue, Feb 24, 2009 at 3:05 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> On Mon, Feb 23, 2009 at 3:56 PM, Hans Petter Selasky > >> >> >> > >> >> > > >> >> > wrote: > >> >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> >> Running 8.0-CURRENT as of 2-22-09 > >> >> >> >> > >> >> >> >> The 3g0 device is a Novatel U727 EVDO wireless radio. > >> >> >> >> > >> >> >> >> If the machine boots with the device attached, dmesg reads: > >> >> >> >> > >> >> >> >> u3g0: on usbus2 > >> >> >> >> > >> >> >> >> Remove the device and this is logged: > >> >> >> >> > >> >> >> >> u3g0: at ushub2, port 2, addr 2 (disconnected) > >> >> >> >> > >> >> >> >> Reattach the device and there is this message: > >> >> >> >> > >> >> >> >> uhub_reattach_port:414: could not allocate new device! > >> > >> Was there any solution for this? > >> > >> I may provide further debugging information if somebody tells me how > >> to obtail useful details. > >> > >> A sniplet with hw.usb.debug=3: > >> usbd_req_set_config:1456: setting config 1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_do_request_callback:95: st=0 > >> usbd_transfer_submit:1397: xfer=0xc72210b0, endpoint=0xc5dd5078, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc5dd5078 edesc=0xc5dd532c isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x00 > >> usb_dump_queue: endpoint=0xc5dd5078 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72210b0 endpoint=0xc5dd5078 > >> sts=0 alen=8 , slen=8, afrm=1, nfrm=1 > >> usbd_do_request_callback:95: st=1 > >> usb_cdev_create:1854: Creating device nodes > >> usbd_set_config_index:584: error=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=36 > >> usbd_transfer_submit:1397: xfer=0xc7223188, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc7223188 endpoint=0xc71f9000 > >> sts=0 alen=3 6, slen=36, afrm=1, nfrm=1 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=0 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usb_test_autoinstall:571: Eject CD command status: > >> USB_ERR_NORMAL_COMPLETION usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usb_alloc_device:1781: Found Huawei auto-install disk! > >> usb_alloc_device:1789: new dev (addr 3), udev=0xc5dd5000, > >> parent_hub=0xc621b400 ugen0.3: at usbus0 > >> usb_set_device_state:2442: udev 0xc5dd5000 state CONFIGURED -> DETACHED > >> ugen0.3: at usbus0 (disconnected) > >> usb_cdev_free:1906: Freeing device nodes > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> uhub_reattach_port:440: could not allocate new device! > >> > >> *sigh* Unfortunately, I don't understand what is happening here. > > > > Try: > > > > sysctl hw.usb.ehci.no_hs=1 > > Sorry, but I get the same messages: > > $ sysctl hw.usb.ehci.no_hs=1 > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > > > Lucius If you kldload u3g after plugging the device? Any change? --HPS From hselasky at c2i.net Thu Aug 6 13:46:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 6 13:47:00 2009 Subject: reattach 3g0 device: could not allocate new device In-Reply-To: <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> References: <89dbfdc30902231031j4407614vdce09e8e58cdc346@mail.gmail.com> <200908060937.48442.hselasky@c2i.net> <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> Message-ID: <200908061546.38885.hselasky@c2i.net> On Thursday 06 August 2009 13:12:49 Lucius Windschuh wrote: > Hi Hans. > > 2009/8/6 Hans Petter Selasky : > > On Thursday 06 August 2009 00:29:09 Lucius Windschuh wrote: > >> Hi. > >> I have a Vodafone-branded "OVATION MC950D (Qualcomm 3G CDMA)" UMTS pen > >> here. > >> > >> I found this thread from some months ago: > >> > >> 2009/2/24 Hans Petter Selasky : > >> > On Tuesday 24 February 2009, Kim Culhan wrote: > >> >> On Tue, Feb 24, 2009 at 3:05 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> On Mon, Feb 23, 2009 at 3:56 PM, Hans Petter Selasky > >> >> >> > >> >> > > >> >> > wrote: > >> >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> >> Running 8.0-CURRENT as of 2-22-09 > >> >> >> >> > >> >> >> >> The 3g0 device is a Novatel U727 EVDO wireless radio. > >> >> >> >> > >> >> >> >> If the machine boots with the device attached, dmesg reads: > >> >> >> >> > >> >> >> >> u3g0: on usbus2 > >> >> >> >> > >> >> >> >> Remove the device and this is logged: > >> >> >> >> > >> >> >> >> u3g0: at ushub2, port 2, addr 2 (disconnected) > >> >> >> >> > >> >> >> >> Reattach the device and there is this message: > >> >> >> >> > >> >> >> >> uhub_reattach_port:414: could not allocate new device! > >> > >> Was there any solution for this? > >> > >> I may provide further debugging information if somebody tells me how > >> to obtail useful details. > >> > >> A sniplet with hw.usb.debug=3: > >> usbd_req_set_config:1456: setting config 1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_do_request_callback:95: st=0 > >> usbd_transfer_submit:1397: xfer=0xc72210b0, endpoint=0xc5dd5078, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc5dd5078 edesc=0xc5dd532c isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x00 > >> usb_dump_queue: endpoint=0xc5dd5078 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72210b0 endpoint=0xc5dd5078 > >> sts=0 alen=8 , slen=8, afrm=1, nfrm=1 > >> usbd_do_request_callback:95: st=1 > >> usb_cdev_create:1854: Creating device nodes > >> usbd_set_config_index:584: error=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=36 > >> usbd_transfer_submit:1397: xfer=0xc7223188, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc7223188 endpoint=0xc71f9000 > >> sts=0 alen=3 6, slen=36, afrm=1, nfrm=1 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=0 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usb_test_autoinstall:571: Eject CD command status: > >> USB_ERR_NORMAL_COMPLETION usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usb_alloc_device:1781: Found Huawei auto-install disk! > >> usb_alloc_device:1789: new dev (addr 3), udev=0xc5dd5000, > >> parent_hub=0xc621b400 ugen0.3: at usbus0 > >> usb_set_device_state:2442: udev 0xc5dd5000 state CONFIGURED -> DETACHED > >> ugen0.3: at usbus0 (disconnected) > >> usb_cdev_free:1906: Freeing device nodes > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> uhub_reattach_port:440: could not allocate new device! > >> > >> *sigh* Unfortunately, I don't understand what is happening here. > > > > Try: > > > > sysctl hw.usb.ehci.no_hs=1 > > Sorry, but I get the same messages: > > $ sysctl hw.usb.ehci.no_hs=1 > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > > > Lucius If you kldload u3g after plugging the device? Any change? --HPS From rwatson at FreeBSD.org Thu Aug 6 14:11:27 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Aug 6 14:11:34 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: On Thu, 6 Aug 2009, Larry Rosenman wrote: > On Thu, 6 Aug 2009, Robert Watson wrote: > >> On Tue, 4 Aug 2009, Navdeep Parhar wrote: >> >>>>> This occurs on today's HEAD + some unrelated patches. That makes it >>>>> 8.0BETA2+ code. I haven't tried older builds. >>>> >>>> We have finally been able to reproduce this ourselves yesterday and >>> >>> Well, it happens every single time on all of my amd64 machines. After I'd >>> already sent my email I noticed that the netisr mutex has an odd address >>> (pun intended :-)) >>> >>> m=0xffffffff8144d867 >> >> Heh, indeed. We just spotted the same result here. In this case it's >> causing a panic because it leads to a non-atomic read due to mtx_lock >> spanning a cache line boundary, followed shortly by a panic because it's >> not a valid thread pointer when it's dereferenced, as we get a fractional >> pointer. > [snip] > > Do we have an ETA for a testable patch? RSN, I'm afraid. We can eliminate the effect by reverting the use of DPCPU in netisr.c (basically reverting to pre-r195019 of netisr.c). The interesting question is where the problem originates -- is gcc/ld/etc not laying out the elf section properly, or are the MD parts not providing an aligned base? There are also probably issues in the DPCPU handling of modules along similar lines, but first things first. We'll be adding assertions of alignment to the various lock init functions to catch this happening explicitly in the future. There are probably one or two other places where we have very strong alignment requirements on i386/amd64, such as the td_ucred pointer that we check for change on system calls/traps to see if we need to refresh the thread's credential from the process credential. Robert N M Watson Computer Laboratory University of Cambridge From rmacklem at uoguelph.ca Thu Aug 6 14:39:56 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Aug 6 14:40:03 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: On Thu, 6 Aug 2009, Robert Watson wrote: > other places where we have very strong alignment requirements on i386/amd64, > such as the td_ucred pointer that we check for change on system calls/traps > to see if we need to refresh the thread's credential from the process > credential. > Does this imply that the nfs/krpc hack of: oldcred = td->td_ucred; td->td_ucred = "some other cred ptr" ... td->td_ucred = oldcred; could be dangerous? Maybe it should be converted to code that replaces the contents instead of replacing the *cred? (Variants of the above live in a bunch of places in the krpc, nlm and nfs code, due to the fact that the socket functions use td->td_ucred in various places.) rick From mav at FreeBSD.org Thu Aug 6 14:56:12 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 14:56:20 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A7AB52B.5000300@cbtnet.ru> References: <4A4517BE.9040504@FreeBSD.org> <4A6EBAFC.6090800@cbtnet.ru> <4A709323.6050001@FreeBSD.org> <4A7AB52B.5000300@cbtnet.ru> Message-ID: <4A7AEF07.2040906@FreeBSD.org> Ilya Zhuravlev wrote: > Alexander Motin wrote: >> Ilya Zhuravlev wrote: >>> ahci cannot attach drives >>> 8.0-beta2, laptop asus k50in, nvidia MCP75L-based >>> >>> ahci0: [THREAD] >>> ahci0: AHCI v1.20 with 2 3Gbps ports, Port Multiplier supported >>> ahcich0: at channel 0 on ahci0 >>> ahcich0: [THREAD] >>> ahcich1: at channel 1 on ahci0 >>> ahcich1: [THREAD] >>> ...... >>> (aprobe0:ahcich0:0:15:0): SIGNATURE: 0000 >>> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 >>> (aprobe0:ahcich0:0:0:0): Uncorrected Parity Error >>> (aprobe0:ahcich0:0:0:0): Retrying Command >>> (aprobe0:ahcich0:0:0:0): Uncoreccted Parity Error >>> (aprobe0:ahcich0:0:0:0): error 5 >>> (aprobe0:ahcich0:0:0:0): Retries Exhausted >>> (aprobe1:ahcich1:0:15:0): SIGNATURE: eb14 >>> (aprobe0:ahcich1:0:0:0): SIGNATURE: eb14 >>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>> (aprobe0:ahcich1:0:0:0): Retrying Command >>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>> (aprobe0:ahcich1:0:0:0): error 5 >>> (aprobe0:ahcich1:0:0:0): Retries Exhausted >>> >>> pciconf with ata-driver and ata-compat enabled in bios: >>> atapci0@pci0:0:11:0: class=0x010185 card=0x1cf71043 >>> chip=0x0ab510de rev=0xb1 hdr=0x00 >>> vendor = 'Nvidia Corp' >>> class = mass storage >>> subclass = ATA >>> bar [10] = type I/O Port, range 32, base 0xc080, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xbc00, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0xb880, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0xb800, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfae7c000, size 8192, >>> enabled >>> cap 01[44] = powerspec 2 supports D0 D3 current D0 >>> cap 12[8c] = SATA Index-Data Pair >>> cap 05[b0] = MSI supports 8 messages, 64 bit >>> >>> atacontrol for devices on channels attached >> >> Try please to uncomment device_printf() lines inside ahci_ch_intr() >> function. It could give some ideas about what's going on there. >> > Sorry for long delay. > boot -v, pciconf attached I don't see that you've uncommented //device_printf(dev, "%s ERROR is %08x cs %08x... lines in ahci_ch_intr() and rebuilt kernel as I've said. -- Alexander Motin From rmacklem at uoguelph.ca Thu Aug 6 15:35:15 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Aug 6 15:35:21 2009 Subject: reproducible panic in netisr In-Reply-To: <4A7AF25D.40608@elischer.org> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <4A7AF25D.40608@elischer.org> Message-ID: On Thu, 6 Aug 2009, Julian Elischer wrote: > Rick Macklem wrote: >> >> >> On Thu, 6 Aug 2009, Robert Watson wrote: >> >>> other places where we have very strong alignment requirements on >>> i386/amd64, such as the td_ucred pointer that we check for change on >>> system calls/traps to see if we need to refresh the thread's credential >>> from the process credential. >>> >> Does this imply that the krpc/nlm/nfs hack of: >> oldcred = td->td_ucred; >> td->td_ucred = "some other cred ptr, such as the mount one" >> ... >> td->td_ucred = oldcred; >> >> could be dangerous? >> >> Maybe it should be converted to code that replaces the contents instead >> of replacing the *cred? (Variants of the above live in a bunch of places >> in the krpc, nlm and nfs code, due to the fact that the socket functions >> use td->td_ucred in various places.) > > no, creds are read-only .. you never change a cred. > You alwasy make a new one ans use it, becasue you may be shareing your cred > with hundreds of other sibling threads or processes. (they are refcounted) > Righto, yes. So does that imply that the alignment provided by crget() { which uses malloc() } is sufficient for td->td_ucred or is td->td_ucred a special case? rick ps: The above hack, which came up in a separate discussion yesterday, isn't gonna be easy to get rid of, imho. A whole bunch of network related functions use td->td_ucred and the only fix I can see would be to add "*cred" arguments to them all, so that the krpc/nlm/nfs code could pass the correct *cred in. (It is set to the one used at mount time for network reconnects, etc.) From rwatson at FreeBSD.org Thu Aug 6 16:33:23 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Aug 6 16:33:30 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: On Thu, 6 Aug 2009, Rick Macklem wrote: > On Thu, 6 Aug 2009, Robert Watson wrote: > >> other places where we have very strong alignment requirements on >> i386/amd64, such as the td_ucred pointer that we check for change on system >> calls/traps to see if we need to refresh the thread's credential from the >> process credential. >> > Does this imply that the nfs/krpc hack of: > oldcred = td->td_ucred; > td->td_ucred = "some other cred ptr" > ... > td->td_ucred = oldcred; > > could be dangerous? > > Maybe it should be converted to code that replaces the contents instead of > replacing the *cred? (Variants of the above live in a bunch of places in the > krpc, nlm and nfs code, due to the fact that the socket functions use > td->td_ucred in various places.) td->td_ucred is a thread-local variable, meaning that it will only be accessed and modified from the current thread. So the above construct is fine. Also, struct thread should be properly aligned. :-) Robert N M Watson Computer Laboratory University of Cambridge From qing.li at bluecoat.com Thu Aug 6 17:36:50 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Aug 6 17:36:57 2009 Subject: network problems In-Reply-To: <5151249558460@webmail6.yandex.ru> References: <5151249558460@webmail6.yandex.ru> Message-ID: > > -----------nestat -rn----------- > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > 10.0.0.0/8 10.55.102.1 UGS 0 40 re0 > 10.55.102.0/24 10.55.102.1 UGS 0 0 re0 => > 10.55.102.0/23 link#1 U 0 0 re0 The problem is you have 2 routes with the same key 10.55.102.0, but the one with the more specific mask (marked by the "re0 =>" entry) is an indirect route (G flag), and it's used to search for 10.55.102.1, which is a problem. This problem seems to point to your overlapping prefix configuration. You will have the exact same problem even on FSBD 7.2R with the above routing table. > > In /etc/rc.conf i disabled all services such as nfs, apache, dbus, > samba and so on (may be this problems due to it). > When i try ping 10.55.102.1 it says > sendto: Invalid argument > > And in dmesg output very much this lines: > ipv4 address: "10.55.102.1" is not on the network > ipv4 address: "10.55.102.1" is not on the network > arpresolve: can't allocate llinfo for 10.55.102.1 > Yup, those are the right messages. -- Qing From stickybit at gmx.net Thu Aug 6 18:22:24 2009 From: stickybit at gmx.net (Sticky Bit) Date: Thu Aug 6 18:22:36 2009 Subject: [regression] 8.0-CURRENT amd64: SATA disks not attaching, MCP55 controller In-Reply-To: <4A7A863A.7080608@kasimir.com> References: <200908052217.06935.stickybit@gmx.net> <4A7A863A.7080608@kasimir.com> Message-ID: <200908062021.56672.stickybit@gmx.net> On Thu August 6 2009 09:28:58 Florian Smeets wrote: > i had the same problem with MCP55 on amd64, i tried the new ahci module > but to no avail. > > However if you set hw.pci.mcfg=0 the disks are found by the normal ata Thanks for the hint! I tried it again with 'set hw.pci.mcfg=0' from boot loader prompt and now it actually finds and attaches the disks as usual. But I do not know if I need 'support for PCI-e memory mapped config access', where it is needed and if it can cause problems later with an RELENG_8 installation if it is disabled like in RELENG_7. I only have one PCIe device, a PCIe graphics card, which is working well with drm.ko / radeon.ko modules and radeonhd driver under RELENG_7. Is it safe to stay with 'hw.pci.mcfg=0' under RELENG_8 for the future? And if so, should the default setting be changed from enabled to disabled for 8.0-RELEASE if it is not yet mature enough and the cause of problems? Looks like several people are affected by this regression. -- Regards From nox at jelal.kn-bremen.de Thu Aug 6 18:48:16 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 18:48:23 2009 Subject: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) Message-ID: <20090806184510.GA12039@triton.kn-bremen.de> Hi! So I put the problematic optical drive on a siis pcie card now because I wanted to play with esata too which seems to be kinda broken on the jmicron that I used before at least with _this_ esata drive (hw issue most likely, has been reported by users of other OSes too) - and I noticed two things: 1. cd(4) (which the new ahci and siis drivers now also use) fails to do any reads when a drive fails the read toc command as seems to happen with bluray (data) discs at least; I was able to work around this by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): Index: sys/cam/scsi/scsi_cd.c @@ -2868,12 +2868,18 @@ } softc->flags |= CD_FLAG_VALID_TOC; + +bailout: softc->disk->d_maxsize = DFLTPHYS; softc->disk->d_sectorsize = softc->params.blksize; softc->disk->d_mediasize = (off_t)softc->params.blksize * softc->params.disksize; +/* if bailout: + * is here read requests will fail when the toc cant be read although + * CD_FLAG_VALID_MEDIA is set. + */ /* * We unconditionally (re)set the blocksize each time the (I say work around because I don't know if there might be stuff somewhere that depends on the old behaviour, although thats probably unlikely; also acd(4) seems to behave similarly.) 2. cdda/dae seems to be broken entirely with ahci(4) as well as siis(4) (I remember a report about it being broken for usb optical drives too so maybe this is related?) - I tested with the audio/cdparanoia port as well as with mplayer -cdrom-device /dev/cd{0,1} cdda://... (mplayer needs to be built with the libparanoia knob on for this) - this does work with atapicam(4) without ahci/siis so it can't be cd(4)'s fault alone. On siis(4) it seems to just fail while on ahci(4) (I still have another optical drive on there, it's on the board's amd sb700) it causes the sata channel to be reset endlessly until I ^C mplayer: ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000113 ahcich1: ready wait time=144ms ahcich1: AHCI reset done: devices=00000001 ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000113 ahcich1: ready wait time=144ms ahcich1: AHCI reset done: devices=00000001 (Remeber if you want to reproduce this libparanoia needs permissions on the optical drive's pass(4) device node and possibly /dev/xpt0 too. And of course you need an audio cd. :) Soo, anyone have ideas/patches/things they want me to check for this? Thanx, Juergen PS: I have built quite a few more ports with ahci(4) enabled on this box now after I updated it to RELENG_8 and the ncq(?) hang hasn't reappeared yet, so _maybe_ it works now *knock-on-wood*... From julian at elischer.org Thu Aug 6 18:59:35 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 6 18:59:45 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <4A7AF25D.40608@elischer.org> Message-ID: <4A7B27DD.20503@elischer.org> Rick Macklem wrote: > > > On Thu, 6 Aug 2009, Julian Elischer wrote: > >> Rick Macklem wrote: >>> >>> >>> On Thu, 6 Aug 2009, Robert Watson wrote: >>> >>>> other places where we have very strong alignment requirements on >>>> i386/amd64, such as the td_ucred pointer that we check for change on >>>> system calls/traps to see if we need to refresh the thread's >>>> credential from the process credential. >>>> >>> Does this imply that the krpc/nlm/nfs hack of: >>> oldcred = td->td_ucred; >>> td->td_ucred = "some other cred ptr, such as the mount one" >>> ... >>> td->td_ucred = oldcred; >>> >>> could be dangerous? >>> >>> Maybe it should be converted to code that replaces the contents instead >>> of replacing the *cred? (Variants of the above live in a bunch of places >>> in the krpc, nlm and nfs code, due to the fact that the socket functions >>> use td->td_ucred in various places.) >> >> no, creds are read-only .. you never change a cred. >> You alwasy make a new one ans use it, becasue you may be shareing your >> cred with hundreds of other sibling threads or processes. (they are >> refcounted) >> > Righto, yes. So does that imply that the alignment provided by crget() > { which uses malloc() } is sufficient for td->td_ucred or is td->td_ucred > a special case? It should be enough. > > rick > ps: The above hack, which came up in a separate discussion yesterday, > isn't gonna be easy to get rid of, imho. A whole bunch of network > related functions use td->td_ucred and the only fix I can see would > be to add "*cred" arguments to them all, so that the krpc/nlm/nfs > code could pass the correct *cred in. (It is set to the one used at > mount time for network reconnects, etc.) we should probably do the right thign refcount-wise for the ucred but refcount (atomic) ops are expensive. > > _______________________________________________ > 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 pluknet at gmail.com Thu Aug 6 19:16:17 2009 From: pluknet at gmail.com (pluknet) Date: Thu Aug 6 19:16:24 2009 Subject: newbus locking: 2 LORs Message-ID: Hi. csup'ed few hours ago (cvsup4.ru). c8-vb# kldunload snd_hda lock order reversal: 1st 0xc0dc26a0 module subsystem sx lock (module subsystem sx lock) @ /usr/src/s ys/kern/kern_linker.c:602 2nd 0xc0dd4740 newbus (newbus) @ /usr/src/sys/kern/subr_bus.c:4127 KDB: stack backtrace: db_trace_self_wrapper(c0c72da6,e6c72b34,c08c0cb5,c08b19fb,c0c75c3b,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c08b19fb,c0c75c3b,c452bc20,c452c850,e6c72b90,...) at kdb_backtrace +0x29 _witness_debugger(c0c75c3b,c0dd4740,c0c7248e,c452c850,c0c724c0,...) at _witness_ debugger+0x25 witness_checkorder(c0dd4740,9,c0c724c0,101f,0,...) at witness_checkorder+0x839 _sx_xlock(c0dd4740,0,c0c724c0,101f,c4f59dd8,...) at _sx_xlock+0x85 driver_module_handler(c498b200,3,c4f59dd8,fc,1,...) at driver_module_handler+0x4 8 module_quiesce(c498b200,0,c0c6c577,25a,c0864346,...) at module_quiesce+0x43 linker_file_unload(c4954200,0,c0c6c577,42c,c4f41000,...) at linker_file_unload+0 xa8 kern_kldunload(c4aa3480,5,0,e6c72d2c,c0baeed3,...) at kern_kldunload+0xd5 kldunloadf(c4aa3480,e6c72cf8,8,c0c76cfd,c0d57c30,...) at kldunloadf+0x2b syscall(e6c72d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280ced2b, esp = 0xbfbfe48c , ebp = 0xbfbfecd8 --- lock order reversal: 1st 0xc0dc1fdc kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c: 1068 2nd 0xc0dd4740 newbus (newbus) @ /usr/src/sys/kern/subr_bus.c:4127 KDB: stack backtrace: db_trace_self_wrapper(c0c72da6,e6c72b34,c08c0cb5,c08b19fb,c0c75c3b,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c08b19fb,c0c75c3b,c452bc88,c452c850,e6c72b90,...) at kdb_backtrace +0x29 _witness_debugger(c0c75c3b,c0dd4740,c0c7248e,c452c850,c0c724c0,...) at _witness_ debugger+0x25 witness_checkorder(c0dd4740,9,c0c724c0,101f,0,...) at witness_checkorder+0x839 _sx_xlock(c0dd4740,0,c0c724c0,101f,c4f59dd8,...) at _sx_xlock+0x85 driver_module_handler(c498b200,1,c4f59dd8,109,0,...) at driver_module_handler+0x 48 module_unload(c498b200,c0c6c577,274,271,c0864346,...) at module_unload+0x43 linker_file_unload(c4954200,0,c0c6c577,42c,c4f41000,...) at linker_file_unload+0 x15e kern_kldunload(c4aa3480,5,0,e6c72d2c,c0baeed3,...) at kern_kldunload+0xd5 kldunloadf(c4aa3480,e6c72cf8,8,c0c76cfd,c0d57c30,...) at kldunloadf+0x2b syscall(e6c72d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280ced2b, esp = 0xbfbfe48c , ebp = 0xbfbfecd8 --- -- wbr, pluknet From nox at jelal.kn-bremen.de Thu Aug 6 19:21:28 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 19:21:35 2009 Subject: (es)ata drives may need an explicit spinup command? Message-ID: <20090806191848.GA14171@triton.kn-bremen.de> So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro drive and it does work - until the drive falls into powersave mode after being idle for a little while. :( (I had the drive on 1394 before on another box where it was able to recover from this condition, but not on usb or esata - and the drive's 1394 interface died a while ago and also esata is faster anyway...) And now I came across this patch for the linux ata driver: http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e So my question is, could the same be done in our ata code? I have a slight :) hope it would help this drive too at least as it does seem to work on Linux... Thanx, Juergen From mav at FreeBSD.org Thu Aug 6 19:47:40 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 19:47:47 2009 Subject: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) In-Reply-To: <20090806184510.GA12039@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> Message-ID: <4A7B3328.5020307@FreeBSD.org> Juergen Lock wrote: > So I put the problematic optical drive on a siis pcie card now because > I wanted to play with esata too which seems to be kinda broken on the > jmicron that I used before at least with _this_ esata drive (hw issue > most likely, has been reported by users of other OSes too) - and I > noticed two things: > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > any reads when a drive fails the read toc command as seems to happen > with bluray (data) discs at least; I was able to work around this > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > Index: sys/cam/scsi/scsi_cd.c > @@ -2868,12 +2868,18 @@ > } > > softc->flags |= CD_FLAG_VALID_TOC; > + > +bailout: > softc->disk->d_maxsize = DFLTPHYS; > softc->disk->d_sectorsize = softc->params.blksize; > softc->disk->d_mediasize = > (off_t)softc->params.blksize * softc->params.disksize; > > +/* if > bailout: > + * is here read requests will fail when the toc cant be read although > + * CD_FLAG_VALID_MEDIA is set. > + */ > > /* > * We unconditionally (re)set the blocksize each time the > > (I say work around because I don't know if there might be stuff > somewhere that depends on the old behaviour, although thats probably > unlikely; also acd(4) seems to behave similarly.) I have no idea about this, ... > 2. cdda/dae seems to be broken entirely with ahci(4) as well as > siis(4) (I remember a report about it being broken for usb optical > drives too so maybe this is related?) - I tested with the > audio/cdparanoia port as well as with > mplayer -cdrom-device /dev/cd{0,1} cdda://... > (mplayer needs to be built with the libparanoia knob on for this) - this > does work with atapicam(4) without ahci/siis so it can't be cd(4)'s > fault alone. On siis(4) it seems to just fail while on ahci(4) (I still > have another optical drive on there, it's on the board's amd sb700) > it causes the sata channel to be reset endlessly until I ^C mplayer: > > ahcich1: AHCI reset... > ahcich1: hardware reset ... > ahcich1: SATA connect time=0ms status=00000113 > ahcich1: ready wait time=144ms > ahcich1: AHCI reset done: devices=00000001 > ahcich1: AHCI reset... > ahcich1: hardware reset ... > ahcich1: SATA connect time=0ms status=00000113 > ahcich1: ready wait time=144ms > ahcich1: AHCI reset done: devices=00000001 > > (Remeber if you want to reproduce this libparanoia needs permissions > on the optical drive's pass(4) device node and possibly /dev/xpt0 too. > And of course you need an audio cd. :) > > Soo, anyone have ideas/patches/things they want me to check for this? But this appeared to to be really trivial. cdparanoia uses extremely simple method for detecting ATAPI devices - it checks that SIM is named "ata". Trivial single line hack made it successfully play some old AudioCD in SATA drive on SiI3132 controller for me, while I am typing this. Probably we should invent better way to do this. -- Alexander Motin From mav at FreeBSD.org Thu Aug 6 19:57:36 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 19:57:42 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <20090806191848.GA14171@triton.kn-bremen.de> References: <20090806191848.GA14171@triton.kn-bremen.de> Message-ID: <4A7B357C.5010203@FreeBSD.org> Juergen Lock wrote: > So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro > drive and it does work - until the drive falls into powersave mode > after being idle for a little while. :( (I had the drive on 1394 > before on another box where it was able to recover from this condition, > but not on usb or esata - and the drive's 1394 interface died a while > ago and also esata is faster anyway...) > > And now I came across this patch for the linux ata driver: > http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e > > So my question is, could the same be done in our ata code? > I have a slight :) hope it would help this drive too at least as it > does seem to work on Linux... I am not sure it is related to your case, as you said your drive works for some time after plug. If drive spun-down automatically due to inactivity, it should spin-up automatically also, as OS unable to track that transition. 30 seconds of ATA command timeout should be sufficient for drive to do this. Do you have any other symptoms? -- Alexander Motin From nox at jelal.kn-bremen.de Thu Aug 6 20:10:18 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 20:10:25 2009 Subject: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) In-Reply-To: <4A7B3328.5020307@FreeBSD.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> Message-ID: <20090806200715.GA16313@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > Juergen Lock wrote: > > So I put the problematic optical drive on a siis pcie card now because > > I wanted to play with esata too which seems to be kinda broken on the > > jmicron that I used before at least with _this_ esata drive (hw issue > > most likely, has been reported by users of other OSes too) - and I > > noticed two things: > > > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > > any reads when a drive fails the read toc command as seems to happen > > with bluray (data) discs at least; I was able to work around this > > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > > > Index: sys/cam/scsi/scsi_cd.c > > @@ -2868,12 +2868,18 @@ > > } > > > > softc->flags |= CD_FLAG_VALID_TOC; > > + > > +bailout: > > softc->disk->d_maxsize = DFLTPHYS; > > softc->disk->d_sectorsize = softc->params.blksize; > > softc->disk->d_mediasize = > > (off_t)softc->params.blksize * softc->params.disksize; > > > > +/* if > > bailout: > > + * is here read requests will fail when the toc cant be read although > > + * CD_FLAG_VALID_MEDIA is set. > > + */ > > > > /* > > * We unconditionally (re)set the blocksize each time the > > > > (I say work around because I don't know if there might be stuff > > somewhere that depends on the old behaviour, although thats probably > > unlikely; also acd(4) seems to behave similarly.) > > I have no idea about this, ... > Btw with `acd(4) seems to behave similarly' I meant a drive on acd _can_ read bluray. > > 2. cdda/dae seems to be broken entirely with ahci(4) as well as > > siis(4) (I remember a report about it being broken for usb optical > > drives too so maybe this is related?) - I tested with the > > audio/cdparanoia port as well as with > > mplayer -cdrom-device /dev/cd{0,1} cdda://... > > (mplayer needs to be built with the libparanoia knob on for this) - this > > does work with atapicam(4) without ahci/siis so it can't be cd(4)'s > > fault alone. On siis(4) it seems to just fail while on ahci(4) (I still > > have another optical drive on there, it's on the board's amd sb700) > > it causes the sata channel to be reset endlessly until I ^C mplayer: > > > > ahcich1: AHCI reset... > > ahcich1: hardware reset ... > > ahcich1: SATA connect time=0ms status=00000113 > > ahcich1: ready wait time=144ms > > ahcich1: AHCI reset done: devices=00000001 > > ahcich1: AHCI reset... > > ahcich1: hardware reset ... > > ahcich1: SATA connect time=0ms status=00000113 > > ahcich1: ready wait time=144ms > > ahcich1: AHCI reset done: devices=00000001 > > > > (Remeber if you want to reproduce this libparanoia needs permissions > > on the optical drive's pass(4) device node and possibly /dev/xpt0 too. > > And of course you need an audio cd. :) > > > > Soo, anyone have ideas/patches/things they want me to check for this? > > But this appeared to to be really trivial. cdparanoia uses extremely > simple method for detecting ATAPI devices - it checks that SIM is named > "ata". Trivial single line hack made it successfully play some old > AudioCD in SATA drive on SiI3132 controller for me, while I am typing > this. Probably we should invent better way to do this. Oooh! :) I need to test this... Thanx, Juergen From rmacklem at uoguelph.ca Thu Aug 6 20:28:40 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Aug 6 20:28:47 2009 Subject: reproducible panic in netisr In-Reply-To: <4A7B27DD.20503@elischer.org> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <4A7AF25D.40608@elischer.org> <4A7B27DD.20503@elischer.org> Message-ID: On Thu, 6 Aug 2009, Julian Elischer wrote: >> Righto, yes. So does that imply that the alignment provided by crget() >> { which uses malloc() } is sufficient for td->td_ucred or is td->td_ucred >> a special case? > > It should be enough. > Ok, that's good news. > > we should probably do the right thign refcount-wise for the ucred > but refcount (atomic) ops are expensive. > In the clnt_rc.c case, it does do a crdup(), although I think a crhold() would have been sufficient. In the nlm, there is a case where the mount point cred gets used without a crhold() and that does cause panics for pho@'s tests related to "umount -f". I have a fix for that one, which is waiting for a Doug R. review. (It only affects "umount -f", which I think still has other issues, so I haven't tried to push for it getting into head.) So, yes, I think that the refcount issue is being handled, rick From nox at jelal.kn-bremen.de Thu Aug 6 20:37:28 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 20:37:34 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <4A7B357C.5010203@FreeBSD.org> References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> Message-ID: <20090806203501.GA16639@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: > Juergen Lock wrote: > > So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro > > drive and it does work - until the drive falls into powersave mode > > after being idle for a little while. :( (I had the drive on 1394 > > before on another box where it was able to recover from this condition, > > but not on usb or esata - and the drive's 1394 interface died a while > > ago and also esata is faster anyway...) > > > > And now I came across this patch for the linux ata driver: > > http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e > > > > So my question is, could the same be done in our ata code? > > I have a slight :) hope it would help this drive too at least as it > > does seem to work on Linux... > > I am not sure it is related to your case, as you said your drive works > for some time after plug. If drive spun-down automatically due to > inactivity, it should spin-up automatically also, as OS unable to track > that transition. 30 seconds of ATA command timeout should be sufficient > for drive to do this. Do you have any other symptoms? Well the drive becomes completely `dead' for our drivers once in this state, and when I try an atacontrol detach/attach on it at that point its not even found anymore. (And when I powercycle it by pulling its little wall wart for a moment it comes back.) Oh and I think I saw something in our 1394 drivers too that does send something like a spinup command... Also there have been threads on the net about Seagate external drives not working properly on Linux for a few years as well because of this powersaving `feature', and the drive does work on Linux here as I said (at least on esata) so I suspected that commit might have been what fixed it. Thanx, Juergen From mav at FreeBSD.org Thu Aug 6 20:45:45 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 20:45:52 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <20090806203501.GA16639@triton.kn-bremen.de> References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> <20090806203501.GA16639@triton.kn-bremen.de> Message-ID: <4A7B40C5.7040500@FreeBSD.org> Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: >> Juergen Lock wrote: >>> So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro >>> drive and it does work - until the drive falls into powersave mode >>> after being idle for a little while. :( (I had the drive on 1394 >>> before on another box where it was able to recover from this condition, >>> but not on usb or esata - and the drive's 1394 interface died a while >>> ago and also esata is faster anyway...) >>> >>> And now I came across this patch for the linux ata driver: >>> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e >>> >>> So my question is, could the same be done in our ata code? >>> I have a slight :) hope it would help this drive too at least as it >>> does seem to work on Linux... >> I am not sure it is related to your case, as you said your drive works >> for some time after plug. If drive spun-down automatically due to >> inactivity, it should spin-up automatically also, as OS unable to track >> that transition. 30 seconds of ATA command timeout should be sufficient >> for drive to do this. Do you have any other symptoms? > > Well the drive becomes completely `dead' for our drivers once in this > state, and when I try an atacontrol detach/attach on it at that point > its not even found anymore. (And when I powercycle it by pulling its > little wall wart for a moment it comes back.) Oh and I think I saw > something in our 1394 drivers too that does send something like a > spinup command... The problem is that we have no idea when to use this command after drive was successfully working. Could you boot with new CAM drivers and kernel verbose messages enabled? I am interested of what exactly happens on logs/console when drive dies and how it reacts on `camcontrol reset X` and `camcontrol rescan X` commands. -- Alexander Motin From mav at FreeBSD.org Thu Aug 6 21:14:36 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 6 21:14:43 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <11167f520908052336x3fb98290tceb1e984fe9ad6aa@mail.gmail.com> References: <4A4517BE.9040504@FreeBSD.org> <11167f520908052336x3fb98290tceb1e984fe9ad6aa@mail.gmail.com> Message-ID: <4A7B4788.4090103@FreeBSD.org> Sam Fourman Jr. wrote: > On Fri, Jun 26, 2009 at 1:47 PM, Alexander Motin wrote: >> Hi. >> >> I would like to present for testing and feedback present state of my and >> Scott work on extending CAM subsystem to support ATA in addition to >> SCSI. At this moment we have > > Are these patches in FreeBSD BETA2 (src from today) > > I decided to try the iscsi client on FreeBSD 8 and I noticed that > da0 will not attach, but the same setup works on PC-BSD computer > aka FreeBSD 7.2 > > on the FreeBSD 8 i386 machine I get this message after > > iscsi: version 2.1.0 > xpt_dev_async called <-- This is why I am asking if it has anything > to do with these patches I've reproduced your problem. Try attached patch. It fixed problem for me: iscsi: version 2.1.0 pass0 at iscsi0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device GEOM: new disk da0 da0 at iscsi0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device -- Alexander Motin -------------- next part -------------- diff -ruNp sys/cam.prev/cam_ccb.h sys/cam/cam_ccb.h --- sys/cam.prev/cam_ccb.h 2009-07-19 11:26:54.000000000 +0300 +++ sys/cam/cam_ccb.h 2009-08-06 23:28:36.000000000 +0300 @@ -230,6 +230,7 @@ typedef enum { XPORT_ATA, /* AT Attachment */ XPORT_SAS, /* Serial Attached SCSI */ XPORT_SATA, /* Serial AT Attachment */ + XPORT_ISCSI, /* iSCSI */ } cam_xport; #define PROTO_VERSION_UNKNOWN (UINT_MAX - 1) diff -ruNp sys/cam.prev/cam_xpt.c sys/cam/cam_xpt.c --- sys/cam.prev/cam_xpt.c 2009-07-25 15:19:01.000000000 +0300 +++ sys/cam/cam_xpt.c 2009-08-06 23:29:03.000000000 +0300 @@ -3799,6 +3799,7 @@ xpt_bus_register(struct cam_sim *sim, de case XPORT_SAS: case XPORT_FC: case XPORT_USB: + case XPORT_ISCSI: new_bus->xport = scsi_get_xport(); break; case XPORT_ATA: --- sys/dev/iscsi/initiator/isc_cam.c.prev 2009-05-19 07:37:07.000000000 +0300 +++ sys/dev/iscsi/initiator/isc_cam.c 2009-08-06 23:30:35.000000000 +0300 @@ -190,6 +190,8 @@ _inq(struct cam_sim *sim, union ccb *ccb strncpy(cpi->hba_vid, "iSCSI", HBA_IDLEN); strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); cpi->unit_number = cam_sim_unit(sim); + cpi->transport = XPORT_ISCSI; + cpi->transport_version = 0; cpi->ccb_h.status = CAM_REQ_CMP; } From rick-freebsd2008 at kiwi-computer.com Thu Aug 6 21:30:52 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Thu Aug 6 21:30:59 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <4A7B357C.5010203@FreeBSD.org> References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> Message-ID: <20090806213048.GA17945@keira.kiwi-computer.com> On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: > Juergen Lock wrote: > >So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro > >drive and it does work - until the drive falls into powersave mode > >after being idle for a little while. :( (I had the drive on 1394 > >before on another box where it was able to recover from this condition, > >but not on usb or esata - and the drive's 1394 interface died a while > >ago and also esata is faster anyway...) > > > > And now I came across this patch for the linux ata driver: > > http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e > > > > So my question is, could the same be done in our ata code? > >I have a slight :) hope it would help this drive too at least as it > >does seem to work on Linux... > > I am not sure it is related to your case, as you said your drive works > for some time after plug. If drive spun-down automatically due to > inactivity, it should spin-up automatically also, as OS unable to track > that transition. 30 seconds of ATA command timeout should be sufficient > for drive to do this. Do you have any other symptoms? I believe this patch is for something different. Certain drives are automatically spun down at power up. One such drive is in my satellite provider's DVR. If you hook it up to regular SATA and power, it will never spin up. It requires a special ATA command to tell it to spin up. I believe the linux patch does precisely this. I know there's a special SATA power cable that tells the drive not to spin up until given the spinup command, which I also found in my satellite provider's DVR. Basically this is done through pin 11: http://en.wikipedia.org/wiki/Serial_ATA#Power_supply Although not every drive supports this feature. -- Rick C. Petty From mel.flynn+fbsd.current at mailing.thruhere.net Thu Aug 6 22:18:41 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Thu Aug 6 22:18:50 2009 Subject: panic: vm_fault: fault on nofault entry, addr: c33a3000 - r195941/BETA2 Message-ID: <200908061418.38978.mel.flynn+fbsd.current@mailing.thruhere.net> Hi, got the following panic. Have been having this a few times quite randomly, since beta2. Finally with KDB_UNATTENDED got a core dump. I can't really relate this to a workload. It happened once when machine was totally idle, this time there was a rather high workload from compiling kde4 related ports in a jail with -j2. FreeBSD smoochies.rachie.is-a-geek.net 8.0-BETA2 FreeBSD 8.0-BETA2 #9 r195941M: Sun Aug 2 12:25:04 AKDT 2009 mel@smoochies.rachie.is-a- geek.net:/usr/obj/usr/src/sys/HPDV9000 i386 panic: vm_fault: fault on nofault entry, addr: c33a3000 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"... Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: c33a3000 cpuid = 1 Uptime: 3d12h41m32s Physical memory: 1517 MB Dumping 257 MB: 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc064d0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc064d3e2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc08216b7 in vm_fault (map=0xc1890000, vaddr=3275370496, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:283 #4 0xc088540e in trap_pfault (frame=0xe7919a34, usermode=0, eva=3275370840) at /usr/src/sys/i386/i386/trap.c:835 #5 0xc0885e83 in trap (frame=0xe7919a34) at /usr/src/sys/i386/i386/trap.c:528 #6 0xc0868aab in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc0839a05 in vm_reserv_level_iffullpop (m=0xc776c5e8) at /usr/src/sys/vm/vm_reserv.c:512 #8 0xc0882ad0 in pmap_enter (pmap=0xc4d42450, va=750776320, access=2 '\002', m=0xc776c5e8, prot=3 '\003', wired=0) at /usr/src/sys/i386/i386/pmap.c:3226 #9 0xc0823095 in vm_fault (map=0xc4d423a0, vaddr=750776320, fault_type=2 '\002', fault_flags=Variable "fault_flags" is not available. ) at /usr/src/sys/vm/vm_fault.c:933 #10 0xc088535b in trap_pfault (frame=0xe7919d38, usermode=1, eva=750776320) at /usr/src/sys/i386/i386/trap.c:823 #11 0xc0885cfe in trap (frame=0xe7919d38) at /usr/src/sys/i386/i386/trap.c:398 #12 0xc0868aab in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #13 0x2832f530 in ?? () (kgdb) f 9 #9 0xc0823095 in vm_fault (map=0xc4d423a0, vaddr=750776320, fault_type=2 '\002', fault_flags=Variable "fault_flags" is not available. ) at /usr/src/sys/vm/vm_fault.c:933 933 pmap_enter(fs.map->pmap, vaddr, fault_type, fs.m, prot, wired); (kgdb) print *map $1 = {header = {prev = 0xc59d15a0, next = 0xc59d1630, left = 0x0, right = 0x0, start = 0, end = 3217031168, avail_ssize = 0, adj_free = 0, max_free = 0, object = { vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', max_protection = 0 '\0', inheritance = 0 '\0', wired_count = 0, lastr = 0, uip = 0x0}, lock = {lock_object = {lo_name = 0xc090395e "user map", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 17}, system_mtx = {lock_object = { lo_name = 0xc0903953 "system map", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, nentries = 154, size = 322252800, timestamp = 137335, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0 '\0', root = 0xcaab3d80, pmap = 0xc4d42450, deferred_freelist = 0x0} Anything else anyone wants to see? -- Mel From nox at jelal.kn-bremen.de Thu Aug 6 22:25:06 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 22:25:20 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <4A7B40C5.7040500@FreeBSD.org> References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> <20090806203501.GA16639@triton.kn-bremen.de> <4A7B40C5.7040500@FreeBSD.org> Message-ID: <20090806221307.GA1940@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 11:44:53PM +0300, Alexander Motin wrote: > Juergen Lock wrote: > > On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: > >> Juergen Lock wrote: > >>> So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro > >>> drive and it does work - until the drive falls into powersave mode > >>> after being idle for a little while. :( (I had the drive on 1394 > >>> before on another box where it was able to recover from this condition, > >>> but not on usb or esata - and the drive's 1394 interface died a while > >>> ago and also esata is faster anyway...) > >>> > >>> And now I came across this patch for the linux ata driver: > >>> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e > >>> > >>> So my question is, could the same be done in our ata code? > >>> I have a slight :) hope it would help this drive too at least as it > >>> does seem to work on Linux... > >> I am not sure it is related to your case, as you said your drive works > >> for some time after plug. If drive spun-down automatically due to > >> inactivity, it should spin-up automatically also, as OS unable to track > >> that transition. 30 seconds of ATA command timeout should be sufficient > >> for drive to do this. Do you have any other symptoms? > > > > Well the drive becomes completely `dead' for our drivers once in this > > state, and when I try an atacontrol detach/attach on it at that point > > its not even found anymore. (And when I powercycle it by pulling its > > little wall wart for a moment it comes back.) Oh and I think I saw > > something in our 1394 drivers too that does send something like a > > spinup command... > > The problem is that we have no idea when to use this command after drive > was successfully working. Could you boot with new CAM drivers and kernel > verbose messages enabled? I am interested of what exactly happens on > logs/console when drive dies and how it reacts on `camcontrol reset X` > and `camcontrol rescan X` commands. Well, what should I say, siis(4) seems to do the right thing now, i.e. the drive spins up again properly now after a small delay like it used to do on 1394. So either I must have tested it on the old ata driver or I only tested it on 7... So, sorry for the noise, :) Juergen From nox at jelal.kn-bremen.de Thu Aug 6 22:25:06 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 22:25:21 2009 Subject: cdparanoia patch for ahci(4)/siis(4) (was: Re: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4)) In-Reply-To: <20090806200715.GA16313@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> Message-ID: <20090806222127.GB1940@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > > Juergen Lock wrote: > > > 2. cdda/dae seems to be broken entirely with ahci(4) as well as > > > siis(4) (I remember a report about it being broken for usb optical > > > drives too so maybe this is related?) - I tested with the > > > audio/cdparanoia port as well as with > > > mplayer -cdrom-device /dev/cd{0,1} cdda://... > > > (mplayer needs to be built with the libparanoia knob on for this) - this > > > does work with atapicam(4) without ahci/siis so it can't be cd(4)'s > > > fault alone. On siis(4) it seems to just fail while on ahci(4) (I still > > > have another optical drive on there, it's on the board's amd sb700) > > > it causes the sata channel to be reset endlessly until I ^C mplayer: > > > > > > ahcich1: AHCI reset... > > > ahcich1: hardware reset ... > > > ahcich1: SATA connect time=0ms status=00000113 > > > ahcich1: ready wait time=144ms > > > ahcich1: AHCI reset done: devices=00000001 > > > ahcich1: AHCI reset... > > > ahcich1: hardware reset ... > > > ahcich1: SATA connect time=0ms status=00000113 > > > ahcich1: ready wait time=144ms > > > ahcich1: AHCI reset done: devices=00000001 > > > > > > (Remeber if you want to reproduce this libparanoia needs permissions > > > on the optical drive's pass(4) device node and possibly /dev/xpt0 too. > > > And of course you need an audio cd. :) > > > > > > Soo, anyone have ideas/patches/things they want me to check for this? > > > > But this appeared to to be really trivial. cdparanoia uses extremely > > simple method for detecting ATAPI devices - it checks that SIM is named > > "ata". Trivial single line hack made it successfully play some old > > AudioCD in SATA drive on SiI3132 controller for me, while I am typing > > this. Probably we should invent better way to do this. > > Oooh! :) I need to test this... Yup, works here too on siis and ahci with the following patch: (maintainer Cc'd) Index: interface/scsi_interface.c @@ -1480,9 +1480,12 @@ /* * if the bus device name is `ata', we're (obviously) * running ATAPICAM. + * XXX same for the new ahci(4) and siis(4) drivers... */ - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); d->is_atapi = 1; } else { Thanx, :) Juergen From nox at jelal.kn-bremen.de Thu Aug 6 22:40:32 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 22:40:39 2009 Subject: cd(4) vs bluray ... In-Reply-To: <20090806200715.GA16313@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> Message-ID: <20090806223806.GA6332@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > > Juergen Lock wrote: > > > So I put the problematic optical drive on a siis pcie card now because > > > I wanted to play with esata too which seems to be kinda broken on the > > > jmicron that I used before at least with _this_ esata drive (hw issue > > > most likely, has been reported by users of other OSes too) - and I > > > noticed two things: > > > > > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > > > any reads when a drive fails the read toc command as seems to happen > > > with bluray (data) discs at least; I was able to work around this > > > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > > > > > Index: sys/cam/scsi/scsi_cd.c > > > @@ -2868,12 +2868,18 @@ > > > } > > > > > > softc->flags |= CD_FLAG_VALID_TOC; > > > + > > > +bailout: > > > softc->disk->d_maxsize = DFLTPHYS; > > > softc->disk->d_sectorsize = softc->params.blksize; > > > softc->disk->d_mediasize = > > > (off_t)softc->params.blksize * softc->params.disksize; > > > > > > +/* if > > > bailout: > > > + * is here read requests will fail when the toc cant be read although > > > + * CD_FLAG_VALID_MEDIA is set. > > > + */ > > > > > > /* > > > * We unconditionally (re)set the blocksize each time the > > > > > > (I say work around because I don't know if there might be stuff > > > somewhere that depends on the old behaviour, although thats probably > > > unlikely; also acd(4) seems to behave similarly.) > > > > I have no idea about this, ... > > > Btw with `acd(4) seems to behave similarly' I meant a drive on acd > _can_ read bluray. Ok what do the -scsi folks say about this? Should it check for the disc (or drive?) to be bluray on only accept read toc failure in that case? Or is the patch fine as it is? As I said the old acd(4) driver seems not to care i.e. reads from bluray discs just fine... Wondering, Juergen From nox at jelal.kn-bremen.de Thu Aug 6 22:49:30 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu Aug 6 22:49:37 2009 Subject: (es)ata drives may need an explicit spinup command? In-Reply-To: <20090806213048.GA17945@keira.kiwi-computer.com> References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> <20090806213048.GA17945@keira.kiwi-computer.com> Message-ID: <20090806224707.GA7454@triton.kn-bremen.de> On Thu, Aug 06, 2009 at 04:30:49PM -0500, Rick C. Petty wrote: > On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: > > Juergen Lock wrote: > > >So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro > > >drive and it does work - until the drive falls into powersave mode > > >after being idle for a little while. :( (I had the drive on 1394 > > >before on another box where it was able to recover from this condition, > > >but not on usb or esata - and the drive's 1394 interface died a while > > >ago and also esata is faster anyway...) > > > > > > And now I came across this patch for the linux ata driver: > > > http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e > > > > > > So my question is, could the same be done in our ata code? > > >I have a slight :) hope it would help this drive too at least as it > > >does seem to work on Linux... > > > > I am not sure it is related to your case, as you said your drive works > > for some time after plug. If drive spun-down automatically due to > > inactivity, it should spin-up automatically also, as OS unable to track > > that transition. 30 seconds of ATA command timeout should be sufficient > > for drive to do this. Do you have any other symptoms? > > I believe this patch is for something different. Certain drives are > automatically spun down at power up. One such drive is in my satellite > provider's DVR. If you hook it up to regular SATA and power, it will never > spin up. It requires a special ATA command to tell it to spin up. I > believe the linux patch does precisely this. I know there's a special > SATA power cable that tells the drive not to spin up until given the spinup > command, which I also found in my satellite provider's DVR. Basically this > is done through pin 11: > http://en.wikipedia.org/wiki/Serial_ATA#Power_supply > > Although not every drive supports this feature. Yup it does seem to be something different after all as the new siis(4) driver handles the condition just fine, apparently I only tested the drive on the old ata driver. Oh well... Juergen From miwi at FreeBSD.org Fri Aug 7 00:21:55 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Fri Aug 7 00:22:03 2009 Subject: All videos play too fast on AMD Phenom II X4 955 Message-ID: <20090807000611.GA38670@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howdy, We got a new box for playing with some appz, now I have a _strange_ problem. All videos / flash vidoes playing to fast. I've tested vlc/xine/mplayer all the same problem. Sound is ok. I played also with kern.hz=100 but still the same problem. A secound problem is powerd, i can't use that under 1200 mhz, under 1200 the box freeze. [1:52][miwi@] $ uname -a (~) FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #1 r196069: Wed Aug 5 14:52:16 CEST 2009 root@:/usr/obj/usr/src/sys/AMD64BOX amd64 [1:52][miwi@] $ dmesg: http://nopaste.unixfreunde.de/2275 pciconf -lv http://nopaste.unixfreunde.de/2276 Does someone have any idea what happend is here? thx miwi - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkp7b/MACgkQdLJIhLHm/Ol6+wCfRhTOPUbIyd2Tcv4y95PpfuUj 1xIAoI6rk4Yvmm9Hik8M/N02PCuMmE2X =nb/U -----END PGP SIGNATURE----- From cpghost at cordula.ws Fri Aug 7 01:22:52 2009 From: cpghost at cordula.ws (cpghost) Date: Fri Aug 7 01:22:59 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: <20090807000611.GA38670@bsdcrew.de> References: <20090807000611.GA38670@bsdcrew.de> Message-ID: <20090807010159.GV86066@phenom.cordula.ws> On Fri, Aug 07, 2009 at 02:06:11AM +0200, Martin Wilke wrote: > A secound problem is powerd, i can't use > that under 1200 mhz, under 1200 the box > freeze. I have that same problem with a CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) AS a work around, I've added debug.cpufreq.lowest="1240" to /boot/loader.conf. It's not ideal, but I have NO idea what's causing the freezes at lower CPU speeds. BTW, you can slow down videos in mplayer manually by typing '[' repeatedly -- and speed them up again with ']'. -cpghost. -- Cordula's Web. http://www.cordula.ws/ From scottl at samsco.org Fri Aug 7 05:23:35 2009 From: scottl at samsco.org (Scott Long) Date: Fri Aug 7 05:23:42 2009 Subject: cdparanoia patch for ahci(4)/siis(4) In-Reply-To: <20090806222127.GB1940@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> Message-ID: <4A7BBA52.306@samsco.org> Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: >> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: >>> Juergen Lock wrote: > >>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as >>>> siis(4) (I remember a report about it being broken for usb optical >>>> drives too so maybe this is related?) - I tested with the >>>> audio/cdparanoia port as well as with >>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... >>>> (mplayer needs to be built with the libparanoia knob on for this) - this >>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s >>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I still >>>> have another optical drive on there, it's on the board's amd sb700) >>>> it causes the sata channel to be reset endlessly until I ^C mplayer: >>>> >>>> ahcich1: AHCI reset... >>>> ahcich1: hardware reset ... >>>> ahcich1: SATA connect time=0ms status=00000113 >>>> ahcich1: ready wait time=144ms >>>> ahcich1: AHCI reset done: devices=00000001 >>>> ahcich1: AHCI reset... >>>> ahcich1: hardware reset ... >>>> ahcich1: SATA connect time=0ms status=00000113 >>>> ahcich1: ready wait time=144ms >>>> ahcich1: AHCI reset done: devices=00000001 >>>> >>>> (Remeber if you want to reproduce this libparanoia needs permissions >>>> on the optical drive's pass(4) device node and possibly /dev/xpt0 too. >>>> And of course you need an audio cd. :) >>>> >>>> Soo, anyone have ideas/patches/things they want me to check for this? >>> But this appeared to to be really trivial. cdparanoia uses extremely >>> simple method for detecting ATAPI devices - it checks that SIM is named >>> "ata". Trivial single line hack made it successfully play some old >>> AudioCD in SATA drive on SiI3132 controller for me, while I am typing >>> this. Probably we should invent better way to do this. >> Oooh! :) I need to test this... > > Yup, works here too on siis and ahci with the following patch: > (maintainer Cc'd) > > Index: interface/scsi_interface.c > @@ -1480,9 +1480,12 @@ > /* > * if the bus device name is `ata', we're (obviously) > * running ATAPICAM. > + * XXX same for the new ahci(4) and siis(4) drivers... > */ > > - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { > + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || > + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || > + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { > cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); > d->is_atapi = 1; > } else { > > Thanx, :) > Juergen This is fine for the moment, but unmaintainable in the long run as more and more drives are written. cdparanoia needs to look at protocol and transport attributes, not device names. Scott From pjd at FreeBSD.org Fri Aug 7 05:44:14 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Aug 7 05:44:26 2009 Subject: zfs: Fatal trap 12: page fault while in kernel mode In-Reply-To: <20090802092714.GA5813@jpru.ffm.jpru.de> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <20090802092714.GA5813@jpru.ffm.jpru.de> Message-ID: <20090807054431.GA2500@garage.freebsd.pl> On Sun, Aug 02, 2009 at 11:27:14AM +0200, Juergen Unger wrote: > I tried the patch, restarted the whole thing yesterday morning > and after less then 24 hours and approximately 3215 zfs-receive > jobs it do not crashes anymore, but the last started zfs-receive > jobs is hanging, cannot be killed, even not with -9. Even other > zfs commands are hanging and cannot be killed, while zpool commands > seems to be not affected. Unfortunatel I wasn't able to reproduce it. The good news is that something was just committed to OpenSolaris which might fix it (see bug 6868108 on http://bugs.opensolaris.org). The bad news is that the fix is too complex to backport to our ZFS version... -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/b71e4070/attachment.pgp From mav at FreeBSD.org Fri Aug 7 07:19:31 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Aug 7 07:19:38 2009 Subject: cdparanoia patch for ahci(4)/siis(4) In-Reply-To: <4A7BBA52.306@samsco.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> Message-ID: <4A7BD57E.3040201@FreeBSD.org> Scott Long wrote: > Juergen Lock wrote: >> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: >>> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: >>>> Juergen Lock wrote: >>>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as >>>>> siis(4) (I remember a report about it being broken for usb optical >>>>> drives too so maybe this is related?) - I tested with the >>>>> audio/cdparanoia port as well as with >>>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... >>>>> (mplayer needs to be built with the libparanoia knob on for this) - >>>>> this >>>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s >>>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I >>>>> still >>>>> have another optical drive on there, it's on the board's amd sb700) >>>>> it causes the sata channel to be reset endlessly until I ^C mplayer: >>>>> >>>>> Soo, anyone have ideas/patches/things they want me to check for this? >>>> But this appeared to to be really trivial. cdparanoia uses extremely >>>> simple method for detecting ATAPI devices - it checks that SIM is >>>> named "ata". Trivial single line hack made it successfully play some >>>> old AudioCD in SATA drive on SiI3132 controller for me, while I am >>>> typing this. Probably we should invent better way to do this. >>> Oooh! :) I need to test this... >> >> Yup, works here too on siis and ahci with the following patch: >> (maintainer Cc'd) >> >> Index: interface/scsi_interface.c >> @@ -1480,9 +1480,12 @@ >> /* >> * if the bus device name is `ata', we're (obviously) >> * running ATAPICAM. >> + * XXX same for the new ahci(4) and siis(4) drivers... >> */ >> >> - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { >> + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || >> + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || >> + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { >> cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); >> d->is_atapi = 1; >> } else { >> >> Thanx, :) >> Juergen > > This is fine for the moment, but unmaintainable in the long run as more > and more drives are written. cdparanoia needs to look at protocol and > transport attributes, not device names. CAM reports SCSI protocol for ATAPI devices at this moment. It is not good probably. but changing it now may be painful. Checks like d->ccb->cpi.transport == XPORT_ATA || d->ccb->cpi.transport == XPORT_SATA should be for now. "ata" hack should also stay there for now, as ATAPICAM emulates SCSI transport now, but not a new ATA one. -- Alexander Motin From scottl at samsco.org Fri Aug 7 07:22:59 2009 From: scottl at samsco.org (Scott Long) Date: Fri Aug 7 07:23:07 2009 Subject: cdparanoia patch for ahci(4)/siis(4) In-Reply-To: <4A7BD57E.3040201@FreeBSD.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> Message-ID: <4A7BD64D.60601@samsco.org> Alexander Motin wrote: > Scott Long wrote: >> Juergen Lock wrote: >>> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: >>>> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: >>>>> Juergen Lock wrote: >>>>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as >>>>>> siis(4) (I remember a report about it being broken for usb optical >>>>>> drives too so maybe this is related?) - I tested with the >>>>>> audio/cdparanoia port as well as with >>>>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... >>>>>> (mplayer needs to be built with the libparanoia knob on for this) - >>>>>> this >>>>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s >>>>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I >>>>>> still >>>>>> have another optical drive on there, it's on the board's amd sb700) >>>>>> it causes the sata channel to be reset endlessly until I ^C mplayer: >>>>>> >>>>>> Soo, anyone have ideas/patches/things they want me to check for this? >>>>> But this appeared to to be really trivial. cdparanoia uses extremely >>>>> simple method for detecting ATAPI devices - it checks that SIM is >>>>> named "ata". Trivial single line hack made it successfully play some >>>>> old AudioCD in SATA drive on SiI3132 controller for me, while I am >>>>> typing this. Probably we should invent better way to do this. >>>> Oooh! :) I need to test this... >>> Yup, works here too on siis and ahci with the following patch: >>> (maintainer Cc'd) >>> >>> Index: interface/scsi_interface.c >>> @@ -1480,9 +1480,12 @@ >>> /* >>> * if the bus device name is `ata', we're (obviously) >>> * running ATAPICAM. >>> + * XXX same for the new ahci(4) and siis(4) drivers... >>> */ >>> >>> - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { >>> + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || >>> + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || >>> + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { >>> cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); >>> d->is_atapi = 1; >>> } else { >>> >>> Thanx, :) >>> Juergen >> This is fine for the moment, but unmaintainable in the long run as more >> and more drives are written. cdparanoia needs to look at protocol and >> transport attributes, not device names. > > CAM reports SCSI protocol for ATAPI devices at this moment. It is not > good probably. but changing it now may be painful. Checks like > d->ccb->cpi.transport == XPORT_ATA || > d->ccb->cpi.transport == XPORT_SATA > should be for now. "ata" hack should also stay there for now, as > ATAPICAM emulates SCSI transport now, but not a new ATA one. > What protocol should CAM be reporting for ATAPI devices? It is SCSI. I don't understand why we have to keep on diverging from the goal of having a unified and consistent interface here. As for ATAPICAM, that hopefully will go away some day, as it's really only a hack. Scott From mav at FreeBSD.org Fri Aug 7 07:42:58 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Aug 7 07:43:04 2009 Subject: cdparanoia patch for ahci(4)/siis(4) In-Reply-To: <4A7BD64D.60601@samsco.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> <4A7BD64D.60601@samsco.org> Message-ID: <4A7BDAFB.7020303@FreeBSD.org> Scott Long wrote: > Alexander Motin wrote: >> CAM reports SCSI protocol for ATAPI devices at this moment. It is not >> good probably. but changing it now may be painful. Checks like >> d->ccb->cpi.transport == XPORT_ATA || >> d->ccb->cpi.transport == XPORT_SATA >> should be for now. "ata" hack should also stay there for now, as >> ATAPICAM emulates SCSI transport now, but not a new ATA one. > > What protocol should CAM be reporting for ATAPI devices? It is SCSI. I > don't understand why we have to keep on diverging from the goal of > having a unified and consistent interface here. ATAPI supports both ATA (partially) and SCSI command sets. And before main SCSI commands can be executed, ATA identification and configuration should be done. Now SATA XPT fetches ATA IDENTIFY and sets respective transfer mode, but it is tricky now for other code to differentiate ATAPI devices from plain SCSI. From the one side transfer negotiation is indeed only a transport feature, but from other side, as in this cdparanoia case ATAPI/SCSI difference somehow affects error handling (haven't looked actually why). -- Alexander Motin From miwi at FreeBSD.org Fri Aug 7 08:09:51 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Fri Aug 7 08:09:58 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: <20090807010159.GV86066@phenom.cordula.ws> References: <20090807000611.GA38670@bsdcrew.de> <20090807010159.GV86066@phenom.cordula.ws> Message-ID: <20090807080946.GB38670@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 07, 2009 at 03:02:00AM +0200, cpghost wrote: > On Fri, Aug 07, 2009 at 02:06:11AM +0200, Martin Wilke wrote: > > A secound problem is powerd, i can't use > > that under 1200 mhz, under 1200 the box > > freeze. > > I have that same problem with a > CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) > > AS a work around, I've added > debug.cpufreq.lowest="1240" > to /boot/loader.conf. > > It's not ideal, but I have NO idea what's causing the freezes > at lower CPU speeds. > > BTW, you can slow down videos in mplayer manually by typing > '[' repeatedly -- and speed them up again with ']'. > > -cpghost. Thanks but that's all workarounds, I want here to get a real solutions, also that solved not the flash problem. - - Martin > > -- > Cordula's Web. http://www.cordula.ws/ > _______________________________________________ > 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" > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEARECAAYFAkp74UoACgkQdLJIhLHm/OneygCfWbaVQY9+/EsL4cQL0FkKoqqD iGkAkgNC4DUOlFWbDSkHOoOFOzb4NFQ= =QAHR -----END PGP SIGNATURE----- From scottl at samsco.org Fri Aug 7 08:16:52 2009 From: scottl at samsco.org (Scott Long) Date: Fri Aug 7 08:16:59 2009 Subject: cdparanoia patch for ahci(4)/siis(4) In-Reply-To: <4A7BDAFB.7020303@FreeBSD.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> <4A7BD64D.60601@samsco.org> <4A7BDAFB.7020303@FreeBSD.org> Message-ID: <4A7BDD78.5020607@samsco.org> Alexander Motin wrote: > Scott Long wrote: >> Alexander Motin wrote: >>> CAM reports SCSI protocol for ATAPI devices at this moment. It is not >>> good probably. but changing it now may be painful. Checks like >>> d->ccb->cpi.transport == XPORT_ATA || >>> d->ccb->cpi.transport == XPORT_SATA >>> should be for now. "ata" hack should also stay there for now, as >>> ATAPICAM emulates SCSI transport now, but not a new ATA one. >> What protocol should CAM be reporting for ATAPI devices? It is SCSI. I >> don't understand why we have to keep on diverging from the goal of >> having a unified and consistent interface here. > > ATAPI supports both ATA (partially) Not really, just enough to get it going into PACKET mode. The SCSI emulation in ATAPI drives has been very good for the past 10 years, as they have to be MMC compliant in order to work with the common Windows software. > and SCSI command sets. And before > main SCSI commands can be executed, ATA identification and configuration > should be done. This is a detail that happens internal to CAM and long before the device is made available to the user. > Now SATA XPT fetches ATA IDENTIFY and sets respective > transfer mode, but it is tricky now for other code to differentiate > ATAPI devices from plain SCSI. Again, there is no need. An application can always look at the protocol transport data, see that it's SATA/ATA, and do an XPT_ATA_IO command. Adding yet another protocol definition only complicates things for no benefit and no portability. > From the one side transfer negotiation is > indeed only a transport feature, but from other side, as in this > cdparanoia case ATAPI/SCSI difference somehow affects error handling > (haven't looked actually why). > As we have discussed many times, ATA error reporting is primitive at best, and vastly inferior to SCSI error reporting. Scott From marius at nuenneri.ch Fri Aug 7 08:42:41 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Aug 7 08:42:51 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: <20090807080946.GB38670@bsdcrew.de> References: <20090807000611.GA38670@bsdcrew.de> <20090807010159.GV86066@phenom.cordula.ws> <20090807080946.GB38670@bsdcrew.de> Message-ID: On Fri, Aug 7, 2009 at 10:09, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Aug 07, 2009 at 03:02:00AM +0200, cpghost wrote: >> On Fri, Aug 07, 2009 at 02:06:11AM +0200, Martin Wilke wrote: >> > A secound problem is powerd, i can't use >> > that under 1200 mhz, under 1200 the box >> > freeze. >> >> I have that same problem with a >> ? CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) >> >> AS a work around, I've added >> ? debug.cpufreq.lowest="1240" >> to /boot/loader.conf. >> >> It's not ideal, but I have NO idea what's causing the freezes >> at lower CPU speeds. >> >> BTW, you can slow down videos in mplayer manually by typing >> '[' repeatedly -- and speed them up again with ']'. >> >> -cpghost. > > Thanks but that's all workarounds, I want here to get a real > solutions, also that solved not the flash problem. > > - - Martin > >> >> -- >> Cordula's Web. http://www.cordula.ws/ >> _______________________________________________ >> 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" >> > > - -- > > +-----------------------+-------------------------------+ > | ?PGP ? ?: 0xB1E6FCE9 ?| ?Jabber : miwi(at)BSDCrew.de ?| > | ?Skype ?: splash_111 ?| ?Mail ? : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | ? ? ? Mess with the Best, Die like the Rest! ? ? ? ? ?| > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEUEARECAAYFAkp74UoACgkQdLJIhLHm/OneygCfWbaVQY9+/EsL4cQL0FkKoqqD > iGkAkgNC4DUOlFWbDSkHOoOFOzb4NFQ= > =QAHR > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Please show: sysctl kern.timecounter afaik using acpi_throttling AND cool'n quiet together often leads to freezes and even to more energy consumption. Maybe you can disable acpi_throttle and just use the cool'n quiet states. From simon at siel.si Fri Aug 7 08:48:56 2009 From: simon at siel.si (=?WINDOWS-1252?Q?Simon_=8Eekar?=) Date: Fri Aug 7 08:49:03 2009 Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 In-Reply-To: <4A66C7BB.6030307@samsco.org> References: <4A66C7BB.6030307@samsco.org> Message-ID: <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> Hello, what's really issue with this ? Is there any workaround ? interesting is that a FreeBSD 7.2 i386 boots fine when preinstalled on a server with a different controller. Thanks, S. On Jul 22, 2009, at 10:03 AM, Scott Long wrote: > This is probably a CISS P410 controller, right? It'll say exactly > what it is further up in the boot messages. I know of the problem > here, and > I'm working on a fix. However, it might be a few more days before I > have anything that can be tested. > > Scott > > > Simon ?ekar wrote: >> Hello, >> I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD >> image on a HP DL380 G6. >> it freezes right after USB hubs & CD initialization with the >> messsage: >> umass0: on usbus5 >> umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 >> umass0:2:0:-1: Attached to scbus2 >> run_interrupt_driven_hooks: still waiting after 60 seconds for >> xpt_config >> run_interrupt_driven_hooks: still waiting after 120 seconds for >> xpt_config >> run_interrupt_driven_hooks: still waiting after 180 seconds for >> xpt_config >> run_interrupt_driven_hooks: still waiting after 240 seconds for >> xpt_config >> run_interrupt_driven_hooks: still waiting after 300 seconds for >> xpt_config >> panic: run_interrupt_driven_config_hooks: waited too long >> cpuid = 0 >> KDB: enter : panic >> [thread pid 0 tid 100000] >> Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) >> db> >> keyboard freezes here, so no way I can do backtrace. >> The same error is with 7.2-RELEASE bootable CD, but there it just >> freezes, no messages about waiting for xpt_config. >> What's there to be done ? >> I can provide remote access to iLO of this server if this would >> somehow help fix things. >> Thank you, >> Simon. From miwi at FreeBSD.org Fri Aug 7 10:07:07 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Fri Aug 7 10:07:14 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: <20090807000611.GA38670@bsdcrew.de> References: <20090807000611.GA38670@bsdcrew.de> Message-ID: <20090807100705.GE42714@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 07, 2009 at 02:06:11AM +0200, Martin Wilke wrote: > Howdy, > > We got a new box for playing with some appz, > now I have a _strange_ problem. All > videos / flash vidoes playing to fast. > I've tested vlc/xine/mplayer all the > same problem. Sound is ok. I played also > with kern.hz=100 but still the same problem. > A secound problem is powerd, i can't use > that under 1200 mhz, under 1200 the box > freeze. > > [1:52][miwi@] $ uname -a (~) > FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #1 r196069: Wed Aug 5 14:52:16 CEST 2009 root@:/usr/obj/usr/src/sys/AMD64BOX amd64 > [1:52][miwi@] $ > > dmesg: > http://nopaste.unixfreunde.de/2275 > > pciconf -lv > http://nopaste.unixfreunde.de/2276 > > Does someone have any idea what happend is here? > > thx miwi Ok all solved, bios updated solved the powerd problem (thx to b.f for the tip) and video speed problem can I solve with hw.snd.default_unit=1. (thx to rnoland) - - Martin > > -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkp7/MkACgkQdLJIhLHm/Okw0ACgsBteWn4zZDucqucrLowF35e/ PnAAoL8y74jR2mKgiHJ2L+FEDwN2tjWA =Muss -----END PGP SIGNATURE----- From fullblaststorm at gmail.com Fri Aug 7 10:33:41 2009 From: fullblaststorm at gmail.com (FuLLBLaSTstorm) Date: Fri Aug 7 10:33:48 2009 Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 In-Reply-To: <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> References: <4A66C7BB.6030307@samsco.org> <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> Message-ID: <6c51dbb10908070312m489e3910tf7082ba6c741a25@mail.gmail.com> Greetings, I have the Fujitsu Siemens ESPRIMO V6505 laptop. So I have *exactly* the same problem installing FreeBSD on it. So if some testing is required i will be more than happy to do it. Regards From simon at siel.si Fri Aug 7 11:24:59 2009 From: simon at siel.si (=?WINDOWS-1252?Q?Simon_=8Eekar?=) Date: Fri Aug 7 11:25:05 2009 Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 In-Reply-To: <6c51dbb10908070312m489e3910tf7082ba6c741a25@mail.gmail.com> References: <4A66C7BB.6030307@samsco.org> <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> <6c51dbb10908070312m489e3910tf7082ba6c741a25@mail.gmail.com> Message-ID: I have noticed that behaviour on some old IBM servers as well. It looks like this was introduced in 7.2 release. 7.1 release boots fine. S. On Aug 7, 2009, at 12:12 PM, FuLLBLaSTstorm wrote: > Greetings, > I have the Fujitsu Siemens ESPRIMO V6505 laptop. So I have *exactly* > the same problem installing FreeBSD on it. So if some testing is > required i will be more than happy to do it. > > Regards > _______________________________________________ > 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 syrinx at FreeBSD.org Fri Aug 7 11:27:17 2009 From: syrinx at FreeBSD.org (Shteryana Shopova) Date: Fri Aug 7 11:27:23 2009 Subject: kernel crash while loading snd_hda - _sx_xlock_hard: recursed on non-recursive sx Message-ID: <61b573980908070359h2b79d507t4661bea162378ab0@mail.gmail.com> Hi, I am getting a kernel crash every time I try to load the snd_hda module - backtrace in the attachment - this is on a current as of August 6th, ~17pm. Making the newbus lock recursable fixed the issue for me (patch attached) but I am not familiar with the newbus subsystem & locking so I am not sure that this is the appropriate solution. cheers, Shteryana -------------- next part -------------- #9 0xc087fce6 in panic ( fmt=0xc0c70429 "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xc0887554 in _sx_xlock_hard (sx=0xc0dd4740, tid=3320844864, opts=0, file=0xc0c724c0 "/usr/src/sys/kern/subr_bus.c", line=219) at /usr/src/sys/kern/kern_sx.c:484 #11 0xc0887cb0 in _sx_xlock (sx=0xc0dd4740, opts=0, file=0xc0c724c0 "/usr/src/sys/kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08a752a in newbus_xlock () at /usr/src/sys/kern/subr_bus.c:219 #13 0xc63a0124 in hdac_attach2 (arg=0xc5ac6800) ---Type to continue, or q to quit--- at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc63a89e5 in hdac_attach (dev=0xc5b07e80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08a8817 in device_attach (dev=0xc5b07e80) at device_if.h:178 #16 0xc08a954c in device_probe_and_attach (dev=0xc5b07e80) at /usr/src/sys/kern/subr_bus.c:2602 #17 0xc070d9b5 in pci_driver_added (dev=0xc5b09380, driver=0xc63ad320) at /usr/src/sys/dev/pci/pci.c:2839 #18 0xc08a6488 in devclass_driver_added (dc=0xc5955b00, driver=0xc63ad320) at bus_if.h:183 #19 0xc08a8163 in driver_module_handler (mod=0xc5e8bb40, what=0, arg=0xc63ad2f0) at /usr/src/sys/kern/subr_bus.c:1084 #20 0xc086f557 in module_register_init (arg=0xc63ad250) at /usr/src/sys/kern/kern_module.c:124 #21 0xc0866d2a in linker_load_module (kldname=Variable "kldname" is not available. ) at /usr/src/sys/kern/kern_linker.c:234 #22 0xc08671ea in kern_kldload (td=0xc5f01240, file=0xc5e0f800 "snd_hda", fileid=0xe81e4c70) at /usr/src/sys/kern/kern_linker.c:1016 #23 0xc0867324 in kldload (td=0xc5f01240, uap=0xe81e4cf8) at /usr/src/sys/kern/kern_linker.c:1044 -------------- next part -------------- A non-text attachment was scrubbed... Name: subr_bus.c-20090807-01.diff Type: application/octet-stream Size: 459 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/b41ada6f/subr_bus.c-20090807-01.obj From hselasky at c2i.net Fri Aug 7 12:24:33 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Aug 7 12:24:39 2009 Subject: Recent newbus lock patches cleanup in USB regard Message-ID: <200908071424.32236.hselasky@c2i.net> Hi, I've reviewed Attilio's patches in USB regard and I've spent some hours today to cleanup his initial patch. Result is below: http://perforce.freebsd.org/chv.cgi?CH=167087 Patch for -current will be posted later. The patch needs some more testing before committing. --HPS From hselasky at c2i.net Fri Aug 7 12:33:17 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Aug 7 12:33:29 2009 Subject: USB busdma sync flag fix Message-ID: <200908071433.16484.hselasky@c2i.net> Hi, Can people with AMD64 + USB and more than 4GBytes of RAM give the following patch a shot? http://perforce.freebsd.org/chv.cgi?CH=167088 Thanks to "Grzegorz Bernacki" and his friends at Semihalf for fixing USB on ARM and PowerPC ++ --HPS From freebsd-listen at fabiankeil.de Fri Aug 7 12:38:49 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Fri Aug 7 12:38:55 2009 Subject: Fatal trap 12: page fault while in kernel mode - current process: flowcleaner Message-ID: <20090807142027.1a30e8ba@fabiankeil.de> Using: FreeBSD TP51.local 8.0-BETA2 FreeBSD 8.0-BETA2 #36: Sat Aug 1 00:07:09 CEST 2009 fk@TP51.local:/usr/obj/usr/src/sys/THINKPAD i386 I got the following panic: fk@TP51 /usr/crash $kgdb /boot/kernel/kernel.symbols vmcore.6 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"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xf1a2fc94 frame pointer = 0x28:0xf1a2fcd8 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 = 40 (flowcleaner) panic: from debugger cpuid = 0 Uptime: 2m1s Physical memory: 998 MB Dumping 144 MB: 129 113 97 81 65 49 33 17 1 Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /boot/kernel/unionfs.ko.symbols...done. done. [...] Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:246 #1 0xc0678e66 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc06790a2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc04f2e57 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:478 #4 0xc04f33e1 in db_command (last_cmdp=0xc0a1f31c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04f353a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc04f532d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #7 0xc06a33c6 in kdb_trap (type=12, code=0, tf=0xf1a2fc54) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xc0913a8f in trap_fatal (frame=0xf1a2fc54, eva=0) at /usr/src/sys/i386/i386/trap.c:924 #9 0xc0913cc3 in trap_pfault (frame=0xf1a2fc54, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #10 0xc091469a in trap (frame=0xf1a2fc54) at /usr/src/sys/i386/i386/trap.c:528 #11 0xc08f83bb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #12 0x00000000 in ?? () Previous frame inner to this frame (corrupt stack?) The backtrace in ddb mentioned several flow* functions, but unfortunately it doesn't seem to have survived the dump. The problem occurred after booting the system with the rc.conf line: ifconfig_wlan0="inet 192.168.178.49 -wme" changing it to: ifconfig_wlan0="inet 192.168.178.49 ssid [...] wepkey 1:[0x...] deftxkey 1 wepmode on chanlist 7 -wme" running: /etc/rc.d/netif restart followed by: ifconfig wlan0 which showed that wlan0 got associated. The panic happened less than a second later. The system is an IBM ThinkPad R51 with iwi0 as wlandev. em0 was configured and up but unconnected. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/6d4fe498/signature.pgp From jhb at freebsd.org Fri Aug 7 12:44:44 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Aug 7 12:44:57 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> Message-ID: <200908070835.20246.jhb@freebsd.org> On Thursday 06 August 2009 10:11:26 am Robert Watson wrote: > On Thu, 6 Aug 2009, Larry Rosenman wrote: > > > On Thu, 6 Aug 2009, Robert Watson wrote: > > > >> On Tue, 4 Aug 2009, Navdeep Parhar wrote: > >> > >>>>> This occurs on today's HEAD + some unrelated patches. That makes it > >>>>> 8.0BETA2+ code. I haven't tried older builds. > >>>> > >>>> We have finally been able to reproduce this ourselves yesterday and > >>> > >>> Well, it happens every single time on all of my amd64 machines. After I'd > >>> already sent my email I noticed that the netisr mutex has an odd address > >>> (pun intended :-)) > >>> > >>> m=0xffffffff8144d867 > >> > >> Heh, indeed. We just spotted the same result here. In this case it's > >> causing a panic because it leads to a non-atomic read due to mtx_lock > >> spanning a cache line boundary, followed shortly by a panic because it's > >> not a valid thread pointer when it's dereferenced, as we get a fractional > >> pointer. > > [snip] > > > > Do we have an ETA for a testable patch? > > RSN, I'm afraid. We can eliminate the effect by reverting the use of DPCPU in > netisr.c (basically reverting to pre-r195019 of netisr.c). The interesting > question is where the problem originates -- is gcc/ld/etc not laying out the > elf section properly, or are the MD parts not providing an aligned base? > There are also probably issues in the DPCPU handling of modules along similar > lines, but first things first. No, gcc/ld/etc is doing the right thing. However, the DPCPU and VNET code implicitly assumes that the dpcpu/vnet sets start off with a specific alignment and that assumption is false (as it turns out). -- John Baldwin From lstewart at freebsd.org Fri Aug 7 12:53:18 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Fri Aug 7 12:53:52 2009 Subject: Fatal trap 12: page fault while in kernel mode - current process: flowcleaner In-Reply-To: <20090807142027.1a30e8ba@fabiankeil.de> References: <20090807142027.1a30e8ba@fabiankeil.de> Message-ID: <4A7C2395.6020600@freebsd.org> Fabian Keil wrote: > Using: > > FreeBSD TP51.local 8.0-BETA2 FreeBSD 8.0-BETA2 #36: Sat Aug 1 00:07:09 CEST 2009 > fk@TP51.local:/usr/obj/usr/src/sys/THINKPAD i386 > > I got the following panic: > > fk@TP51 /usr/crash $kgdb /boot/kernel/kernel.symbols vmcore.6 > 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"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xf1a2fc94 > frame pointer = 0x28:0xf1a2fcd8 > 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 = 40 (flowcleaner) > panic: from debugger > cpuid = 0 > Uptime: 2m1s > Physical memory: 998 MB > Dumping 144 MB: 129 113 97 81 65 49 33 17 1 > > Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /boot/kernel/unionfs.ko.symbols...done. > done. > [...] > Loaded symbols for /boot/kernel/fdescfs.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:246 > #1 0xc0678e66 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xc06790a2 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc04f2e57 in db_panic (addr=Could not find the frame base for "db_panic". > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xc04f33e1 in db_command (last_cmdp=0xc0a1f31c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #5 0xc04f353a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xc04f532d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #7 0xc06a33c6 in kdb_trap (type=12, code=0, tf=0xf1a2fc54) at /usr/src/sys/kern/subr_kdb.c:534 > #8 0xc0913a8f in trap_fatal (frame=0xf1a2fc54, eva=0) at /usr/src/sys/i386/i386/trap.c:924 > #9 0xc0913cc3 in trap_pfault (frame=0xf1a2fc54, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:846 > #10 0xc091469a in trap (frame=0xf1a2fc54) at /usr/src/sys/i386/i386/trap.c:528 > #11 0xc08f83bb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #12 0x00000000 in ?? () > Previous frame inner to this frame (corrupt stack?) > > The backtrace in ddb mentioned several flow* functions, > but unfortunately it doesn't seem to have survived the > dump. > > The problem occurred after booting the system with the rc.conf line: > ifconfig_wlan0="inet 192.168.178.49 -wme" > changing it to: > ifconfig_wlan0="inet 192.168.178.49 ssid [...] wepkey 1:[0x...] deftxkey 1 wepmode on chanlist 7 -wme" > running: > /etc/rc.d/netif restart > followed by: > ifconfig wlan0 > which showed that wlan0 got associated. > The panic happened less than a second later. > > The system is an IBM ThinkPad R51 with iwi0 as wlandev. > em0 was configured and up but unconnected. I can reliably trigger a flowcleaner panic as well on my Toshiba R600 laptop with a rum based WIFI dongle (D-Link DWA-110). I only get it on teardown/detach though. Kip is aware of the issue and will hopefully have a patch for us at some point. Panic details: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff80628998 stack pointer = 0x28:0xffffff80568ebba0 frame pointer = 0x28:0xffffff80568ebc00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 51 (flowcleaner) Relevant part of backtrace: #8 0xffffffff80849083 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff80628998 in flowtable_free_stale (ft=Variable "ft" is not available. ) at /usr/src/sys/net/flowtable.c:835 #10 0xffffffff80628b17 in flowtable_cleaner () at /usr/src/sys/net/flowtable.c:944 #11 0xffffffff8055a37a in fork_exit (callout=0xffffffff80628a60 , arg=0x0, frame=0xffffff80568ebc80) at /usr/src/sys/kern/kern_fork.c:838 #12 0xffffffff8084955e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 Cheers, Lawrence From cpghost at cordula.ws Fri Aug 7 14:04:29 2009 From: cpghost at cordula.ws (cpghost) Date: Fri Aug 7 14:04:36 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: References: <20090807000611.GA38670@bsdcrew.de> <20090807010159.GV86066@phenom.cordula.ws> <20090807080946.GB38670@bsdcrew.de> Message-ID: <20090807140422.GE1650@phenom.cordula.ws> On Fri, Aug 07, 2009 at 10:42:39AM +0200, Marius N?nnerich wrote: > >> > A secound problem is powerd, i can't use > >> > that under 1200 mhz, under 1200 the box > >> > freeze. > >> > >> I have that same problem with a > >> ? CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) > >> > >> AS a work around, I've added > >> ? debug.cpufreq.lowest="1240" > >> to /boot/loader.conf. > >> > >> It's not ideal, but I have NO idea what's causing the freezes > >> at lower CPU speeds. > > Please show: > sysctl kern.timecounter With debug.cpufreq.lowest="1240" in /boot/loader.conf, this is what I get: phenom# sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 4503 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 4294967295 kern.timecounter.tc.ACPI-safe.counter: 2712383003 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1471646472 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 524765121 kern.timecounter.tc.TSC.frequency: 2000079241 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 phenom# sysctl -a | grep acpi_throttle dev.acpi_throttle.0.%desc: ACPI CPU Throttling dev.acpi_throttle.0.%driver: acpi_throttle dev.acpi_throttle.0.%parent: cpu0 dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 phenom# kenv | grep acpi acpi_load="YES" hint.acpi.0.oem="ACPIAM" hint.acpi.0.revision="1" hint.acpi.0.rsdp="0xf9d40" hint.acpi.0.rsdt="0x77f90000" > afaik using acpi_throttling AND cool'n quiet together often leads to > freezes and even to more energy consumption. Maybe you can disable > acpi_throttle and just use the cool'n quiet states. Ah, interesting! How can I disable it? In the BIOS or via ACPI? acpi(4) is somewhat confusing: I'm not sure what to put into debug.acpi.disabled. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From attilio at freebsd.org Fri Aug 7 14:04:54 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Aug 7 14:05:00 2009 Subject: kernel crash while loading snd_hda - _sx_xlock_hard: recursed on non-recursive sx In-Reply-To: <61b573980908070359h2b79d507t4661bea162378ab0@mail.gmail.com> References: <61b573980908070359h2b79d507t4661bea162378ab0@mail.gmail.com> Message-ID: <3bbf2fe10908070704h5c57282fofb911e18161918de@mail.gmail.com> 2009/8/7 Shteryana Shopova : > Hi, > > I am getting a kernel crash every time I try to load the snd_hda > module - backtrace in the attachment - this is on a current as of > August 6th, ~17pm. Making the newbus lock recursable fixed the issue > for me (patch attached) but I am not familiar with the newbus > subsystem & locking so I am not sure that this is the appropriate > solution. This patch will fix it: http://www.freebsd.org/~attilio/hdac.diff Please just bear with it until commits are restored. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From pluknet at gmail.com Fri Aug 7 14:56:26 2009 From: pluknet at gmail.com (pluknet) Date: Fri Aug 7 14:56:33 2009 Subject: [newbus][aac] Lock newbus not exclusively locked @ /usr/HEAD/src/sys/kern/subr_bus.c:3154 Message-ID: Hi. As for today's HEAD I got a panic in bad newbus locking vs aac(4) interaction. acd0: CDRW at ata1-master UDMA33 panic: Lock newbus not exclusively locked @ /usr/HEAD/src/sys/kern/subr_bus.c:3154 cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3d: movq $0,0x69e9e0(%rip) db> bt Tracing pid 0 tid 100000 td 0xffffffff80c2dc00 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b assert_sx() at assert_sx bus_generic_attach() at bus_generic_attach+0x57 aac_startup() at aac_startup+0xd7 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x6c mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> bt 6 Tracing pid 6 tid 100038 td 0xffffff000267e720 sched_switch() at sched_switch+0x180 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x341 aac_command_thread() at aac_command_thread+0xbd fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000147d30, rbp = 0 --- db> show locks exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff80c305a0) locked @ /usr/HEAD/src/sys/kern/kern_module.c:117 -- wbr, pluknet From attilio at freebsd.org Fri Aug 7 15:07:30 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Aug 7 15:07:38 2009 Subject: [newbus][aac] Lock newbus not exclusively locked @ /usr/HEAD/src/sys/kern/subr_bus.c:3154 In-Reply-To: References: Message-ID: <3bbf2fe10908070807u3b8a232w48ffc3c4d7dff389@mail.gmail.com> 2009/8/7 pluknet : > Hi. > > As for today's HEAD I got a panic in bad newbus locking vs aac(4) interaction. > > acd0: CDRW at ata1-master UDMA33 > panic: Lock newbus not exclusively locked @ > /usr/HEAD/src/sys/kern/subr_bus.c:3154 I'm preparing a patch based also on your older reports about LORs, I will send out shortly. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From marius at nuenneri.ch Fri Aug 7 15:08:03 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Aug 7 15:08:10 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: <20090807140422.GE1650@phenom.cordula.ws> References: <20090807000611.GA38670@bsdcrew.de> <20090807010159.GV86066@phenom.cordula.ws> <20090807080946.GB38670@bsdcrew.de> <20090807140422.GE1650@phenom.cordula.ws> Message-ID: On Fri, Aug 7, 2009 at 16:04, cpghost wrote: > On Fri, Aug 07, 2009 at 10:42:39AM +0200, Marius N?nnerich wrote: >> >> > A secound problem is powerd, i can't use >> >> > that under 1200 mhz, under 1200 the box >> >> > freeze. >> >> >> >> I have that same problem with a >> >> ? CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) >> >> >> >> AS a work around, I've added >> >> ? debug.cpufreq.lowest="1240" >> >> to /boot/loader.conf. >> >> >> >> It's not ideal, but I have NO idea what's causing the freezes >> >> at lower CPU speeds. >> >> Please show: >> sysctl kern.timecounter > > With debug.cpufreq.lowest="1240" in /boot/loader.conf, this is > what I get: > > phenom# sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) > ? ? ? ? ? ? ? ? ? ? ? ? dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 4503 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-safe.mask: 4294967295 > kern.timecounter.tc.ACPI-safe.counter: 2712383003 > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > kern.timecounter.tc.ACPI-safe.quality: 850 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 1471646472 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 524765121 > kern.timecounter.tc.TSC.frequency: 2000079241 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > phenom# sysctl -a | grep acpi_throttle > dev.acpi_throttle.0.%desc: ACPI CPU Throttling > dev.acpi_throttle.0.%driver: acpi_throttle > dev.acpi_throttle.0.%parent: cpu0 > dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 5000/-1 3750/-1 2500/-1 1250/-1 > > phenom# kenv | grep acpi > acpi_load="YES" > hint.acpi.0.oem="ACPIAM" > hint.acpi.0.revision="1" > hint.acpi.0.rsdp="0xf9d40" > hint.acpi.0.rsdt="0x77f90000" > >> afaik using acpi_throttling AND cool'n quiet together often leads to >> freezes and even to more energy consumption. Maybe you can disable >> acpi_throttle and just use the cool'n quiet states. > > Ah, interesting! How can I disable it? In the BIOS or via ACPI? > acpi(4) is somewhat confusing: I'm not sure what to put into > debug.acpi.disabled. > > Thanks, > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > http://markmail.org/message/njjpogzsylxmmkl7 I hope this helps. From hselasky at c2i.net Fri Aug 7 15:12:56 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Aug 7 15:13:18 2009 Subject: reattach 3g0 device: could not allocate new device In-Reply-To: <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> References: <89dbfdc30902231031j4407614vdce09e8e58cdc346@mail.gmail.com> <200908060937.48442.hselasky@c2i.net> <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> Message-ID: <200908071712.50579.hselasky@c2i.net> On Thursday 06 August 2009 13:12:49 Lucius Windschuh wrote: > Hi Hans. > > 2009/8/6 Hans Petter Selasky : > > On Thursday 06 August 2009 00:29:09 Lucius Windschuh wrote: > >> Hi. > >> I have a Vodafone-branded "OVATION MC950D (Qualcomm 3G CDMA)" UMTS pen > >> here. > >> > >> I found this thread from some months ago: > >> > >> 2009/2/24 Hans Petter Selasky : > >> > On Tuesday 24 February 2009, Kim Culhan wrote: > >> >> On Tue, Feb 24, 2009 at 3:05 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> On Mon, Feb 23, 2009 at 3:56 PM, Hans Petter Selasky > >> >> >> > >> >> > > >> >> > wrote: > >> >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> >> Running 8.0-CURRENT as of 2-22-09 > >> >> >> >> > >> >> >> >> The 3g0 device is a Novatel U727 EVDO wireless radio. > >> >> >> >> > >> >> >> >> If the machine boots with the device attached, dmesg reads: > >> >> >> >> > >> >> >> >> u3g0: on usbus2 > >> >> >> >> > >> >> >> >> Remove the device and this is logged: > >> >> >> >> > >> >> >> >> u3g0: at ushub2, port 2, addr 2 (disconnected) > >> >> >> >> > >> >> >> >> Reattach the device and there is this message: > >> >> >> >> > >> >> >> >> uhub_reattach_port:414: could not allocate new device! > >> > >> Was there any solution for this? > >> > >> I may provide further debugging information if somebody tells me how > >> to obtail useful details. > >> > >> A sniplet with hw.usb.debug=3: > >> usbd_req_set_config:1456: setting config 1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_do_request_callback:95: st=0 > >> usbd_transfer_submit:1397: xfer=0xc72210b0, endpoint=0xc5dd5078, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc5dd5078 edesc=0xc5dd532c isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x00 > >> usb_dump_queue: endpoint=0xc5dd5078 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72210b0 endpoint=0xc5dd5078 > >> sts=0 alen=8 , slen=8, afrm=1, nfrm=1 > >> usbd_do_request_callback:95: st=1 > >> usb_cdev_create:1854: Creating device nodes > >> usbd_set_config_index:584: error=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=36 > >> usbd_transfer_submit:1397: xfer=0xc7223188, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc7223188 endpoint=0xc71f9000 > >> sts=0 alen=3 6, slen=36, afrm=1, nfrm=1 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=0 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usb_test_autoinstall:571: Eject CD command status: > >> USB_ERR_NORMAL_COMPLETION usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usb_alloc_device:1781: Found Huawei auto-install disk! > >> usb_alloc_device:1789: new dev (addr 3), udev=0xc5dd5000, > >> parent_hub=0xc621b400 ugen0.3: at usbus0 > >> usb_set_device_state:2442: udev 0xc5dd5000 state CONFIGURED -> DETACHED > >> ugen0.3: at usbus0 (disconnected) > >> usb_cdev_free:1906: Freeing device nodes > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> uhub_reattach_port:440: could not allocate new device! > >> > >> *sigh* Unfortunately, I don't understand what is happening here. > > > > Try: > > > > sysctl hw.usb.ehci.no_hs=1 > > Sorry, but I get the same messages: > > $ sysctl hw.usb.ehci.no_hs=1 > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > Try this patch: src/sys/dev/usb/usb_device.c @@ -1777,7 +1777,8 @@ } } else if (usb_test_huawei_autoinst_p(udev, &uaa) == 0) { DPRINTFN(0, "Found Huawei auto-install disk!\n"); - err = USB_ERR_STALLED; /* fake an error */ + /* leave device unconfigured */ + usb_unconfigure(udev, USB_UNCFG_FLAG_FREE_SUBDEV); } } else { err = 0; /* set success */ --HPS From hselasky at c2i.net Fri Aug 7 15:12:56 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Aug 7 15:13:20 2009 Subject: reattach 3g0 device: could not allocate new device In-Reply-To: <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> References: <89dbfdc30902231031j4407614vdce09e8e58cdc346@mail.gmail.com> <200908060937.48442.hselasky@c2i.net> <90a5caac0908060412r3a117597m16573c16d35cc34a@mail.gmail.com> Message-ID: <200908071712.50579.hselasky@c2i.net> On Thursday 06 August 2009 13:12:49 Lucius Windschuh wrote: > Hi Hans. > > 2009/8/6 Hans Petter Selasky : > > On Thursday 06 August 2009 00:29:09 Lucius Windschuh wrote: > >> Hi. > >> I have a Vodafone-branded "OVATION MC950D (Qualcomm 3G CDMA)" UMTS pen > >> here. > >> > >> I found this thread from some months ago: > >> > >> 2009/2/24 Hans Petter Selasky : > >> > On Tuesday 24 February 2009, Kim Culhan wrote: > >> >> On Tue, Feb 24, 2009 at 3:05 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> On Mon, Feb 23, 2009 at 3:56 PM, Hans Petter Selasky > >> >> >> > >> >> > > >> >> > wrote: > >> >> >> > On Monday 23 February 2009, Kim Culhan wrote: > >> >> >> >> Running 8.0-CURRENT as of 2-22-09 > >> >> >> >> > >> >> >> >> The 3g0 device is a Novatel U727 EVDO wireless radio. > >> >> >> >> > >> >> >> >> If the machine boots with the device attached, dmesg reads: > >> >> >> >> > >> >> >> >> u3g0: on usbus2 > >> >> >> >> > >> >> >> >> Remove the device and this is logged: > >> >> >> >> > >> >> >> >> u3g0: at ushub2, port 2, addr 2 (disconnected) > >> >> >> >> > >> >> >> >> Reattach the device and there is this message: > >> >> >> >> > >> >> >> >> uhub_reattach_port:414: could not allocate new device! > >> > >> Was there any solution for this? > >> > >> I may provide further debugging information if somebody tells me how > >> to obtail useful details. > >> > >> A sniplet with hw.usb.debug=3: > >> usbd_req_set_config:1456: setting config 1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_do_request_callback:95: st=0 > >> usbd_transfer_submit:1397: xfer=0xc72210b0, endpoint=0xc5dd5078, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc5dd5078 edesc=0xc5dd532c isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x00 > >> usb_dump_queue: endpoint=0xc5dd5078 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72210b0 endpoint=0xc5dd5078 > >> sts=0 alen=8 , slen=8, afrm=1, nfrm=1 > >> usbd_do_request_callback:95: st=1 > >> usb_cdev_create:1854: Creating device nodes > >> usbd_set_config_index:584: error=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=36 > >> usbd_transfer_submit:1397: xfer=0xc7223188, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc7223188 endpoint=0xc71f9000 > >> sts=0 alen=3 6, slen=36, afrm=1, nfrm=1 > >> bbb_data_read_callback:320: max_bulk=64, data_rem=0 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_transfer_submit:1416: open > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72230b0, endpoint=0xc71f9024, > >> nframes=1, dir= write > >> usb_dump_endpoint: endpoint=0xc71f9024 edesc=0xc624e4d9 isoc_next=0 > >> toggle_next= 1 bEndpointAddress=0x09 > >> usb_dump_queue: endpoint=0xc71f9024 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72230b0 endpoint=0xc71f9024 > >> sts=0 alen=3 1, slen=31, afrm=1, nfrm=1 > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_transfer_submit:1397: xfer=0xc72234f8, endpoint=0xc71f9000, > >> nframes=1, dir= read > >> usb_dump_endpoint: endpoint=0xc71f9000 edesc=0xc624e4d2 isoc_next=0 > >> toggle_next= 0 bEndpointAddress=0x88 > >> usb_dump_queue: endpoint=0xc71f9000 xfer: > >> usbd_pipe_enter:1584: enter > >> usbd_pipe_start:2416: start > >> usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION > >> usbd_callback_wrapper:2030: case 1-4 > >> usbd_callback_wrapper_sub:2550: xfer=0xc72234f8 endpoint=0xc71f9000 > >> sts=0 alen=1 3, slen=13, afrm=1, nfrm=1 > >> usb_test_autoinstall:571: Eject CD command status: > >> USB_ERR_NORMAL_COMPLETION usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> usb_alloc_device:1781: Found Huawei auto-install disk! > >> usb_alloc_device:1789: new dev (addr 3), udev=0xc5dd5000, > >> parent_hub=0xc621b400 ugen0.3: at usbus0 > >> usb_set_device_state:2442: udev 0xc5dd5000 state CONFIGURED -> DETACHED > >> ugen0.3: at usbus0 (disconnected) > >> usb_cdev_free:1906: Freeing device nodes > >> usbd_transfer_stop:1691: close > >> usbd_transfer_done:2185: err=USB_ERR_CANCELLED > >> usbd_transfer_done:2192: not transferring > >> uhub_reattach_port:440: could not allocate new device! > >> > >> *sigh* Unfortunately, I don't understand what is happening here. > > > > Try: > > > > sysctl hw.usb.ehci.no_hs=1 > > Sorry, but I get the same messages: > > $ sysctl hw.usb.ehci.no_hs=1 > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > Try this patch: src/sys/dev/usb/usb_device.c @@ -1777,7 +1777,8 @@ } } else if (usb_test_huawei_autoinst_p(udev, &uaa) == 0) { DPRINTFN(0, "Found Huawei auto-install disk!\n"); - err = USB_ERR_STALLED; /* fake an error */ + /* leave device unconfigured */ + usb_unconfigure(udev, USB_UNCFG_FLAG_FREE_SUBDEV); } } else { err = 0; /* set success */ --HPS From cpghost at cordula.ws Fri Aug 7 15:14:30 2009 From: cpghost at cordula.ws (cpghost) Date: Fri Aug 7 15:14:44 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: References: <20090807000611.GA38670@bsdcrew.de> <20090807010159.GV86066@phenom.cordula.ws> <20090807080946.GB38670@bsdcrew.de> <20090807140422.GE1650@phenom.cordula.ws> Message-ID: <20090807151425.GC2419@phenom.cordula.ws> On Fri, Aug 07, 2009 at 05:08:01PM +0200, Marius N?nnerich wrote: > >> afaik using acpi_throttling AND cool'n quiet together often leads to > >> freezes and even to more energy consumption. Maybe you can disable > >> acpi_throttle and just use the cool'n quiet states. > > > > Ah, interesting! How can I disable it? In the BIOS or via ACPI? > > acpi(4) is somewhat confusing: I'm not sure what to put into > > debug.acpi.disabled. > > http://markmail.org/message/njjpogzsylxmmkl7 > I hope this helps. Thank you. I'll try it as soon as I can reboot this box. ;) Kind regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From Joerg.Schilling at fokus.fraunhofer.de Sun Aug 2 09:54:06 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri Aug 7 15:52:53 2009 Subject: RFC: ATA to CAM integration patch Message-ID: <4a755d11.YH68jo2T1j3qYokP%Joerg.Schilling@fokus.fraunhofer.de> >2) Audio CD stuff on the DVD drive gets cranky. > - cdrecord doesn't seem to like it anymore. -scanbus says > cdrecord: Inappropriate ioctl for device. CAMIOCOMMAND ioctl > failed. Cannot open SCSI driver. Did someone iomplement a CAM driver that does not support the ioctl for sending SCSI commands, or do you have different problems? > - Using cdda2wav to try and rip an audio track using the cd0 device > scrolls a lot of > Sorry, this driver and/or drive does not support cdda reading. > and such errors. Guessing the bus/id/lun from the devlist gives > what I assume is the same ioctl error from above. Be careful: if you give a /dev/* parameter to cdda2wav, it will use cooked ioctls from the kernel to read audio and I know of no operating system that does this in a recent way. If you like to get the best quality, you need to send RAW SCSI commands directly from cdda2wav. Do you use a recent cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de Note that this is slow today as a switch died yesterday and I needed to reroute the data though other networks without physical device access. J?rg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From gjb at semihalf.com Tue Aug 4 15:01:17 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Aug 7 15:55:26 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908031759.46491.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> Message-ID: <4A7848A0.4080905@semihalf.com> Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient > to update the CPU cache. One reason for this is that USB needs to invalidate > the same memory area multiple times. Busdma sync expects paired operation when > using the PRE and POST flags, from what I understand. I do not consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current list, or see > previous thread on the ARM mailing list. > > USB needs a solution where it can call a function given a busdma mapping, > preferably with an offset and length, which handles the cache sync issue and > works with bounce pages on +4GB systems. > Hi Hans, New USB stack uses busdma in a little unconventional way. As you mentioned in one of previous mails your assumptions are: XXX_PREXXX functions should be used prior to read/write device access. In other words, PRE has to be a flush operation. XXX_POSTXXX functions should be used after read/write device access. In other words, POST has to be an invalidate operation. Generally it is true, but if you look at ARM code you will find out that it is not that simple. You assumed that after bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there will be no data in cache, but it that's not true. Cache operation are performed on cache lines (32 bytes on our ARM device). Let's say you want to invalidate buffer with size 10 bytes. In this case first whole cache line is invalidated ( and now all requirements related to busdma synchronization are fulfilled, old contents of cache is gone). The second step is to restore back into cache 22 bytes of data which were not a part of buffer. After this second step data are loaded into cache line (it is because our device uses write allocate feature). So busdma on ARM "Perform any synchronization required after an update of host memory by the device", but we still end up with not invalidated flush. It is hard to fix it. We cannot just invalidate whole cache line. We cannot also use cpu_dcache_wbinv, because this function is called after buffer was used by device so we dont want to overwrite those data with old cache contents. One possible solution is to call first bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but this is ugly workaround which applies probably only to ARM case. The second problem is that you cannot use cpu_dcache_wb(inv) function directly because you need to handle bounce pages in USB code. I think that duplication of busdma code makes no sense. Probably it takes less work to add bus_dmamap_sync() before/after each transaction. Could you give us a quick overview of buffer handling in USB stack? I want to understand what is the relation between usb_pc_cpu_invalidate/flush() functions and reading/writing to USB device? From yours previous mail I understand that invalidate is called *before* reading and flush *before* writing. Is that true? Can we add a functions which will be called *after* reading/writing? If you have any questions regarding cache operation on ARM. please let me know, I will try to answer them. regards, Grzesiek From axel.scheepers at nl.clara.net Tue Aug 4 17:15:05 2009 From: axel.scheepers at nl.clara.net (Axel Scheepers) Date: Fri Aug 7 15:55:51 2009 Subject: GEOM geometry mismatch Message-ID: <1249406101.20811.12.camel@ceridwen.thuis.net> Hi List, I've installed a fresh 8.0-BETA2 from the provided iso's, did a cvsup to -current a couple of days back reinstalled world a now I see: GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). I quick look around tells me to use bsdlabel -e -A ad4s1 but then I get scary messages: bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities bsdlabel: Class not found (without changing anything in the label) This is just my desktop but I do wonder if I can manually change the c partition and the mismatch to make things right again without thrashing any filesystem? c: 625137282 63 unused 0 0 # "raw" part, don't edit Without the -A flag for reading historical parts I also get: partition g: partition extends past end of unit Thanks, Kind regards, Axel Scheepers From lists at lozenetz.org Tue Aug 4 18:23:41 2009 From: lists at lozenetz.org (Anton - Valqk) Date: Fri Aug 7 15:56:26 2009 Subject: 8.0-BETA2: two kernel lockups in one night Message-ID: <4A787826.5090909@lozenetz.org> Hi group. I've installed amd64 8.0-BETA2 distro from iso from official ftp. I knew there was a problem with hangs of the system because of disk io (and this machine is going to be loaded) and started tesing with bonnie++ In about 5-6 hours the first lockup came into real. Kernel went into dbg console and continue rebooted the system. Few hours later bonnie started again - same thing in few hours I got the second dump. This is the bonnie++ opts I've used: #> bonnie++ -u root -d /usr/test/ -c 10 -s 4098 -n 26000:100000:10:1000 -n 2048 -r 4098 -x 10000 -q -Z /dev/urandom > stat.html and here are links to the txt dumps. If someone is interested in the vmcore files let me know. http://bg0.eu/core.txt.0 http://bg0.eu/core.txt.1 Are these issues known for 8.0-BETA2? Are they going to be fixed or this is the well known old bug with *ata disks? I'm downloading 7.2 now and I'm going to do the same tests.... hope I don't get dbg console there... pls. CC me because I'm not subscribed. From gjb at semihalf.com Wed Aug 5 13:17:21 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Aug 7 15:57:47 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908041754.50244.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> <200908041754.50244.hselasky@c2i.net> Message-ID: <4A79865E.3060206@semihalf.com> Hans Petter Selasky wrote: > There are two kinds of DMA memory in USB regard: > 1) Transfer descriptors are allocated in coherent DMA memory. > Operation logic: > > 1.a) Write to descriptor. > 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. > 1.b.1) Write more fields to descriptor. > 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. > 1.c) Call usb_pc_cpu_invalidate() to clear cache. > 1.d) Read status field. If not complete goto 1.c) > > 2) Any kernel virtual memory (which might not be coherent) > > 2.a.0) CPU read case: > 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any > data in cache for this buffer. > 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. > > 2.b.0) CPU write case: > 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data > in cache to RAM for this buffer. > 2.b.2) After transfer completion there is no cache operation. > The best solution is to use bus_dmamap_sync() in in conventional way. I mean call bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) in case 2.a.1 and bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) in cases 2.a.2 and 1.c. But this is quite a big change and it's risky to put in into -current now, so below is another solution which I believe is simple and safe. I understand that usb_pc_cpu_flush() is called *before* write transfer. So I think that we can just call bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE) there. usb_pc_cpu_invalidate() is called before and after each read transfer and to invalidate cache before reading status field. So I think that simplest fix is to call following sequence of functions in it: bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); Below is the patch with that solution. I tested it on ARM and PowerPC and it fixes the problem. Please test it on other platforms you have to see if there is no regression. diff --git a/sys/dev/usb/usb_busdma.c b/sys/dev/usb/usb_busdma.c index 82d18a1..c57f51d 100644 --- a/sys/dev/usb/usb_busdma.c +++ b/sys/dev/usb/usb_busdma.c @@ -678,8 +678,8 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); } /*------------------------------------------------------------------------* @@ -692,8 +692,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); } /*------------------------------------------------------------------------* From julian at elischer.org Thu Aug 6 15:10:23 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 7 16:01:07 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: <4A7AF25D.40608@elischer.org> Rick Macklem wrote: > > > On Thu, 6 Aug 2009, Robert Watson wrote: > >> other places where we have very strong alignment requirements on >> i386/amd64, such as the td_ucred pointer that we check for change on >> system calls/traps to see if we need to refresh the thread's >> credential from the process credential. >> > Does this imply that the nfs/krpc hack of: > oldcred = td->td_ucred; > td->td_ucred = "some other cred ptr" > ... > td->td_ucred = oldcred; > > could be dangerous? > > Maybe it should be converted to code that replaces the contents instead > of replacing the *cred? (Variants of the above live in a bunch of places > in the krpc, nlm and nfs code, due to the fact that the socket functions > use td->td_ucred in various places.) no, creds are read-only .. you never change a cred. You alwasy make a new one ans use it, becasue you may be shareing your cred with hundreds of other sibling threads or processes. (they are refcounted) > > rick > > _______________________________________________ > 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 ubm at u-boot-man.de Thu Aug 6 21:09:16 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Fri Aug 7 16:01:27 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: <20090722201750.4ff23293.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> Message-ID: <20090806230909.d01e844a.ubm@u-boot-man.de> On Wed, 22 Jul 2009 20:17:50 +0200 Marc "UBM" Bocklet wrote: > On Sun, 12 Jul 2009 19:45:47 +0200 > Marc "UBM" Bocklet wrote: > > > On Sun, 12 Jul 2009 18:10:34 +0200 > > Marc "UBM" Bocklet wrote: > > > > > > > I've got it narrowed down between "2009.06.30.06.00.00" and > > > today. A kernel with the "old" date boots, a freshly csupped and > > > compiled kernel hangs with the usual symptoms (waiting for > > > interrupt driven hooks). > > > > > > I'll try csupping to just before the big cam commit to see if > > > there is any connection. When I said earlier that I was not > > > running with the ahci patch, I was partly wrong. I did not have > > > device ahci in my kernel config file nor had it loaded as a > > > module, but I had the patch applied. > > > > "2009.07.09.06.00.00" fixes the problem. > > Could it be that there are some subtle interactions in the cam > > subsystem that are stirred by the recent mega-commit? > > Is there any other info I can / should provide to help debugging this? Any news on this? This pretty much prevents me from running 8.0 :-/ Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From stapleton.41 at gmail.com Fri Aug 7 00:34:46 2009 From: stapleton.41 at gmail.com (Jim) Date: Fri Aug 7 16:01:49 2009 Subject: FreeBSD 8.0 Beta2 / ALC driver crashbase Message-ID: <80f4f2b20908061705h6b218702ked110fa54d1bee5@mail.gmail.com> I couldn't get the copy of the if_alc driver to compile in FreeBSD 7.2 on my new notebook, so I decided to use 8.0, and I found an issue, when I boot the installer media CD (boot only or DVD1), I get the following error: alc0: irq 16 at device 0.0 on pci7 alc0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). alc0: cannot allocate memory resources). Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fatal virtual address = 0x08 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff0024c6e8 stack pointer = 0x20:0xffffffff813f65f0 frame pointer = 0x20:0xffffffff813f6600 code segment = base 0x0, limit 0xfffff, type 0x1b = DLP 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 correct process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at alc_phy_down+0x0: cmpq $0,0x8(xrax) db> I'm not knowledgeable about this to the point where I could debug the issue, is there anything I could do to provide the developers with the info needed to fix the issue, or could someone tell me how to boot the installer and force it to not load if_alc, and suggest give me an idea of what this means, in laymans terms so I can try to diagnose it? If I had to guess, I would say it's trying to access a chunk of memory/address-space that hasn't been allocated or doesn't exist, but I don't know if that's correct or where to go from there. Thanks, -Jim Stapleton From gjb at semihalf.com Fri Aug 7 11:15:25 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Aug 7 16:02:20 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908051549.43890.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> <200908051549.43890.hselasky@c2i.net> Message-ID: <4A7C0CC9.3080701@semihalf.com> Hans Petter Selasky wrote: > On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > > I will do some more testing and then commit it to USB P4. > Hi Hans, Have you had a chance to perform your tests? Do you see any problems on your machine after applying the patch? regards, Grzesiek From ggajic at afrodita.rcub.bg.ac.rs Fri Aug 7 12:29:12 2009 From: ggajic at afrodita.rcub.bg.ac.rs (Goran Gajic) Date: Fri Aug 7 16:03:08 2009 Subject: hda kernel panic Message-ID: Hi, As of today I have tried running: FreeBSD 8.0-BETA2 #0 r196085M but I have experienced kernel panic when snd_hda.ko was loaded during boot. Here is what I could get from vmcore. 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"... Unread portion of the kernel message buffer: ichsmb0: port 0x8400-0x840f mem 0xfed00000-0xfed003ff at device 20.0 on pci0 ichsmb0: can't map I/O device_attach: ichsmb0 attach returned 6 hdac0: mem 0xc0000000-0xc0003fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] panic: _sx_xlock_hard: recursed on non-recursive sx newbus @ ../../../kern/subr_bus.c:219 cpuid = 0 KDB: enter: panic Physical memory: 878 MB Dumping 55 MB: 40 24 8 Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04cbff9 in db_fncall (dummy1=1574, dummy2=0, dummy3=-1060725237, dummy4=0xe36433c4 "") at ../../../ddb/db_command.c:548 #2 0xc04cc3f1 in db_command (last_cmdp=0xc0d995bc, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc04cc54a in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc04ce3dd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:229 #5 0xc08b24a6 in kdb_trap (type=3, code=0, tf=0xe364356c) at ../../../kern/subr_kdb.c:534 #6 0xc0bb731b in trap (frame=0xe364356c) at ../../../i386/i386/trap.c:685 #7 0xc0b9937b in calltrap () at ../../../i386/i386/exception.s:165 #8 0xc08b262a in kdb_enter (why=0xc0c77a73 "panic", msg=0xc0c77a73 "panic") at cpufunc.h:71 #9 0xc08847f6 in panic ( fmt=0xc0c782ea "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at ../../../kern/kern_shutdown.c:558 #10 0xc088c064 in _sx_xlock_hard (sx=0xc0ddcb40, tid=3297265344, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at ../../../kern/kern_sx.c:484 #11 0xc088c7c0 in _sx_xlock (sx=0xc0ddcb40, opts=0, file=0xc0c7a34d "../../../kern/subr_bus.c", line=219) at sx.h:155 #12 0xc08ac03a in newbus_xlock () at ../../../kern/subr_bus.c:219 #13 0xc4bb7124 in hdac_attach2 (arg=0xc46ec000) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:7438 #14 0xc4bbf9e5 in hdac_attach (dev=0xc46bcd80) at /usr/src/sys/modules/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:4193 #15 0xc08ad327 in device_attach (dev=0xc46bcd80) at device_if.h:178 #16 0xc08ae05c in device_probe_and_attach (dev=0xc46bcd80) at ../../../kern/subr_bus.c:2602 #17 0xc0710d95 in pci_driver_added (dev=0xc46bc880, driver=0xc4bc431c) at ../../../dev/pci/pci.c:2839 #18 0xc08aaf98 in devclass_driver_added (dc=0xc4556bc0, driver=0xc4bc431c) at bus_if.h:183 #19 0xc08acc73 in driver_module_handler (mod=0xc492d0c0, what=0, arg=0xc4bc42ec) at ../../../kern/subr_bus.c:1084 #20 0xc0874067 in module_register_init (arg=0xc4bc4250) at ../../../kern/kern_module.c:124 #21 0xc086b83a in linker_load_module (kldname=Variable "kldname" is not available. ) at ../../../kern/kern_linker.c:234 #22 0xc086bcfa in kern_kldload (td=0xc48846c0, file=0xc4717400 "snd_hda.ko", fileid=0xe3643c70) at ../../../kern/kern_linker.c:1016 #23 0xc086be34 in kldload (td=0xc48846c0, uap=0xe3643cf8) at ../../../kern/kern_linker.c:1044 #24 0xc0bb6a53 in syscall (frame=0xe3643d38) at ../../../i386/i386/trap.c:1073 #25 0xc0b993e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #26 0x00000033 in ?? () (kgdb) Quit (kgdb) Regards, gg. From attilio at freebsd.org Fri Aug 7 16:08:23 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Aug 7 16:08:31 2009 Subject: hda kernel panic In-Reply-To: References: Message-ID: <3bbf2fe10908070908m6cb9d2fao7552a5ddb33bac5a@mail.gmail.com> 2009/8/7 Goran Gajic : > > Hi, > > As of today I have tried running: FreeBSD 8.0-BETA2 #0 r196085M > but I have experienced kernel panic when snd_hda.ko was loaded during boot. > Here is what I could get from vmcore. http://www.freebsd.org/~attilio/hdac.diff It will be committed once the commits are restored along with a newbus errata I'm preparing. Attilio -- Peace can only be achieved by understanding - A. Einstein From gary.jennejohn at freenet.de Fri Aug 7 16:12:56 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Aug 7 16:13:04 2009 Subject: GEOM geometry mismatch In-Reply-To: <1249406101.20811.12.camel@ceridwen.thuis.net> References: <1249406101.20811.12.camel@ceridwen.thuis.net> Message-ID: <20090807181253.59ba37ed@ernst.jennejohn.org> On Tue, 04 Aug 2009 19:15:01 +0200 Axel Scheepers wrote: > I've installed a fresh 8.0-BETA2 from the provided iso's, did a cvsup to > -current a couple of days back reinstalled world a now I see: > > GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). > Just ignore it. I see this error at every boot also but it has no negative effects. --- Gary Jennejohn From gavin.atkinson at ury.york.ac.uk Fri Aug 7 16:56:28 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Fri Aug 7 16:56:35 2009 Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 In-Reply-To: <6c51dbb10908070312m489e3910tf7082ba6c741a25@mail.gmail.com> References: <4A66C7BB.6030307@samsco.org> <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> <6c51dbb10908070312m489e3910tf7082ba6c741a25@mail.gmail.com> Message-ID: <1249662310.65644.30.camel@buffy.york.ac.uk> On Fri, 2009-08-07 at 17:12 +0700, FuLLBLaSTstorm wrote: > Greetings, > I have the Fujitsu Siemens ESPRIMO V6505 laptop. So I have *exactly* > the same problem installing FreeBSD on it. So if some testing is > required i will be more than happy to do it. Unless your laptop uses the ciss(4) SCSI controller, as I understand it this is unlikely to be the same issue. It may well be worth including more information (like, for example, a full verbose dmesg), alongside information about when you first started seeing this, etc, in a new thread. Thanks, Gavin From nox at jelal.kn-bremen.de Fri Aug 7 17:07:30 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Aug 7 17:07:37 2009 Subject: cdparanoia patch for ahci(4)/siis(4) (next version) In-Reply-To: <4A7BD57E.3040201@FreeBSD.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> Message-ID: <20090807170426.GA4292@triton.kn-bremen.de> On Fri, Aug 07, 2009 at 10:19:26AM +0300, Alexander Motin wrote: > Scott Long wrote: > > Juergen Lock wrote: > >> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: > >>> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > >>>> Juergen Lock wrote: > >>>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as > >>>>> siis(4) (I remember a report about it being broken for usb optical > >>>>> drives too so maybe this is related?) - I tested with the > >>>>> audio/cdparanoia port as well as with > >>>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... > >>>>> (mplayer needs to be built with the libparanoia knob on for this) - > >>>>> this > >>>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s > >>>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I > >>>>> still > >>>>> have another optical drive on there, it's on the board's amd sb700) > >>>>> it causes the sata channel to be reset endlessly until I ^C mplayer: > >>>>> > >>>>> Soo, anyone have ideas/patches/things they want me to check for this? > >>>> But this appeared to to be really trivial. cdparanoia uses extremely > >>>> simple method for detecting ATAPI devices - it checks that SIM is > >>>> named "ata". Trivial single line hack made it successfully play some > >>>> old AudioCD in SATA drive on SiI3132 controller for me, while I am > >>>> typing this. Probably we should invent better way to do this. > >>> Oooh! :) I need to test this... > >> > >> Yup, works here too on siis and ahci with the following patch: > >> (maintainer Cc'd) > >> > >> Index: interface/scsi_interface.c > >> @@ -1480,9 +1480,12 @@ > >> /* > >> * if the bus device name is `ata', we're (obviously) > >> * running ATAPICAM. > >> + * XXX same for the new ahci(4) and siis(4) drivers... > >> */ > >> > >> - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { > >> + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || > >> + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || > >> + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { > >> cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); > >> d->is_atapi = 1; > >> } else { > >> > >> Thanx, :) > >> Juergen > > > > This is fine for the moment, but unmaintainable in the long run as more > > and more drives are written. cdparanoia needs to look at protocol and > > transport attributes, not device names. > > CAM reports SCSI protocol for ATAPI devices at this moment. It is not > good probably. but changing it now may be painful. Checks like > d->ccb->cpi.transport == XPORT_ATA || > d->ccb->cpi.transport == XPORT_SATA > should be for now. "ata" hack should also stay there for now, as > ATAPICAM emulates SCSI transport now, but not a new ATA one. Ok checking for XPORT_(S)ATA works for me as well: Index: interface/scsi_interface.c @@ -1480,10 +1480,16 @@ /* * if the bus device name is `ata', we're (obviously) * running ATAPICAM. + * same for the new ahci(4) and siis(4) drivers and future others + * which use SATA transport too... */ - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { - cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || +#if __FreeBSD_version >= 800102 + d->ccb->cpi.transport == XPORT_SATA || +#endif + d->ccb->cpi.transport == XPORT_ATA) { + cdmessage(d, "\tDrive is ATAPI (using ATAPICAM or direct CAM (S)ATA transport)\n"); d->is_atapi = 1; } else { cdmessage(d, "\tDrive is SCSI\n"); One question remains tho: What if someone connects a sata drive to a sas controller, will that still be XPORT_SAS then? In that case I'd say we'd need to check for that as well, or maybe just assume there are no `real' sas optical drives and treat everything sas as sata here... Thanx, Juergen From mav at FreeBSD.org Fri Aug 7 17:24:18 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Aug 7 17:24:25 2009 Subject: cdparanoia patch for ahci(4)/siis(4) (next version) In-Reply-To: <20090807170426.GA4292@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> <20090807170426.GA4292@triton.kn-bremen.de> Message-ID: <4A7C630D.6010500@FreeBSD.org> Juergen Lock wrote: > One question remains tho: What if someone connects a sata drive > to a sas controller, will that still be XPORT_SAS then? In that case > I'd say we'd need to check for that as well, or maybe just assume there > are no `real' sas optical drives and treat everything sas as sata here... There is no precedent yet, but I think it should become XPORT_SATA. SATA and SAS drives work quite different from management point of view, especially when working with PMP/Expanders, so controller should report what exactly going on there. -- Alexander Motin From scottl at samsco.org Fri Aug 7 18:01:09 2009 From: scottl at samsco.org (Scott Long) Date: Fri Aug 7 18:01:16 2009 Subject: cdparanoia patch for ahci(4)/siis(4) (next version) In-Reply-To: <20090807170426.GA4292@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> <20090807170426.GA4292@triton.kn-bremen.de> Message-ID: <20090807115859.M20031@pooker.samsco.org> On Fri, 7 Aug 2009, Juergen Lock wrote: > On Fri, Aug 07, 2009 at 10:19:26AM +0300, Alexander Motin wrote: >> Scott Long wrote: >>> Juergen Lock wrote: >>>> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: >>>>> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: >>>>>> Juergen Lock wrote: >>>>>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as >>>>>>> siis(4) (I remember a report about it being broken for usb optical >>>>>>> drives too so maybe this is related?) - I tested with the >>>>>>> audio/cdparanoia port as well as with >>>>>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... >>>>>>> (mplayer needs to be built with the libparanoia knob on for this) - >>>>>>> this >>>>>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s >>>>>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I >>>>>>> still >>>>>>> have another optical drive on there, it's on the board's amd sb700) >>>>>>> it causes the sata channel to be reset endlessly until I ^C mplayer: >>>>>>> >>>>>>> Soo, anyone have ideas/patches/things they want me to check for this? >>>>>> But this appeared to to be really trivial. cdparanoia uses extremely >>>>>> simple method for detecting ATAPI devices - it checks that SIM is >>>>>> named "ata". Trivial single line hack made it successfully play some >>>>>> old AudioCD in SATA drive on SiI3132 controller for me, while I am >>>>>> typing this. Probably we should invent better way to do this. >>>>> Oooh! :) I need to test this... >>>> >>>> Yup, works here too on siis and ahci with the following patch: >>>> (maintainer Cc'd) >>>> >>>> Index: interface/scsi_interface.c >>>> @@ -1480,9 +1480,12 @@ >>>> /* >>>> * if the bus device name is `ata', we're (obviously) >>>> * running ATAPICAM. >>>> + * XXX same for the new ahci(4) and siis(4) drivers... >>>> */ >>>> >>>> - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { >>>> + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || >>>> + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || >>>> + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { >>>> cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); >>>> d->is_atapi = 1; >>>> } else { >>>> >>>> Thanx, :) >>>> Juergen >>> >>> This is fine for the moment, but unmaintainable in the long run as more >>> and more drives are written. cdparanoia needs to look at protocol and >>> transport attributes, not device names. >> >> CAM reports SCSI protocol for ATAPI devices at this moment. It is not >> good probably. but changing it now may be painful. Checks like >> d->ccb->cpi.transport == XPORT_ATA || >> d->ccb->cpi.transport == XPORT_SATA >> should be for now. "ata" hack should also stay there for now, as >> ATAPICAM emulates SCSI transport now, but not a new ATA one. > > Ok checking for XPORT_(S)ATA works for me as well: > > Index: interface/scsi_interface.c > @@ -1480,10 +1480,16 @@ > /* > * if the bus device name is `ata', we're (obviously) > * running ATAPICAM. > + * same for the new ahci(4) and siis(4) drivers and future others > + * which use SATA transport too... > */ > > - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { > - cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); > + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || > +#if __FreeBSD_version >= 800102 > + d->ccb->cpi.transport == XPORT_SATA || > +#endif > + d->ccb->cpi.transport == XPORT_ATA) { > + cdmessage(d, "\tDrive is ATAPI (using ATAPICAM or direct CAM (S)ATA transport)\n"); > d->is_atapi = 1; > } else { > cdmessage(d, "\tDrive is SCSI\n"); > > One question remains tho: What if someone connects a sata drive > to a sas controller, will that still be XPORT_SAS then? In that case > I'd say we'd need to check for that as well, or maybe just assume there > are no `real' sas optical drives and treat everything sas as sata here... It's very possible to connect a SATA ATAPI drive to a SAS controller, though I'm not sure it's very common at the moment as it likely requires special support by the SAS controller and firmware. Scott From jemrpo at gmail.com Fri Aug 7 18:14:51 2009 From: jemrpo at gmail.com (Juan Esteban Martinez Restrepo) Date: Fri Aug 7 18:14:58 2009 Subject: PROBLEMS WITH 250GB SATA HD Message-ID: <1249666983.1305.4.camel@dmhosting.g.ysm.yahoo.com> Yesterday I upgraded from 7.2 to 8.0beta2, had some issues with fuse.ko and linux compat, but rebuilt and worked ok, I'm having problems trying to mount my SATA 250GB HD, because it just finds one partition (/dev/ad4s1), but I really have 2 partitions there (/dev/ad4s5 /dev/ad4s6) which are ntfs, when i use FreeSBIE live cd to boot it recognizes both partition (/dev/ad4s5 /dev/ad4s6) and can mount them and read the info which I have stored, but when i boot with 8.0BETA2 just find /dev/ad4s1. any ideas what could that be?, i have tried to boot either generic and custom kernel. and got this message on dmesg http://pastebin.com/m45a3711f -- Juan Esteban Martinez Restrepo From drew at mykitchentable.net Fri Aug 7 18:27:48 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 18:27:55 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] Message-ID: <4A7C7220.2090309@mykitchentable.net> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with current sources as of yesterday (8/6/09). I successfully built world and kernel, and installed the kernel. However when I attempted to install world, I got this error: ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib install: /lib/libc.so.7: chflags: Invalid argument *** Error code 71 Stop in /usr/src/lib/libc. *** Error code 1 And now I can't do anything as every command fails with: /libexec/ld-elf.so.1: Shared object "libc.so.7" not found How can I recover from this error? Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From spawk at acm.poly.edu Fri Aug 7 18:31:32 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Fri Aug 7 18:31:41 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <4A7C7220.2090309@mykitchentable.net> References: <4A7C7220.2090309@mykitchentable.net> Message-ID: <4A7C72E0.8080303@acm.poly.edu> Drew Tomlinson wrote: > I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with > current sources as of yesterday (8/6/09). I successfully built world and > kernel, and installed the kernel. However when I attempted to install > world, I got this error: > > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > install: /lib/libc.so.7: chflags: Invalid argument > *** Error code 71 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > > And now I can't do anything as every command fails with: > > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found > > How can I recover from this error? > > Thanks, > > Drew > > There are statically-linked versions of essential utilities in /rescue/. For example, you can use /rescue/mount_nfs to mount an NFS server with the files you need, then /rescue/cp to copy them to your system. -Boris From jakub_lach at mailplus.pl Fri Aug 7 18:36:25 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Fri Aug 7 18:36:33 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <4A7C7220.2090309@mykitchentable.net> References: <4A7C7220.2090309@mykitchentable.net> Message-ID: <24869963.post@talk.nabble.com> Drew Tomlinson wrote: > > I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with > current sources as of yesterday (8/6/09). I successfully built world and > kernel, and installed the kernel. However when I attempted to install > world, I got this error: > > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > install: /lib/libc.so.7: chflags: Invalid argument > *** Error code 71 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > > And now I can't do anything as every command fails with: > > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found > > How can I recover from this error? > > Thanks, > > Drew > > -- > Be a Great Magician! > Visit The Alchemist's Warehouse > > http://www.alchemistswarehouse.com > > _______________________________________________ > 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" > > If it's really missing, use some bootcd. It shouldn't though. Any chance you have deleted /lib conten in attempt to purge /usr/local/lib? -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/-Fwd%3A-How-To-Recover-From-Missing--lib-libc.so.7---tp24869873p24869963.html Sent from the freebsd-current mailing list archive at Nabble.com. From drew at mykitchentable.net Fri Aug 7 18:44:38 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 18:44:45 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <24869963.post@talk.nabble.com> References: <4A7C7220.2090309@mykitchentable.net> <24869963.post@talk.nabble.com> Message-ID: <4A7C7605.3010606@mykitchentable.net> Jakub Lach wrote: > > Drew Tomlinson wrote: > >> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with >> current sources as of yesterday (8/6/09). I successfully built world and >> kernel, and installed the kernel. However when I attempted to install >> world, I got this error: >> >> ===> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> install: /lib/libc.so.7: chflags: Invalid argument >> *** Error code 71 >> >> Stop in /usr/src/lib/libc. >> *** Error code 1 >> >> >> And now I can't do anything as every command fails with: >> >> /libexec/ld-elf.so.1: Shared object "libc.so.7" not found >> >> How can I recover from this error? >> >> Thanks, >> >> Drew > > If it's really missing, use some bootcd. > It shouldn't though. > > Any chance you have deleted /lib conten in attempt to purge > /usr/local/lib? > I'm really out of my league and appreciate the help. I was about to install this new machine with 7.x but then 8.0-BETA2 was announced with the actual release expected soon. Thus I installed 8.0-BETA2, especially since I wanted to learn about ZFS. But anyway, I didn't directly delete /lib. However I don't know what "make installworld" may have done. Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From drew at mykitchentable.net Fri Aug 7 18:51:38 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 18:51:45 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <4A7C72E0.8080303@acm.poly.edu> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> Message-ID: <4A7C77B6.8000209@mykitchentable.net> Boris Kochergin wrote: > Drew Tomlinson wrote: >> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with >> current sources as of yesterday (8/6/09). I successfully built world and >> kernel, and installed the kernel. However when I attempted to install >> world, I got this error: >> >> ===> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> install: /lib/libc.so.7: chflags: Invalid argument >> *** Error code 71 >> >> Stop in /usr/src/lib/libc. >> *** Error code 1 >> >> >> And now I can't do anything as every command fails with: >> >> /libexec/ld-elf.so.1: Shared object "libc.so.7" not found >> >> How can I recover from this error? >> >> Thanks, >> >> Drew >> >> > There are statically-linked versions of essential utilities in > /rescue/. For example, you can use /rescue/mount_nfs to mount an NFS > server with the files you need, then /rescue/cp to copy them to your > system. Thanks for the reply. As I mentioned in my reply to Jakob Lach, I really have no business running -CURRENT but loaded BETA2 because the release is expected soon. So basically I have the rescue tools and the BETA2 cd. Can I just mount the BETA2 CD, search for libc.so.7, can copy it to /lib? Will that give me enough to attempt grabbing updated sources and trying again. Or should I just somehow install world from the BETA2 CD and move /boot/kernel.old back to /boot/kernel? If so, how? Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From yr.retarded at gmail.com Fri Aug 7 18:56:21 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Fri Aug 7 18:56:28 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <4A7C77B6.8000209@mykitchentable.net> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> Message-ID: <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> On Fri, Aug 7, 2009 at 1:51 PM, Drew Tomlinson wrote: > Boris Kochergin wrote: >> Drew Tomlinson wrote: >>> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with >>> current sources as of yesterday (8/6/09). I successfully built world and >>> kernel, and installed the kernel. However when I attempted to install >>> world, I got this error: >>> >>> ===> lib/libc (install) >>> install -C -o root -g wheel -m 444 ? libc.a /usr/lib >>> install -C -o root -g wheel -m 444 ? libc_p.a /usr/lib >>> install -s -o root -g wheel -m 444 ? -fschg -S ?libc.so.7 /lib >>> install: /lib/libc.so.7: chflags: Invalid argument >>> *** Error code 71 >>> >>> Stop in /usr/src/lib/libc. >>> *** Error code 1 >>> >>> >>> And now I can't do anything as every command fails with: >>> >>> /libexec/ld-elf.so.1: Shared object "libc.so.7" not found >>> >>> How can I recover from this error? >>> >>> Thanks, >>> >>> Drew >>> >>> >> There are statically-linked versions of essential utilities in >> /rescue/. For example, you can use /rescue/mount_nfs to mount an NFS >> server with the files you need, then /rescue/cp to copy them to your >> system. > > Thanks for the reply. ?As I mentioned in my reply to Jakob Lach, I > really have no business running -CURRENT but loaded BETA2 because the > release is expected soon. > > So basically I have the rescue tools and the BETA2 cd. ?Can I just mount > the BETA2 CD, search for libc.so.7, can copy it to /lib? ?Will that give > me enough to attempt grabbing updated sources and trying again. ?Or > should I just somehow install world from the BETA2 CD and move > /boot/kernel.old back to /boot/kernel? ?If so, how? You must specify NO_FSCHG= when you installworld on an unupgraded ZFS filesystem, otherwise you will lose libc.so.7! I'll spare you the details on why this happens. Here's a quick fix: #/rescue/cp /usr/obj/usr/src/lib/libc/libc.so.7 /lib -- @chrisattack ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From ed at 80386.nl Fri Aug 7 19:03:52 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Aug 7 19:04:00 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> Message-ID: <20090807190350.GO1292@hoeg.nl> * Chris Ruiz wrote: > You must specify NO_FSCHG= when you installworld on an unupgraded ZFS > filesystem, otherwise you will lose libc.so.7! I'll spare you the > details on why this happens. Which is because our install(1) is stupid enough to delete the resulting binary if it can't add the schg flag. We should really change this behaviour. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/882376a1/attachment.pgp From mel.flynn+fbsd.current at mailing.thruhere.net Fri Aug 7 19:11:28 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Fri Aug 7 19:11:35 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <4A7C7220.2090309@mykitchentable.net> References: <4A7C7220.2090309@mykitchentable.net> Message-ID: <200908071111.26347.mel.flynn+fbsd.current@mailing.thruhere.net> On Friday 07 August 2009 10:27:44 Drew Tomlinson wrote: > I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with > current sources as of yesterday (8/6/09). I successfully built world and > kernel, and installed the kernel. However when I attempted to install > world, I got this error: > > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > install: /lib/libc.so.7: chflags: Invalid argument > *** Error code 71 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > > And now I can't do anything as every command fails with: > > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found > > How can I recover from this error? I assume you're running zfs? You should be able to run commands by setting LD_LIBRARY_PATH=/usr/obj/usr/src/lib/libc. -- Mel From ed at 80386.nl Fri Aug 7 19:14:55 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Aug 7 19:15:03 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <20090807190350.GO1292@hoeg.nl> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> <20090807190350.GO1292@hoeg.nl> Message-ID: <20090807191454.GP1292@hoeg.nl> * Ed Schouten wrote: > * Chris Ruiz wrote: > > You must specify NO_FSCHG= when you installworld on an unupgraded ZFS > > filesystem, otherwise you will lose libc.so.7! I'll spare you the > > details on why this happens. > > Which is because our install(1) is stupid enough to delete the resulting > binary if it can't add the schg flag. We should really change this > behaviour. It looks like there are actually two bugs: - install(1) does check for EOPNOTSUPP, while ZFS seems to return EINVAL. This is probably a ZFS bug. - Inside jails, (un)setting schg is not permitted and returns EPERM. We should change the VFS to return EOPNOTSUPP or install(1) to allow EPERM as well. It's a bit late, but I think it would be nice to have this fixed before 8.0. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/8665c41e/attachment.pgp From pawel.worach at gmail.com Fri Aug 7 19:24:16 2009 From: pawel.worach at gmail.com (Pawel Worach) Date: Fri Aug 7 19:24:23 2009 Subject: [panic] cam_error_string Message-ID: Hi, When connecting a USB mass storage device I sometimes get a panic where it looks like cam tried to report an error where the message or something related is NULL. Sometimes when it does not panic I get some junk printed on the console instead of the panic. Also crashdumps are broken, 256Mb RAM and 1Gb dumpdev, call doadump says the "Partition is to small", is this a known issue ? So, no dump, just a couple of screenshots from VMWare. http://i27.tinypic.com/2ykez5y.jpg - panic http://i30.tinypic.com/keg9py.jpg - trace Any other information I can provide ? Regards -- Pawel From morganw at chemikals.org Fri Aug 7 19:42:39 2009 From: morganw at chemikals.org (Wes Morgan) Date: Fri Aug 7 19:42:46 2009 Subject: mpt errors - UNIT ATTENTION asc:29,0 In-Reply-To: References: Message-ID: On Fri, 7 Aug 2009, Artem Belevich wrote: > Hi, > > I'm running 8.0-BETA2 on Asus p5BV/SAS with built-in LSI1068 > controller with 8 SATA ports. 6 of the ports hooked up to 1TB WD Green > drives. The drives are used as a single raidz2 ZFS pool: > > NAME STATE READ WRITE CKSUM > z2 ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da0 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > > I'm runing a simple stress test that copies 10GB file until it fills > the volume and then runs "zfs scrub" on it. > > dd if=/dev/urandom of=/z2/f.0 bs=1m count=10240 > for f in {1..350}; do echo $f; cp f.$[$f-1] f.$f; done; > zpool scrub z2 > > What concerns me is that I'm periodically getting error messages from > MPT driver. They usually start few hours after the start of the script > and by the end of it they are happening every few minutes seemingly > randomly on all six drives. > > Aug 7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug 7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): READ(10). CDB: 28 0 46 > 32 97 c0 0 0 80 0 > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): CAM Status: SCSI Status Error > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): SCSI Status: Check Condition > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): UNIT ATTENTION asc:29,0 > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Power on, reset, or bus > device reset occurred > Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Retrying Command (per Sense Data) > > ZFS scrub does not seem to report any issues so far - no checksum or > read/write errors. WD's hard drive diagnostics tools didn't find any > issues with te drives either. > > Sould somebody shed some light on why would such error happen? Is that > some sort of hardware issue? Driver bug? Issue with compatibility > between controller and the drives? System configuration issue (some > sysctl/tunable needs tweaking, perhaps)? I have that same board with 8 500gb drives in a raidz2. I used to be using a SATA backplane and I would see those timeouts fairly regularly when moving lots of data around. To eliminate the cable mess I switched to an SAS backplane with fanout cables and since then I have not seen the timeouts. From artemb at gmail.com Fri Aug 7 18:39:12 2009 From: artemb at gmail.com (Artem Belevich) Date: Fri Aug 7 20:40:05 2009 Subject: mpt errors - UNIT ATTENTION asc:29,0 Message-ID: Hi, I'm running 8.0-BETA2 on Asus p5BV/SAS with built-in LSI1068 controller with 8 SATA ports. 6 of the ports hooked up to 1TB WD Green drives. The drives are used as a single raidz2 ZFS pool: NAME STATE READ WRITE CKSUM z2 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 I'm runing a simple stress test that copies 10GB file until it fills the volume and then runs "zfs scrub" on it. dd if=/dev/urandom of=/z2/f.0 bs=1m count=10240 for f in {1..350}; do echo $f; cp f.$[$f-1] f.$f; done; zpool scrub z2 What concerns me is that I'm periodically getting error messages from MPT driver. They usually start few hours after the start of the script and by the end of it they are happening every few minutes seemingly randomly on all six drives. Aug 7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 Aug 7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): READ(10). CDB: 28 0 46 32 97 c0 0 0 80 0 Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): CAM Status: SCSI Status Error Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): SCSI Status: Check Condition Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): UNIT ATTENTION asc:29,0 Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Power on, reset, or bus device reset occurred Aug 7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Retrying Command (per Sense Data) ZFS scrub does not seem to report any issues so far - no checksum or read/write errors. WD's hard drive diagnostics tools didn't find any issues with te drives either. Sould somebody shed some light on why would such error happen? Is that some sort of hardware issue? Driver bug? Issue with compatibility between controller and the drives? System configuration issue (some sysctl/tunable needs tweaking, perhaps)? I'd appreciate any hints on what could be going on and what should be done about it. Thanks, --Artem From grarpamp at gmail.com Fri Aug 7 20:11:15 2009 From: grarpamp at gmail.com (grarpamp) Date: Fri Aug 7 20:40:17 2009 Subject: Cdparanoia Message-ID: Hi. While folks are looking at cdparanoia, would it be possible to update the port to the current release of cdparanoia? I got stuck trying to make a fresh port of it myself using the current port as a guide. It seemed like it would be a small changeset but it got me. Thanks :) ATAPICAM works for me btw. # release = r15302 http://downloads.xiph.org/releases/cdparanoia/cdparanoia-III-10.2.src.tgz # trac code browser https://trac.xiph.org/browser/trunk/cdparanoia https://trac.xiph.org/log/trunk/cdparanoia # svn [this trac doesn't have a download button, trunk is same] http://svn.xiph.org/trunk/cdparanoia/ From oberman at es.net Fri Aug 7 20:54:36 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 7 20:54:43 2009 Subject: Unable to build HEAD In-Reply-To: Your message of "Thu, 06 Aug 2009 11:37:50 -0000." Message-ID: <20090807205432.8FA4D1CC31@ptavv.es.net> > Date: Thu, 6 Aug 2009 11:37:50 +0000 > From: "b. f." > > On 8/6/09, Kevin Oberman wrote: > >I have tested a patch from bf and it works. I've asked if he wants to > >submit the PR or if he wants me to. If I don;t hear from him, I'll > >submit tomorrow. > > Slightly revised and augmented patch is in: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=137483 I think the patch is right, but I am still broken. I also had to remove the ".if ${MK_OPENSSH) != "no" and paired ".endif" from /usr/src/lib/libpam/modules/modules.inc. Once this was done, it looks like everything is correct. I think the right answer is to either unconditionally build the pam module or to add an option that is specific to the module. I think the former is really the way to go as the module only adds 46K to the system and, if you build without OpenSSH, you are either building an embedded system where you will almost certainly be trimming a lot further than the src.conf file allows, or because you are using the version from ports. If the latter, you almost certainly WILL want pam_ssh. And thanks for fixing the Makefile and submitting the PR! -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From nox at jelal.kn-bremen.de Fri Aug 7 21:05:28 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Aug 7 21:05:36 2009 Subject: cdparanoia patch for ahci(4)/siis(4) (next version) In-Reply-To: <20090807115859.M20031@pooker.samsco.org> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> <20090806222127.GB1940@triton.kn-bremen.de> <4A7BBA52.306@samsco.org> <4A7BD57E.3040201@FreeBSD.org> <20090807170426.GA4292@triton.kn-bremen.de> <20090807115859.M20031@pooker.samsco.org> Message-ID: <20090807210307.GA53016@triton.kn-bremen.de> On Fri, Aug 07, 2009 at 12:01:03PM -0600, Scott Long wrote: > On Fri, 7 Aug 2009, Juergen Lock wrote: > > On Fri, Aug 07, 2009 at 10:19:26AM +0300, Alexander Motin wrote: > >> Scott Long wrote: > >>> Juergen Lock wrote: > >>>> On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: > >>>>> On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > >>>>>> Juergen Lock wrote: > >>>>>>> 2. cdda/dae seems to be broken entirely with ahci(4) as well as > >>>>>>> siis(4) (I remember a report about it being broken for usb optical > >>>>>>> drives too so maybe this is related?) - I tested with the > >>>>>>> audio/cdparanoia port as well as with > >>>>>>> mplayer -cdrom-device /dev/cd{0,1} cdda://... > >>>>>>> (mplayer needs to be built with the libparanoia knob on for this) - > >>>>>>> this > >>>>>>> does work with atapicam(4) without ahci/siis so it can't be cd(4)'s > >>>>>>> fault alone. On siis(4) it seems to just fail while on ahci(4) (I > >>>>>>> still > >>>>>>> have another optical drive on there, it's on the board's amd sb700) > >>>>>>> it causes the sata channel to be reset endlessly until I ^C mplayer: > >>>>>>> > >>>>>>> Soo, anyone have ideas/patches/things they want me to check for this? > >>>>>> But this appeared to to be really trivial. cdparanoia uses extremely > >>>>>> simple method for detecting ATAPI devices - it checks that SIM is > >>>>>> named "ata". Trivial single line hack made it successfully play some > >>>>>> old AudioCD in SATA drive on SiI3132 controller for me, while I am > >>>>>> typing this. Probably we should invent better way to do this. > >>>>> Oooh! :) I need to test this... > >>>> > >>>> Yup, works here too on siis and ahci with the following patch: > >>>> (maintainer Cc'd) > >>>> > >>>> Index: interface/scsi_interface.c > >>>> @@ -1480,9 +1480,12 @@ > >>>> /* > >>>> * if the bus device name is `ata', we're (obviously) > >>>> * running ATAPICAM. > >>>> + * XXX same for the new ahci(4) and siis(4) drivers... > >>>> */ > >>>> > >>>> - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { > >>>> + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || > >>>> + strncmp(d->ccb->cpi.dev_name, "ahcich", 6) == 0 || > >>>> + strncmp(d->ccb->cpi.dev_name, "siisch", 6) == 0) { > >>>> cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); > >>>> d->is_atapi = 1; > >>>> } else { > >>>> > >>>> Thanx, :) > >>>> Juergen > >>> > >>> This is fine for the moment, but unmaintainable in the long run as more > >>> and more drives are written. cdparanoia needs to look at protocol and > >>> transport attributes, not device names. > >> > >> CAM reports SCSI protocol for ATAPI devices at this moment. It is not > >> good probably. but changing it now may be painful. Checks like > >> d->ccb->cpi.transport == XPORT_ATA || > >> d->ccb->cpi.transport == XPORT_SATA > >> should be for now. "ata" hack should also stay there for now, as > >> ATAPICAM emulates SCSI transport now, but not a new ATA one. > > > > Ok checking for XPORT_(S)ATA works for me as well: > > > > Index: interface/scsi_interface.c > > @@ -1480,10 +1480,16 @@ > > /* > > * if the bus device name is `ata', we're (obviously) > > * running ATAPICAM. > > + * same for the new ahci(4) and siis(4) drivers and future others > > + * which use SATA transport too... > > */ > > > > - if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0) { > > - cdmessage(d, "\tDrive is ATAPI (using ATAPICAM)\n"); > > + if (strncmp(d->ccb->cpi.dev_name, "ata", 3) == 0 || > > +#if __FreeBSD_version >= 800102 > > + d->ccb->cpi.transport == XPORT_SATA || > > +#endif > > + d->ccb->cpi.transport == XPORT_ATA) { > > + cdmessage(d, "\tDrive is ATAPI (using ATAPICAM or direct CAM (S)ATA transport)\n"); > > d->is_atapi = 1; > > } else { > > cdmessage(d, "\tDrive is SCSI\n"); > > > > One question remains tho: What if someone connects a sata drive > > to a sas controller, will that still be XPORT_SAS then? In that case > > I'd say we'd need to check for that as well, or maybe just assume there > > are no `real' sas optical drives and treat everything sas as sata here... > > It's very possible to connect a SATA ATAPI drive to a SAS controller, > though I'm not sure it's very common at the moment as it likely requires > special support by the SAS controller and firmware. Heh ok, so its probably just something to keep in mind for the future then... Btw, do you have any comment on the cd(4) bluray data disc issue? Thanx, Juergen From fb-embedded at psconsult.nl Fri Aug 7 21:37:11 2009 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Fri Aug 7 21:56:10 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090807.104414.221852486.imp@bsdimp.com> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <19068.18919.843159.936827@gromit.timing.com> <20090807.104414.221852486.imp@bsdimp.com> Message-ID: <20090807205817.GA82868@psconsult.nl> On Fri, Aug 07, 2009 at 10:44:14AM -0600, M. Warner Losh wrote: > In message: <19068.18919.843159.936827@gromit.timing.com> > John Hein writes: > : Olivier Cochard-Labb? wrote at 17:09 +0200 on Aug 7, 2009: > : > I meet a problem under FreeBSD 7.2 and 8.0-current (nanoBSD) using > : > boot0cfg: I can't use boot0cfg for changing the booting slice. > : > Here is my problem: > : > I'm using the FreeBSD Boot manager on a system with MBR partitions. > : > The active slice is the partition 1, but I want to boot from the slice 2. > : > > : > Then I use boot0cfg like that: > : > > : > sysctl kern.geom.debugflags=16 > : > boot0cfg -s 2 -v /dev/ad0 > : > sysctl kern.geom.debugflags=0 > : > > : > But, after the reboot my system still reboot from the slice 1 (but the > : > boot loader show correctly that the default choice is now the 2)! > : > Where is my problem ? > : > : Are you sure you're booting from slice 1? > : Is fstab on slice 2 pointing to slice 1? > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > the last slice you booted from... To mark it active, you must use > fdisk. If by 'active' you mean 'what mount reports root as' then I > think John's suggestion is right on the money... [I cc'ed freebsd-current as I feel this is a regression that really needs fixing before 8.0 comes out] Pre-7.2 world: boot0cfg changes the default slice to boot from by altering block0 byte at offset 0x1b9. Allowed values are 0-3 to boot from slice 1 thru 4 or 4 to boot from the next drive. Boot0 ignores the active flag in the MBR and only looks at the byte described above. 7.2-and-up world: boot0cfg still changes the same byte at 0x1b9 in block0 but boot0 seems to completely ignore this byte and boots from the slice marked active in the MBR. NanoBSD relies on the working of boot0cfg when upgrading, since 7.2 this just does not work any more. It seems that the original implementation of boot0 introduced the new way of storing the default slice to boot from to allow for other defaults than just slice 1 thru 4 which the active flag(s) in MBR allow. My personal opinion is that boot0 should either look at the byte at 0x1b9 or at the active flags. Since the active flags can only specify a default of 1 thru 4 and the design of MBR and the active flags is broken by design [1] I'd *really* like to see boot0 revert to the pre-7.2 behaviour. Hope this gets fixed before 8.0 comes out, leaving it the way it is renders boot0cfg and NanoBSD (which relies on boot0cfg) crippled and too difficult to use for all users not intimately acquainted with the way boot0cfg, the MBR record and boot0 interact. Unfortunately I'm not enough x86 assembly literate to understand the diffs between boot0.s in 7.1 and 7.2 to be able to produce a useful patch. [1] I have had installs of 8.0 snapshots that left MBR with more than one MBR slice marked active, BIOS subsequently completely rejected the disk and the only remedy was to manually fdisk -a from fixit mode using a live CD/DVD. This has happened with several recent Intel desktop boards like DG965RY and DP35DP. > Warner Regards, Paul Schenkeveld From drew at mykitchentable.net Fri Aug 7 23:17:05 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 23:17:11 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7? -- SOLVED!!! In-Reply-To: <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> Message-ID: <4A7CB5EC.4010404@mykitchentable.net> Chris Ruiz wrote: > On Fri, Aug 7, 2009 at 1:51 PM, Drew Tomlinson wrote: > >> Boris Kochergin wrote: >> >>> Drew Tomlinson wrote: >>> >>>> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with >>>> current sources as of yesterday (8/6/09). I successfully built world and >>>> kernel, and installed the kernel. However when I attempted to install >>>> world, I got this error: >>>> >>>> ===> lib/libc (install) >>>> install -C -o root -g wheel -m 444 libc.a /usr/lib >>>> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >>>> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >>>> install: /lib/libc.so.7: chflags: Invalid argument >>>> *** Error code 71 >>>> >>>> Stop in /usr/src/lib/libc. >>>> *** Error code 1 >>>> >>>> >>>> And now I can't do anything as every command fails with: >>>> >>>> /libexec/ld-elf.so.1: Shared object "libc.so.7" not found >>>> >>>> How can I recover from this error? >>>> >>>> Thanks, >>>> >>>> Drew >>>> >>>> >>>> >>> There are statically-linked versions of essential utilities in >>> /rescue/. For example, you can use /rescue/mount_nfs to mount an NFS >>> server with the files you need, then /rescue/cp to copy them to your >>> system. >>> >> Thanks for the reply. As I mentioned in my reply to Jakob Lach, I >> really have no business running -CURRENT but loaded BETA2 because the >> release is expected soon. >> >> So basically I have the rescue tools and the BETA2 cd. Can I just mount >> the BETA2 CD, search for libc.so.7, can copy it to /lib? Will that give >> me enough to attempt grabbing updated sources and trying again. Or >> should I just somehow install world from the BETA2 CD and move >> /boot/kernel.old back to /boot/kernel? If so, how? >> > > You must specify NO_FSCHG= when you installworld on an unupgraded ZFS > filesystem, otherwise you will lose libc.so.7! I'll spare you the > details on why this happens. > > Here's a quick fix: > > #/rescue/cp /usr/obj/usr/src/lib/libc/libc.so.7 /lib > Thanks, this worked perfectly. For those like me that might not understand how to "specify NO_FSCHG=", I Googled and found "make installworld NO_FSCHG=" is the way in this case. After restoring libc.so.7 and redoing the installworld, everything seems fine. For my own info, is this something that's documented somewhere and I missed it? Or is this just one of those quirks that has come up and will likely be fixed before the release? Cheers, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From drew at mykitchentable.net Fri Aug 7 23:18:37 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 23:18:43 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <20090807191454.GP1292@hoeg.nl> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> <20090807190350.GO1292@hoeg.nl> <20090807191454.GP1292@hoeg.nl> Message-ID: <4A7CB647.80201@mykitchentable.net> Ed Schouten wrote: > * Ed Schouten wrote: > >> * Chris Ruiz wrote: >> >>> You must specify NO_FSCHG= when you installworld on an unupgraded ZFS >>> filesystem, otherwise you will lose libc.so.7! I'll spare you the >>> details on why this happens. >>> >> Which is because our install(1) is stupid enough to delete the resulting >> binary if it can't add the schg flag. We should really change this >> behaviour. >> > > It looks like there are actually two bugs: > > - install(1) does check for EOPNOTSUPP, while ZFS seems to return > EINVAL. This is probably a ZFS bug. > - Inside jails, (un)setting schg is not permitted and returns EPERM. We > should change the VFS to return EOPNOTSUPP or install(1) to allow > EPERM as well. > > It's a bit late, but I think it would be nice to have this fixed before > 8.0. > I guess this answers my previous question regarding if the NO_FSCHG= is documented... Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From drew at mykitchentable.net Fri Aug 7 23:21:09 2009 From: drew at mykitchentable.net (Drew Tomlinson) Date: Fri Aug 7 23:21:16 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7?] In-Reply-To: <200908071111.26347.mel.flynn+fbsd.current@mailing.thruhere.net> References: <4A7C7220.2090309@mykitchentable.net> <200908071111.26347.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <4A7CB6E0.1050406@mykitchentable.net> Mel Flynn wrote: > On Friday 07 August 2009 10:27:44 Drew Tomlinson wrote: > >> I was running FreeBSD8.0-BETA2 amd64 and attempted to upgrade with >> current sources as of yesterday (8/6/09). I successfully built world and >> kernel, and installed the kernel. However when I attempted to install >> world, I got this error: >> >> ===> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> install: /lib/libc.so.7: chflags: Invalid argument >> *** Error code 71 >> >> Stop in /usr/src/lib/libc. >> *** Error code 1 >> >> >> And now I can't do anything as every command fails with: >> >> /libexec/ld-elf.so.1: Shared object "libc.so.7" not found >> >> How can I recover from this error? >> > > I assume you're running zfs? You should be able to run commands by setting > LD_LIBRARY_PATH=/usr/obj/usr/src/lib/libc. > Yes, I am using zfs filesystems. Thanks for your tip. Cheers, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From ed at 80386.nl Fri Aug 7 23:22:11 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Aug 7 23:22:18 2009 Subject: [Fwd: How To Recover From Missing /lib/libc.so.7? -- SOLVED!!! In-Reply-To: <4A7CB5EC.4010404@mykitchentable.net> References: <4A7C7220.2090309@mykitchentable.net> <4A7C72E0.8080303@acm.poly.edu> <4A7C77B6.8000209@mykitchentable.net> <58c737d70908071156l2f5f2deds526a996ef9f386b@mail.gmail.com> <4A7CB5EC.4010404@mykitchentable.net> Message-ID: <20090807232210.GR1292@hoeg.nl> Hello Drew, * Drew Tomlinson wrote: > For those like me that might not understand how to "specify NO_FSCHG=", > I Googled and found "make installworld NO_FSCHG=" is the way in this > case. After restoring libc.so.7 and redoing the installworld, > everything seems fine. > > For my own info, is this something that's documented somewhere and I > missed it? Or is this just one of those quirks that has come up and > will likely be fixed before the release? You can also put NO_FSCHG= in /etc/src.conf. There is this manual page, src.conf(5), but it doesn't mention NO_FSCHG= at all. It only seems to document the WITH_* and WITHOUT_* switches. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090807/4fcc9848/attachment.pgp From ubm at u-boot-man.de Fri Aug 7 22:24:00 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Fri Aug 7 23:26:33 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: <20090806230909.d01e844a.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> Message-ID: <20090808002354.61c6c5a3.ubm@u-boot-man.de> On Thu, 6 Aug 2009 23:09:09 +0200 Marc "UBM" Bocklet wrote: > On Wed, 22 Jul 2009 20:17:50 +0200 > Marc "UBM" Bocklet wrote: > > > On Sun, 12 Jul 2009 19:45:47 +0200 > > Marc "UBM" Bocklet wrote: > > > > > On Sun, 12 Jul 2009 18:10:34 +0200 > > > Marc "UBM" Bocklet wrote: > > > > > > > > > > I've got it narrowed down between "2009.06.30.06.00.00" and > > > > today. A kernel with the "old" date boots, a freshly csupped and > > > > compiled kernel hangs with the usual symptoms (waiting for > > > > interrupt driven hooks). > > > > > > > > I'll try csupping to just before the big cam commit to see if > > > > there is any connection. When I said earlier that I was not > > > > running with the ahci patch, I was partly wrong. I did not have > > > > device ahci in my kernel config file nor had it loaded as a > > > > module, but I had the patch applied. > > > > > > "2009.07.09.06.00.00" fixes the problem. > > > Could it be that there are some subtle interactions in the cam > > > subsystem that are stirred by the recent mega-commit? > > > > Is there any other info I can / should provide to help debugging > > this? > > Any news on this? This pretty much prevents me from running 8.0 :-/ I've a friend with a similar problem (also HighPoint controller, also "run interrupt driven hooks: still waiting for xpt_config"), who gets a panic. I'll try to get the panic string and a backtrace, if I do, I'll post it here. Bye Marc From oberman at es.net Fri Aug 7 23:35:10 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 7 23:35:17 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: Your message of "Fri, 07 Aug 2009 10:42:39 +0200." Message-ID: <20090807233435.076631CC31@ptavv.es.net> > Date: Fri, 7 Aug 2009 10:42:39 +0200 > From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= > Sender: owner-freebsd-current@freebsd.org > > On Fri, Aug 7, 2009 at 10:09, Martin Wilke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Fri, Aug 07, 2009 at 03:02:00AM +0200, cpghost wrote: > >> On Fri, Aug 07, 2009 at 02:06:11AM +0200, Martin Wilke wrote: > >> > A secound problem is powerd, i can't use > >> > that under 1200 mhz, under 1200 the box > >> > freeze. > >> > >> I have that same problem with a > >>   CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) > >> > >> AS a work around, I've added > >>   debug.cpufreq.lowest="1240" > >> to /boot/loader.conf. > >> > >> It's not ideal, but I have NO idea what's causing the freezes > >> at lower CPU speeds. > >> > >> BTW, you can slow down videos in mplayer manually by typing > >> '[' repeatedly -- and speed them up again with ']'. > >> > >> -cpghost. > > > > Thanks but that's all workarounds, I want here to get a real > > solutions, also that solved not the flash problem. > > > > - - Martin > > > >> > >> -- > >> Cordula's Web. http://www.cordula.ws/ > >> _______________________________________________ > >> 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" > >> > > > > - -- > > > > +-----------------------+-------------------------------+ > > |  PGP    : 0xB1E6FCE9  |  Jabber : miwi(at)BSDCrew.de  | > > |  Skype  : splash_111  |  Mail   : miwi(at)FreeBSD.org | > > +-----------------------+-------------------------------+ > > |       Mess with the Best, Die like the Rest!          | > > +-----------------------+-------------------------------+ > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.11 (FreeBSD) > > > > iEUEARECAAYFAkp74UoACgkQdLJIhLHm/OneygCfWbaVQY9+/EsL4cQL0FkKoqqD > > iGkAkgNC4DUOlFWbDSkHOoOFOzb4NFQ= > > =QAHR > > -----END PGP SIGNATURE----- > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > Please show: > sysctl kern.timecounter > > afaik using acpi_throttling AND cool'n quiet together often leads to > freezes and even to more energy consumption. Maybe you can disable > acpi_throttle and just use the cool'n quiet states. I really wish we could put a bullet through the head of both throttling and TCC. They are ineffective for almost every occasion and can cause all kinds of problems. But people are probably getting tired of my saying this. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From oberman at es.net Fri Aug 7 23:47:18 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 7 23:47:26 2009 Subject: All videos play too fast on AMD Phenom II X4 955 In-Reply-To: Your message of "Fri, 07 Aug 2009 17:14:25 +0200." <20090807151425.GC2419@phenom.cordula.ws> Message-ID: <20090807234659.051AA1CC31@ptavv.es.net> > Date: Fri, 7 Aug 2009 17:14:25 +0200 > From: cpghost > Sender: owner-freebsd-current@freebsd.org > > On Fri, Aug 07, 2009 at 05:08:01PM +0200, Marius N?nnerich wrote: > > >> afaik using acpi_throttling AND cool'n quiet together often leads to > > >> freezes and even to more energy consumption. Maybe you can disable > > >> acpi_throttle and just use the cool'n quiet states. > > > > > > Ah, interesting! How can I disable it? In the BIOS or via ACPI? > > > acpi(4) is somewhat confusing: I'm not sure what to put into > > > debug.acpi.disabled. > > > > http://markmail.org/message/njjpogzsylxmmkl7 > > I hope this helps. > > Thank you. I'll try it as soon as I can reboot this box. ;) One small note...just put hints into /boot/loader.conf. Because the hints file is subject to overwrite during system upgrades, it is not the ideal place for these, though having it in both does no harm that I can tell. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mel.flynn+fbsd.current at mailing.thruhere.net Sat Aug 8 00:03:02 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Sat Aug 8 00:03:09 2009 Subject: Fixing install (Was: Re: [Fwd: How To Recover From Missing /lib/libc.so.7?]) In-Reply-To: <20090807191454.GP1292@hoeg.nl> References: <4A7C7220.2090309@mykitchentable.net> <20090807190350.GO1292@hoeg.nl> <20090807191454.GP1292@hoeg.nl> Message-ID: <200908071602.59676.mel.flynn+fbsd.current@mailing.thruhere.net> On Friday 07 August 2009 11:14:54 Ed Schouten wrote: > * Ed Schouten wrote: > > * Chris Ruiz wrote: > > > You must specify NO_FSCHG= when you installworld on an unupgraded ZFS > > > filesystem, otherwise you will lose libc.so.7! I'll spare you the > > > details on why this happens. > > > > Which is because our install(1) is stupid enough to delete the resulting > > binary if it can't add the schg flag. We should really change this > > behaviour. > > It looks like there are actually two bugs: > > - install(1) does check for EOPNOTSUPP, while ZFS seems to return > EINVAL. This is probably a ZFS bug. > - Inside jails, (un)setting schg is not permitted and returns EPERM. We > should change the VFS to return EOPNOTSUPP or install(1) to allow > EPERM as well. > > It's a bit late, but I think it would be nice to have this fixed before > 8.0. Perhaps the second case only if jailed? EPERM is also given when the running user doesn't have permission and I'd rather have things bail out sooner then later. Patch attached for this. -- Mel -------------- next part -------------- Index: usr.bin/xinstall/xinstall.c =================================================================== --- usr.bin/xinstall/xinstall.c (revision 196085) +++ usr.bin/xinstall/xinstall.c (working copy) @@ -47,6 +47,8 @@ __FBSDID("$FreeBSD$"); #include +#include +#include #include #include #include @@ -83,6 +85,7 @@ gid_t gid; uid_t uid; int dobackup, docompare, dodir, dopreserve, dostrip, nommap, safecopy, verbose; +int is_jailed; mode_t mode = S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH; const char *suffix = BACKUP_SUFFIX; @@ -106,9 +109,11 @@ int ch, no_target; u_int iflags; char *flags; + size_t len = sizeof(int); const char *group, *owner, *to_name; iflags = 0; + is_jailed = 0; group = owner = NULL; while ((ch = getopt(argc, argv, "B:bCcdf:g:Mm:o:pSsv")) != -1) switch((char)ch) { @@ -242,6 +247,11 @@ errx(EX_USAGE, "%s and %s are the same file", *argv, to_name); } + if( sysctlbyname("security.jail.jailed", (void *)&is_jailed, + &len, NULL, 0) == -1 ) { + warn("Unable to get security.jail.jailed, assuming unjailed"); + is_jailed = 0; + } install(*argv, to_name, fset, iflags); exit(EX_OK); /* NOTREACHED */ @@ -506,6 +516,8 @@ if (flags & SETFLAGS) { if (errno == EOPNOTSUPP) warn("%s: chflags", to_name); + else if( errno == EPERM && is_jailed ) + warn("%s: chflags", to_name); else { serrno = errno; (void)unlink(to_name); From traveling08 at cox.net Sat Aug 8 01:06:41 2009 From: traveling08 at cox.net (Robert) Date: Sat Aug 8 01:06:48 2009 Subject: LOR wlan0 wi0 Message-ID: <20090807165850.3e8541f8@vaio> Greetings I have just upgraded a laptop on my network to current: [root@hp] ~# uname -a FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob j/usr/src/sys/VESA i386 I have made the changes in rc.conf after reading UPDATING and rc.conf defaults. Here is the bits from rc.conf wlans_wi0=wlan0 # I have tried with quotes around wlan0 with # no difference. ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ deftxkey 1 wepkey 0xSecretNumber78bf" # ifconfig_re0="DHCP" My wlan0 interface comes up but never retrieves an IP from the router. [root@hp] ~# ifconfig -a plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 ether 00:09:5b:25:5e:b3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated wlan0: flags=8843 metric 0 mtu 1500 ether 00:09:5b:25:5e:b3 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid MY_SSID channel 11 (2462 Mhz 11b) bssid 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 Searching dmesg I see this wlan0: Ethernet address: 00:09:5b:25:5e:b3 lock order reversal: 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack backtrace: db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at kdb_backtrace+0x29 _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) at _witness_debugger+0x25 witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at _mtx_lock_flags+0xc4 wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at wi_raw_xmit+0x3e ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) at ieee80211_send_probereq+0x488 ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at ieee80211_probe_curchan+0x93 scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at scan_curchan+0x49 scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) at scan_task+0x33a taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at taskqueue_run+0x10b taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) at taskqueue_thread_loop+0x68 fork_exit(c08ba5b0,c2c04074,cca4ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. The PCMCIA is and older Netgear 802.11b that was working fine on 7 stable. I have searched the archives and tried changing things in rc.conf but I can not seem to make this work. Any help or direction will be greatly appreciated. Robert From bf1783 at googlemail.com Sat Aug 8 01:15:11 2009 From: bf1783 at googlemail.com (b. f.) Date: Sat Aug 8 01:15:18 2009 Subject: Cdparanoia Message-ID: >Hi. While folks are looking at cdparanoia, would it be possible to >update the port to the current release of cdparanoia? I got stuck >trying to make a fresh port of it myself using the current port as >a guide. It seemed like it would be a small changeset but it got >me. Thanks :) The new version uses some Linux 2.6 SG_IO by default. You may have to make some changes to get it to work. You've seen the developer's manifesto?: "Paranoia is Linux only (although it runs on all the flavors of linux. It is not only for i386 or x86_64). In the past, there was effort to make this library as portable as possible across other OS platforms. As time has worn on, I've come to realize that most cross-platform libraries that try to bring a completely uniform interface to a wide variety of very different OSes: 1. fail to be all that uniform 2. limit functionality to some subset of what any given platform can do 3. introduce additional lyers of bugs 4. just don't work very well I'm a Linux user. I'm a Linux developer. As a user and developer, I don't really give a damn about other platforms. I want my apps to be the best Linux apps they can be. Full stop." So much for FOSS ecumenism. b. From bf1783 at googlemail.com Sat Aug 8 01:50:26 2009 From: bf1783 at googlemail.com (b. f.) Date: Sat Aug 8 01:50:32 2009 Subject: Unable to build HEAD In-Reply-To: <20090807205432.8FA4D1CC31@ptavv.es.net> References: <20090807205432.8FA4D1CC31@ptavv.es.net> Message-ID: On 8/7/09, Kevin Oberman wrote: >> Date: Thu, 6 Aug 2009 11:37:50 +0000 >> From: "b. f." >> >> On 8/6/09, Kevin Oberman wrote: >> >I have tested a patch from bf and it works. I've asked if he wants to >> >submit the PR or if he wants me to. If I don;t hear from him, I'll >> >submit tomorrow. >> >> Slightly revised and augmented patch is in: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=137483 > > I think the patch is right, but I am still broken. I also had to remove > the ".if ${MK_OPENSSH) != "no" and paired ".endif" from > /usr/src/lib/libpam/modules/modules.inc. Once this was done, it looks > like everything is correct. > > I think the right answer is to either unconditionally build the pam > module or to add an option that is specific to the module. I think the > former is really the way to go as the module only adds 46K to the system > and, if you build without OpenSSH, you are either building an embedded > system where you will almost certainly be trimming a lot further than > the src.conf file allows, or because you are using the version from > ports. If the latter, you almost certainly WILL want pam_ssh. I agree, this is a problem if you still want pam_ssh, and want to use OpenSSH from Ports. A similar situation exists for pam_krb5 and pam_ksu with WITHOUT_KERBEROS=yes. But I don't see how you can still properly build working versions of these modules without putting in some hooks to link to the needed libraries in ${LOCALBASE}. (They need to be linked against the appropriate OpenSSH and Heimdal libraries.) How were you able to build pam_ssh when WITHOUT_OPENSSH=yes? Do you still have some old OpenSSH cruft installed in your base system that wasn't removed by make delete-old/make-delete-old-libs (which aren't set up properly for this option yet, as I pointed out), and so the modules were able to link against the old libraries? b. From danny at cs.huji.ac.il Sat Aug 8 10:52:48 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Aug 8 10:52:55 2009 Subject: request test drivers for iscsi_initiator 2.2.3 Message-ID: This new version: o - has some bug fixes. o - has full header/data digest support, thanks to Daisuke Aoyama . o - the limit for the number of sessions is now 64, but can be raised - eventually via a sysctl call. o - the number of LUNs is unlimited, but things might get hairy over 128. o - now compiles & works under -current (8.0). The tag option is supported, but by default is set very low (0), if someone knows of a way to figure the optimal value I'll gladly add it. If it works for you, please let me know the model/make of the target so I can update the list. cheers, danny From danny at cs.huji.ac.il Sat Aug 8 10:52:50 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Aug 8 10:53:11 2009 Subject: request test drivers for iscsi_initiator 2.2.3 Message-ID: wups, forgot a small little detail: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz danny From rwatson at FreeBSD.org Sat Aug 8 11:02:42 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 8 11:02:49 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: <20090808002354.61c6c5a3.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> Message-ID: On Sat, 8 Aug 2009, Marc UBM Bocklet wrote: >>>>> I've got it narrowed down between "2009.06.30.06.00.00" and today. A >>>>> kernel with the "old" date boots, a freshly csupped and compiled kernel >>>>> hangs with the usual symptoms (waiting for interrupt driven hooks). >>>>> >>>>> I'll try csupping to just before the big cam commit to see if there is >>>>> any connection. When I said earlier that I was not running with the ahci >>>>> patch, I was partly wrong. I did not have device ahci in my kernel >>>>> config file nor had it loaded as a module, but I had the patch applied. >>>> >>>> "2009.07.09.06.00.00" fixes the problem. Could it be that there are some >>>> subtle interactions in the cam subsystem that are stirred by the recent >>>> mega-commit? >>> >>> Is there any other info I can / should provide to help debugging this? >> >> Any news on this? This pretty much prevents me from running 8.0 :-/ > > I've a friend with a similar problem (also HighPoint controller, also "run > interrupt driven hooks: still waiting for xpt_config"), who gets a panic. > I'll try to get the panic string and a backtrace, if I do, I'll post it > here. xpt_config basically means that you're waiting on a device driver attached to CAM to finish probing, which could point at a number of potential problem sources (including things like interrupt routing problems). At least in the 7.x line, I've seen firewire and USB at various times cause this issue. It might be interesting to compile down to the smallest set of cam-related drivers required to support necessary hardware (omit firewire, for example) and see if you see any improvement. Pinning it down to a specific driver would have significant debugging value :-). Robert N M Watson Computer Laboratory University of Cambridge From ubm at u-boot-man.de Sat Aug 8 08:30:06 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Sat Aug 8 12:42:42 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: <20090806230909.d01e844a.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> Message-ID: <20090808095017.028f3e46.ubm@u-boot-man.de> On Thu, 6 Aug 2009 23:09:09 +0200 Marc "UBM" Bocklet wrote: > > Is there any other info I can / should provide to help debugging > > this? > > Any news on this? This pretty much prevents me from running 8.0 :-/ I could donate a cheap Highpoint Controller, if that helps. Or is this something I should take up with Highpoint themselves? Bye Marc From ohartman at mail.zedat.fu-berlin.de Sat Aug 8 08:49:19 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Sat Aug 8 12:43:01 2009 Subject: Where is the list of show-stopper for CURRENT on the website www.freebsd.org Message-ID: <4A7D3C0D.9010905@mail.zedat.fu-berlin.de> Well, in the past it was easy for me to watch the list of problems and show-stopper of CURRENT before it gets released on FreeBSD's website. At this moment, I try to figure out where this page has gone but it is not very clear. I can't find it! Why isn't this list easily accessible as it was in the past? Maybe someone can give me a hint, maybe I have overseen a link. Logically, I would look in 'Developer' or the 'RElease' section, but I always run into nothing ... Please give me a hint, I'm lost. Regards, Oliver From grarpamp at gmail.com Sat Aug 8 09:19:18 2009 From: grarpamp at gmail.com (grarpamp) Date: Sat Aug 8 12:43:15 2009 Subject: Cdparanoia In-Reply-To: References: Message-ID: > The new version uses some Linux 2.6 SG_IO by default. You may have to > make some changes to get it to work. It's been months since I've looked/tried it. Some of the device things looked like they could simply be lobotomized away... specify a device instead of bus scanning, define some parameters, that sort of thing, just to get it going. > You've seen the developer's manifesto? Yes, sigh. It's still a good app though. And Simon who did the original FreeBSD port did just fine, works with atapicam. It's a pretty small changeset so maybe someone with more skills than I would carry it onward. Later. From axel.scheepers at nl.clara.net Sat Aug 8 11:14:12 2009 From: axel.scheepers at nl.clara.net (Axel Scheepers) Date: Sat Aug 8 12:43:23 2009 Subject: GEOM geometry mismatch In-Reply-To: <20090807181253.59ba37ed@ernst.jennejohn.org> References: <1249406101.20811.12.camel@ceridwen.thuis.net> <20090807181253.59ba37ed@ernst.jennejohn.org> Message-ID: <1249730049.3897.7.camel@ceridwen.thuis.net> On Fri, 2009-08-07 at 18:12 +0200, Gary Jennejohn wrote: > Just ignore it. I see this error at every boot also but it has no > negative effects. Hi Gary, Thanks. I filled the g partition as root in the meantime and indeed no nasty suprise. Quite some time since I used FreeBSD as a desktop but I'm pleasantly suprised with 8. Thanks for all the great work. Kind regards, Axel Scheepers From joel at FreeBSD.org Sat Aug 8 13:37:49 2009 From: joel at FreeBSD.org (Joel Dahl) Date: Sat Aug 8 13:37:56 2009 Subject: Where is the list of show-stopper for CURRENT on the website www.freebsd.org In-Reply-To: <4A7D3C0D.9010905@mail.zedat.fu-berlin.de> References: <4A7D3C0D.9010905@mail.zedat.fu-berlin.de> Message-ID: <4A7D7B73.7060606@FreeBSD.org> O. Hartmann skrev: > Well, > in the past it was easy for me to watch the list of problems and > show-stopper of CURRENT before it gets released on FreeBSD's website. At > this moment, I try to figure out where this page has gone but it is not > very clear. I can't find it! Why isn't this list easily accessible as it > was in the past? > Maybe someone can give me a hint, maybe I have overseen a link. > Logically, I would look in 'Developer' or the 'RElease' section, but I > always run into nothing ... > > Please give me a hint, I'm lost. http://wiki.freebsd.org/8.0TODO -- Joel From mav at FreeBSD.org Sat Aug 8 14:46:07 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Aug 8 14:46:15 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <4A7D8D7A.5030303@mavhome.dp.ua> References: <1249741381.00149226.1249729205@10.7.7.3> <4A7D8D7A.5030303@mavhome.dp.ua> Message-ID: <4A7D8F72.8090905@FreeBSD.org> Alexander Motin wrote: > Danny Braniss wrote: >> wups, forgot a small little detail: >> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > > Is there reason why > cpi->transport = XPORT_ISCSI; > covered by > #if defined(KNOB_VALID_ADDRESS) > ? Sorry, wrong question. But those who will test on CURRENT should take care about it. -- Alexander Motin From attilio at freebsd.org Sat Aug 8 15:51:21 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 8 15:51:28 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> Message-ID: <3bbf2fe10908080851j61efcf67g8e638aff9a9c5ba9@mail.gmail.com> 2009/8/8 Robert Watson : > On Sat, 8 Aug 2009, Marc UBM Bocklet wrote: > >>>>>> I've got it narrowed down between "2009.06.30.06.00.00" and today. A >>>>>> kernel with the "old" date boots, a freshly csupped and compiled kernel >>>>>> hangs with the usual symptoms (waiting for interrupt driven hooks). >>>>>> >>>>>> I'll try csupping to just before the big cam commit to see if there is >>>>>> any connection. When I said earlier that I was not running with the ahci >>>>>> patch, I was partly wrong. I did not have device ahci in my kernel config >>>>>> file nor had it loaded as a module, but I had the patch applied. >>>>> >>>>> "2009.07.09.06.00.00" fixes the problem. Could it be that there are >>>>> some subtle interactions in the cam subsystem that are stirred by the recent >>>>> mega-commit? >>>> >>>> Is there any other info I can / should provide to help debugging this? >>> >>> Any news on this? This pretty much prevents me from running 8.0 :-/ >> >> I've a friend with a similar problem (also HighPoint controller, also "run >> interrupt driven hooks: still waiting for xpt_config"), who gets a panic. >> I'll try to get the panic string and a backtrace, if I do, I'll post it >> here. > > xpt_config basically means that you're waiting on a device driver attached > to CAM to finish probing, which could point at a number of potential problem > sources (including things like interrupt routing problems). At least in the > 7.x line, I've seen firewire and USB at various times cause this issue. It > might be interesting to compile down to the smallest set of cam-related > drivers required to support necessary hardware (omit firewire, for example) > and see if you see any improvement. Pinning it down to a specific driver > would have significant debugging value :-). Beyon that, I think that debugging in CAM can be improved by a good factor using alredy existing general infrastructure (KTR logging points, new ddb commands, etc). We need someone which is willing to spend some time on that. Attilio -- Peace can only be achieved by understanding - A. Einstein From sam at errno.com Sat Aug 8 15:59:30 2009 From: sam at errno.com (Sam Leffler) Date: Sat Aug 8 15:59:42 2009 Subject: LOR wlan0 wi0 In-Reply-To: <20090807165850.3e8541f8@vaio> References: <20090807165850.3e8541f8@vaio> Message-ID: <4A7DA0DF.50107@errno.com> Robert wrote: > Greetings > > I have just upgraded a laptop on my network to current: > > [root@hp] ~# uname -a > FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug 7 > 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob > j/usr/src/sys/VESA i386 > > I have made the changes in rc.conf after reading UPDATING and rc.conf > defaults. Here is the bits from rc.conf > > wlans_wi0=wlan0 # I have tried with quotes around wlan0 with > # no difference. > ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ > deftxkey 1 wepkey 0xSecretNumber78bf" > > # ifconfig_re0="DHCP" > > My wlan0 interface comes up but never retrieves an IP from the router. > > [root@hp] ~# ifconfig -a > plip0: flags=8810 metric 0 mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > ether 00:09:5b:25:5e:b3 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > status: associated > wlan0: flags=8843 metric 0 mtu > 1500 ether 00:09:5b:25:5e:b3 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > status: associated > ssid MY_SSID channel 11 (2462 Mhz 11b) bssid 00:1c:df:f9:ad:fc > country US authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit > txpower 0 bmiss 7 scanvalid 60 > > Searching dmesg I see this > > wlan0: Ethernet address: 00:09:5b:25:5e:b3 > lock order reversal: > 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) > @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 > (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack > backtrace: > db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) at > _witness_debugger+0x25 > witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at > witness_checkorder+0x839 > _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at > _mtx_lock_flags+0xc4 > wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at > wi_raw_xmit+0x3e > ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) > at ieee80211_send_probereq+0x488 > ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at > ieee80211_probe_curchan+0x93 > scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at scan_curchan+0x49 > scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) at scan_task+0x33a > taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at > taskqueue_run+0x10b > taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) at > taskqueue_thread_loop+0x68 fork_exit(c08ba5b0,c2c04074,cca4ed38) at > fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip > = 0, esp = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. > > The PCMCIA is and older Netgear 802.11b that was working fine on 7 > stable. I have searched the archives and tried changing things in > rc.conf but I can not seem to make this work. > > > Any help or direction will be greatly appreciated. Ignore the LOR. The first thing to do is simplify your config; remove crypto. If you can pass data frames then your problem is in the crypto setup. If not then you have unencrypted data to examine for problems. Use tools/tools/net80211/wlanstats to check for errors. You can trace packet traffic with tcpdump to see if frames are moving. You also don't identify your card. wi in 8.0 works with a subset of the cards in RELENG_7 so your card may not work correctly--though since you appear to have associated that doesn't seem like the issue (cards that don't work are unlikely to successfully associate). Sam From mav at mavhome.dp.ua Sat Aug 8 15:37:38 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Sat Aug 8 17:15:49 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <1249741381.00149226.1249729205@10.7.7.3> References: <1249741381.00149226.1249729205@10.7.7.3> Message-ID: <4A7D8D7A.5030303@mavhome.dp.ua> Hi. Danny Braniss wrote: > wups, forgot a small little detail: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz Is there reason why cpi->transport = XPORT_ISCSI; covered by #if defined(KNOB_VALID_ADDRESS) ? -- Alexander Motin From jason.harmening at gmail.com Sat Aug 8 15:56:59 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Sat Aug 8 17:16:02 2009 Subject: [follow-up] FreeBSD/amd64 r195146 to r195848, fatal trap 12 under network load Message-ID: <2d1264630908080856m21b45aa8o90bf0737f3c5fa3a@mail.gmail.com> I think I'm seeing this panic after a cvsup yesterday. With all kernel debugging options turned off, it will happen almost immediately and 100% of the time with the "ping-flood" test. Machine is nehalem (4 cores + HTT). So far I haven't been able to reproduce it with debugging turned on, but I'll gladly take any suggestions and do whatever I can to help fix it. --Jason From jason.harmening at gmail.com Sat Aug 8 16:11:33 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Sat Aug 8 17:16:16 2009 Subject: LORs during module unload Message-ID: <2d1264630908080846r3c73e0a5h7df2db83096401d@mail.gmail.com> Hi all, When testing my kernel module against a kernel built yesterday, I noticed the following LORs when unloading the top-level module (which also automatically unloaded some dependency modules): lock order reversal: 1st 0xffffffff807af4a0 module subsystem sx lock (module subsystem sx lock) @ /usr/src/sys/kern/kern_linker.c:602 2nd 0xffffffff807d0900 newbus (newbus) @ /usr/src/sys/kern/subr_bus.c:4127 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x32 _witness_debugger() at _witness_debugger+0x1e witness_checkorder() at witness_checkorder+0x8c7 _sx_xlock() at _sx_xlock+0x74 driver_module_handler() at driver_module_handler+0x49 module_quiesce() at module_quiesce+0x38 linker_file_unload() at linker_file_unload+0x98 kern_kldunload() at kern_kldunload+0xdf kldunloadf() at kldunloadf+0x1a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (444, FreeBSD ELF64, kldunloadf), rip = 0x8006989fc, rsp = 0x7fffffffe2c8, rbp = 0x2 --- lock order reversal: 1st 0xffffffff807ae8c0 kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1068 2nd 0xffffffff807d0900 newbus (newbus) @ /usr/src/sys/kern/subr_bus.c:4127 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x32 _witness_debugger() at _witness_debugger+0x1e witness_checkorder() at witness_checkorder+0x8c7 _sx_xlock() at _sx_xlock+0x74 driver_module_handler() at driver_module_handler+0x49 module_unload() at module_unload+0x38 linker_file_unload() at linker_file_unload+0x13a kern_kldunload() at kern_kldunload+0xdf kldunloadf() at kldunloadf+0x1a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (444, FreeBSD ELF64, kldunloadf), rip = 0x8006989fc, rsp = 0x7fffffffe2c8, rbp = 0x2 --- iicbus2: detached lock order reversal: 1st 0xffffffff807ae8c0 kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1068 2nd 0xffffffff807b0ec0 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:256 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x32 _witness_debugger() at _witness_debugger+0x1e witness_checkorder() at witness_checkorder+0x8c7 _sx_xlock() at _sx_xlock+0x74 sysctl_ctx_free() at sysctl_ctx_free+0x2d device_sysctl_fini() at device_sysctl_fini+0x22 device_detach() at device_detach+0x1dd cx88_i2c_destroy() at cx88_i2c_destroy+0x48 device_detach() at device_detach+0x8b cx23885_teardown() at cx23885_teardown+0x7d cx88_release_client() at cx88_release_client+0x86 cx88_common_detach() at cx88_common_detach+0x20 device_detach() at device_detach+0x8b driver_module_handler() at driver_module_handler+0x395 module_unload() at module_unload+0x38 linker_file_unload() at linker_file_unload+0x13a kern_kldunload() at kern_kldunload+0xdf kldunloadf() at kldunloadf+0x1a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (444, FreeBSD ELF64, kldunloadf), rip = 0x8006989fc, rsp = 0x7fffffffe2c8, rbp = 0x2 --- --Jason From serenity at exscape.org Sat Aug 8 17:27:50 2009 From: serenity at exscape.org (Thomas Backman) Date: Sat Aug 8 17:27:57 2009 Subject: What's up with the SVN repository? Message-ID: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> Anyone care to fill us outsiders in? ;) No commits at all in the last few days, and given "Please just bear with it until commits are restored" (from Attilio Rao)... How are things? Any status updates anywhere? I looked through the list of mailing lists, but didn't find a fitting one with a topic covering this. Regards, Thomas From ed at 80386.nl Sat Aug 8 18:00:49 2009 From: ed at 80386.nl (Ed Schouten) Date: Sat Aug 8 18:00:57 2009 Subject: What's up with the SVN repository? In-Reply-To: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> Message-ID: <20090808174443.GT1292@hoeg.nl> * Thomas Backman wrote: > No commits at all in the last few days, and given "Please just bear > with it until commits are restored" (from Attilio Rao)... How are > things? Any status updates anywhere? I looked through the list of > mailing lists, but didn't find a fitting one with a topic covering > this. The FreeBSD Project has been discontinued. Nothing to see here! ;-) Ken Smith created the stable/8 branch, in preparation for 8.0-RELEASE. This is the first time we're creating a new major branch since our migration to SVN, so it turns out there are some problems with the SVN -> CVS exporter catching up. After this issues have been resolved, the release procedure should continue as expected. It's a little unfortunate that this means some people will have to wait for some newbus/netisr/etc bug fixes to land, but I assume it won't take too long. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090808/ed9d4553/attachment.pgp From gcr+freebsd-current at tharned.org Sat Aug 8 18:11:08 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Sat Aug 8 18:11:15 2009 Subject: hald broken with USB drives since 8.0-BETA2 Message-ID: I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now hald seems to work only the first time a USB drive is attached. The drive is detected and mounted, and can be unmounted and remounted via kde3's media interface. But if I unmount the drive and detach it, hald wedges the USB buss. No further USB connections (any device, not just disks) are detected, and hald becomes unkillable. Has anyone else experienced this? Any suggestions for troubleshooting? -- Greg Rivers From gpalmer at freebsd.org Sat Aug 8 18:12:34 2009 From: gpalmer at freebsd.org (Gary Palmer) Date: Sat Aug 8 18:12:41 2009 Subject: What's up with the SVN repository? In-Reply-To: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> Message-ID: <20090808175831.GA84046@in-addr.com> On Sat, Aug 08, 2009 at 07:27:23PM +0200, Thomas Backman wrote: > Anyone care to fill us outsiders in? ;) > No commits at all in the last few days, and given "Please just bear > with it until commits are restored" (from Attilio Rao)... How are > things? Any status updates anywhere? I looked through the list of > mailing lists, but didn't find a fitting one with a topic covering this. Not the easiest mention to find: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010255.html Regards, Gary From attilio at freebsd.org Sat Aug 8 18:16:09 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 8 18:16:17 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: References: Message-ID: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> 2009/8/8 Greg Rivers : > I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now hald > seems to work only the first time a USB drive is attached. The drive is > detected and mounted, and can be unmounted and remounted via kde3's media > interface. > > But if I unmount the drive and detach it, hald wedges the USB buss. No > further USB connections (any device, not just disks) are detected, and hald > becomes unkillable. > > Has anyone else experienced this? Any suggestions for troubleshooting? After installing BETA2 did you further update to -CURRENT or simply used BETA2 system? Attilio -- Peace can only be achieved by understanding - A. Einstein From gcr+freebsd-current at tharned.org Sat Aug 8 18:34:37 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Sat Aug 8 18:34:44 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> Message-ID: On Sat, 8 Aug 2009, Attilio Rao wrote: > 2009/8/8 Greg Rivers : >> I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now >> hald seems to work only the first time a USB drive is attached. The >> drive is detected and mounted, and can be unmounted and remounted via >> kde3's media interface. >> >> But if I unmount the drive and detach it, hald wedges the USB buss. >> No further USB connections (any device, not just disks) are detected, >> and hald becomes unkillable. >> >> Has anyone else experienced this? Any suggestions for troubleshooting? > > After installing BETA2 did you further update to -CURRENT or simply used > BETA2 system? > I've been tracking -CURRENT. I last rebuilt kernel and world on August 2nd. Sorry for not being clear about that. I removed and rebuilt all ports from source after the July 19 shared library version bump, and I rebuilt hald and dbus after the August 2nd kernel/world update. -- Greg Rivers From mel.flynn+fbsd.current at mailing.thruhere.net Sat Aug 8 18:44:57 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Sat Aug 8 18:45:03 2009 Subject: What's up with the SVN repository? In-Reply-To: <20090808174443.GT1292@hoeg.nl> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> Message-ID: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> On Saturday 08 August 2009 09:44:43 Ed Schouten wrote: > * Thomas Backman wrote: > > No commits at all in the last few days, and given "Please just bear > > with it until commits are restored" (from Attilio Rao)... How are > > things? Any status updates anywhere? I looked through the list of > > mailing lists, but didn't find a fitting one with a topic covering > > this. > > The FreeBSD Project has been discontinued. Nothing to see here! ;-) > > Ken Smith created the stable/8 branch, in preparation for 8.0-RELEASE. > This is the first time we're creating a new major branch since our > migration to SVN, so it turns out there are some problems with the SVN > -> CVS exporter catching up. After this issues have been resolved, the > release procedure should continue as expected. So for people using svn, should we now start tracking stable/8 or is HEAD safe for the time being? Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, checkout stable/8 and re-apply diffs? -- Mel From ohartman at mail.zedat.fu-berlin.de Sat Aug 8 18:05:35 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Sat Aug 8 18:46:17 2009 Subject: Where is the list of show-stopper for CURRENT on the website www.freebsd.org In-Reply-To: <4A7D7B73.7060606@FreeBSD.org> References: <4A7D3C0D.9010905@mail.zedat.fu-berlin.de> <4A7D7B73.7060606@FreeBSD.org> Message-ID: <4A7DBE6D.6090104@mail.zedat.fu-berlin.de> Joel Dahl wrote: > O. Hartmann skrev: >> Well, >> in the past it was easy for me to watch the list of problems and >> show-stopper of CURRENT before it gets released on FreeBSD's website. At >> this moment, I try to figure out where this page has gone but it is not >> very clear. I can't find it! Why isn't this list easily accessible as it >> was in the past? >> Maybe someone can give me a hint, maybe I have overseen a link. >> Logically, I would look in 'Developer' or the 'RElease' section, but I >> always run into nothing ... >> >> Please give me a hint, I'm lost. > > http://wiki.freebsd.org/8.0TODO > > -- > Joel > _______________________________________________ > 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" Thank you very much. I missed the Wiki :-( Oliver From attilio at freebsd.org Sat Aug 8 18:51:39 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 8 18:51:46 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> Message-ID: <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> 2009/8/8 Greg Rivers : > On Sat, 8 Aug 2009, Attilio Rao wrote: > >> 2009/8/8 Greg Rivers : >>> >>> I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now >>> hald seems to work only the first time a USB drive is attached. The drive >>> is detected and mounted, and can be unmounted and remounted via kde3's media >>> interface. >>> >>> But if I unmount the drive and detach it, hald wedges the USB buss. No >>> further USB connections (any device, not just disks) are detected, and hald >>> becomes unkillable. >>> >>> Has anyone else experienced this? Any suggestions for troubleshooting? >> >> After installing BETA2 did you further update to -CURRENT or simply used >> BETA2 system? >> > > I've been tracking -CURRENT. I last rebuilt kernel and world on August 2nd. > Sorry for not being clear about that. > > I removed and rebuilt all ports from source after the July 19 shared > library version bump, and I rebuilt hald and dbus after the August 2nd > kernel/world update. Did you include r196037? If you did, can you try remove it and rebuild anything and experience the problem again? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From deischen at freebsd.org Sat Aug 8 18:57:48 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Aug 8 18:57:55 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> Message-ID: On Sat, 8 Aug 2009, Attilio Rao wrote: > 2009/8/8 Greg Rivers : >> On Sat, 8 Aug 2009, Attilio Rao wrote: >> >>> 2009/8/8 Greg Rivers : >>>> >>>> I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now >>>> hald seems to work only the first time a USB drive is attached. The drive >>>> is detected and mounted, and can be unmounted and remounted via kde3's media >>>> interface. >>>> >>>> But if I unmount the drive and detach it, hald wedges the USB buss. No >>>> further USB connections (any device, not just disks) are detected, and hald >>>> becomes unkillable. >>>> >>>> Has anyone else experienced this? Any suggestions for troubleshooting? >>> >>> After installing BETA2 did you further update to -CURRENT or simply used >>> BETA2 system? >>> >> >> I've been tracking -CURRENT. I last rebuilt kernel and world on August 2nd. >> Sorry for not being clear about that. >> >> I removed and rebuilt all ports from source after the July 19 shared >> library version bump, and I rebuilt hald and dbus after the August 2nd >> kernel/world update. > > Did you include r196037? > If you did, can you try remove it and rebuild anything and experience > the problem again? You can also see this thread from June: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1494406+0+archive/2009/freebsd-current/20090607.freebsd-current -- DE From attilio at freebsd.org Sat Aug 8 19:01:29 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 8 19:01:36 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> Message-ID: <3bbf2fe10908081201g3378b8q479b8836d69f636b@mail.gmail.com> 2009/8/8 Daniel Eischen : > On Sat, 8 Aug 2009, Attilio Rao wrote: > >> 2009/8/8 Greg Rivers : >>> >>> On Sat, 8 Aug 2009, Attilio Rao wrote: >>> >>>> 2009/8/8 Greg Rivers : >>>>> >>>>> I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now >>>>> hald seems to work only the first time a USB drive is attached. The >>>>> drive >>>>> is detected and mounted, and can be unmounted and remounted via kde3's >>>>> media >>>>> interface. >>>>> >>>>> But if I unmount the drive and detach it, hald wedges the USB buss. No >>>>> further USB connections (any device, not just disks) are detected, and >>>>> hald >>>>> becomes unkillable. >>>>> >>>>> Has anyone else experienced this? Any suggestions for troubleshooting? >>>> >>>> After installing BETA2 did you further update to -CURRENT or simply used >>>> BETA2 system? >>>> >>> >>> I've been tracking -CURRENT. I last rebuilt kernel and world on August >>> 2nd. >>> Sorry for not being clear about that. >>> >>> I removed and rebuilt all ports from source after the July 19 shared >>> library version bump, and I rebuilt hald and dbus after the August 2nd >>> kernel/world update. >> >> Did you include r196037? >> If you did, can you try remove it and rebuild anything and experience >> the problem again? > > You can also see this thread from June: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1494406+0+archive/2009/freebsd-current/20090607.freebsd-current Oh, so it should not be the newbus locking patch. Attilio -- Peace can only be achieved by understanding - A. Einstein From dougb at FreeBSD.org Sat Aug 8 19:02:40 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Aug 8 19:02:47 2009 Subject: What's up with the SVN repository? In-Reply-To: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <4A7DCBC6.9020005@FreeBSD.org> Mel Flynn wrote: > On Saturday 08 August 2009 09:44:43 Ed Schouten wrote: >> * Thomas Backman wrote: >>> No commits at all in the last few days, and given "Please just bear >>> with it until commits are restored" (from Attilio Rao)... How are >>> things? Any status updates anywhere? I looked through the list of >>> mailing lists, but didn't find a fitting one with a topic covering >>> this. >> The FreeBSD Project has been discontinued. Nothing to see here! ;-) >> >> Ken Smith created the stable/8 branch, in preparation for 8.0-RELEASE. >> This is the first time we're creating a new major branch since our >> migration to SVN, so it turns out there are some problems with the SVN >> -> CVS exporter catching up. After this issues have been resolved, the >> release procedure should continue as expected. > > So for people using svn, should we now start tracking stable/8 or is HEAD safe > for the time being? > > Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo > TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, > checkout stable/8 and re-apply diffs? No updates are being made on HEAD or stable/8 until the exporter problem is fixed, so you don't have to worry about it. hth, Doug -- This .signature sanitized for your protection From deischen at freebsd.org Sat Aug 8 19:04:01 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Aug 8 19:04:08 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: <3bbf2fe10908081201g3378b8q479b8836d69f636b@mail.gmail.com> References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> <3bbf2fe10908081201g3378b8q479b8836d69f636b@mail.gmail.com> Message-ID: On Sat, 8 Aug 2009, Attilio Rao wrote: > 2009/8/8 Daniel Eischen : >> On Sat, 8 Aug 2009, Attilio Rao wrote: >> >>> 2009/8/8 Greg Rivers : >>>> >>>> On Sat, 8 Aug 2009, Attilio Rao wrote: >>>> >>>>> 2009/8/8 Greg Rivers : >>>>>> >>>>>> I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now >>>>>> hald seems to work only the first time a USB drive is attached. The >>>>>> drive >>>>>> is detected and mounted, and can be unmounted and remounted via kde3's >>>>>> media >>>>>> interface. >>>>>> >>>>>> But if I unmount the drive and detach it, hald wedges the USB buss. No >>>>>> further USB connections (any device, not just disks) are detected, and >>>>>> hald >>>>>> becomes unkillable. >>>>>> >>>>>> Has anyone else experienced this? Any suggestions for troubleshooting? >>>>> >>>>> After installing BETA2 did you further update to -CURRENT or simply used >>>>> BETA2 system? >>>>> >>>> >>>> I've been tracking -CURRENT. I last rebuilt kernel and world on August >>>> 2nd. >>>> Sorry for not being clear about that. >>>> >>>> I removed and rebuilt all ports from source after the July 19 shared >>>> library version bump, and I rebuilt hald and dbus after the August 2nd >>>> kernel/world update. >>> >>> Did you include r196037? >>> If you did, can you try remove it and rebuild anything and experience >>> the problem again? >> >> You can also see this thread from June: >> >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1494406+0+archive/2009/freebsd-current/20090607.freebsd-current > > Oh, so it should not be the newbus locking patch. No, hald sucks :-) -- DE From ertr1013 at student.uu.se Sat Aug 8 19:05:40 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sat Aug 8 19:05:49 2009 Subject: What's up with the SVN repository? In-Reply-To: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <20090808190514.GA60303@owl.midgard.homeip.net> On Sat, Aug 08, 2009 at 10:44:54AM -0800, Mel Flynn wrote: > On Saturday 08 August 2009 09:44:43 Ed Schouten wrote: > > * Thomas Backman wrote: > > > No commits at all in the last few days, and given "Please just bear > > > with it until commits are restored" (from Attilio Rao)... How are > > > things? Any status updates anywhere? I looked through the list of > > > mailing lists, but didn't find a fitting one with a topic covering > > > this. > > > > The FreeBSD Project has been discontinued. Nothing to see here! ;-) > > > > Ken Smith created the stable/8 branch, in preparation for 8.0-RELEASE. > > This is the first time we're creating a new major branch since our > > migration to SVN, so it turns out there are some problems with the SVN > > -> CVS exporter catching up. After this issues have been resolved, the > > release procedure should continue as expected. > > So for people using svn, should we now start tracking stable/8 or is HEAD safe > for the time being? I guess that depends on if you want -CURRENT or (what will be) 8-STABLE > > Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo > TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, > checkout stable/8 and re-apply diffs? If I understand what that command is supposed to do I guess 'svn switch' is the answer. See the subversion documentation at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.switchwc.html for exact syntax and details. (Subversion has fairly good documentation. If you intend to use svn I would suggest you read that documentation to find all the things you can do and how to do them.) -- Erik Trulsson ertr1013@student.uu.se From dimitry at andric.com Sat Aug 8 19:06:29 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Aug 8 19:06:36 2009 Subject: What's up with the SVN repository? In-Reply-To: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <4A7DC8CC.5050402@andric.com> On 2009-08-08 20:44, Mel Flynn wrote: > So for people using svn, should we now start tracking stable/8 or is HEAD safe > for the time being? If you want -CURRENT, follow head, if you want -STABLE, follow stable. :) > Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo > TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, > checkout stable/8 and re-apply diffs? Use svn switch to switch over your checked out copy, e.g. svn switch svn://svn.freebsd.org/base/stable/8 or the equivalent for your local mirror. From gcr+freebsd-current at tharned.org Sat Aug 8 19:12:28 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Sat Aug 8 19:12:36 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: <3bbf2fe10908081201g3378b8q479b8836d69f636b@mail.gmail.com> References: <3bbf2fe10908081116q384da0dcp1f41554dea0b0b95@mail.gmail.com> <3bbf2fe10908081151o35a9141dhcea06fcaa5b6838e@mail.gmail.com> <3bbf2fe10908081201g3378b8q479b8836d69f636b@mail.gmail.com> Message-ID: On Sat, 8 Aug 2009, Attilio Rao wrote: > 2009/8/8 Daniel Eischen : >> On Sat, 8 Aug 2009, Attilio Rao wrote: >> >>> 2009/8/8 Greg Rivers : >>>> >>>> On Sat, 8 Aug 2009, Attilio Rao wrote: >>>> >>>>> 2009/8/8 Greg Rivers : >>>>>> >>>>>> I've had to disable hald on my Acer One netbook since 8.0-BETA2. >>>>>> Now hald seems to work only the first time a USB drive is attached. >>>>>> The drive is detected and mounted, and can be unmounted and >>>>>> remounted via kde3's media interface. >>>>>> >>>>>> But if I unmount the drive and detach it, hald wedges the USB buss. >>>>>> No further USB connections (any device, not just disks) are >>>>>> detected, and hald becomes unkillable. >>>>>> >>>>>> Has anyone else experienced this? Any suggestions for >>>>>> troubleshooting? >>>>> >>>>> After installing BETA2 did you further update to -CURRENT or simply >>>>> used BETA2 system? >>>>> >>>> >>>> I've been tracking -CURRENT. I last rebuilt kernel and world on >>>> August 2nd. Sorry for not being clear about that. >>>> >>>> I removed and rebuilt all ports from source after the July 19 shared >>>> library version bump, and I rebuilt hald and dbus after the August >>>> 2nd kernel/world update. >>> >>> Did you include r196037? >>> If you did, can you try remove it and rebuild anything and experience >>> the problem again? >> >> You can also see this thread from June: >> >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1494406+0+archive/2009/freebsd-current/20090607.freebsd-current > > Oh, so it should not be the newbus locking patch. > Right, r196037 was committed on August 2nd, and I've seen this problem since ~July 20. -- Greg Rivers From mel.flynn+fbsd.current at mailing.thruhere.net Sat Aug 8 19:38:09 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Sat Aug 8 19:38:16 2009 Subject: What's up with the SVN repository? In-Reply-To: <20090808190514.GA60303@owl.midgard.homeip.net> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> Message-ID: <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> On Saturday 08 August 2009 11:05:14 Erik Trulsson wrote: > (Subversion has fairly good documentation. If you intend to use svn I > would suggest you read that documentation to find all the things you can do > and how to do them.) It's on my TODO, as soon as I'm going to convert my local cvs to svn, which is as soon as someone rewrites "how to set up a local cvs repository the freebsd way" to the svn equivalent ;). Maybe I should be volunteering for that, since everything seems to reside in svnadmin/. Thanks all for guiding me to svn help switch. -- Mel From sam at errno.com Sat Aug 8 20:08:01 2009 From: sam at errno.com (Sam Leffler) Date: Sat Aug 8 20:08:07 2009 Subject: hald broken with USB drives since 8.0-BETA2 In-Reply-To: References: Message-ID: <4A7DDB1F.5020709@errno.com> Greg Rivers wrote: > I've had to disable hald on my Acer One netbook since 8.0-BETA2. Now > hald seems to work only the first time a USB drive is attached. The > drive is detected and mounted, and can be unmounted and remounted via > kde3's media interface. > > But if I unmount the drive and detach it, hald wedges the USB buss. No > further USB connections (any device, not just disks) are detected, and > hald becomes unkillable. > > Has anyone else experienced this? Any suggestions for troubleshooting? > It is my understanding there is an outstanding bug in the usb code handling device enumeration for umass devices (and some others). This manifests itself by the symptoms you see. I believe the explorer thread is blocked so device detection stops. I have personally seen this bug. Unfortunately the person that was going to fix this has been away for awhile and will not return for another month so unless someone else fixes it 8.0 will ship with the bug. Sam From mike at sentex.net Sat Aug 8 20:30:55 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Aug 8 20:31:01 2009 Subject: USB busdma sync flag fix In-Reply-To: <200908071433.16484.hselasky@c2i.net> References: <200908071433.16484.hselasky@c2i.net> Message-ID: <200908082027.n78KRpoV018525@lava.sentex.ca> At 08:33 AM 8/7/2009, Hans Petter Selasky wrote: >Hi, > >Can people with AMD64 + USB and more than 4GBytes of RAM give the following >patch a shot? > >http://perforce.freebsd.org/chv.cgi?CH=167088 I tried an eToken key, a USB thumb drive and an uplcom device and it seems to work. Latest HEAD with above patch on a box with CPU: AMD Phenom(tm) 9950 Quad-Core Processor (2608.82-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8001216512 (7630 MB) ACPI APIC Table: <051209 APIC1231> 0(freebsd-current2)# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON 0(freebsd-current2)# ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From artis.caune at gmail.com Sat Aug 8 20:39:05 2009 From: artis.caune at gmail.com (Artis Caune) Date: Sat Aug 8 20:39:12 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DC8CC.5050402@andric.com> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DC8CC.5050402@andric.com> Message-ID: <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> 2009/8/8 Dimitry Andric : > >> Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo >> TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, >> checkout stable/8 and re-apply diffs? > > Use svn switch to switch over your checked out copy, e.g. > > ?svn switch svn://svn.freebsd.org/base/stable/8 If you svn switch, keywords are not re-expanded: # $FreeBSD: head/Makefile 190628 2009-04-01 17:11:50Z bz $ but should be # $FreeBSD: stable/8/Makefile 190628 2009-04-01 17:11:50Z bz $ I think "svn diff, svn co, patch" is the only way how to switch to stable/8. -- Artis Caune Everything should be made as simple as possible, but not simpler. From traveling08 at cox.net Sat Aug 8 20:41:07 2009 From: traveling08 at cox.net (Robert) Date: Sat Aug 8 20:41:14 2009 Subject: LOR wlan0 wi0 In-Reply-To: <4A7DA0DF.50107@errno.com> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> Message-ID: <20090808134101.44d7d210@vaio> On Sat, 08 Aug 2009 08:59:27 -0700 Sam Leffler wrote: > Robert wrote: > > Greetings > > > > I have just upgraded a laptop on my network to current: > > > > [root@hp] ~# uname -a > > FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug > > 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob > > j/usr/src/sys/VESA i386 > > > > I have made the changes in rc.conf after reading UPDATING and > > rc.conf defaults. Here is the bits from rc.conf > > > > wlans_wi0=wlan0 # I have tried with quotes around wlan0 with > > # no difference. > > ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ > > deftxkey 1 wepkey 0xSecretNumber78bf" > > > > # ifconfig_re0="DHCP" > > > > My wlan0 interface comes up but never retrieves an IP from the > > router. > > > > [root@hp] ~# ifconfig -a > > plip0: flags=8810 metric 0 mtu 1500 > > lo0: flags=8049 metric 0 mtu 16384 > > options=3 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > inet6 ::1 prefixlen 128 > > ether 00:09:5b:25:5e:b3 > > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > > status: associated > > wlan0: flags=8843 metric 0 > > mtu 1500 ether 00:09:5b:25:5e:b3 > > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > > status: associated > > ssid MY_SSID channel 11 (2462 Mhz 11b) bssid > > 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 > > wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 > > > > Searching dmesg I see this > > > > wlan0: Ethernet address: 00:09:5b:25:5e:b3 > > lock order reversal: > > 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) > > @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 > > (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack > > backtrace: > > db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at > > kdb_backtrace+0x29 > > _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) > > at _witness_debugger+0x25 > > witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at > > witness_checkorder+0x839 > > _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at > > _mtx_lock_flags+0xc4 > > wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at > > wi_raw_xmit+0x3e > > ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) > > at ieee80211_send_probereq+0x488 > > ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at > > ieee80211_probe_curchan+0x93 > > scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at scan_curchan+0x49 > > scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) at scan_task+0x33a > > taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at > > taskqueue_run+0x10b > > taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) > > at taskqueue_thread_loop+0x68 fork_exit(c08ba5b0,c2c04074,cca4ed38) > > at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap > > 0, eip = 0, esp = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. > > > > The PCMCIA is and older Netgear 802.11b that was working fine on 7 > > stable. I have searched the archives and tried changing things in > > rc.conf but I can not seem to make this work. > > > > > > Any help or direction will be greatly appreciated. > > Ignore the LOR. The first thing to do is simplify your config; > remove crypto. If you can pass data frames then your problem is in > the crypto setup. If not then you have unencrypted data to examine > for problems. > > Use tools/tools/net80211/wlanstats to check for errors. You can > trace packet traffic with tcpdump to see if frames are moving. > > You also don't identify your card. wi in 8.0 works with a subset of > the cards in RELENG_7 so your card may not work correctly--though > since you appear to have associated that doesn't seem like the issue > (cards that don't work are unlikely to successfully associate). > > Sam Sam Thanks for responding and for all of the fine work you are doing. I thought that I had tried without the crypto before but I either didn't or messed up. Anyway, The interface links up fine without WEP activated. I am able to get on the network and NFS loads all file systems from other boxes. Re-enabling WEP on the router (Belkin) and in rc.conf, causes the same failure as show above: associated without an IP. The interface card is old. It shows to be a Netgear MA401. I have ordered a newer model of the Netgear card. It is a WG511T which is supposed to have an atheros chipset. I should receive this card in about a week. I really do not know if any of this is relevant to my problem. On this laptop, because it is old and slow, I NFS mount /usr/src from a faster machine. So, wlanstats is not available when I do not have an IP. Running tcpdump -vv shows a whole lot of stuff. It starts with wlan0: no IPv4 assigned, so I do not know if the rest is important. There are many lines which contain "Unknown SSAP" and "Unknown DSAP". I have copied some of it to a file which I can forward if it of any help. Robert From dougb at FreeBSD.org Sat Aug 8 20:49:49 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Aug 8 20:49:56 2009 Subject: What's up with the SVN repository? In-Reply-To: <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DC8CC.5050402@andric.com> <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> Message-ID: <4A7DE4E0.4010205@FreeBSD.org> Artis Caune wrote: > 2009/8/8 Dimitry Andric : >>> Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo >>> TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, >>> checkout stable/8 and re-apply diffs? >> Use svn switch to switch over your checked out copy, e.g. >> >> svn switch svn://svn.freebsd.org/base/stable/8 > > If you svn switch, keywords are not re-expanded: > # $FreeBSD: head/Makefile 190628 2009-04-01 17:11:50Z bz $ > but should be > # $FreeBSD: stable/8/Makefile 190628 2009-04-01 17:11:50Z bz $ > > I think "svn diff, svn co, patch" is the only way how to switch to stable/8. You guys are making this way too complicated. cd /usr mv src src-old svn co svn://svn.freebsd.org/base/stable/8 src Then if you have anything in the old tree that you need you can use 'svn diff' etc. and bring it over. Doug -- This .signature sanitized for your protection From dougb at FreeBSD.org Sat Aug 8 20:51:04 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Aug 8 20:51:12 2009 Subject: What's up with the SVN repository? In-Reply-To: <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <4A7DE52F.5000201@FreeBSD.org> Mel Flynn wrote: > It's on my TODO, as soon as I'm going to convert my local cvs to svn, which is > as soon as someone rewrites "how to set up a local cvs repository the freebsd > way" to the svn equivalent ;). Actually svn basically eliminates the need for a local copy of the repository. What are you doing with your local repository now that you would like to continue doing with svn? Doug -- This .signature sanitized for your protection From kostikbel at gmail.com Sat Aug 8 21:03:05 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 8 21:03:13 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DE52F.5000201@FreeBSD.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> Message-ID: <20090808210258.GA1884@deviant.kiev.zoral.com.ua> On Sat, Aug 08, 2009 at 01:50:55PM -0700, Doug Barton wrote: > Mel Flynn wrote: > > > It's on my TODO, as soon as I'm going to convert my local cvs to svn, which is > > as soon as someone rewrites "how to set up a local cvs repository the freebsd > > way" to the svn equivalent ;). > > Actually svn basically eliminates the need for a local copy of the > repository. What are you doing with your local repository now that you > would like to continue doing with svn? Working with the history with reasonable speed. Additional bonus is ability to be able to work offline. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090808/85511642/attachment.pgp From dimitry at andric.com Sat Aug 8 21:03:50 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Aug 8 21:03:57 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DE4E0.4010205@FreeBSD.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DC8CC.5050402@andric.com> <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> <4A7DE4E0.4010205@FreeBSD.org> Message-ID: <4A7DE834.6020304@andric.com> On 2009-08-08 22:49, Doug Barton wrote: > Artis Caune wrote: >> I think "svn diff, svn co, patch" is the only way how to switch to stable/8. > You guys are making this way too complicated. > > cd /usr > mv src src-old > svn co svn://svn.freebsd.org/base/stable/8 src > > Then if you have anything in the old tree that you need you can use > 'svn diff' etc. and bring it over. That's exactly what Artis is suggesting, except for swapping the co and diff steps. :) Anyway, you could consider not re-expanding the keywords a bug in either Subversion, or the FreeBSD extensions to it. Since the help says "This behavior is similar to 'svn update'", you would expect it to update keywords... From dimitry at andric.com Sat Aug 8 21:05:46 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Aug 8 21:05:53 2009 Subject: What's up with the SVN repository? In-Reply-To: <20090808210258.GA1884@deviant.kiev.zoral.com.ua> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> Message-ID: <4A7DE8A9.7070703@andric.com> On 2009-08-08 23:02, Kostik Belousov wrote: > Working with the history with reasonable speed. Additional bonus > is ability to be able to work offline. Lowering the load on the main FreeBSD svn server is also nice. :) From mel.flynn+fbsd.current at mailing.thruhere.net Sat Aug 8 21:14:02 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Sat Aug 8 21:14:09 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DE52F.5000201@FreeBSD.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> Message-ID: <200908081314.00378.mel.flynn+fbsd.current@mailing.thruhere.net> On Saturday 08 August 2009 12:50:55 Doug Barton wrote: > Mel Flynn wrote: > > It's on my TODO, as soon as I'm going to convert my local cvs to svn, > > which is as soon as someone rewrites "how to set up a local cvs > > repository the freebsd way" to the svn equivalent ;). > > Actually svn basically eliminates the need for a local copy of the > repository. What are you doing with your local repository now that you > would like to continue doing with svn? I didn't mean the FreeBSD source tree. I have my own software in cvs, which was way back when set up using Stijn Hoop's article [1]. I'd like to do a onetime conversion, and keep the commit mail, commit checks, avail functionality. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/cvs-freebsd/index.html -- Mel From rwatson at FreeBSD.org Sat Aug 8 21:14:24 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 8 21:14:57 2009 Subject: What's up with the SVN repository? In-Reply-To: <20090808175831.GA84046@in-addr.com> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808175831.GA84046@in-addr.com> Message-ID: On Sat, 8 Aug 2009, Gary Palmer wrote: > On Sat, Aug 08, 2009 at 07:27:23PM +0200, Thomas Backman wrote: >> Anyone care to fill us outsiders in? ;) No commits at all in the last few >> days, and given "Please just bear with it until commits are restored" (from >> Attilio Rao)... How are things? Any status updates anywhere? I looked >> through the list of mailing lists, but didn't find a fitting one with a >> topic covering this. > > Not the easiest mention to find: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010255.html A lot more information on the in-progress release can be found here: http://wiki.freebsd.org/8.0TODO I updated it significantly today to add information on the current patch queue, explicit release status, and more detailed schedule. We're supposed to move over to the normal release web page structure shortly: http://www.freebsd.org/releases/8.0R/schedule.html However, I've deferred hooking that up to the build until the current issue is resolved. Robert N M Watson Computer Laboratory University of Cambridge From ubm at u-boot-man.de Sat Aug 8 21:50:20 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Sat Aug 8 22:38:03 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> Message-ID: <20090808235013.eab98028.ubm@u-boot-man.de> On Sat, 8 Aug 2009 12:02:41 +0100 (BST) Robert Watson wrote: > On Sat, 8 Aug 2009, Marc UBM Bocklet wrote: > > >>>>> I've got it narrowed down between "2009.06.30.06.00.00" and > >>>>> today. A kernel with the "old" date boots, a freshly csupped > >>>>> and compiled kernel hangs with the usual symptoms (waiting for > >>>>> interrupt driven hooks). > >>>>> > >>>>> I'll try csupping to just before the big cam commit to see if > >>>>> there is any connection. When I said earlier that I was not > >>>>> running with the ahci patch, I was partly wrong. I did not have > >>>>> device ahci in my kernel config file nor had it loaded as a > >>>>> module, but I had the patch applied. > >>>> > >>>> "2009.07.09.06.00.00" fixes the problem. Could it be that there > >>>> are some subtle interactions in the cam subsystem that are > >>>> stirred by the recent mega-commit? > >>> > >>> Is there any other info I can / should provide to help debugging > >>> this? > >> > >> Any news on this? This pretty much prevents me from running 8.0 :-/ > > > > I've a friend with a similar problem (also HighPoint controller, > > also "run interrupt driven hooks: still waiting for xpt_config"), > > who gets a panic. I'll try to get the panic string and a backtrace, > > if I do, I'll post it here. > > xpt_config basically means that you're waiting on a device driver > attached to CAM to finish probing, which could point at a number of > potential problem sources (including things like interrupt routing > problems). At least in the 7.x line, I've seen firewire and USB at > various times cause this issue. It might be interesting to compile > down to the smallest set of cam-related drivers required to support > necessary hardware (omit firewire, for example) and see if you see > any improvement. Pinning it down to a specific driver would have > significant debugging value :-). Thanks a lot for the suggestion, I'll be on holiday for one week starting tomorrow, I'll try narrowing it down as soon as I'm back :-) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From oberman at es.net Sun Aug 9 01:47:51 2009 From: oberman at es.net (Kevin Oberman) Date: Sun Aug 9 01:47:59 2009 Subject: Unable to build HEAD In-Reply-To: Your message of "Wed, 05 Aug 2009 20:45:11 PDT." <4A7A51C7.3060702@FreeBSD.org> Message-ID: <20090809014748.284AB1CC31@ptavv.es.net> > Date: Wed, 05 Aug 2009 20:45:11 -0700 > From: Doug Barton > > Kevin Oberman wrote: > > > OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. > > I'm going to assume that you mean just your conf file there. > > > > While I > > will have to re-do my kernel config, I prefer to save my old one, > > That's fine, just compare it to GENERIC to make sure that all of your > entries are valid, and that you're not missing anything important. > > > But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is > > broken which is a problem > > Agreed. If you want to help debug this problem you could try building > with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in > src.conf. Then debug from there. > > This (IMWO) is something that should be fixed before release. > > > Guess I should have tried V8 a couple of months ago. > > In the immortal words of Jiminy Cricket, let your conscience be your > guide. :) Doug, Two patches have been submitted to fix this problem, one by bf (conf/137483) and one by me (conf/137486). I have confidence that the bf patch is correct and appropriate and that buildworld is broken with various src.conf options. I am convinced my patch is correct, but I suspect that some might argue that it is not appropriate. It allows pam_ssh to be built even though WITHOUT_OPENSSH is specified. I will be happy to defend my patch, if challenged, but the short time until 8.0 makes it questionable as to whether a consensus can be reached in time. Whether you like my patch, I'd love to see the patch by bf (conf/137483) committed before 8.0 and I believe that you agree. If so, could you request the RE to approve it to be committed. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From kientzle at freebsd.org Sun Aug 9 02:48:43 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Aug 9 02:48:51 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DE8A9.7070703@andric.com> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> Message-ID: <4A7E3906.60007@freebsd.org> > On 2009-08-08 23:02, Kostik Belousov wrote: >> Working with the history with reasonable speed. Additional bonus >> is ability to be able to work offline. "svnsync" is a standard SVN tool (installed as part of svn) that makes it pretty easy to set up a read-only copy of an SVN repository. It's a little confusing to get set up initially, but once you do, you can just run it from cron every hour or so to keep in sync. Main documentation for svnsync starts here: http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html Even without a replica, I've found offline work with SVN pretty reasonable. No history, but the common "svn status", "svn diff", and "svn revert" commands are fully functional when offline. Dimitry Andric wrote: > Lowering the load on the main FreeBSD svn server is also nice. :) This is much less of an issue with SVN than CVS. Tim From sam at errno.com Sun Aug 9 05:27:11 2009 From: sam at errno.com (Sam Leffler) Date: Sun Aug 9 05:27:18 2009 Subject: LOR wlan0 wi0 In-Reply-To: <20090808134101.44d7d210@vaio> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> Message-ID: <4A7E5E2B.6060204@errno.com> Robert wrote: > On Sat, 08 Aug 2009 08:59:27 -0700 > Sam Leffler wrote: > >> Robert wrote: >>> Greetings >>> >>> I have just upgraded a laptop on my network to current: >>> >>> [root@hp] ~# uname -a >>> FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug >>> 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob >>> j/usr/src/sys/VESA i386 >>> >>> I have made the changes in rc.conf after reading UPDATING and >>> rc.conf defaults. Here is the bits from rc.conf >>> >>> wlans_wi0=wlan0 # I have tried with quotes around wlan0 with >>> # no difference. >>> ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ >>> deftxkey 1 wepkey 0xSecretNumber78bf" >>> >>> # ifconfig_re0="DHCP" >>> >>> My wlan0 interface comes up but never retrieves an IP from the >>> router. >>> >>> [root@hp] ~# ifconfig -a >>> plip0: flags=8810 metric 0 mtu 1500 >>> lo0: flags=8049 metric 0 mtu 16384 >>> options=3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>> inet6 ::1 prefixlen 128 >>> ether 00:09:5b:25:5e:b3 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11b >>> status: associated >>> wlan0: flags=8843 metric 0 >>> mtu 1500 ether 00:09:5b:25:5e:b3 >>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b >>> status: associated >>> ssid MY_SSID channel 11 (2462 Mhz 11b) bssid >>> 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 >>> wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 >>> >>> Searching dmesg I see this >>> >>> wlan0: Ethernet address: 00:09:5b:25:5e:b3 >>> lock order reversal: >>> 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) >>> @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 >>> (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack >>> backtrace: >>> db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) >>> at db_trace_self_wrapper+0x26 >>> kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at >>> kdb_backtrace+0x29 >>> _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) >>> at _witness_debugger+0x25 >>> witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at >>> witness_checkorder+0x839 >>> _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at >>> _mtx_lock_flags+0xc4 >>> wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at >>> wi_raw_xmit+0x3e >>> ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) >>> at ieee80211_send_probereq+0x488 >>> ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at >>> ieee80211_probe_curchan+0x93 >>> scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at scan_curchan+0x49 >>> scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) at scan_task+0x33a >>> taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at >>> taskqueue_run+0x10b >>> taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) >>> at taskqueue_thread_loop+0x68 fork_exit(c08ba5b0,c2c04074,cca4ed38) >>> at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap >>> 0, eip = 0, esp = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. >>> >>> The PCMCIA is and older Netgear 802.11b that was working fine on 7 >>> stable. I have searched the archives and tried changing things in >>> rc.conf but I can not seem to make this work. >>> >>> >>> Any help or direction will be greatly appreciated. >> Ignore the LOR. The first thing to do is simplify your config; >> remove crypto. If you can pass data frames then your problem is in >> the crypto setup. If not then you have unencrypted data to examine >> for problems. >> >> Use tools/tools/net80211/wlanstats to check for errors. You can >> trace packet traffic with tcpdump to see if frames are moving. >> >> You also don't identify your card. wi in 8.0 works with a subset of >> the cards in RELENG_7 so your card may not work correctly--though >> since you appear to have associated that doesn't seem like the issue >> (cards that don't work are unlikely to successfully associate). >> >> Sam > > Sam > > Thanks for responding and for all of the fine work you are doing. > > I thought that I had tried without the crypto before but I either > didn't or messed up. Anyway, The interface links up fine without WEP > activated. > > I am able to get on the network and NFS loads all file systems from > other boxes. > > Re-enabling WEP on the router (Belkin) and in rc.conf, causes the same > failure as show above: associated without an IP. > > The interface card is old. It shows to be a Netgear MA401. I have > ordered a newer model of the Netgear card. It is a WG511T which is > supposed to have an atheros chipset. I should receive this card in about > a week. I really do not know if any of this is relevant to my problem. > > On this laptop, because it is old and slow, I NFS mount /usr/src from a > faster machine. So, wlanstats is not available when I do not have an IP. > > Running tcpdump -vv shows a whole lot of stuff. It starts with wlan0: > no IPv4 assigned, so I do not know if the rest is important. There are > many lines which contain "Unknown SSAP" and "Unknown DSAP". I have > copied some of it to a file which I can forward if it of any help. I can confirm WEP is broken on wi in sta mode (and probably ap mode). I found at least two bugs but couldn't get it to work so am going to leave it as an errata for 8.0. But what's truly odd is that WPA works fine despite a bug that should've caused it to not work. I knew WPA worked which is probably why I ignored WEP (noone in their right mind uses WEP when WPA is available :-)). Sam From scottl at samsco.org Sun Aug 9 05:27:28 2009 From: scottl at samsco.org (Scott Long) Date: Sun Aug 9 05:27:35 2009 Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 In-Reply-To: <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> References: <4A66C7BB.6030307@samsco.org> <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> Message-ID: <53E87472-D6F5-4EE3-B905-8A3EF8AC7D83@samsco.org> I'm working on a fix, and hopefully I'll have something before the next 8.0 beta/rc build. Scott On Aug 7, 2009, at 2:48 AM, Simon ?ekar wrote: > Hello, > > what's really issue with this ? Is there any workaround ? > > interesting is that a FreeBSD 7.2 i386 boots fine when preinstalled > on a server with a different controller. > > Thanks, > S. > > On Jul 22, 2009, at 10:03 AM, Scott Long wrote: > >> This is probably a CISS P410 controller, right? It'll say exactly >> what it is further up in the boot messages. I know of the problem >> here, and >> I'm working on a fix. However, it might be a few more days before I >> have anything that can be tested. >> >> Scott >> >> >> Simon ?ekar wrote: >>> Hello, >>> I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD >>> image on a HP DL380 G6. >>> it freezes right after USB hubs & CD initialization with the >>> messsage: >>> umass0: on usbus5 >>> umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 >>> umass0:2:0:-1: Attached to scbus2 >>> run_interrupt_driven_hooks: still waiting after 60 seconds for >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 120 seconds for >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 180 seconds for >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 240 seconds for >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 300 seconds for >>> xpt_config >>> panic: run_interrupt_driven_config_hooks: waited too long >>> cpuid = 0 >>> KDB: enter : panic >>> [thread pid 0 tid 100000] >>> Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) >>> db> >>> keyboard freezes here, so no way I can do backtrace. >>> The same error is with 7.2-RELEASE bootable CD, but there it just >>> freezes, no messages about waiting for xpt_config. >>> What's there to be done ? >>> I can provide remote access to iLO of this server if this would >>> somehow help fix things. >>> Thank you, >>> Simon. From danny at cs.huji.ac.il Sun Aug 9 07:00:55 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Aug 9 07:01:10 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <4A7D8F72.8090905@FreeBSD.org> References: <1249741381.00149226.1249729205@10.7.7.3> <4A7D8D7A.5030303@mavhome.dp.ua> <4A7D8F72.8090905@FreeBSD.org> Message-ID: > Alexander Motin wrote: > > Danny Braniss wrote: > >> wups, forgot a small little detail: > >> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > > > > Is there reason why > > cpi->transport = XPORT_ISCSI; > > covered by > > #if defined(KNOB_VALID_ADDRESS) > > ? > I needed something to differentiate between the new CAM changes and the old (in <= 7.2), so if you have a better knob ... > Sorry, wrong question. But those who will test on CURRENT should take > care about it. why? it compiles - and works - ok under 8.0, at least till the last svn update :-) cheers, danny From hlh at restart.be Sun Aug 9 09:22:57 2009 From: hlh at restart.be (Henri Hennebert) Date: Sun Aug 9 09:23:05 2009 Subject: What's up with the SVN repository? In-Reply-To: References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808175831.GA84046@in-addr.com> Message-ID: <4A7E956A.4070903@restart.be> Robert Watson wrote: > On Sat, 8 Aug 2009, Gary Palmer wrote: > >> On Sat, Aug 08, 2009 at 07:27:23PM +0200, Thomas Backman wrote: >>> Anyone care to fill us outsiders in? ;) No commits at all in the last >>> few days, and given "Please just bear with it until commits are >>> restored" (from Attilio Rao)... How are things? Any status updates >>> anywhere? I looked through the list of mailing lists, but didn't find >>> a fitting one with a topic covering this. >> >> Not the easiest mention to find: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010255.html >> > > A lot more information on the in-progress release can be found here: > > http://wiki.freebsd.org/8.0TODO > > I updated it significantly today to add information on the current patch > queue, explicit release status, and more detailed schedule. We're > supposed to move over to the normal release web page structure shortly: Thank you for those valuable informations and for your time Henri > > http://www.freebsd.org/releases/8.0R/schedule.html > > However, I've deferred hooking that up to the build until the current > issue is resolved. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 simon at FreeBSD.org Sun Aug 9 09:53:57 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sun Aug 9 09:54:04 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7E3906.60007@freebsd.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> Message-ID: <20090809095354.GA1257@arthur.nitro.dk> On 2009.08.08 19:48:38 -0700, Tim Kientzle wrote: > Dimitry Andric wrote: > > Lowering the load on the main FreeBSD svn server is also nice. :) > > This is much less of an issue with SVN than CVS. But probably is still going to be an issue at some point, so people setting up syncs from svn.FreeBSD.org now should be expect to move to a mirror site at some point. PS. in case people are wondering - no, we don't currently have an svn mirroring infrastructure. There might be a couple of mirror sites, but I can't really recall. -- Simon L. Nielsen Hat: FreeBSD.org admins From h.schmalzbauer at omnilan.de Sun Aug 9 10:11:03 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sun Aug 9 10:11:11 2009 Subject: USB umass device not working on -current Message-ID: <4A7EA0A7.1000507@omnilan.de> Hello, one year ago I fed my present for my mother with some music files - a samsung ogg-player. Until now the music collection is still untouched, so I tried to help her and replace some files. Unfortunately it doesn't attach as daX any more. While watching for the lines with hw.usb.umass.debug=-1 I found that there's something strange goning on all the time. I guess it's hal. But are these messages to worry (-current from today)? (Samsung lines below) Thanks in advance for any hints. -Harry Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:2:XPT_PATH_INQ:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:2:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:2:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4021: cmd = 6b (0x004000000000), data = 0b, lun = 2, dir = out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4021: sig = 0x53425355 (valid), tag = 0x00000fb5, res = 0, status = 0x01 (failed) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Command failed, residue = 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4022: cmd = 6b (0x030000002000), data = 32b, lun = 2, dir = in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4022: sig = 0x53425355 (valid), tag = 0x00000fb6, res = 14, status = 0x00 (good) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:0:XPT_PATH_INQ:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4023: cmd = 6b (0x000000000000), data = 0b, lun = 0, dir = out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4023: sig = 0x53425355 (valid), tag = 0x00000fb7, res = 0, status = 0x01 (failed) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Command failed, residue = 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4024: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4024: sig = 0x53425355 (valid), tag = 0x00000fb8, res = 14, status = 0x00 (good) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:3:XPT_PATH_INQ:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:3:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:3:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4025: cmd = 6b (0x006000000000), data = 0b, lun = 3, dir = out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4025: sig = 0x53425355 (valid), tag = 0x00000fb9, res = 0, status = 0x01 (failed) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Command failed, residue = 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4026: cmd = 6b (0x030000002000), data = 32b, lun = 3, dir = in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4026: sig = 0x53425355 (valid), tag = 0x00000fba, res = 14, status = 0x00 (good) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:1:XPT_PATH_INQ:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:1:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:1:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4027: cmd = 6b (0x002000000000), data = 0b, lun = 1, dir = out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4027: sig = 0x53425355 (valid), tag = 0x00000fbb, res = 0, status = 0x01 (failed) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Command failed, residue = 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4028: cmd = 6b (0x030000002000), data = 32b, lun = 1, dir = in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer index = 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4028: sig = 0x53425355 (valid), tag = 0x00000fbc, res = 14, status = 0x00 (good) #################### Here's the samsung lines: Aug 9 12:03:55 titan root: Unknown USB device: vendor 0x04e8 product 0x5050 bus uhub3 Aug 9 12:03:55 titan kernel: ugen3.3: at usbus3 Aug 9 12:03:55 titan kernel: umass1: on usbus3 Aug 9 12:03:55 titan kernel: umass1: SCSI over Bulk-Only; quirks = 0x0110 Aug 9 12:04:00 titan kernel: umass1:umass_init_shuttle: Shuttle init returned 0x0000 Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:-1:-1:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:11:1:-1: Attached to scbus11 Aug 9 12:04:01 titan kernel: umass1:umass_cam_rescan: scbus11: scanning for 11:1:-1 Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:-1:-1:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_attach: Attach finishedumass1:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in Aug 9 12:04:01 titan kernel: Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 8 Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_csw: CSW 1: sig = 0x53425355 (valid), tag = 0x00000001, res = 0, status = 0x00 (good) Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/56b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x120000003800), data = 56b, lun = 0, dir = in Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=56 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 8 Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_csw: CSW 2: sig = 0x53425355 (valid), tag = 0x00000002, res = 0, status = 0x00 (good) Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x12010000ff00), data = 255b, lun = 0, dir = in Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer index = 5 Aug 9 12:04:06 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:06 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:06 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:04:11 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:11 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:11 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:04:16 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:16 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:16 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:04:22 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:22 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:22 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:04:27 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 12:04:27 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:04:32 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:04:33 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense ...... Aug 9 12:05:53 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:05:53 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:05:53 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:05:59 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): got CAM status 0x4 Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): fatal error, failed to attach to device Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): lost device Aug 9 12:05:59 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:05:59 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:06:04 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:06:04 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:04 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:06:09 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:06:09 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:09 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:06:15 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:06:15 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:15 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:06:20 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:06:20 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:20 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 12:06:26 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 12:06:26 titan kernel: (da4:umass-sim1:1:0:0): removing device entry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090809/050515f2/signature.pgp From kostikbel at gmail.com Sun Aug 9 10:21:27 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Aug 9 10:22:05 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7E3906.60007@freebsd.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> Message-ID: <20090809102119.GC1884@deviant.kiev.zoral.com.ua> On Sat, Aug 08, 2009 at 07:48:38PM -0700, Tim Kientzle wrote: > >On 2009-08-08 23:02, Kostik Belousov wrote: > >>Working with the history with reasonable speed. Additional bonus > >>is ability to be able to work offline. > > "svnsync" is a standard SVN tool (installed as part > of svn) that makes it pretty easy to set up a read-only > copy of an SVN repository. It's a little confusing > to get set up initially, but once you do, you can > just run it from cron every hour or so to keep in > sync. > > Main documentation for svnsync starts here: > http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html The issue with svnsync is that modifications of the non-versioned properties, that is the normal svn operation, but disabled on our repo, are not propagated by svnsync. Also, direct manipulations on the repo, like the surgery that was done with cvs2svn:cvs-rev properties, also not propagated by svnsync. I believe this is major reason why the svnsync mirrors are not given a bless. I do use svnsync, and my local mirror is used both to feed the the git-svn and local checkouts. > > Even without a replica, I've found offline work with > SVN pretty reasonable. No history, but the common > "svn status", "svn diff", and "svn revert" commands > are fully functional when offline. > > Dimitry Andric wrote: > >Lowering the load on the main FreeBSD svn server is also nice. :) > > This is much less of an issue with SVN than CVS. > > Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090809/56ce38ab/attachment.pgp From hselasky at c2i.net Sun Aug 9 13:20:45 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Aug 9 13:20:52 2009 Subject: USB umass device not working on -current In-Reply-To: <4A7EA0A7.1000507@omnilan.de> References: <4A7EA0A7.1000507@omnilan.de> Message-ID: <200908091520.46786.hselasky@c2i.net> On Sunday 09 August 2009 12:10:47 Harald Schmalzbauer wrote: > Hello, > > one year ago I fed my present for my mother with some music files - a > samsung ogg-player. > Until now the music collection is still untouched, so I tried to help > her and replace some files. > Unfortunately it doesn't attach as daX any more. > While watching for the lines with hw.usb.umass.debug=-1 I found that > there's something strange goning on all the time. I guess it's hal. But > are these messages to worry (-current from today)? (Samsung lines below) > > Thanks in advance for any hints. > > -Harry > Hi, Can you try attaching at FULL speed? sysctl hw.usb.ehci.no_hs=1 Replug your device. Another idea is that your device does not support certain SCSI commands, and will crash upon any non-support command. --HPS From js at alien8.de Sun Aug 9 13:29:25 2009 From: js at alien8.de (Julian Stecklina) Date: Sun Aug 9 13:29:58 2009 Subject: What's up with the SVN repository? References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> Message-ID: <87ws5dru8r.fsf@tabernacle.localhost> Kostik Belousov writes: > On Sat, Aug 08, 2009 at 01:50:55PM -0700, Doug Barton wrote: >> Mel Flynn wrote: >> >> > It's on my TODO, as soon as I'm going to convert my local cvs to svn, which is >> > as soon as someone rewrites "how to set up a local cvs repository the freebsd >> > way" to the svn equivalent ;). >> >> Actually svn basically eliminates the need for a local copy of the >> repository. What are you doing with your local repository now that you >> would like to continue doing with svn? > > Working with the history with reasonable speed. Additional bonus > is ability to be able to work offline. Perhaps someone can setup a git mirror of the Subversion repository somewhere? git svn clone is quite nice. Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From kraduk at googlemail.com Sun Aug 9 14:19:46 2009 From: kraduk at googlemail.com (chris scott) Date: Sun Aug 9 14:19:53 2009 Subject: usb pen drive detection - still no joy In-Reply-To: <200908060915.37155.hselasky@c2i.net> References: <200908051022.45347.hselasky@c2i.net> <200908060915.37155.hselasky@c2i.net> Message-ID: 2009/8/6 Hans Petter Selasky > On Wednesday 05 August 2009 23:17:12 chris scott wrote: > > will play around with setting tomorrow > > Find out at exactly which value your device stops working, and which of the > values is critical. > > --HPS > I had a good play around with those values but no joy 8( I took the delay from fairly low (25 ms) right through to 1000ms but it didn't help. I also ranged the continue from 2- 24ms I did however manage to find the psu for a usb2 hub i had. When i plu the device into the powered hub it works. However iff i pull the power plug on the usb hub everything disconnects. I have another non powered usb hub and thats still seen ugen4.2: at usbus4 uhub5: on usbus4 uhub5: 4 ports with 4 removable, self powered ugen4.3: at usbus4 uhub6: on usbus4 uhub6: 4 ports with 4 removable, self powered ugen4.4: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3840MB (7864320 512 byte sectors: 255H 63S/T 489C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. GEOM: ufsid/4a6383ef48125a83: partition 1 does not start on a track boundary. GEOM: ufsid/4a6383ef48125a83: partition 1 does not end on a track boundary. GEOM: ufs/uroot: partition 1 does not start on a track boundary. GEOM: ufs/uroot: partition 1 does not end on a track boundary. ugen4.2: at usbus4 (disconnected) uhub5: at uhub2, port 2, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry ugen4.3: at usbus4 (disconnected) ugen4.4: at usbus4 (disconnected) From keramida at ceid.upatras.gr Sun Aug 9 14:19:58 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sun Aug 9 14:20:07 2009 Subject: What's up with the SVN repository? In-Reply-To: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> (Mel Flynn's message of "Sat, 8 Aug 2009 10:44:54 -0800") References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <87my692ix7.fsf@kobe.laptop> On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: > Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo > TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, > checkout stable/8 and re-apply diffs? It should be possible to 'svn switch'... cd svn-head-workspace svn switch --relocate http://svn.freebsd.org/base/stable/8 From christoph.mallon at gmx.de Sun Aug 9 14:57:57 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Aug 9 14:58:03 2009 Subject: What's up with the SVN repository? In-Reply-To: <87my692ix7.fsf@kobe.laptop> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> Message-ID: <4A7EDDB1.6060208@gmx.de> Giorgos Keramidas schrieb: > On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: >> Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo >> TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, >> checkout stable/8 and re-apply diffs? > > It should be possible to 'svn switch'... > > cd svn-head-workspace > svn switch --relocate http://svn.freebsd.org/base/stable/8 --relocate is used *only* if the URL of the repository changes but the content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so the URL of the repository changes to http://svn.unfreebsd.org/base/, then you use --relocate. svn switch --relocate does something completely different than svn switch. The latter is used to switch between branches. Christoph From serenity at exscape.org Sun Aug 9 16:15:32 2009 From: serenity at exscape.org (Thomas Backman) Date: Sun Aug 9 16:15:38 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 Message-ID: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Hey everybody, I discovered a reproducible network-triggerable panic on my -CURRENT box (r196074). The NIC is a nfe (nForce4 SLI) in case it matters. The backtrace differs slightly (the first one had less ??'s, but I'm not sure I ran the same scan that time). I ran the following on a Linux box, while trialling zenmap ("Slow comprehensive scan" - and needless to say .1.10 is the FreeBSD box): nmap -sS -sU -T4 -A -v -PE -PP -PS21,22,23,25,80,113,31339 - PA80,113,443,10042 -PO --script all 192.168.1.10 (nmap -sU -A -v 192.168.1.10 also triggers a panic within 3 seconds, at most.) Starting Nmap 5.00 ( http://nmap.org ) at 2009-08-09 17:52 CEST NSE: Loaded 59 scripts for scanning. Initiating ARP Ping Scan at 17:52 Scanning 192.168.1.10 [1 port] Completed ARP Ping Scan at 17:52, 0.01s elapsed (1 total hosts) Initiating SYN Stealth Scan at 17:52 Scanning chaos (192.168.1.10) [1000 ports] Discovered open port .../tcp on 192.168.10 Discovered open port 80/tcp on 192.168.1.10 Discovered open port .../tcp on 192.168.10 ... and a few more Completed SYN Stealth Scan at 17:52, 5.04s elapsed (1000 total ports) Initiating UDP Scan at 17:52 [... the FreeBSD target box panicked here here, within a second or two] ----------------------------------------------------------------- On the console: Limiting closed port RST response from 276 to 200 packets/sec Limiting closed port RST response from 239 to 200 packets/sec Limiting closed port RST response from 280 to 200 packets/sec Limiting closed port RST response from 319 to 200 packets/sec Limiting icmp unreach response from 214 to 200 packets/sec Limiting icmp unreach response from 275 to 200 packets/sec Limiting icmp unreach response from 449 to 200 packets/sec core.txt: Unread portion of the kernel message buffer: Limiting icmp unreach response from 449 to 200 packets/sec Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805d2722 stack pointer = 0x28:0xffffff803e76f980 frame pointer = 0x28:0xffffff803e76f990 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 846 (nfsd: service) [NOTE: nfsd was not in use, merely running] panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 8m48s Physical memory: 2029 MB Dumping 1625 MB: ... #11 0xffffffff805dba87 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:224 #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, len=4) at /usr/src/sys/xdr/xdr_mbuf.c:302 #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not available. ) at /usr/src/sys/xdr/xdr.c:111 #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not available. ) at /usr/src/sys/rpc/svc_dg.c:216 #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, ismaster=0) at /usr/src/sys/rpc/svc.c:797 #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is not available. ) at /usr/src/sys/rpc/svc.c:1198 #19 0xffffffff80341008 in fork_exit ( callout=0xffffffff80558110 , arg=0xffffff00027acc00, frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 #20 0xffffffff805dbf5e in fork_trampoline () at /usr/src/sys/amd64/ amd64/exception.S:561 #21 0x0000000000000010 in ?? () #22 0x00007fffffffe710 in ?? () ... #47 0x0000000000000000 in ?? () #48 0xffffffff808acf00 in affinity () #49 0xffffff0002d9d390 in ?? () #50 0xffffff803e76f200 in ?? () #51 0xffffff803e76f1b8 in ?? () #52 0xffffff0002336720 in ?? () #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, newtd=0xffffff00027acc00, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 ----------------------------------------- I'll be honest and say that FreeBSD doesn't feel very stable for me... Yeah, sure, I use experimental features which causes many of my panics (like ZFS) and run -CURRENT, but will really all issues like this one be fixed in time for 8.0-RELEASE? It's pretty ugly that I can panic it via the network every try, in literally 2-3 seconds. Regards, Thomas From traveling08 at cox.net Sun Aug 9 17:04:26 2009 From: traveling08 at cox.net (Robert) Date: Sun Aug 9 17:04:32 2009 Subject: LOR wlan0 wi0 In-Reply-To: <4A7E5E2B.6060204@errno.com> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> Message-ID: <20090809100420.3ca4ff14@vaio> On Sat, 08 Aug 2009 22:27:07 -0700 Sam Leffler wrote: > Robert wrote: > > On Sat, 08 Aug 2009 08:59:27 -0700 > > Sam Leffler wrote: > > > >> Robert wrote: > >>> Greetings > >>> > >>> I have just upgraded a laptop on my network to current: > >>> > >>> [root@hp] ~# uname -a > >>> FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug > >>> 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob > >>> j/usr/src/sys/VESA i386 > >>> > >>> I have made the changes in rc.conf after reading UPDATING and > >>> rc.conf defaults. Here is the bits from rc.conf > >>> > >>> wlans_wi0=wlan0 # I have tried with quotes around wlan0 with > >>> # no difference. > >>> ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ > >>> deftxkey 1 wepkey 0xSecretNumber78bf" > >>> > >>> # ifconfig_re0="DHCP" > >>> > >>> My wlan0 interface comes up but never retrieves an IP from the > >>> router. > >>> > >>> [root@hp] ~# ifconfig -a > >>> plip0: flags=8810 metric 0 mtu 1500 > >>> lo0: flags=8049 metric 0 mtu 16384 > >>> options=3 > >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >>> inet6 ::1 prefixlen 128 > >>> ether 00:09:5b:25:5e:b3 > >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > >>> status: associated > >>> wlan0: flags=8843 metric 0 > >>> mtu 1500 ether 00:09:5b:25:5e:b3 > >>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > >>> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > >>> status: associated > >>> ssid MY_SSID channel 11 (2462 Mhz 11b) bssid > >>> 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 > >>> wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 > >>> > >>> Searching dmesg I see this > >>> > >>> wlan0: Ethernet address: 00:09:5b:25:5e:b3 > >>> lock order reversal: > >>> 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) > >>> @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 > >>> (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack > >>> backtrace: > >>> db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) > >>> at db_trace_self_wrapper+0x26 > >>> kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at > >>> kdb_backtrace+0x29 > >>> _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) > >>> at _witness_debugger+0x25 > >>> witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at > >>> witness_checkorder+0x839 > >>> _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at > >>> _mtx_lock_flags+0xc4 > >>> wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at > >>> wi_raw_xmit+0x3e > >>> ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) > >>> at ieee80211_send_probereq+0x488 > >>> ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at > >>> ieee80211_probe_curchan+0x93 > >>> scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at > >>> scan_curchan+0x49 scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) > >>> at scan_task+0x33a > >>> taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at > >>> taskqueue_run+0x10b > >>> taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) > >>> at taskqueue_thread_loop+0x68 > >>> fork_exit(c08ba5b0,c2c04074,cca4ed38) at fork_exit+0xb8 > >>> fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp > >>> = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. > >>> > >>> The PCMCIA is and older Netgear 802.11b that was working fine on 7 > >>> stable. I have searched the archives and tried changing things in > >>> rc.conf but I can not seem to make this work. > >>> > >>> > >>> Any help or direction will be greatly appreciated. > >> Ignore the LOR. The first thing to do is simplify your config; > >> remove crypto. If you can pass data frames then your problem is in > >> the crypto setup. If not then you have unencrypted data to examine > >> for problems. > >> > >> Use tools/tools/net80211/wlanstats to check for errors. You can > >> trace packet traffic with tcpdump to see if frames are moving. > >> > >> You also don't identify your card. wi in 8.0 works with a subset > >> of the cards in RELENG_7 so your card may not work > >> correctly--though since you appear to have associated that doesn't > >> seem like the issue (cards that don't work are unlikely to > >> successfully associate). > >> > >> Sam > > > > Sam > > > > Thanks for responding and for all of the fine work you are doing. > > > > I thought that I had tried without the crypto before but I either > > didn't or messed up. Anyway, The interface links up fine without WEP > > activated. > > > > I am able to get on the network and NFS loads all file systems from > > other boxes. > > > > Re-enabling WEP on the router (Belkin) and in rc.conf, causes the > > same failure as show above: associated without an IP. > > > > The interface card is old. It shows to be a Netgear MA401. I have > > ordered a newer model of the Netgear card. It is a WG511T which is > > supposed to have an atheros chipset. I should receive this card in > > about a week. I really do not know if any of this is relevant to my > > problem. > > > > On this laptop, because it is old and slow, I NFS mount /usr/src > > from a faster machine. So, wlanstats is not available when I do not > > have an IP. > > > > Running tcpdump -vv shows a whole lot of stuff. It starts with > > wlan0: no IPv4 assigned, so I do not know if the rest is important. > > There are many lines which contain "Unknown SSAP" and "Unknown > > DSAP". I have copied some of it to a file which I can forward if it > > of any help. > > I can confirm WEP is broken on wi in sta mode (and probably ap > mode). I found at least two bugs but couldn't get it to work so am > going to leave it as an errata for 8.0. But what's truly odd is that > WPA works fine despite a bug that should've caused it to not work. I > knew WPA worked which is probably why I ignored WEP (noone in their > right mind uses WEP when WPA is available :-)). > > Sam Sam I never claimed to be in my right mind. I haven't been myself since I quit smoking in 1986. :-) I tried WPA yesterday before answering the previous email. I kept getting and error stating: unable to start wpa_supplicant. I was thinking (always dangerous) that this old card maybe didn't have support for WPA. I'm probably wrong since I am not in my right mind. I was going to try again when the WG511T arrives. But now I will try again. Thanks again Robert From fbsdlist at src.cx Sun Aug 9 17:12:43 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Sun Aug 9 17:12:54 2009 Subject: [SOLVED] Re: mpt errors - UNIT ATTENTION asc:29,0 In-Reply-To: References: Message-ID: A bit more digging showed that these mpt errors match UDMA_CRC_Error_Count reported by drives via SMART. Connecting the same drives with the same cables to ICH7 SATA ports completely eliminates the errors which suggests that drives and cables themself are OK. So, my guess is that there's fair amount of cross-talk between LSI1068 ports on the motherboard (Asus P5BV/SAS). In the end I've switched on spread spectrum clocking on the drives (jumper 1-2 on WD SATA drives) and the errors almost completely disappeared. I've got 1 CRC error vs hundreds there used to be after ~10TB have been read/written. What didn't quite work: * Forcing drives into 1.5Gb mode (jumper 5-6 on WD drives). Errors became somewhat less frequent, but didn't go away. * replacing SATA cables -- tried three different sets with virtually no change in error rate. --Artem On Fri, Aug 7, 2009 at 11:06 AM, Artem Belevich wrote: > Hi, > > I'm running 8.0-BETA2 on Asus p5BV/SAS with built-in LSI1068 > controller with 8 SATA ports. 6 of the ports hooked up to 1TB WD Green > drives. The drives are used as a single raidz2 ZFS pool: > > ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM > ? ? ? ?z2 ? ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ?raidz2 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da1 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da0 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da2 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da3 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da5 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > > I'm runing a simple stress test that copies 10GB file until it fills > the volume and then runs "zfs scrub" on it. > > dd if=/dev/urandom of=/z2/f.0 bs=1m count=10240 > for f in {1..350}; do echo $f; cp f.$[$f-1] f.$f; done; > zpool scrub z2 > > What concerns me is that I'm periodically getting error messages from > MPT driver. They usually start few hours after the start of the script > and by the end of it they are happening every few minutes seemingly > randomly on all six drives. > > Aug ?7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug ?7 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): READ(10). CDB: 28 0 46 > 32 97 c0 0 0 80 0 > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): CAM Status: SCSI Status Error > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): SCSI Status: Check Condition > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): UNIT ATTENTION asc:29,0 > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Power on, reset, or bus > device reset occurred > Aug ?7 10:25:32 buz kernel: (da4:mpt0:0:4:0): Retrying Command (per Sense Data) > > ZFS scrub does not seem to report any issues so far - no checksum or > read/write errors. WD's hard drive diagnostics tools didn't find any > issues with te drives either. > > Sould somebody shed some light on why would such error happen? Is that > some sort of hardware issue? Driver bug? Issue with compatibility > between controller and the drives? System configuration issue (some > sysctl/tunable needs tweaking, perhaps)? > > I'd appreciate any hints on what could be going on and what should be > done about it. > > Thanks, > --Artem > From uqs at spoerlein.net Sun Aug 9 17:21:01 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Sun Aug 9 17:21:07 2009 Subject: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) In-Reply-To: <20090806184510.GA12039@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> Message-ID: <20090809172057.GD78940@acme.spoerlein.net> On Thu, 06.08.2009 at 20:45:10 +0200, Juergen Lock wrote: > Hi! > > So I put the problematic optical drive on a siis pcie card now because > I wanted to play with esata too which seems to be kinda broken on the > jmicron that I used before at least with _this_ esata drive (hw issue > most likely, has been reported by users of other OSes too) - and I > noticed two things: > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > any reads when a drive fails the read toc command as seems to happen > with bluray (data) discs at least; I was able to work around this > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > Index: sys/cam/scsi/scsi_cd.c > @@ -2868,12 +2868,18 @@ > } > > softc->flags |= CD_FLAG_VALID_TOC; > + > +bailout: > softc->disk->d_maxsize = DFLTPHYS; > softc->disk->d_sectorsize = softc->params.blksize; > softc->disk->d_mediasize = > (off_t)softc->params.blksize * softc->params.disksize; > > +/* if > bailout: > + * is here read requests will fail when the toc cant be read although > + * CD_FLAG_VALID_MEDIA is set. > + */ > > /* > * We unconditionally (re)set the blocksize each time the > > (I say work around because I don't know if there might be stuff > somewhere that depends on the old behaviour, although thats probably > unlikely; also acd(4) seems to behave similarly.) T H A N K Y O U ! Hi Juergen, this nice little patch lets my USB/Firewire attached Plextor drive read "pressed" DVD media, where it failed before. I have mentioned this in the past, but due to the esoteric nature of this problem failed to attract enough attention. http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003730.html http://docs.freebsd.org/cgi/getmsg.cgi?fetch=644449+0+archive/2007/freebsd-current/20070812.freebsd-current So this is not only related to Bluray, but plain DVD media is affected too (at least for some drives ...) Hopefully this can get committed some time soon... Regards, Uli From rmacklem at uoguelph.ca Sun Aug 9 18:21:35 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Aug 9 18:21:41 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Message-ID: On Sun, 9 Aug 2009, Thomas Backman wrote: [stuff snipped] > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805d2722 > stack pointer = 0x28:0xffffff803e76f980 > frame pointer = 0x28:0xffffff803e76f990 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 846 (nfsd: service) [NOTE: nfsd was not in use, merely > running] > panic: from debugger > cpuid = 0 > KDB: stack backtrace: > Uptime: 8m48s > Physical memory: 2029 MB > Dumping 1625 MB: ... > > #11 0xffffffff805dba87 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:224 > #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, len=4) > at /usr/src/sys/xdr/xdr_mbuf.c:302 > #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, > lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 > #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not available. > ) at /usr/src/sys/xdr/xdr.c:111 > #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, > cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 > #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not available. > ) at /usr/src/sys/rpc/svc_dg.c:216 > #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, > ismaster=0) at /usr/src/sys/rpc/svc.c:797 > #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is not > available. > ) at /usr/src/sys/rpc/svc.c:1198 > #19 0xffffffff80341008 in fork_exit ( > callout=0xffffffff80558110 , arg=0xffffff00027acc00, > frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 > #20 0xffffffff805dbf5e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:561 > #21 0x0000000000000010 in ?? () > #22 0x00007fffffffe710 in ?? () > ... > #47 0x0000000000000000 in ?? () > #48 0xffffffff808acf00 in affinity () > #49 0xffffff0002d9d390 in ?? () > #50 0xffffff803e76f200 in ?? () > #51 0xffffff803e76f1b8 in ?? () > #52 0xffffff0002336720 in ?? () > #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, > newtd=0xffffff00027acc00, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1858 > You could try this patch, which is currently in the re@ queue. I'm not sure if it will help, since the above panic didn't seem to happen at the beginning of xdrmbuf_inline() as I would have expected it to. rick --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 @@ -282,6 +282,8 @@ size_t available; char *p; + if (!m) + return (0); if (xdrs->x_op == XDR_ENCODE) { available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); } else { From rwatson at FreeBSD.org Sun Aug 9 18:26:53 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 9 18:27:31 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Message-ID: On Sun, 9 Aug 2009, Thomas Backman wrote: > I'll be honest and say that FreeBSD doesn't feel very stable for me... Yeah, > sure, I use experimental features which causes many of my panics (like ZFS) > and run -CURRENT, but will really all issues like this one be fixed in time > for 8.0-RELEASE? It's pretty ugly that I can panic it via the network every > try, in literally 2-3 seconds. Looks like a bug in the NFS server socket/RPC code, which has been revised in 8.0. CC'ing Doug and Rick whose hands were in this (see the original post for stack trace, etc). FYI, there's already at least one bug fix along these lines in the re@ queue pending the 8 branch being completed so that it can be merged -- not sure if it's for the same bug or not. Robert N M Watson Computer Laboratory University of Cambridge From traveling08 at cox.net Sun Aug 9 18:28:06 2009 From: traveling08 at cox.net (Robert) Date: Sun Aug 9 18:28:13 2009 Subject: LOR wlan0 wi0 In-Reply-To: <20090809100420.3ca4ff14@vaio> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> Message-ID: <20090809112759.3f1c2399@vaio> On Sun, 9 Aug 2009 10:04:20 -0700 Robert wrote: > On Sat, 08 Aug 2009 22:27:07 -0700 > Sam Leffler wrote: > > > Robert wrote: > > > On Sat, 08 Aug 2009 08:59:27 -0700 > > > Sam Leffler wrote: > > > > > >> Robert wrote: > > >>> Greetings > > >>> > > >>> I have just upgraded a laptop on my network to current: > > > > I can confirm WEP is broken on wi in sta mode (and probably ap > > mode). I found at least two bugs but couldn't get it to work so am > > going to leave it as an errata for 8.0. But what's truly odd is > > that WPA works fine despite a bug that should've caused it to not > > work. I knew WPA worked which is probably why I ignored WEP (noone > > in their right mind uses WEP when WPA is available :-)). > > > > Sam > Sam > > I never claimed to be in my right mind. I haven't been myself since I > quit smoking in 1986. :-) > > I tried WPA yesterday before answering the previous email. I kept > getting and error stating: unable to start wpa_supplicant. > > I was thinking (always dangerous) that this old card maybe didn't have > support for WPA. I'm probably wrong since I am not in my right mind. I > was going to try again when the WG511T arrives. But now I will try > again. > > Thanks again > Sam Set up WPA again. The exact error is: wpa_supplicant[1919]: Failed to initialize driver interface I found this error message in wpa_supplicant.c at line 1772 as part of "static int wpa_supplicant_init_iface2(struct wpa_supplicant *wpa_s)" function. I am just guessing but it seems this card is unable to use WPA. I will wait for the delivery and try with that one. Thanks for all of your help. Robert From rwatson at FreeBSD.org Sun Aug 9 18:33:37 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 9 18:33:44 2009 Subject: FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive In-Reply-To: <20090803152202.GB61519@rink.nu> References: <20090803152202.GB61519@rink.nu> Message-ID: On Mon, 3 Aug 2009, Rink Springer wrote: > On Mon, Aug 03, 2009 at 11:04:31AM -0400, David Boyd wrote: >> Can someone "PLEASE" commit this fix. > > This fix looks OK to me; I'll ask re@ for permission. Just a status update: this is in the re@ queue but approval is pending completion of the stable/7 branch. The plan is that this should appear in beta3. Robert N M Watson Computer Laboratory University of Cambridge From nox at jelal.kn-bremen.de Sun Aug 9 19:11:47 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Aug 9 19:11:54 2009 Subject: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) In-Reply-To: <20090809172057.GD78940@acme.spoerlein.net> References: <20090806184510.GA12039@triton.kn-bremen.de> <20090809172057.GD78940@acme.spoerlein.net> Message-ID: <20090809190452.GA4740@triton8.kn-bremen.de> On Sun, Aug 09, 2009 at 07:20:57PM +0200, Ulrich Sp?rlein wrote: > On Thu, 06.08.2009 at 20:45:10 +0200, Juergen Lock wrote: > > Hi! > > > > So I put the problematic optical drive on a siis pcie card now because > > I wanted to play with esata too which seems to be kinda broken on the > > jmicron that I used before at least with _this_ esata drive (hw issue > > most likely, has been reported by users of other OSes too) - and I > > noticed two things: > > > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > > any reads when a drive fails the read toc command as seems to happen > > with bluray (data) discs at least; I was able to work around this > > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > > > Index: sys/cam/scsi/scsi_cd.c > > @@ -2868,12 +2868,18 @@ > > } > > > > softc->flags |= CD_FLAG_VALID_TOC; > > + > > +bailout: > > softc->disk->d_maxsize = DFLTPHYS; > > softc->disk->d_sectorsize = softc->params.blksize; > > softc->disk->d_mediasize = > > (off_t)softc->params.blksize * softc->params.disksize; > > > > +/* if > > bailout: > > + * is here read requests will fail when the toc cant be read although > > + * CD_FLAG_VALID_MEDIA is set. > > + */ > > > > /* > > * We unconditionally (re)set the blocksize each time the > > > > (I say work around because I don't know if there might be stuff > > somewhere that depends on the old behaviour, although thats probably > > unlikely; also acd(4) seems to behave similarly.) > > T H A N K Y O U ! > > Hi Juergen, this nice little patch lets my USB/Firewire attached Plextor > drive read "pressed" DVD media, where it failed before. Cool, I'm glad it helped. :) > I have mentioned > this in the past, but due to the esoteric nature of this problem failed > to attract enough attention. > Heh I know _that_ feeling... > http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003730.html > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=644449+0+archive/2007/freebsd-current/20070812.freebsd-current > > So this is not only related to Bluray, but plain DVD media is affected > too (at least for some drives ...) > Yeah, good to know! > Hopefully this can get committed some time soon... > *nod* Juergen From glen.j.barber at gmail.com Sun Aug 9 19:24:31 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sun Aug 9 19:24:37 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7EDDB1.6060208@gmx.de> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> <4A7EDDB1.6060208@gmx.de> Message-ID: <4ad871310908091224x5f26e341sc7aa74d969d2f328@mail.gmail.com> On Sun, Aug 9, 2009 at 10:31 AM, Christoph Mallon wrote: > > --relocate is used *only* if the URL of the repository changes but the > content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so the > URL of the repository changes to http://svn.unfreebsd.org/base/, then you > use --relocate. svn switch --relocate does something completely different > than svn switch. The latter is used to switch between branches. > Should we wait for a -BETA3 or -RC1 (or some other) announcement before switching the repository location, or can we assume it is safe to do so now? -- Glen Barber From serenity at exscape.org Sun Aug 9 19:33:18 2009 From: serenity at exscape.org (Thomas Backman) Date: Sun Aug 9 19:33:25 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Message-ID: <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> On Aug 9, 2009, at 20:25, Rick Macklem wrote: > > > On Sun, 9 Aug 2009, Thomas Backman wrote: > > [stuff snipped] >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x18 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805d2722 >> stack pointer = 0x28:0xffffff803e76f980 >> frame pointer = 0x28:0xffffff803e76f990 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 846 (nfsd: service) [NOTE: nfsd was not in >> use, merely running] >> panic: from debugger >> cpuid = 0 >> KDB: stack backtrace: >> Uptime: 8m48s >> Physical memory: 2029 MB >> Dumping 1625 MB: ... >> >> #11 0xffffffff805dba87 in calltrap () at /usr/src/sys/amd64/ >> amd64/exception.S:224 >> #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, >> len=4) >> at /usr/src/sys/xdr/xdr_mbuf.c:302 >> #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, >> lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 >> #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not >> available. >> ) at /usr/src/sys/xdr/xdr.c:111 >> #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, >> cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 >> #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not >> available. >> ) at /usr/src/sys/rpc/svc_dg.c:216 >> #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, >> ismaster=0) at /usr/src/sys/rpc/svc.c:797 >> #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is >> not available. >> ) at /usr/src/sys/rpc/svc.c:1198 >> #19 0xffffffff80341008 in fork_exit ( >> callout=0xffffffff80558110 , >> arg=0xffffff00027acc00, >> frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 >> #20 0xffffffff805dbf5e in fork_trampoline () at /usr/src/sys/ >> amd64/amd64/exception.S:561 >> #21 0x0000000000000010 in ?? () >> #22 0x00007fffffffe710 in ?? () >> ... >> #47 0x0000000000000000 in ?? () >> #48 0xffffffff808acf00 in affinity () >> #49 0xffffff0002d9d390 in ?? () >> #50 0xffffff803e76f200 in ?? () >> #51 0xffffff803e76f1b8 in ?? () >> #52 0xffffff0002336720 in ?? () >> #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, >> newtd=0xffffff00027acc00, flags=Variable "flags" is not available. >> ) at /usr/src/sys/kern/sched_ule.c:1858 >> > You could try this patch, which is currently in the re@ queue. I'm not > sure if it will help, since the above panic didn't seem to happen at > the beginning of xdrmbuf_inline() as I would have expected it to. > > rick > --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 > +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 > @@ -282,6 +282,8 @@ > size_t available; > char *p; > > + if (!m) > + return (0); > if (xdrs->x_op == XDR_ENCODE) { > available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); > } else { > Initial results are certainly good! :-) Pre-patch, it panicked three times in a row, as I said within a few seconds. Post-patch I've looped the simpler scan for a while (10 minutes, or about 8-9 runs) with no crash, and I also ran the more extensive one (which I doubt makes any difference...) once. Just for fun, I tried actually using nfsd while looping the scan, too. No problems. Regards/thanks, Thomas From dougb at FreeBSD.org Sun Aug 9 19:42:39 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Aug 9 19:42:46 2009 Subject: Unable to build HEAD In-Reply-To: <20090809014748.284AB1CC31@ptavv.es.net> References: <20090809014748.284AB1CC31@ptavv.es.net> Message-ID: <4A7F26A3.6000809@FreeBSD.org> I'll let bf take the lead on this one. :) Doug Kevin Oberman wrote: >> Date: Wed, 05 Aug 2009 20:45:11 -0700 >> From: Doug Barton >> >> Kevin Oberman wrote: >> >>> OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. >> I'm going to assume that you mean just your conf file there. >> >> >>> While I >>> will have to re-do my kernel config, I prefer to save my old one, >> That's fine, just compare it to GENERIC to make sure that all of your >> entries are valid, and that you're not missing anything important. >> >>> But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is >>> broken which is a problem >> Agreed. If you want to help debug this problem you could try building >> with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in >> src.conf. Then debug from there. >> >> This (IMWO) is something that should be fixed before release. >> >>> Guess I should have tried V8 a couple of months ago. >> In the immortal words of Jiminy Cricket, let your conscience be your >> guide. :) > > Doug, > > Two patches have been submitted to fix this problem, one by bf > (conf/137483) and one by me (conf/137486). I have confidence that the bf > patch is correct and appropriate and that buildworld is broken with > various src.conf options. I am convinced my patch is correct, > but I suspect that some might argue that it is not appropriate. It > allows pam_ssh to be built even though WITHOUT_OPENSSH is specified. > > I will be happy to defend my patch, if challenged, but the short time > until 8.0 makes it questionable as to whether a consensus can be reached > in time. Whether you like my patch, I'd love to see the patch by bf > (conf/137483) committed before 8.0 and I believe that you agree. If so, > could you request the RE to approve it to be committed. From rmacklem at uoguelph.ca Sun Aug 9 19:49:18 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Aug 9 19:49:25 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: On Sun, 9 Aug 2009, Thomas Backman wrote: [stuff snipped] >> --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 >> +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 >> @@ -282,6 +282,8 @@ >> size_t available; >> char *p; >> >> + if (!m) >> + return (0); >> if (xdrs->x_op == XDR_ENCODE) { >> available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); >> } else { >> > > Initial results are certainly good! :-) > Pre-patch, it panicked three times in a row, as I said within a few seconds. > Post-patch I've looped the simpler scan for a while (10 minutes, or about 8-9 > runs) with no crash, and I also ran the more extensive one (which I doubt > makes any difference...) once. > Just for fun, I tried actually using nfsd while looping the scan, too. No > problems. > Ok, sounds good. It's already in the re@ queue, so it should make it into 8.0. If it does crap out again, please let the list (and me) know. Thanks for testing the patch, rick ps: Thanks mostly goes to pho@ for his "wicked" test scripts that found the crash that the above patch fixes + a bunch of others. From serenity at exscape.org Sun Aug 9 19:55:18 2009 From: serenity at exscape.org (Thomas Backman) Date: Sun Aug 9 19:55:24 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: <8934C698-C37D-4DB7-A7F5-4B93014AD0E9@exscape.org> On Aug 9, 2009, at 21:53, Rick Macklem wrote: > On Sun, 9 Aug 2009, Thomas Backman wrote: > > [stuff snipped] >>> --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 >>> +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 >>> @@ -282,6 +282,8 @@ >>> size_t available; >>> char *p; >>> + if (!m) >>> + return (0); >>> if (xdrs->x_op == XDR_ENCODE) { >>> available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); >>> } else { >> >> Initial results are certainly good! :-) >> Pre-patch, it panicked three times in a row, as I said within a few >> seconds. Post-patch I've looped the simpler scan for a while (10 >> minutes, or about 8-9 runs) with no crash, and I also ran the more >> extensive one (which I doubt makes any difference...) once. >> Just for fun, I tried actually using nfsd while looping the scan, >> too. No problems. >> > Ok, sounds good. It's already in the re@ queue, so it should make it > into > 8.0. If it does crap out again, please let the list (and me) know. > > Thanks for testing the patch, rick > ps: Thanks mostly goes to pho@ for his "wicked" test scripts that > found > the crash that the above patch fixes + a bunch of others. I just looked at the xdrs variable in kgdb, and "m" would indeed be 0 in the crash: (kgdb) p *xdrs $2 = {x_op = XDR_DECODE, x_ops = 0xffffffff806a16c0, x_public = 0xffffff007ffdc3a8 "?Z\t<", x_private = 0x0, x_base = 0xffffff000a066e00 "", x_handy = 0} And since m is "xdrs->x_private", accessing m wouln't be a good idea. As a newbie, I still think it's safe to say that at least this particular issue is fixed (for me, anyhow). :) Regards, Thomas From sam at errno.com Sun Aug 9 19:56:16 2009 From: sam at errno.com (Sam Leffler) Date: Sun Aug 9 19:56:23 2009 Subject: LOR wlan0 wi0 In-Reply-To: <20090809112759.3f1c2399@vaio> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> <20090809112759.3f1c2399@vaio> Message-ID: <4A7F29DD.30907@errno.com> Robert wrote: > On Sun, 9 Aug 2009 10:04:20 -0700 > Robert wrote: > >> On Sat, 08 Aug 2009 22:27:07 -0700 >> Sam Leffler wrote: >> >>> Robert wrote: >>>> On Sat, 08 Aug 2009 08:59:27 -0700 >>>> Sam Leffler wrote: >>>> >>>>> Robert wrote: >>>>>> Greetings >>>>>> >>>>>> I have just upgraded a laptop on my network to current: > > > > >>> I can confirm WEP is broken on wi in sta mode (and probably ap >>> mode). I found at least two bugs but couldn't get it to work so am >>> going to leave it as an errata for 8.0. But what's truly odd is >>> that WPA works fine despite a bug that should've caused it to not >>> work. I knew WPA worked which is probably why I ignored WEP (noone >>> in their right mind uses WEP when WPA is available :-)). >>> >>> Sam >> Sam >> >> I never claimed to be in my right mind. I haven't been myself since I >> quit smoking in 1986. :-) >> >> I tried WPA yesterday before answering the previous email. I kept >> getting and error stating: unable to start wpa_supplicant. >> >> I was thinking (always dangerous) that this old card maybe didn't have >> support for WPA. I'm probably wrong since I am not in my right mind. I >> was going to try again when the WG511T arrives. But now I will try >> again. >> >> Thanks again >> > > Sam > > Set up WPA again. The exact error is: > > wpa_supplicant[1919]: Failed to initialize driver interface > > I found this error message in wpa_supplicant.c at line 1772 as part of > > "static int wpa_supplicant_init_iface2(struct wpa_supplicant *wpa_s)" > > function. > > I am just guessing but it seems this card is unable to use WPA. I will > wait for the delivery and try with that one. > > Thanks for all of your help. You're probably correct. ifconfig wlan0 list caps will tell you for sure. I think I dropped this issue--that wpa_supplicant should check device capabilities when it hits an error to see if the device is even capable. I've got an MA401 but didn't find it. I tested with a different card the does support wpa. Sam From keramida at freebsd.org Sun Aug 9 20:08:17 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Sun Aug 9 20:08:51 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7EDDB1.6060208@gmx.de> (Christoph Mallon's message of "Sun, 09 Aug 2009 16:31:13 +0200") References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> <4A7EDDB1.6060208@gmx.de> Message-ID: <87ab28oiyd.fsf@kobe.laptop> On Sun, 09 Aug 2009 16:31:13 +0200, Christoph Mallon wrote: > Giorgos Keramidas schrieb: >> On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: >>> Also, what's the equivalent of find /usr/src -type d -name CVS -exec >>> echo TRELENG_8 \>{}/Tag \; or do we have to svn diff for local >>> patches, rm -rf, checkout stable/8 and re-apply diffs? >> >> It should be possible to 'svn switch'... >> >> cd svn-head-workspace >> svn switch --relocate http://svn.freebsd.org/base/stable/8 > > --relocate is used *only* if the URL of the repository changes but the > content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so > the URL of the repository changes to http://svn.unfreebsd.org/base/, > then you use --relocate. svn switch --relocate does something completely > different than svn switch. The latter is used to switch between > branches. You are right, of course. Thanks :) I got too used to --relocate by using it to switch between /home/svn/base and svn+ssh access to the main repo. To switch between branches of the same repository --relocate is not needed (and may actually cause problems, now that I think about it). From h.schmalzbauer at omnilan.de Sun Aug 9 20:25:01 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sun Aug 9 20:25:12 2009 Subject: USB umass device not working on -current In-Reply-To: <200908091520.46786.hselasky@c2i.net> References: <4A7EA0A7.1000507@omnilan.de> <200908091520.46786.hselasky@c2i.net> Message-ID: <4A7F308E.3050601@omnilan.de> Hans Petter Selasky schrieb am 09.08.2009 15:20 (localtime): ... > Can you try attaching at FULL speed? > > sysctl hw.usb.ehci.no_hs=1 Thanks for your quick response! Here's what I get with high-speed disabled: Aug 9 22:15:35 titan root: Unknown USB device: vendor 0x04e8 product 0x5050 bus uhub1 Aug 9 22:15:35 titan kernel: ugen1.2: at usbus1 Aug 9 22:15:36 titan kernel: umass1: on usbus1 Aug 9 22:15:36 titan kernel: umass1: SCSI over Bulk-Only; quirks = 0x0110 Aug 9 22:15:40 titan kernel: umass1:umass_init_shuttle: Shuttle init returned 0x0000 Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:-1:-1:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:11:1:-1: Attached to scbus11 Aug 9 22:15:41 titan kernel: umass1:umass_cam_rescan: scbus11: scanning for 11:1:-1 Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:-1:-1:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_attach: Attach finishedumass1:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in Aug 9 22:15:41 titan kernel: Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 8 Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_csw: CSW 1: sig = 0x53425355 (valid), tag = 0x00000001, res = 0, status = 0x00 (good) Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/56b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x120000003800), data = 56b, lun = 0, dir = in Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=56 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 8 Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_csw: CSW 2: sig = 0x53425355 (valid), tag = 0x00000002, res = 0, status = 0x00 (good) Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x12010000ff00), data = 255b, lun = 0, dir = in Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer index = 5 Aug 9 22:15:46 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_TIMEOUT -> reset Aug 9 22:15:46 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:46 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! Aug 9 22:15:47 titan kernel: umass1:umass_tr_error: transfer error, USB_ERR_STALLED -> reset Aug 9 22:15:47 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:47 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB reset! > Another idea is that your device does not support certain SCSI commands, and > will crash upon any non-support command. Hmm, if I remember correctly there was some quirk file with devices that need special treatment. Is it still the same? Maybe there has been an entry for my player which got lost. Or should the new code auto-detect such devices? How's redmond treating such devices? Needless to say that the player doesn't crash on windows, nor does windows crash ;) Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090809/537d3e2a/signature.pgp From rwatson at FreeBSD.org Sun Aug 9 20:51:38 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 9 20:51:45 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: On Sun, 9 Aug 2009, Rick Macklem wrote: >> Initial results are certainly good! :-) Pre-patch, it panicked three times >> in a row, as I said within a few seconds. Post-patch I've looped the >> simpler scan for a while (10 minutes, or about 8-9 runs) with no crash, and >> I also ran the more extensive one (which I doubt makes any difference...) >> once. Just for fun, I tried actually using nfsd while looping the scan, >> too. No problems. >> > Ok, sounds good. It's already in the re@ queue, so it should make it into > 8.0. If it does crap out again, please let the list (and me) know. > > Thanks for testing the patch, rick ps: Thanks mostly goes to pho@ for his > "wicked" test scripts that found the crash that the above patch fixes + a > bunch of others. It sounds a bit like we would benefit from some directed RPC fuzzing on the NFS client and server. I wonder if an existing fuzzer could easily be adapted to generate RPC-like garbage? Robert N M Watson Computer Laboratory University of Cambridge From cenixxx at gmail.com Sun Aug 9 21:24:17 2009 From: cenixxx at gmail.com (Nikolay Antsiferov) Date: Sun Aug 9 21:24:23 2009 Subject: reattach 3g0 device: could not allocate new device Message-ID: <5d97c6ec0908091401l26c82ab4u448f4408762fc081@mail.gmail.com> Hi. I have seen this issue since december 2008. I have 3G EvDO modem Novatel U-727. It fully supported by u3g driver except this issue with replugging. If I kldload u3g driver and replug modem i have the same messages: > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > HPS: Your patch resolved for me this problem. Thanks. I tested replugging modem, device attach correctly, >Try this patch: >src/sys/dev/usb/usb_device.c >@@ -1777,7 +1777,8 @@ > } > } else if (usb_test_huawei_autoinst_p(udev, &uaa) == 0) { > DPRINTFN(0, "Found Huawei auto-install disk!\n"); >- err = USB_ERR_STALLED; /* fake an error */ >+ /* leave device unconfigured */ >+ usb_unconfigure(udev, USB_UNCFG_FLAG_FREE_SUBDEV); > } > } else { > err = 0; /* set success */ -- From traveling08 at cox.net Sun Aug 9 21:37:41 2009 From: traveling08 at cox.net (Robert) Date: Sun Aug 9 21:39:16 2009 Subject: LOR wlan0 wi0 In-Reply-To: <4A7F29DD.30907@errno.com> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> <20090809112759.3f1c2399@vaio> <4A7F29DD.30907@errno.com> Message-ID: <20090809143735.3fa4e8db@vaio> On Sun, 09 Aug 2009 12:56:13 -0700 Sam Leffler wrote: > Robert wrote: > > On Sun, 9 Aug 2009 10:04:20 -0700 > > Robert wrote: > > > >> On Sat, 08 Aug 2009 22:27:07 -0700 > >> Sam Leffler wrote: > >> > >>> Robert wrote: > >>>> On Sat, 08 Aug 2009 08:59:27 -0700 > >>>> Sam Leffler wrote: > >>>> > >>>>> Robert wrote: > >>>>>> Greetings > >>>>>> > >>>>>> I have just upgraded a laptop on my network to current: > > > > > > > > > >>> I can confirm WEP is broken on wi in sta mode (and probably ap > >>> mode). I found at least two bugs but couldn't get it to work so > >>> am going to leave it as an errata for 8.0. But what's truly odd > >>> is that WPA works fine despite a bug that should've caused it to > >>> not work. I knew WPA worked which is probably why I ignored WEP > >>> (noone in their right mind uses WEP when WPA is available :-)). > >>> > >>> Sam > >> Sam > >> > >> I never claimed to be in my right mind. I haven't been myself > >> since I quit smoking in 1986. :-) > >> > >> I tried WPA yesterday before answering the previous email. I kept > >> getting and error stating: unable to start wpa_supplicant. > >> > >> I was thinking (always dangerous) that this old card maybe didn't > >> have support for WPA. I'm probably wrong since I am not in my > >> right mind. I was going to try again when the WG511T arrives. But > >> now I will try again. > >> > >> Thanks again > >> > > > > Sam > > > > Set up WPA again. The exact error is: > > > > wpa_supplicant[1919]: Failed to initialize driver interface > > > > I found this error message in wpa_supplicant.c at line 1772 as part > > of > > > > "static int wpa_supplicant_init_iface2(struct wpa_supplicant > > *wpa_s)" > > > > function. > > > > I am just guessing but it seems this card is unable to use WPA. I > > will wait for the delivery and try with that one. > > > > Thanks for all of your help. > > You're probably correct. > > ifconfig wlan0 list caps > > will tell you for sure. I think I dropped this issue--that > wpa_supplicant should check device capabilities when it hits an error > to see if the device is even capable. > > I've got an MA401 but didn't find it. I tested with a different card > the does support wpa. > > Sam ifconfig wlan0 list caps drivercaps=10701 cryptocaps=1 It doesn't look promising. At least it wasn't my burned out brain :-) Robert From jille at quis.cx Sun Aug 9 21:46:24 2009 From: jille at quis.cx (Jille Timmermans) Date: Sun Aug 9 21:46:58 2009 Subject: Freeze while playing with unionfs Message-ID: <4A7F3F22.6090005@quis.cx> I was playing with unionfs (nearly everytime I do that I lose my uptime ;)). I somehow managed to get the same unionfs mount from and to the same dir. # mount -t unionfs -o copymode=transparent,whiteout=whenneeded,noatime bla1 bla2 both empty dirs; and after hitting some tab too much, my bash froze . Backtrace (shortened; each line was () at +0x): sched_switch() +0xdd mi_switch() +0x16f sleepq_wait() +0x42 __lockmgr_args() +0x7bb ffs_lock() + 0x8c VOP_LOCK1_APV() +0x46 unionfs_lock() + 0x327 VOP_LOCK1_APV() +0x46 unionfs_lock() + 0x1ac VOP_LOCK1_APV() +0x46 _vn_lock() +0x47 unionfs_readdir() +0x134 kern_getdirentries() +0x1fa getdirentries() +0x23 I will reboot this machine in a few minutes; but I think this is reproducable. -- Jille From ota at j.email.ne.jp Mon Aug 10 02:04:14 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Mon Aug 10 02:04:23 2009 Subject: What's up with the SVN repository? In-Reply-To: <20090809102119.GC1884@deviant.kiev.zoral.com.ua> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> <20090809102119.GC1884@deviant.kiev.zoral.com.ua> Message-ID: <20090809220402.f22935e1.ota@j.email.ne.jp> How about SVK? Something like below will copy a repository. % svk mirror svn://svn.freebsd.org/base //freebsd/base I do not know the details mentioned below, though. Hiro On Sun, 9 Aug 2009 13:21:19 +0300 Kostik Belousov wrote: > On Sat, Aug 08, 2009 at 07:48:38PM -0700, Tim Kientzle wrote: > > >On 2009-08-08 23:02, Kostik Belousov wrote: > > >>Working with the history with reasonable speed. Additional bonus > > >>is ability to be able to work offline. > > > > "svnsync" is a standard SVN tool (installed as part > > of svn) that makes it pretty easy to set up a read-only > > copy of an SVN repository. It's a little confusing > > to get set up initially, but once you do, you can > > just run it from cron every hour or so to keep in > > sync. > > > > Main documentation for svnsync starts here: > > http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html > The issue with svnsync is that modifications of the non-versioned > properties, that is the normal svn operation, but disabled on our repo, > are not propagated by svnsync. Also, direct manipulations on the repo, > like the surgery that was done with cvs2svn:cvs-rev properties, also not > propagated by svnsync. > > I believe this is major reason why the svnsync mirrors are not given a > bless. I do use svnsync, and my local mirror is used both to feed the > the git-svn and local checkouts. > > > > > Even without a replica, I've found offline work with > > SVN pretty reasonable. No history, but the common > > "svn status", "svn diff", and "svn revert" commands > > are fully functional when offline. > > > > Dimitry Andric wrote: > > >Lowering the load on the main FreeBSD svn server is also nice. :) > > > > This is much less of an issue with SVN than CVS. > > > > Tim > From mel.flynn+fbsd.current at mailing.thruhere.net Mon Aug 10 05:27:22 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Mon Aug 10 05:27:29 2009 Subject: What's up with the SVN repository? In-Reply-To: <4A7DE4E0.4010205@FreeBSD.org> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> <4A7DE4E0.4010205@FreeBSD.org> Message-ID: <200908092127.19931.mel.flynn+fbsd.current@mailing.thruhere.net> On Saturday 08 August 2009 12:49:36 Doug Barton wrote: > Artis Caune wrote: > > 2009/8/8 Dimitry Andric : > >>> Also, what's the equivalent of find /usr/src -type d -name CVS -exec > >>> echo TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, > >>> rm -rf, checkout stable/8 and re-apply diffs? > >> > >> Use svn switch to switch over your checked out copy, e.g. > >> > >> svn switch svn://svn.freebsd.org/base/stable/8 > > > > If you svn switch, keywords are not re-expanded: > > # $FreeBSD: head/Makefile 190628 2009-04-01 17:11:50Z bz $ > > but should be > > # $FreeBSD: stable/8/Makefile 190628 2009-04-01 17:11:50Z bz $ > > > > I think "svn diff, svn co, patch" is the only way how to switch to > > stable/8. > > You guys are making this way too complicated. Well, I took the lazy road, cause I didn't feel like sorting out what directories were not under svn's control (and thus not showing up in svn diff). svn switch worked fine and fixing the keywords was a breeze: find . -name '.svn' -prune -o -type f -print |while read FILE; do if grep -q '\$FreeBSD: head/.*\$' ${FILE}; then sed -e 's,\$FreeBSD: head/,$FreeBSD: stable/8/,' -i '' ${FILE} else echo "No match: ${FILE}" fi done I put in the else so I could see which files didn't have a keyword. That was fun when we went into contrib :) -- Mel From muriamas at yahoo.ca Mon Aug 10 04:31:26 2009 From: muriamas at yahoo.ca (Walter Scott) Date: Mon Aug 10 05:28:04 2009 Subject: 8-current: no internet connection Message-ID: <981942.73761.qm@web111615.mail.gq1.yahoo.com> Please take a look: http://forums.freebsd.org/showthread.php?=6138 __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From h.schmalzbauer at omnilan.de Mon Aug 10 06:54:12 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Mon Aug 10 06:54:19 2009 Subject: USB umass device not working on -current In-Reply-To: <4A7EA0A7.1000507@omnilan.de> References: <4A7EA0A7.1000507@omnilan.de> Message-ID: <4A7FC408.6020401@omnilan.de> Harald Schmalzbauer schrieb am 09.08.2009 12:10 (localtime): ... > one year ago I fed my present for my mother with some music files - a > samsung ogg-player. > Until now the music collection is still untouched, so I tried to help > her and replace some files. > Unfortunately it doesn't attach as daX any more. ... Hmmm, very strange, here I found a PR reporting the opposite: http://www.jp.freebsd.org/cgi/query-pr.cgi?pr=114154 It's my player (just the 2G version) and Ulrich Spoerlein reports it working with HPS' stack, but not with the old USB code. I'm sure I filled this puppy here and I've been running FreeBSD-7 until -current was ready for testing (arround beta1). None the less, this device seems to work somehow on FreeBSD. I'm not sure how usb_quirk.ko is related. I'm lost. Are there still hard coded quirks? Any help appreciated Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090810/cded7a59/signature.pgp From stb at lassitu.de Mon Aug 10 09:48:01 2009 From: stb at lassitu.de (Stefan Bethke) Date: Mon Aug 10 09:48:07 2009 Subject: 8-current: no internet connection In-Reply-To: <981942.73761.qm@web111615.mail.gq1.yahoo.com> References: <981942.73761.qm@web111615.mail.gq1.yahoo.com> Message-ID: Am 10.08.2009 um 04:55 schrieb Walter Scott: > Please take a look: http://forums.freebsd.org/showthread.php?=6138 The correct link is (I assume). I'm quoting relevant parts from the forum post: > dmesg output: > de0: port 0x9400-0x947f mem > 0xe4800000-0xe480007f irq1 > de0: SMC 21041 [10Mb/s] pass 2.1 > de0: WARNING: using obsolete if_watchdog interface > de0: Ethernet address: xxxxxxxxxxxx > de0: [ITHREAD] > ifconfig output: > de0: flags=8843 metric 0 > mtu 1500 > ether xxxxxxxxxx > media: Ethernet autoselect (10baseT/UTP) > status: active I'm guessing that you're trying DHCP on de0? What's in /etc/rc.conf? Does it work if you assign an address manually? If not, can you see any packets arriving on the interface with tcpdump? You can also try to fiddle with the interfaces full-duplex setting. If this should be a problem with the de driver, someone will likely know more details about the hardware, so the output of pciconf -vl should be interesting, as well as dmesg output from a working FreeBSD (i.e. 6.4 or 7.x). What interrupt do other OSes report for the card? irq 1 can't be right. Or is the dmesg line cut off? There should be further output after the irq, like "at device n.m on pci0" HTH, Stefan -- Stefan Bethke Fon +49 151 14070811 From jhb at freebsd.org Mon Aug 10 12:49:55 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 10 12:50:05 2009 Subject: 8.0-BETA2: two kernel lockups in one night In-Reply-To: <4A787826.5090909@lozenetz.org> References: <4A787826.5090909@lozenetz.org> Message-ID: <200908100807.30269.jhb@freebsd.org> On Tuesday 04 August 2009 2:04:22 pm Anton - Valqk wrote: > Hi group. > I've installed amd64 8.0-BETA2 distro from iso from official ftp. > I knew there was a problem with hangs of the system because of disk io > (and this machine is going to be loaded) and started tesing with bonnie++ > > In about 5-6 hours the first lockup came into real. > Kernel went into dbg console and continue rebooted the system. > Few hours later bonnie started again - same thing in few hours I got the > second dump. > > This is the bonnie++ opts I've used: > > #> bonnie++ -u root -d /usr/test/ -c 10 -s 4098 -n 26000:100000:10:1000 > -n 2048 -r 4098 -x 10000 -q -Z /dev/urandom > stat.html > > and here are links to the txt dumps. > If someone is interested in the vmcore files let me know. > http://bg0.eu/core.txt.0 > http://bg0.eu/core.txt.1 > > Are these issues known for 8.0-BETA2? I don't think these are known issues. I think the two panics may be caused by the same bug which looks to be a duplicate free() issue in the soft updates code. -- John Baldwin From jhay at meraka.org.za Mon Aug 10 13:05:52 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Aug 10 13:06:00 2009 Subject: gptboot parse error Message-ID: <20090810130538.GA62008@zibbi.meraka.csir.co.za> Hi, When experimenting with gptboot to boot different partitions, I found that its parse() function was broken. Using 'p' to seperate the units from the partition did not work, neither did a ','. Here is a fix to make it work with 'p' like it is suggested in main(). Any comments? Should we try to get it in before 8.0? This allows me to use boot.config to select different partitions to boot from. Something like "ad(0p3)/boot/loader" for instance. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org Index: gptboot.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/gptboot/gptboot.c,v retrieving revision 1.86.2.3 diff -u -r1.86.2.3 gptboot.c --- gptboot.c 15 Aug 2008 19:31:12 -0000 1.86.2.3 +++ gptboot.c 7 Aug 2009 10:27:09 -0000 @@ -466,16 +466,13 @@ dsk.type = i; arg += 3; dsk.unit = *arg - '0'; - if (arg[1] != ',' || dsk.unit > 9) + if (arg[1] != 'p' || dsk.unit > 9) return -1; arg += 2; - dsk.part = -1; - if (arg[1] == ',') { - dsk.part = *arg - '0'; - if (dsk.part < 1 || dsk.part > 9) - return -1; - arg += 2; - } + dsk.part = *arg - '0'; + if (dsk.part < 1 || dsk.part > 9) + return -1; + arg++; if (arg[0] != ')') return -1; arg++; From bz at FreeBSD.org Mon Aug 10 13:40:10 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 10 13:40:17 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> Message-ID: <20090810133111.C93661@maildrop.int.zabbadoz.net> On Thu, 6 Aug 2009, Robert Watson wrote: Hi, > On Thu, 6 Aug 2009, Larry Rosenman wrote: > >> On Thu, 6 Aug 2009, Robert Watson wrote: >> >>> On Tue, 4 Aug 2009, Navdeep Parhar wrote: >>> >>>>>> This occurs on today's HEAD + some unrelated patches. That makes it >>>>>> 8.0BETA2+ code. I haven't tried older builds. >>>>> >>>>> We have finally been able to reproduce this ourselves yesterday and >>>> >>>> Well, it happens every single time on all of my amd64 machines. After I'd >>>> already sent my email I noticed that the netisr mutex has an odd address >>>> (pun intended :-)) >>>> >>>> m=0xffffffff8144d867 >>> >>> Heh, indeed. We just spotted the same result here. In this case it's >>> causing a panic because it leads to a non-atomic read due to mtx_lock >>> spanning a cache line boundary, followed shortly by a panic because it's >>> not a valid thread pointer when it's dereferenced, as we get a fractional >>> pointer. >> [snip] >> >> Do we have an ETA for a testable patch? > > RSN, I'm afraid. ... You can fetch the following from .. as well: http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff I tried to get things summarized a bit; as good as possible from my pov/knowledge: ------------------------------------------------------------------------ [ The following samples, etc are generally "thinking" arch=amd64: ] There are two different kinds of places where we find dynamic per-cpu (dpcpu) data: (1) the so called 'master copy', that is a linker set, which holds the BSS initialized compile-time defaults. (2) a copy for each PU copied to allocated memory. The problem seen has been that single members of the set had been un-aligned at run-time. Dumping the linker set (master copy), things look like this for example: ffffffff8168f8e9 g *ABS* 0000000000000000 __start_set_pcpu ffffffff8168f900 l d set_pcpu 0000000000000000 ffffffff8168f900 g O set_pcpu 0000000000000068 pcpu_entry_sched_switch_stats ffffffff8168f980 l O set_pcpu 0000000000000800 pcpu_entry_modspace ffffffff81690180 g O set_pcpu 0000000000000038 pcpu_entry_epair_dpcpu ffffffff81690200 g O set_pcpu 0000000000000500 pcpu_entry_nws ffffffff81690700 g *ABS* 0000000000000000 __stop_set_pcpu The members of the linker set (master copy) are all well aligned within the set: for example pcpu_entry_nws: 0xffffffff81690200 % 128 = 0 Looking at elfdump for the kernel this is also what we would expect: entry: 32 sh_name: set_pcpu sh_type: SHT_PROGBITS sh_flags: SHF_WRITE|SHF_ALLOC sh_addr: 0xffffffff8168f900 sh_offset: 21559552 sh_size: 3584 sh_link: 0 sh_info: 0 sh_addralign: 128 <<<< sh_entsize: 0 The problem is with __start_set_pcpu, the symbol ld adds to mark the beginning of the section. The address of __start_set_pcpu is not well-aligned, not even pointer-aligned: 0xffffffff8168f8e9 % 8 = 1. When now copying the 'master copy' to a dpcpu area the aligned symbols become un-aligned. Example: dpcpu area starts at 0xffff0000 |--------+------------------------------------------ Copyin the master copy from the objdump above starting at __start_set_pcpu will put __start_set_pcpu at 0xffff0000 but the first symbol pcpu_entry_sched_switch_stats at 0xffff0017 0xffff0000 |--------+------------------------------------------ |~~~~~~~~|------------------------------------------======== 0xffff0017 Two problems become obvious: (1) the symbols are now un-aligned in the per-cpu area. (2) due to the offset we did not copy the entire dpcpu area, so some symbols at the end might not have been properly initialized. While (2) may lead to run-time problems it usually is not a problem with memory corrution as the dpcpu area is usually allocated in pages. So unless the dpcpu symbols end page aligned there should be no corruption. (1) in contrast may lead to other effects like a lock spanning multiple cache lines thus no longer permitting atomic reads and being open to races. The results are panics with truncated pointers trying to access invalid memory regions, etc. On architectures like arm, this will immediatly fault as arm does not allow un-aligned reads. So one solution to the problem would be to make sure we allocate enough memory to also account for the offset to proper alignment and then copying the 'master copy' to a possibly unaligned address as well making the symbols properly aligned again: dpcpu area starts at 0xffff0000 |--------+---------+------------------------------------... |*** unused *******|~~~~~~~~|---------------------------... 0xffff0069 | 0xffff0080 In this sample __start_set_pcpu would be at 0xffff0069 and pcpu_entry_sched_switch_stats at 0xffff0080 and thus properly aligned again. With this things will work. Looking further at the problem you may have already noticed that the section for the 'master copy' starts at 0xffffffff8168f900 and that the __start_set_pcpu is outside of that section at 0xffffffff8168f8e9. Looking at a section dump from `readelf -S kernel` you would notice that the __start_set_pcpu directly follows the end of the previous section. The reasons for this are twofold: (1) ld places the __start_ symbol at '.' (the location counter), which at that point is at the end of the old section as the new (set_pcpu) is not yet added with __start_set_pcpu = ALIGN(0). (2) because we manually define the section, so that it is writeable, ld at the point of writing the __start_ symbol does not yet have any possible section alignment information. That is the reason for the ALIGN(0) in (1). An expected behaviour would be for ld to put the *ABS* at the address where the section begins, once known or fixup the address. This could arguably be a bug in ld we should fix post-8.0. One possible workaround would be to force the __start_ symbol and the section to be equally aligned and thus on the same address using linker scripts. The drawbacks are that we need to touch the fragile linker scripts for each of the sections we add and for all architectures individually. As the enforcement of alignment would be at a different place to the actual set creation, putting the alignment in might be easily forgotten. The advantage would be that we can always be sure that __start_ would be on the same address where the section starts. Another solution is to put minimum alignment on the objects inside the section in a way that it is only in a single place in the source code. The section directive in the respective header file, that will be included by each implementation file, is the ideal place for this. While cache line alignment seems to be the widest alignment restriction currently in use, one drawback, like with above ldscript solution, is that a symbol could possibly enforce a wider alignment restriction onto the section making the __start_ symbol and the section beginning to diverge again. Example: 0xffffffff8168f700 __start_set_pcpu 0xffffffff8168f800 set_pcpu 0xffffffff8168f800 pcpu_entry_sched_switch_stats .. if we would put an alignment of 1024 on pcpu_entry_sched_switch_stats. This is unlikely to happen. With the minimum alignment, ld, at the time of placing the __start_ symbol, already knows about the section alignment and will place it correctly on the section beginning doing: __start_set_pcpu = ALIGN(CACHE_LINE_SHIFT) at ".". Summary: The minimum alignment seems to be the least-intrusive solution and is believed to work for the moment. In addition documenting that the dpcpu and similar sections will not support super-cache line alignment. The long term solution would be to fix ld to DTRT. ------------------------------------------------------------------------ ! ! Put minimum alignment on the dpcpu and vnet section so that ld ! when adding the __start_ symbol knows the expected section alignment ! and can place the __start_ symbol correctly. ! ! These sections will not support symbols with super-cache line alignment ! requirements. ! ! See posting , 2009-08-10, to freebsd-current for full ! details. ! ! Debugging and testing patches by: ! Kamigishi Rei (spambox haruhiism.net), np, lstewart, jhb, ! kib, rwatson ! Tested by: Kamigishi Rei, lstewart ! Reviewed by: kib ! Approved by: ! Index: sys/sys/pcpu.h =================================================================== --- sys/sys/pcpu.h (revision 196086) +++ sys/sys/pcpu.h (working copy) @@ -56,12 +56,14 @@ extern uintptr_t *__start_set_pcpu; extern uintptr_t *__stop_set_pcpu; +__asm__( #if defined(__arm__) -__asm__(".section set_pcpu, \"aw\", %progbits"); + ".section set_pcpu, \"aw\", %progbits\n" #else -__asm__(".section set_pcpu, \"aw\", @progbits"); + ".section set_pcpu, \"aw\", @progbits\n" #endif -__asm__(".previous"); + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" + "\t.previous"); /* * Array of dynamic pcpu base offsets. Indexed by id. Index: sys/net/vnet.h =================================================================== --- sys/net/vnet.h (revision 196086) +++ sys/net/vnet.h (working copy) @@ -185,12 +185,14 @@ * Virtual network stack memory allocator, which allows global variables to * be automatically instantiated for each network stack instance. */ +__asm__( #if defined(__arm__) -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); + ".section " VNET_SETNAME ", \"aw\", %progbits\n" #else -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); + ".section " VNET_SETNAME ", \"aw\", @progbits\n" #endif -__asm__(".previous"); + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" + "\t.previous"); #define VNET_NAME(n) vnet_entry_##n #define VNET ------------------------------------------------------------------------ -- Bjoern A. Zeeb The greatest risk is not taking one. From saifi.khan at datasynergy.org Mon Aug 10 14:45:12 2009 From: saifi.khan at datasynergy.org (Saifi Khan) Date: Mon Aug 10 14:45:20 2009 Subject: 8.0-CURRENT beta2 AMD64 installation issue Message-ID: Hi all: i'm trying to install, FreeBSD 8.0 beta 2 from disc1 on my AMD64 Athlon X2 box. The complete hardware specs can be seen here http://www.freebsd.org/cgi/query-pr.cgi?pr=www/133262 The issue faced is "installInitial: Couldn't clone the boot floppy into the root filesystem. Aborting" If i use the entire SATA II NCQ disk, this error is not seen, but if i create a partition eg. i'm using a 80GB FreeBSD partition (marked bootable), then this error is seen. Any pointers ? What could i be missing ? thanks Saifi. http://twitter.com/saifikhan From lists at lozenetz.org Mon Aug 10 14:08:00 2009 From: lists at lozenetz.org (Anton - Valqk) Date: Mon Aug 10 15:12:06 2009 Subject: 8.0-BETA2: two kernel lockups in one night In-Reply-To: <200908100807.30269.jhb@freebsd.org> References: <4A787826.5090909@lozenetz.org> <200908100807.30269.jhb@freebsd.org> Message-ID: <4A8029BA.8060509@lozenetz.org> Hi there! Thanks for the answer. I've tested a 7-STABLE system and the benchmarks passed perfectly (I've had a doubt in my hardware)... I've installed 8Beta2 again and got some dumps and lockups again.... If I can help with something (I can give serial+ssh access to this machine with 8Beta2 - it's testing machine at the current moment. Will go in production in a month or so.)? If I can't hope that this bug will get fixed until 8-STABLE (when was the release date planned? sept?) Thanks again and cheers, valqk. John Baldwin wrote: > On Tuesday 04 August 2009 2:04:22 pm Anton - Valqk wrote: > >> Hi group. >> I've installed amd64 8.0-BETA2 distro from iso from official ftp. >> I knew there was a problem with hangs of the system because of disk io >> (and this machine is going to be loaded) and started tesing with bonnie++ >> >> In about 5-6 hours the first lockup came into real. >> Kernel went into dbg console and continue rebooted the system. >> Few hours later bonnie started again - same thing in few hours I got the >> second dump. >> >> This is the bonnie++ opts I've used: >> >> #> bonnie++ -u root -d /usr/test/ -c 10 -s 4098 -n 26000:100000:10:1000 >> -n 2048 -r 4098 -x 10000 -q -Z /dev/urandom > stat.html >> >> and here are links to the txt dumps. >> If someone is interested in the vmcore files let me know. >> http://bg0.eu/core.txt.0 >> http://bg0.eu/core.txt.1 >> >> Are these issues known for 8.0-BETA2? >> > > I don't think these are known issues. I think the two panics may be caused by > the same bug which looks to be a duplicate free() issue in the soft updates > code. > > From ler at lerctr.org Mon Aug 10 15:35:20 2009 From: ler at lerctr.org (Larry Rosenman) Date: Mon Aug 10 15:35:29 2009 Subject: reproducible panic in netisr In-Reply-To: <20090810133111.C93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> Message-ID: On Mon, 10 Aug 2009, Bjoern A. Zeeb wrote: [snip] > > You can fetch the following from .. as well: > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff [snip] I applied this patch to my 2009/08/03 csup checkout, and ran my bacula backup. The backup pre-patch would cause the netisr panic very quickly. With the patch applied, it's on the second host, which is a good sign. Just trying to get feedback in. Please let me know if there is anything else I can supply to help with this. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From rmacklem at uoguelph.ca Mon Aug 10 16:39:14 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Aug 10 16:39:22 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 In-Reply-To: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: On Sun, 9 Aug 2009, Robert Watson wrote: > > It sounds a bit like we would benefit from some directed RPC fuzzing on the > NFS client and server. I wonder if an existing fuzzer could easily be > adapted to generate RPC-like garbage? > It certainly sounds like it would make an interesting project. I vaguely recall Isilon mentioning they had something they used for "hardening" their NFS server. I have no idea what that was (or even if it was them;-), but it would be interesting to have something. CITI at UMich have a Python test suite for NFSv4 and I (again, vaguely:-) recall it does try various kinds of bogus/garbage args. It might be one starting point. Could it qualify as a Google SOC project for next summer? (hint, hint...I haven't got the time to do it.) rick From dillon at apollo.backplane.com Mon Aug 10 17:10:51 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Mon Aug 10 17:10:58 2009 Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: <200908101710.n7AHAkod010285@apollo.backplane.com> There are probably still some improper uses of signed integers for length tests, against lengths being too long. If the unsigned value is (signed)negative, the test doesn't catch it. Look for cases where fxdr_unsigned() is being passed a signed integer cast *OR* is being assigned to a signed integer type. I found a few in DFly but I haven't done a real audit. For example, nfs_serv.c line 2768 in the FreeBSD codebase is one such case: cnt = fxdr_unsigned(int, *tl); if (cnt > xfer) <<< WRONG, cnt and xfer are both signed. ... -Matt From arno at heho.snv.jussieu.fr Mon Aug 10 17:40:12 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Mon Aug 10 17:40:20 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless Message-ID: Hello, I get the following panic when pxebooting a 8.0-BETA2 on a VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable and I defined CPUTYPE?=pentiumpro in make.conf. Let me know what I can provide more as info to get around this. Thanks in advance. Best, Arno ##### OK boot -sv KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000007bde0000 SMAP type=04 base=000000007bee0000 len=0000000000003000 SMAP type=03 base=000000007bee3000 len=000000000000d000 SMAP type=02 base=000000007bef0000 len=0000000000010000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc4c00000 MEMGUARD map limit: 0xc6c01000 MEMGUARD map size: 33558528 (Bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 999896638 Hz CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9bbff Features2=0x4181 VIA Padlock Features=0xffcc real memory = 2079195136 (1982 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) avail memory = 2027855872 (1933 MB) Table 'FACP' at 0x7bee3080 Table 'MCFG' at 0x7bee6ec0 Table 'APIC' at 0x7bee6e40 MADT: Found table at 0x7bee6e40 MP Configuration Table version 1.4 found at 0xc00f1ce0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 bios32: Found BIOS32 Service Directory header at 0xc00f8f70 bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x95d0 pnpbios: Found PnP BIOS data at 0xc00fa110 pnpbios: Entry = f0000:a140 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) ACPI: FACS 0x7bee0000 00040 ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 null: nfslock: pseudo-device random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4b9c000 pa 0x1000 AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 Validation 0 10 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 Validation 0 7 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1106, dev=0x0353, revid=0x11 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x1353, revid=0x00 domain=0, bus=0, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x2353, revid=0x00 domain=0, bus=0, slot=0, func=2 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x3353, revid=0x00 domain=0, bus=0, slot=0, func=3 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x4353, revid=0x00 domain=0, bus=0, slot=0, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x5353, revid=0x00 domain=0, bus=0, slot=0, func=5 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x6353, revid=0x00 domain=0, bus=0, slot=0, func=6 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x7353, revid=0x00 domain=0, bus=0, slot=0, func=7 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x1122, revid=0x11 domain=0, bus=0, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled map[14]: type Memory, range 32, base 0xde000000, size 24, enabled map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x1106, dev=0xc353, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 27 found-> vendor=0x1106, dev=0xe353, revid=0x00 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 31 found-> vendor=0x1106, dev=0xf353, revid=0x00 domain=0, bus=0, slot=3, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.3.INTB pcib0: slot 3 INTB hardwired to IRQ 39 found-> vendor=0x1106, dev=0x5324, revid=0x00 domain=0, bus=0, slot=15, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled pcib0: matched entry for 0.16.INTA pcib0: slot 16 INTA hardwired to IRQ 20 found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled pcib0: matched entry for 0.16.INTB pcib0: slot 16 INTB hardwired to IRQ 22 found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled pcib0: matched entry for 0.16.INTC pcib0: slot 16 INTC hardwired to IRQ 21 found-> vendor=0x1106, dev=0x3104, revid=0x90 domain=0, bus=0, slot=16, func=4 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled pcib0: matched entry for 0.16.INTD pcib0: slot 16 INTD hardwired to IRQ 23 found-> vendor=0x1106, dev=0x8353, revid=0x00 domain=0, bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xa353, revid=0x00 domain=0, bus=0, slot=17, func=7 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0xb353, revid=0x00 domain=0, bus=0, slot=19, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x3288, revid=0x10 domain=0, bus=0, slot=20, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 17 NMI ISA 3c, EISA 0 NMI ... going to debugger [thread pid 0 tid 100000 ] Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) db> ps pid ppid pgrp uid state wmesg wchan cmd 5 0 0 0 RL [xpt_thrd] 4 0 0 0 RL [g_down] 3 0 0 0 RL [g_up] 2 0 0 0 RL [g_event] 12 0 0 0 WL (threaded) intr 100021 I [irq9: acpi0] 100016 I [swi2: cambio] 100014 I [swi6: task queue] 100013 I [swi6: Giant taskq] 100011 I [swi5: +] 100006 I [swi1: netisr 0] 100005 I [swi4: clock] 100004 I [swi3: vm] 11 0 0 0 RL [idle: cpu0] 1 0 0 0 ?L [kernel] 10 0 0 0 RL [audit] 0 0 0 0 RLs (threaded) kernel 100020 RunQ [acpi_task_2] 100019 RunQ [acpi_task_1] 100018 RunQ [acpi_task_0] 100017 RunQ [kqueue taskq] 100012 RunQ [thread taskq] 100010 RunQ [firmware taskq] 100000 Run CPU 0 [swapper] db> where Tracing pid 0 tid 100000 td 0xc0934590 vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc mi_startup() at 0xc05839d6 = mi_startup+0xa6 begin() at 0xc0453005 = begin+0x2c db> From julian at elischer.org Mon Aug 10 17:52:29 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 10 17:52:36 2009 Subject: reproducible panic in netisr In-Reply-To: <20090810133111.C93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> Message-ID: <4A805E5B.5000103@elischer.org> Bjoern A. Zeeb wrote: > > Looking further at the problem you may have already noticed that > the section for the 'master copy' starts at 0xffffffff8168f900 > and that the __start_set_pcpu is outside of that section at > 0xffffffff8168f8e9. > Looking at a section dump from `readelf -S kernel` you would > notice that the __start_set_pcpu directly follows the end of the > previous section. > > The reasons for this are twofold: > (1) ld places the __start_ symbol at '.' (the location counter), > which at that point is at the end of the old section as the new > (set_pcpu) is not yet added with __start_set_pcpu = ALIGN(0). > (2) because we manually define the section, so that it is > writeable, ld at the point of writing the __start_ symbol does > not yet have any possible section alignment information. That > is the reason for the ALIGN(0) in (1). > > An expected behaviour would be for ld to put the *ABS* at the > address where the section begins, once known or fixup the address. > This could arguably be a bug in ld we should fix post-8.0. This is getting closer to the root cause, and thus closer to the "root fix". > > One possible workaround would be to force the __start_ symbol > and the section to be equally aligned and thus on the same address > using linker scripts. The drawbacks are that we need to touch > the fragile linker scripts for each of the sections we add and > for all architectures individually. As the enforcement of alignment > would be at a different place to the actual set creation, putting > the alignment in might be easily forgotten. personally I'd see if there is a way to align the section on a page boundary.. > The advantage would be that we can always be sure that __start_ > would be on the same address where the section starts. that sounds like the preferable answer to me. > > Another solution is to put minimum alignment on the objects inside the > section in a way that it is only in a single place in the source code. > The section directive in the respective header file, that will > be included by each implementation file, is the ideal place for this. > While cache line alignment seems to be the widest alignment > restriction currently in use, one drawback, like with above ldscript > solution, is that a symbol could possibly enforce a wider alignment > restriction onto the section making the __start_ symbol and the > section beginning to diverge again. Example: > 0xffffffff8168f700 __start_set_pcpu > 0xffffffff8168f800 set_pcpu > 0xffffffff8168f800 pcpu_entry_sched_switch_stats > .. > if we would put an alignment of 1024 on pcpu_entry_sched_switch_stats. > This is unlikely to happen. > > With the minimum alignment, ld, at the time of placing the > __start_ symbol, already knows about the section alignment > and will place it correctly on the section beginning doing: > __start_set_pcpu = ALIGN(CACHE_LINE_SHIFT) at ".". > > > Summary: The minimum alignment seems to be the least-intrusive > solution and is believed to work for the moment. In addition > documenting that the dpcpu and similar sections will not support > super-cache line alignment. > The long term solution would be to fix ld to DTRT. > > > ------------------------------------------------------------------------ > ! > ! Put minimum alignment on the dpcpu and vnet section so that ld > ! when adding the __start_ symbol knows the expected section alignment > ! and can place the __start_ symbol correctly. > ! > ! These sections will not support symbols with super-cache line alignment > ! requirements. > ! > ! See posting , 2009-08-10, to freebsd-current for full > ! details. > ! > ! Debugging and testing patches by: > ! Kamigishi Rei (spambox haruhiism.net), np, lstewart, jhb, > ! kib, rwatson > ! Tested by: Kamigishi Rei, lstewart > ! Reviewed by: kib > ! Approved by: ! Index: sys/sys/pcpu.h > =================================================================== > --- sys/sys/pcpu.h (revision 196086) > +++ sys/sys/pcpu.h (working copy) > @@ -56,12 +56,14 @@ > extern uintptr_t *__start_set_pcpu; > extern uintptr_t *__stop_set_pcpu; > > +__asm__( > #if defined(__arm__) > -__asm__(".section set_pcpu, \"aw\", %progbits"); > + ".section set_pcpu, \"aw\", %progbits\n" > #else > -__asm__(".section set_pcpu, \"aw\", @progbits"); > + ".section set_pcpu, \"aw\", @progbits\n" > #endif > -__asm__(".previous"); > + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" > + "\t.previous"); > > /* > * Array of dynamic pcpu base offsets. Indexed by id. > Index: sys/net/vnet.h > =================================================================== > --- sys/net/vnet.h (revision 196086) > +++ sys/net/vnet.h (working copy) > @@ -185,12 +185,14 @@ > * Virtual network stack memory allocator, which allows global > variables to > * be automatically instantiated for each network stack instance. > */ > +__asm__( > #if defined(__arm__) > -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); > + ".section " VNET_SETNAME ", \"aw\", %progbits\n" > #else > -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); > + ".section " VNET_SETNAME ", \"aw\", @progbits\n" > #endif I may be visually impaired but I'm not seeing a reason for the ifdef arm.. > -__asm__(".previous"); > + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" > + "\t.previous"); > > #define VNET_NAME(n) vnet_entry_##n > #define VNET > > ------------------------------------------------------------------------ > From rwatson at FreeBSD.org Mon Aug 10 18:02:11 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Aug 10 18:02:18 2009 Subject: reproducible panic in netisr In-Reply-To: <4A805E5B.5000103@elischer.org> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> Message-ID: On Mon, 10 Aug 2009, Julian Elischer wrote: >> One possible workaround would be to force the __start_ symbol and the >> section to be equally aligned and thus on the same address using linker >> scripts. The drawbacks are that we need to touch the fragile linker >> scripts for each of the sections we add and for all architectures >> individually. As the enforcement of alignment would be at a different >> place to the actual set creation, putting the alignment in might be easily >> forgotten. > > personally I'd see if there is a way to align the section on a page > boundary.. I'm not sure it matters for the master copy, but I believe some (if not all) architecture MD parts already allocate the per-CPU data areas as page-aligned, and we extend the master copy out to a page boundary. That said, it would be worth checking on a run-time kernel to make sure it works out that way in practice. In the future, we'll want the pages allocated to the DPCPU area to be local to the CPU from a NUMA perspective. >> --- sys/net/vnet.h (revision 196086) >> +++ sys/net/vnet.h (working copy) >> @@ -185,12 +185,14 @@ >> * Virtual network stack memory allocator, which allows global variables >> to >> * be automatically instantiated for each network stack instance. >> */ >> +__asm__( >> #if defined(__arm__) >> -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); >> + ".section " VNET_SETNAME ", \"aw\", %progbits\n" >> #else >> -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); >> + ".section " VNET_SETNAME ", \"aw\", @progbits\n" >> #endif > > I may be visually impaired but I'm not seeing a reason for the ifdef arm.. I stared at Jeff's original DPCPU code for a while before I saw it -- it's the "%" vs "@" difference. Robert N M Watson Computer Laboratory University of Cambridge From ohartman at mail.zedat.fu-berlin.de Mon Aug 10 17:44:54 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Mon Aug 10 18:07:02 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> Message-ID: <4A805C92.4060104@mail.zedat.fu-berlin.de> Larry Rosenman wrote: > On Mon, 10 Aug 2009, Bjoern A. Zeeb wrote: > [snip] >> >> You can fetch the following from .. as well: >> http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > [snip] > > I applied this patch to my 2009/08/03 csup checkout, and ran my > bacula backup. The backup pre-patch would cause the netisr panic very > quickly. > > With the patch applied, it's on the second host, which is a good sign. > > Just trying to get feedback in. > > Please let me know if there is anything else I can supply to help with > this. > > LER > Great to hear this, I will test the patch as soon as possible. But it would be rather useful having the svn repository for stable/8 online as soon as possible. Regards, Oliver From zec at icir.org Mon Aug 10 18:29:35 2009 From: zec at icir.org (Marko Zec) Date: Mon Aug 10 18:29:46 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: Message-ID: <200908102002.27320.zec@icir.org> On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. adding this line hint.apic.0.disabled="1" to /boot/device.hints should do the trick when booting BETA2 from a local disk, though I don't know whether and how would pxeboot load the device.hints file. Marko From zec at icir.org Mon Aug 10 18:29:35 2009 From: zec at icir.org (Marko Zec) Date: Mon Aug 10 18:29:47 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: Message-ID: <200908102002.27320.zec@icir.org> On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. adding this line hint.apic.0.disabled="1" to /boot/device.hints should do the trick when booting BETA2 from a local disk, though I don't know whether and how would pxeboot load the device.hints file. Marko From bz at FreeBSD.org Mon Aug 10 18:55:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 10 18:55:15 2009 Subject: reproducible panic in netisr In-Reply-To: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> Message-ID: <20090810181027.E93661@maildrop.int.zabbadoz.net> On Mon, 10 Aug 2009, Robert Watson wrote: > > On Mon, 10 Aug 2009, Julian Elischer wrote: > >>> One possible workaround would be to force the __start_ symbol and the >>> section to be equally aligned and thus on the same address using linker >>> scripts. The drawbacks are that we need to touch the fragile linker >>> scripts for each of the sections we add and for all architectures >>> individually. As the enforcement of alignment would be at a different >>> place to the actual set creation, putting the alignment in might be easily >>> forgotten. >> >> personally I'd see if there is a way to align the section on a page >> boundary.. > > I'm not sure it matters for the master copy, but I believe some (if not all) > architecture MD parts already allocate the per-CPU data areas as > page-aligned, and we extend the master copy out to a page boundary. That > said, it would be worth checking on a run-time kernel to make sure it works > out that way in practice. db> show dpcpu_off dpcpu_off[ 0] = 0x42b100 (+ DPCPU_START = 0xffffffff81002000: aligned) dpcpu_off[ 1] = 0xffffff807f44e100 (+ DPCPU_START = 0xffffff8000025000: aligned) dpcpu_off[ 2] = 0xffffff807f455100 (+ DPCPU_START = 0xffffff800002c000: aligned) dpcpu_off[ 3] = 0xffffff807f45c100 (+ DPCPU_START = 0xffffff8000033000: aligned) dpcpu_off[ 4] = 0xffffff807f463100 (+ DPCPU_START = 0xffffff800003a000: aligned) dpcpu_off[ 5] = 0xffffff807f46a100 (+ DPCPU_START = 0xffffff8000041000: aligned) dpcpu_off[ 6] = 0xffffff807f471100 (+ DPCPU_START = 0xffffff8000048000: aligned) dpcpu_off[ 7] = 0xffffff807f478100 (+ DPCPU_START = 0xffffff800004f000: aligned) Note: you don't have that ddb command. I added that last week to my kernel for debugging. But that's nothing I wouldn't have expected as we are using kmem_alloc() for dpcpu. The more intersting thing would be to see what malloc does for vnet, even if we are memeory multiple of page sizes. An updated show vnets gives: db> show vnets vnet = 0xffffff0005c4ab00 ... vnet_data_mem = 0xffffff8000b00000 vnet_data_base = 0xffffff807ff81f80 vnet = 0xffffff0005c278c0 ... vnet_data_mem = 0xffffff8000ab8000 vnet_data_base = 0xffffff807ff39f80 vnet = 0xffffff0001633dc0 ... vnet_data_mem = 0xffffff8000226000 vnet_data_base = 0xffffff807f6a7f80 So looking at vnet_data_mem this looks good as well:) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From rivanr at gmail.com Mon Aug 10 19:39:59 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Mon Aug 10 19:40:08 2009 Subject: Weird console bug Message-ID: <4A80778B.8090708@gmail.com> I just spotted one weird console bug - it is very easy to reproduce it - it seems if you pipe commands together output of one command has something with console settings (namely width of console) For example, if you start opera (it is convenient since process is in /usr/local... - long path), and then you want to check if opera is running with something like ps -axj | grep opera You will receive different results depending on width on console window (for example, for me no results on normal text mode console, in X it depends on width of console you are executing above command in). From phk at phk.freebsd.dk Mon Aug 10 19:43:25 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Aug 10 19:43:32 2009 Subject: Weird console bug In-Reply-To: Your message of "Mon, 10 Aug 2009 21:39:55 +0200." <4A80778B.8090708@gmail.com> Message-ID: <50679.1249933434@critter.freebsd.dk> In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >ps -axj | grep opera >You will receive different results depending on width on console window >(for example, for me no results on normal text mode console, in X it >depends on width of console you are executing above command in). See the -w option to ps -- 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 rivanr at gmail.com Mon Aug 10 19:50:27 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Mon Aug 10 19:50:34 2009 Subject: Weird console bug In-Reply-To: <50679.1249933434@critter.freebsd.dk> References: <50679.1249933434@critter.freebsd.dk> Message-ID: <4A8079FF.1040007@gmail.com> Poul-Henning Kamp wrote: > In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: > > >> ps -axj | grep opera >> You will receive different results depending on width on console window >> (for example, for me no results on normal text mode console, in X it >> depends on width of console you are executing above command in). >> > > See the -w option to ps > > Thanks, anyway I find this behavior weird when redirecting or piping... From dougb at FreeBSD.org Mon Aug 10 20:03:41 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 10 20:03:50 2009 Subject: Weird console bug In-Reply-To: <4A8079FF.1040007@gmail.com> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> Message-ID: <4A807D12.1000104@FreeBSD.org> Ivan Radovanovic wrote: > Poul-Henning Kamp wrote: >> In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >> >> >>> ps -axj | grep opera >>> You will receive different results depending on width on console >>> window (for example, for me no results on normal text mode console, >>> in X it depends on width of console you are executing above command in). >>> >> >> See the -w option to ps >> >> > > Thanks, anyway I find this behavior weird when redirecting or piping... And how does ps know when it's being redirected or piped? Doug -- This .signature sanitized for your protection From jrh29 at alumni.cwru.edu Mon Aug 10 20:15:24 2009 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Mon Aug 10 20:15:31 2009 Subject: Weird console bug In-Reply-To: <4A807D12.1000104@FreeBSD.org> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> Message-ID: On Mon, Aug 10, 2009 at 4:03 PM, Doug Barton wrote: > Ivan Radovanovic wrote: >> Poul-Henning Kamp wrote: >>> In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >>> >>> >>>> ps -axj | grep opera >>>> You will receive different results depending on width on console >>>> window (for example, for me no results on normal text mode console, >>>> in X it depends on width of console you are executing above command in). >>>> >>> >>> See the -w option to ps >>> >>> >> >> Thanks, anyway I find this behavior weird when redirecting or piping... > > And how does ps know when it's being redirected or piped? > > > Doug > > -- > > ? ?This .signature sanitized for your protection > > _______________________________________________ > 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" > ps could be modified to use isatty(3) to determine if stdout is a tty. Currently if any of the tty ioctls return -1 it assumes a failsafe of 79 column width. This may not be necessary, though, since from the man page, specifying '-w' multiple times will make it use as many columns as necessary. Perhaps this could be the default if not a tty. - Justin From rb at gid.co.uk Mon Aug 10 20:18:57 2009 From: rb at gid.co.uk (Bob Bishop) Date: Mon Aug 10 20:19:04 2009 Subject: Weird console bug In-Reply-To: <4A807D12.1000104@FreeBSD.org> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> Message-ID: <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> Hi, On 10 Aug 2009, at 21:03, Doug Barton wrote: > And how does ps know when it's being redirected or piped? > > > Doug stat(2) its standard output? -- Bob Bishop rb@gid.co.uk From dougb at FreeBSD.org Mon Aug 10 20:27:56 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 10 20:28:03 2009 Subject: Weird console bug In-Reply-To: References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> Message-ID: <4A8082C0.2090200@FreeBSD.org> Justin Hibbits wrote: > ps could be modified to use isatty(3) to determine if stdout is a tty. Great, I look forward to your patch. :) Doug -- This .signature sanitized for your protection From des at des.no Mon Aug 10 20:33:35 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 10 20:33:42 2009 Subject: Weird console bug In-Reply-To: <4A8079FF.1040007@gmail.com> (Ivan Radovanovic's message of "Mon, 10 Aug 2009 21:50:23 +0200") References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> Message-ID: <86r5vja0ja.fsf@ds4.des.no> Ivan Radovanovic writes: > Poul-Henning Kamp writes: > > Ivan Radovanovic writes: > > > ps -axj | grep opera > > > You will receive different results depending on width on console > > > window (for example, for me no results on normal text mode console, > > > in X it depends on width of console you are executing above command > > > in). > > See the -w option to ps > Thanks, anyway I find this behavior weird when redirecting or piping... It's definitely a bug; ps(1) should check isatty(). Please file a PR. DES -- Dag-Erling Sm?rgrav - des@des.no From rivanr at gmail.com Mon Aug 10 20:36:23 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Mon Aug 10 20:36:31 2009 Subject: Weird console bug In-Reply-To: <86r5vja0ja.fsf@ds4.des.no> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <86r5vja0ja.fsf@ds4.des.no> Message-ID: <4A8084C3.7090501@gmail.com> Dag-Erling Sm?rgrav wrote: > Ivan Radovanovic writes: > >> Poul-Henning Kamp writes: >> >>> Ivan Radovanovic writes: >>> >>>> ps -axj | grep opera >>>> You will receive different results depending on width on console >>>> window (for example, for me no results on normal text mode console, >>>> in X it depends on width of console you are executing above command >>>> in). >>>> >>> See the -w option to ps >>> >> Thanks, anyway I find this behavior weird when redirecting or piping... >> > > It's definitely a bug; ps(1) should check isatty(). Please file a PR. > > DES > PR submitted From arno at heho.snv.jussieu.fr Mon Aug 10 21:59:19 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Mon Aug 10 21:59:26 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <200908102002.27320.zec@icir.org> (Marko Zec's message of "Mon\, 10 Aug 2009 20\:02\:27 +0200") References: <200908102002.27320.zec@icir.org> Message-ID: Marko Zec writes: > On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: >> Hello, >> >> I get the following panic when pxebooting a 8.0-BETA2 on a >> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >> and I defined CPUTYPE?=pentiumpro in make.conf. >> >> Let me know what I can provide more as info to get around this. > > adding this line > > hint.apic.0.disabled="1" > > to /boot/device.hints should do the trick when booting BETA2 from a local > disk, though I don't know whether and how would pxeboot load the > device.hints file. yes, this works (in /boot/loader.conf). (though at first sight I completely ignore why, since the panic seems to be in sscanf() of a line in /boot/loader.conf or /boot/device.hints starting with "hint." and I certainly did not have any "hint.apic.*" line in it ) That said, it now panics a bit further (the 'xdr'-bug I vaguely remember from recent days? ) : Adjusted interface vge0 in_scrubprefix: deletion failed Shutdown interface vge1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf000e6fa fault code = supervisor read, page not present instruction pointer = 0x20:0xc07e060b stack pointer = 0x28:0xc0c20940 frame pointer = 0x28:0xc0c20990 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 = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl 0x8(%edx),%eax db> where Tracing pid 0 tid 100000 td 0xc0934590 uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = uma_zalloc_arg+0x7b flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at 0xc0673ffb = flowtable_lookup+0x49b ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = udp_send+0x8e8 sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = sosend_dgram+0x35f sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = krpc_call+0x2ce krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = krpc_portmap+0xb6 bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = bootpc_init+0x19a8 mi_startup() at 0xc05839d6 = mi_startup+0xa6 begin() at 0xc0453005 = begin+0x2c db> Merci & best, Arno From lei_du at yeah.net Tue Aug 11 05:08:44 2009 From: lei_du at yeah.net (lei_du) Date: Tue Aug 11 05:08:51 2009 Subject: Update 8.0beta2. Make kernel error. Message-ID: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> When I update 7.2->8.0. machine_arch is amd64 . make build kernel. Some files is missing. Just why? From edhoprima at gmail.com Tue Aug 11 05:11:30 2009 From: edhoprima at gmail.com (Edho P Arief) Date: Tue Aug 11 05:11:46 2009 Subject: Update 8.0beta2. Make kernel error. In-Reply-To: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> References: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> Message-ID: 2009/8/11 lei_du : > > When I update 7.2->8.0. machine_arch is amd64 . > make build kernel. Some files is missing. > Just why? > _______________________________________________ > 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" > you forgot to paste build log -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From randy at psg.com Tue Aug 11 12:46:11 2009 From: randy at psg.com (Randy Bush) Date: Tue Aug 11 12:47:19 2009 Subject: Build error "am_ET.UTF-8.out: Inappropriate ioctl for device" In-Reply-To: <24477244.post@talk.nabble.com> References: <24477244.post@talk.nabble.com> Message-ID: <20090714105429.GL48776@hoeg.nl> in today's current, i have this much discussed problem while building on FreeBSD ran.psg.com 8.0-BETA1 FreeBSD 8.0-BETA1 #5: Mon Jul 13 06:42:59 UTC 2009 root@ran.psg.com:/usr/obj/usr/src/sys/RAN i386 is there a hack out of the corner? randy From nick at van-laarhoven.org Tue Aug 11 13:05:36 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Aug 11 13:05:48 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090807205817.GA82868@psconsult.nl> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> Message-ID: <200908111449.51779.nick@van-laarhoven.org> > > : > But, after the reboot my system still reboot from the slice 1 (but > > : > the boot loader show correctly that the default choice is now the > > : > 2)! Where is my problem ? > > : > > : Are you sure you're booting from slice 1? > > : Is fstab on slice 2 pointing to slice 1? > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > the last slice you booted from... To mark it active, you must use > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > think John's suggestion is right on the money... Perhaps you could change the line in the update script from boot0cfg -s $oslice $NANO_DRIVE to boot0cfg -s $oslice $NANO_DRIVE echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE That's taken from our own version of the update script, but should fit in the NanoBSD update script. Nick From rwatson at FreeBSD.org Tue Aug 11 14:24:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Aug 11 14:24:09 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: <200908102002.27320.zec@icir.org> Message-ID: On Mon, 10 Aug 2009, Arno J. Klaassen wrote: > That said, it now panics a bit further (the 'xdr'-bug I vaguely > remember from recent days? ) : This is actually believed to be a flowtable bug, and has been spotted by a few people. I think Kip is circulating a bug fix for it. There's not yet a patch in the re@ queue for it. > > Adjusted interface vge0 > in_scrubprefix: deletion failed > Shutdown interface vge1 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xf000e6fa > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07e060b > stack pointer = 0x28:0xc0c20940 > frame pointer = 0x28:0xc0c20990 > 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 = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl > 0x8(%edx),%eax > db> where > Tracing pid 0 tid 100000 td 0xc0934590 > uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = > uma_zalloc_arg+0x7b > flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at > 0xc0673ffb = flowtable_lookup+0x49b > ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea > udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = > udp_send+0x8e8 > sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = > sosend_dgram+0x35f > sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f > krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = > krpc_call+0x2ce > krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = > krpc_portmap+0xb6 > bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = > bootpc_init+0x19a8 > mi_startup() at 0xc05839d6 = mi_startup+0xa6 > begin() at 0xc0453005 = begin+0x2c > db> > > > Merci & best, > > Arno > _______________________________________________ > 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 arno at heho.snv.jussieu.fr Tue Aug 11 14:40:26 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Aug 11 14:40:33 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: (Robert Watson's message of "Tue\, 11 Aug 2009 15\:24\:01 +0100 \(BST\)") References: <200908102002.27320.zec@icir.org> Message-ID: Robert Watson writes: > On Mon, 10 Aug 2009, Arno J. Klaassen wrote: > >> That said, it now panics a bit further (the 'xdr'-bug I vaguely >> remember from recent days? ) : > > This is actually believed to be a flowtable bug, and has been spotted > by a few people. I think Kip is circulating a bug fix for it. > There's not yet a patch in the re@ queue for it. OK, feel free to provide me with a pointer to Kip's fix and I'll be glad to test it (I was positively surpised that this C7 board, small as it is, still has a plain RS232, which makes providing you with debug info fairly easy). Thanx, best regards, Arno >> >> Adjusted interface vge0 >> in_scrubprefix: deletion failed >> Shutdown interface vge1 >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0xf000e6fa >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc07e060b >> stack pointer = 0x28:0xc0c20940 >> frame pointer = 0x28:0xc0c20990 >> 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 = 0 (swapper) >> [thread pid 0 tid 100000 ] >> Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl >> 0x8(%edx),%eax >> db> where >> Tracing pid 0 tid 100000 td 0xc0934590 >> uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = >> uma_zalloc_arg+0x7b >> flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at >> 0xc0673ffb = flowtable_lookup+0x49b >> ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea >> udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = >> udp_send+0x8e8 >> sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = >> sosend_dgram+0x35f >> sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f >> krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = >> krpc_call+0x2ce >> krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = >> krpc_portmap+0xb6 >> bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = >> bootpc_init+0x19a8 >> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >> begin() at 0xc0453005 = begin+0x2c >> db> From ed at 80386.nl Tue Aug 11 15:11:20 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 11 15:11:27 2009 Subject: Weird console bug In-Reply-To: <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> Message-ID: <20090811151118.GF1292@hoeg.nl> * Bob Bishop wrote: > stat(2) its standard output? It is likely that very old versions of isatty(3) called fstat(2) and looked at st_rdev to determine whether it was a TTY. This is indeed to how various related functions like ptsname(3) worked. Nowadays stuff is implemented as follows: - isatty(3) just calls tcgetattr(3), which uses TIOCGETA. - ttyname(3) first calls isatty(3) and then fdevname(), which uses FIODGNAME. - ptsname(3) first uses TIOCPTMASTER to see whether the file descriptor is a pseudo-terminal master and then fdevname(). Which is nice, because everything goes by name and not by device number. For example, ptsname(3) on Linux generates the name by looking at the major/minor number. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090811/7aa09c47/attachment.pgp From rnoland at FreeBSD.org Tue Aug 11 15:25:42 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Aug 11 15:25:50 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: Message-ID: <1250004330.1773.223.camel@balrog.2hip.net> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. I've seen this as well. You can disable apic which I see has been suggested. The NMI seems to be generated by HWPMC_HOOKS, in my case removing it from the GENERIC config allows it to boot and use apic. I'm not certain what the correct fix is, but after talking to jkoshy@ we did find the specific point in the HWPMC_HOOKS code that triggers this, which can be disabled by testing for CPU_VENDOR_CENTAUR. The attached hack should get things booting... robert. > Thanks in advance. > > Best, Arno > > > > ##### > > OK boot -sv > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=000000000009f800 > SMAP type=02 base=000000000009f800 len=0000000000000800 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=000000007bde0000 > SMAP type=04 base=000000007bee0000 len=0000000000003000 > SMAP type=03 base=000000007bee3000 len=000000000000d000 > SMAP type=02 base=000000007bef0000 len=0000000000010000 > SMAP type=02 base=00000000e0000000 len=0000000010000000 > SMAP type=02 base=00000000fec00000 len=0000000000001000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000ffff0000 len=0000000000010000 > Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 > toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: > MEMGUARD map base: 0xc4c00000 > MEMGUARD map limit: 0xc6c01000 > MEMGUARD map size: 33558528 (Bytes) > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 999896638 Hz > CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 > Features=0xa7c9bbff > Features2=0x4181 > VIA Padlock Features=0xffcc > real memory = 2079195136 (1982 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) > avail memory = 2027855872 (1933 MB) > Table 'FACP' at 0x7bee3080 > Table 'MCFG' at 0x7bee6ec0 > Table 'APIC' at 0x7bee6e40 > MADT: Found table at 0x7bee6e40 > MP Configuration Table version 1.4 found at 0xc00f1ce0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > ACPI APIC Table: > APIC: CPU 0 has ACPI ID 0 > bios32: Found BIOS32 Service Directory header at 0xc00f8f70 > bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x95d0 > pnpbios: Found PnP BIOS data at 0xc00fa110 > pnpbios: Entry = f0000:a140 Rev = 1.0 > Other BIOS signatures found: > ULE: setup cpu 0 > ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) > ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) > ACPI: FACS 0x7bee0000 00040 > ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > null: > nfslock: pseudo-device > random: > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > npx0: INT 16 interface > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > pcibios: BIOS version 3.00 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc4b9c000 pa 0x1000 > AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 > AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 > AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 > AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 > AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7bde0000 (3) failed > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 > Validation 0 10 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 > Validation 0 11 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 > Validation 0 7 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 > Validation 0 11 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1106, dev=0x0353, revid=0x11 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x1353, revid=0x00 > domain=0, bus=0, slot=0, func=1 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x2353, revid=0x00 > domain=0, bus=0, slot=0, func=2 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x3353, revid=0x00 > domain=0, bus=0, slot=0, func=3 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x4353, revid=0x00 > domain=0, bus=0, slot=0, func=4 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x5353, revid=0x00 > domain=0, bus=0, slot=0, func=5 > class=08-00-20, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x6353, revid=0x00 > domain=0, bus=0, slot=0, func=6 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x7353, revid=0x00 > domain=0, bus=0, slot=0, func=7 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x1122, revid=0x11 > domain=0, bus=0, slot=1, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 1 message > map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled > map[14]: type Memory, range 32, base 0xde000000, size 24, enabled > map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled > pcib0: matched entry for 0.1.INTA > pcib0: slot 1 INTA hardwired to IRQ 16 > found-> vendor=0x1106, dev=0xc353, revid=0x00 > domain=0, bus=0, slot=2, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 27 > found-> vendor=0x1106, dev=0xe353, revid=0x00 > domain=0, bus=0, slot=3, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 31 > found-> vendor=0x1106, dev=0xf353, revid=0x00 > domain=0, bus=0, slot=3, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.3.INTB > pcib0: slot 3 INTB hardwired to IRQ 39 > found-> vendor=0x1106, dev=0x5324, revid=0x00 > domain=0, bus=0, slot=15, func=0 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled > pcib0: matched entry for 0.16.INTA > pcib0: slot 16 INTA hardwired to IRQ 20 > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled > pcib0: matched entry for 0.16.INTB > pcib0: slot 16 INTB hardwired to IRQ 22 > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=7 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled > pcib0: matched entry for 0.16.INTC > pcib0: slot 16 INTC hardwired to IRQ 21 > found-> vendor=0x1106, dev=0x3104, revid=0x90 > domain=0, bus=0, slot=16, func=4 > class=0c-03-20, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=5 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled > pcib0: matched entry for 0.16.INTD > pcib0: slot 16 INTD hardwired to IRQ 23 > found-> vendor=0x1106, dev=0x8353, revid=0x00 > domain=0, bus=0, slot=17, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > found-> vendor=0x1106, dev=0xa353, revid=0x00 > domain=0, bus=0, slot=17, func=7 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0xb353, revid=0x00 > domain=0, bus=0, slot=19, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x3288, revid=0x10 > domain=0, bus=0, slot=20, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 17 > NMI ISA 3c, EISA 0 > NMI ... going to debugger > [thread pid 0 tid 100000 ] > Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 5 0 0 0 RL [xpt_thrd] > 4 0 0 0 RL [g_down] > 3 0 0 0 RL [g_up] > 2 0 0 0 RL [g_event] > 12 0 0 0 WL (threaded) intr > 100021 I [irq9: acpi0] > 100016 I [swi2: cambio] > 100014 I [swi6: task queue] > 100013 I [swi6: Giant taskq] > 100011 I [swi5: +] > 100006 I [swi1: netisr 0] > 100005 I [swi4: clock] > 100004 I [swi3: vm] > 11 0 0 0 RL [idle: cpu0] > 1 0 0 0 ?L [kernel] > 10 0 0 0 RL [audit] > 0 0 0 0 RLs (threaded) kernel > 100020 RunQ [acpi_task_2] > 100019 RunQ [acpi_task_1] > 100018 RunQ [acpi_task_0] > 100017 RunQ [kqueue taskq] > 100012 RunQ [thread taskq] > 100010 RunQ [firmware taskq] > 100000 Run CPU 0 [swapper] > db> where > Tracing pid 0 tid 100000 td 0xc0934590 > vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f > sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 > res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 > resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a > resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 > devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e > device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f > device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb > device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 > device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 > bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c > device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 > acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 > device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe > device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 > nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e > device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd > bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 > root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 > configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc > mi_startup() at 0xc05839d6 = mi_startup+0xa6 > begin() at 0xc0453005 = begin+0x2c > db> > _______________________________________________ > 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" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: via_pmc_hack.patch Type: text/x-patch Size: 457 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090811/2817846c/via_pmc_hack.bin From arno at heho.snv.jussieu.fr Tue Aug 11 16:27:09 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Aug 11 16:27:20 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <1250004330.1773.223.camel@balrog.2hip.net> (Robert Noland's message of "Tue\, 11 Aug 2009 10\:25\:30 -0500") References: <1250004330.1773.223.camel@balrog.2hip.net> Message-ID: Robert Noland writes: > On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >> Hello, >> >> I get the following panic when pxebooting a 8.0-BETA2 on a >> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >> and I defined CPUTYPE?=pentiumpro in make.conf. >> >> Let me know what I can provide more as info to get around this. > > I've seen this as well. You can disable apic which I see has been > suggested. The NMI seems to be generated by HWPMC_HOOKS, in my case > removing it from the GENERIC config allows it to boot and use apic. I'm > not certain what the correct fix is, but after talking to jkoshy@ we did > find the specific point in the HWPMC_HOOKS code that triggers this, > which can be disabled by testing for CPU_VENDOR_CENTAUR. > > The attached hack should get things booting... Correct. It now boots OK with apic enabled (but still panics at the 'flowtable bug'). Thanks. Arno > robert. > >> Thanks in advance. >> >> Best, Arno >> >> >> >> ##### >> >> OK boot -sv >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> SMAP type=01 base=0000000000000000 len=000000000009f800 >> SMAP type=02 base=000000000009f800 len=0000000000000800 >> SMAP type=02 base=00000000000f0000 len=0000000000010000 >> SMAP type=01 base=0000000000100000 len=000000007bde0000 >> SMAP type=04 base=000000007bee0000 len=0000000000003000 >> SMAP type=03 base=000000007bee3000 len=000000000000d000 >> SMAP type=02 base=000000007bef0000 len=0000000000010000 >> SMAP type=02 base=00000000e0000000 len=0000000010000000 >> SMAP type=02 base=00000000fec00000 len=0000000000001000 >> SMAP type=02 base=00000000fee00000 len=0000000000001000 >> SMAP type=02 base=00000000ffff0000 len=0000000000010000 >> Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >> toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >> WARNING: WITNESS option enabled, expect reduced performance. >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >> MEMGUARD map base: 0xc4c00000 >> MEMGUARD map limit: 0xc6c01000 >> MEMGUARD map size: 33558528 (Bytes) >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Calibrating TSC clock ... TSC clock: 999896638 Hz >> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >> Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 >> Features=0xa7c9bbff >> Features2=0x4181 >> VIA Padlock Features=0xffcc >> real memory = 2079195136 (1982 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) >> avail memory = 2027855872 (1933 MB) >> Table 'FACP' at 0x7bee3080 >> Table 'MCFG' at 0x7bee6ec0 >> Table 'APIC' at 0x7bee6e40 >> MADT: Found table at 0x7bee6e40 >> MP Configuration Table version 1.4 found at 0xc00f1ce0 >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> ACPI APIC Table: >> APIC: CPU 0 has ACPI ID 0 >> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >> bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 >> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >> pnpbios: Found PnP BIOS data at 0xc00fa110 >> pnpbios: Entry = f0000:a140 Rev = 1.0 >> Other BIOS signatures found: >> ULE: setup cpu 0 >> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) >> ACPI: FACS 0x7bee0000 00040 >> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> MADT: Interrupt override: source 9, irq 9 >> ioapic0: intpin 9 trigger: level >> ioapic0: intpin 9 polarity: low >> lapic0: Routing NMI -> LINT1 >> lapic0: LINT1 trigger: edge >> lapic0: LINT1 polarity: high >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> cpu0 BSP: >> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> null: >> nfslock: pseudo-device >> random: >> io: >> kbd: new array size 4 >> kbd1 at kbdmux0 >> mem: >> npx0: INT 16 interface >> acpi0: on motherboard >> PCIe: Memory Mapped configuration base @ 0xe0000000 >> pcibios: BIOS version 3.00 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: [MPSAFE] >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 7bde0000 (3) failed >> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pci_link0: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 6 7 10 11 12 >> Validation 0 10 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link1: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 6 7 10 11 12 >> Validation 0 11 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link2: Index IRQ Rtd Ref IRQs >> Initial Probe 0 7 N 0 3 4 6 7 10 11 12 >> Validation 0 7 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link3: Index IRQ Rtd Ref IRQs >> Initial Probe 0 5 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link4: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link5: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link6: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link7: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 6 7 10 11 12 >> Validation 0 11 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=0, physical bus=0 >> found-> vendor=0x1106, dev=0x0353, revid=0x11 >> domain=0, bus=0, slot=0, func=0 >> class=06-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x1353, revid=0x00 >> domain=0, bus=0, slot=0, func=1 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x2353, revid=0x00 >> domain=0, bus=0, slot=0, func=2 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x3353, revid=0x00 >> domain=0, bus=0, slot=0, func=3 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x4353, revid=0x00 >> domain=0, bus=0, slot=0, func=4 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x5353, revid=0x00 >> domain=0, bus=0, slot=0, func=5 >> class=08-00-20, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x6353, revid=0x00 >> domain=0, bus=0, slot=0, func=6 >> class=06-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x7353, revid=0x00 >> domain=0, bus=0, slot=0, func=7 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x1122, revid=0x11 >> domain=0, bus=0, slot=1, func=0 >> class=03-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> MSI supports 1 message >> map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled >> map[14]: type Memory, range 32, base 0xde000000, size 24, enabled >> map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled >> pcib0: matched entry for 0.1.INTA >> pcib0: slot 1 INTA hardwired to IRQ 16 >> found-> vendor=0x1106, dev=0xc353, revid=0x00 >> domain=0, bus=0, slot=2, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.2.INTA >> pcib0: slot 2 INTA hardwired to IRQ 27 >> found-> vendor=0x1106, dev=0xe353, revid=0x00 >> domain=0, bus=0, slot=3, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.3.INTA >> pcib0: slot 3 INTA hardwired to IRQ 31 >> found-> vendor=0x1106, dev=0xf353, revid=0x00 >> domain=0, bus=0, slot=3, func=1 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.3.INTB >> pcib0: slot 3 INTB hardwired to IRQ 39 >> found-> vendor=0x1106, dev=0x5324, revid=0x00 >> domain=0, bus=0, slot=15, func=0 >> class=01-01-8a, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled >> pcib0: matched entry for 0.16.INTA >> pcib0: slot 16 INTA hardwired to IRQ 20 >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled >> pcib0: matched entry for 0.16.INTB >> pcib0: slot 16 INTB hardwired to IRQ 22 >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=7 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled >> pcib0: matched entry for 0.16.INTC >> pcib0: slot 16 INTC hardwired to IRQ 21 >> found-> vendor=0x1106, dev=0x3104, revid=0x90 >> domain=0, bus=0, slot=16, func=4 >> class=0c-03-20, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=d, irq=5 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled >> pcib0: matched entry for 0.16.INTD >> pcib0: slot 16 INTD hardwired to IRQ 23 >> found-> vendor=0x1106, dev=0x8353, revid=0x00 >> domain=0, bus=0, slot=17, func=0 >> class=06-01-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> found-> vendor=0x1106, dev=0xa353, revid=0x00 >> domain=0, bus=0, slot=17, func=7 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0xb353, revid=0x00 >> domain=0, bus=0, slot=19, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=0 >> cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x3288, revid=0x10 >> domain=0, bus=0, slot=20, func=0 >> class=04-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled >> pcib0: matched entry for 0.20.INTA >> pcib0: slot 20 INTA hardwired to IRQ 17 >> NMI ISA 3c, EISA 0 >> NMI ... going to debugger >> [thread pid 0 tid 100000 ] >> Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) >> db> ps >> pid ppid pgrp uid state wmesg wchan cmd >> 5 0 0 0 RL [xpt_thrd] >> 4 0 0 0 RL [g_down] >> 3 0 0 0 RL [g_up] >> 2 0 0 0 RL [g_event] >> 12 0 0 0 WL (threaded) intr >> 100021 I [irq9: acpi0] >> 100016 I [swi2: cambio] >> 100014 I [swi6: task queue] >> 100013 I [swi6: Giant taskq] >> 100011 I [swi5: +] >> 100006 I [swi1: netisr 0] >> 100005 I [swi4: clock] >> 100004 I [swi3: vm] >> 11 0 0 0 RL [idle: cpu0] >> 1 0 0 0 ?L [kernel] >> 10 0 0 0 RL [audit] >> 0 0 0 0 RLs (threaded) kernel >> 100020 RunQ [acpi_task_2] >> 100019 RunQ [acpi_task_1] >> 100018 RunQ [acpi_task_0] >> 100017 RunQ [kqueue taskq] >> 100012 RunQ [thread taskq] >> 100010 RunQ [firmware taskq] >> 100000 Run CPU 0 [swapper] >> db> where >> Tracing pid 0 tid 100000 td 0xc0934590 >> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f >> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 >> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 >> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a >> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 >> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e >> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f >> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb >> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 >> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 >> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c >> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 >> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 >> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe >> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 >> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e >> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd >> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 >> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 >> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc >> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >> begin() at 0xc0453005 = begin+0x2c >> db> >> _______________________________________________ >> 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" -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From fb-embedded at psconsult.nl Tue Aug 11 15:58:59 2009 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Tue Aug 11 16:40:33 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> Message-ID: <20090811155851.GA50096@psconsult.nl> On Tue, Aug 11, 2009 at 02:49:51PM +0200, Nick Hibma wrote: > > > : > But, after the reboot my system still reboot from the slice 1 (but > > > : > the boot loader show correctly that the default choice is now the > > > : > 2)! Where is my problem ? > > > : > > > : Are you sure you're booting from slice 1? > > > : Is fstab on slice 2 pointing to slice 1? > > > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > > the last slice you booted from... To mark it active, you must use > > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > > think John's suggestion is right on the money... > > Perhaps you could change the line in the update script from > > boot0cfg -s $oslice $NANO_DRIVE > > to > > boot0cfg -s $oslice $NANO_DRIVE > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE boot0cfg -s $oslice $NANO_DRIVE fdisk -f - << ! a $NANO_DRIVE ! is even cheaper 8-> > That's taken from our own version of the update script, but should fit in > the NanoBSD update script. I know how to solve the problem on NanoBSD machines I administer, the bigger picture is that the bootloader (boot0) changed from looking at its own default answer as tuned by boot0cfg -s to looking at the active flags in the MBR record. IMHO this is a regression and a POLA violation. The default action can no longer be "F5 boot from next drive" which is valid and useful on multi-drive servers/desktops. So far nobody has come up with a good reason why this was changed and the change cripples the functionality of boot0cfg, makes NanoBSD no longer work as advertised and will scare off new users (of NanoBSD) to some kind of embedded whatever OS besides FreeBSD. So who wins? > Nick Kind regards, Paul Schenkeveld From shuvaev at physik.uni-wuerzburg.de Tue Aug 11 16:41:22 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Tue Aug 11 16:41:44 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090811155851.GA50096@psconsult.nl> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> <20090811155851.GA50096@psconsult.nl> Message-ID: <20090811164119.GA79544@wep4035.physik.uni-wuerzburg.de> On Tue, Aug 11, 2009 at 05:58:51PM +0200, Paul Schenkeveld wrote: > On Tue, Aug 11, 2009 at 02:49:51PM +0200, Nick Hibma wrote: > > > > : > But, after the reboot my system still reboot from the slice 1 (but > > > > : > the boot loader show correctly that the default choice is now the > > > > : > 2)! Where is my problem ? > > > > : > > > > : Are you sure you're booting from slice 1? > > > > : Is fstab on slice 2 pointing to slice 1? > > > > > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > > > the last slice you booted from... To mark it active, you must use > > > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > > > think John's suggestion is right on the money... > > > > Perhaps you could change the line in the update script from > > > > boot0cfg -s $oslice $NANO_DRIVE > > > > to > > > > boot0cfg -s $oslice $NANO_DRIVE > > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE > > boot0cfg -s $oslice $NANO_DRIVE > fdisk -f - << ! > a $NANO_DRIVE > ! > > is even cheaper 8-> > > > That's taken from our own version of the update script, but should fit in > > the NanoBSD update script. > > I know how to solve the problem on NanoBSD machines I administer, the > bigger picture is that the bootloader (boot0) changed from looking at > its own default answer as tuned by boot0cfg -s to looking at the > active flags in the MBR record. IMHO this is a regression and a POLA > violation. The default action can no longer be "F5 boot from next drive" > which is valid and useful on multi-drive servers/desktops. > > So far nobody has come up with a good reason why this was changed and > the change cripples the functionality of boot0cfg, makes NanoBSD no > longer work as advertised and will scare off new users (of NanoBSD) to > some kind of embedded whatever OS besides FreeBSD. > > So who wins? > A lot of new functionality was brought in. I would suggest going through the history at http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/boot0/boot0.S?view=log and examine which compile-time options are now there. Also you can also try contacting luigi who has touched boot0.S My 0.02$, Alexey. From kmacy at freebsd.org Tue Aug 11 19:35:21 2009 From: kmacy at freebsd.org (Kip Macy) Date: Tue Aug 11 19:35:32 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: <1250004330.1773.223.camel@balrog.2hip.net> Message-ID: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Please try the following patch: http://people.freebsd.org/~kmacy/flowtable_boot.patch On Tue, Aug 11, 2009 at 9:27 AM, Arno J. Klaassen wrote: > > Robert Noland writes: > >> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>> Hello, >>> >>> I get the following panic when pxebooting a 8.0-BETA2 on a >>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>> and I defined CPUTYPE?=pentiumpro in make.conf. >>> >>> Let me know what I can provide more as info to get around this. >> >> I've seen this as well. ?You can disable apic which I see has been >> suggested. ?The NMI seems to be generated by HWPMC_HOOKS, in my case >> removing it from the GENERIC config allows it to boot and use apic. ?I'm >> not certain what the correct fix is, but after talking to jkoshy@ we did >> find the specific point in the HWPMC_HOOKS code that triggers this, >> which can be disabled by testing for CPU_VENDOR_CENTAUR. >> >> The attached hack should get things booting... > > > Correct. It now boots OK with apic enabled (but still panics > at the 'flowtable bug'). > Thanks. > > Arno > > >> robert. >> >>> Thanks in advance. >>> >>> Best, Arno >>> >>> >>> >>> ##### >>> >>> OK boot -sv >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> SMAP type=01 base=0000000000000000 len=000000000009f800 >>> SMAP type=02 base=000000000009f800 len=0000000000000800 >>> SMAP type=02 base=00000000000f0000 len=0000000000010000 >>> SMAP type=01 base=0000000000100000 len=000000007bde0000 >>> SMAP type=04 base=000000007bee0000 len=0000000000003000 >>> SMAP type=03 base=000000007bee3000 len=000000000000d000 >>> SMAP type=02 base=000000007bef0000 len=0000000000010000 >>> SMAP type=02 base=00000000e0000000 len=0000000010000000 >>> SMAP type=02 base=00000000fec00000 len=0000000000001000 >>> SMAP type=02 base=00000000fee00000 len=0000000000001000 >>> SMAP type=02 base=00000000ffff0000 len=0000000000010000 >>> Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>> ? ? toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>> WARNING: WITNESS option enabled, expect reduced performance. >>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>> ? ? ? ? MEMGUARD map base: 0xc4c00000 >>> ? ? ? ? MEMGUARD map limit: 0xc6c01000 >>> ? ? ? ? MEMGUARD map size: 33558528 (Bytes) >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>> ? Origin = "CentaurHauls" ?Id = 0x6d0 ?Stepping = 0 >>> ? Features=0xa7c9bbff >>> ? Features2=0x4181 >>> ? VIA Padlock Features=0xffcc >>> real memory ?= 2079195136 (1982 MB) >>> Physical memory chunk(s): >>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) >>> avail memory = 2027855872 (1933 MB) >>> Table 'FACP' at 0x7bee3080 >>> Table 'MCFG' at 0x7bee6ec0 >>> Table 'APIC' at 0x7bee6e40 >>> MADT: Found table at 0x7bee6e40 >>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>> APIC: Using the MADT enumerator. >>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>> SMP: Added CPU 0 (AP) >>> ACPI APIC Table: >>> APIC: CPU 0 has ACPI ID 0 >>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>> bios32: Entry = 0xf9580 (c00f9580) ?Rev = 0 ?Len = 1 >>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>> pnpbios: Entry = f0000:a140 ?Rev = 1.0 >>> Other BIOS signatures found: >>> ULE: setup cpu 0 >>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 ?AWRDACPI 00001000 MSFT 03000000) >>> ACPI: FACS 0x7bee0000 00040 >>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>> ioapic0: Routing external 8259A's -> intpin 0 >>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>> MADT: Interrupt override: source 0, irq 2 >>> ioapic0: Routing IRQ 0 -> intpin 2 >>> MADT: Interrupt override: source 9, irq 9 >>> ioapic0: intpin 9 trigger: level >>> ioapic0: intpin 9 polarity: low >>> lapic0: Routing NMI -> LINT1 >>> lapic0: LINT1 trigger: edge >>> lapic0: LINT1 polarity: high >>> ioapic0 irqs 0-23 on motherboard >>> ioapic1 irqs 24-47 on motherboard >>> cpu0 BSP: >>> ? ? ?ID: 0x00000000 ? VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >>> ? lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >>> ? timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >>> null: >>> nfslock: pseudo-device >>> random: >>> io: >>> kbd: new array size 4 >>> kbd1 at kbdmux0 >>> mem: >>> npx0: INT 16 interface >>> acpi0: on motherboard >>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>> pcibios: BIOS version 3.00 >>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>> acpi0: [MPSAFE] >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 7bde0000 (3) failed >>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>> pci_link0: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link1: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link2: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link3: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ? ?5 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link4: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link5: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link6: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> pci_link7: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>> acpi_button0: on acpi0 >>> acpi_button1: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pci0: domain=0, physical bus=0 >>> found-> vendor=0x1106, dev=0x0353, revid=0x11 >>> ? ? ? ? domain=0, bus=0, slot=0, func=0 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x1353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=1 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x2353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=2 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x3353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=3 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x4353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=4 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x5353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=5 >>> ? ? ? ? class=08-00-20, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x6353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=6 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x7353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=0, func=7 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x1122, revid=0x11 >>> ? ? ? ? domain=0, bus=0, slot=1, func=0 >>> ? ? ? ? class=03-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=a, irq=10 >>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>> ? ? ? ? MSI supports 1 message >>> ? ? ? ? map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled >>> ? ? ? ? map[14]: type Memory, range 32, base 0xde000000, size 24, enabled >>> ? ? ? ? map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled >>> pcib0: matched entry for 0.1.INTA >>> pcib0: slot 1 INTA hardwired to IRQ 16 >>> found-> vendor=0x1106, dev=0xc353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=2, func=0 >>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=a, irq=11 >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.2.INTA >>> pcib0: slot 2 INTA hardwired to IRQ 27 >>> found-> vendor=0x1106, dev=0xe353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=3, func=0 >>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=a, irq=11 >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.3.INTA >>> pcib0: slot 3 INTA hardwired to IRQ 31 >>> found-> vendor=0x1106, dev=0xf353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=3, func=1 >>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=b, irq=11 >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.3.INTB >>> pcib0: slot 3 INTB hardwired to IRQ 39 >>> found-> vendor=0x1106, dev=0x5324, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=15, func=0 >>> ? ? ? ? class=01-01-8a, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xfc00, size ?4, enabled >>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>> ? ? ? ? domain=0, bus=0, slot=16, func=0 >>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=a, irq=10 >>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf800, size ?5, enabled >>> pcib0: matched entry for 0.16.INTA >>> pcib0: slot 16 INTA hardwired to IRQ 20 >>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>> ? ? ? ? domain=0, bus=0, slot=16, func=1 >>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=b, irq=11 >>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf400, size ?5, enabled >>> pcib0: matched entry for 0.16.INTB >>> pcib0: slot 16 INTB hardwired to IRQ 22 >>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>> ? ? ? ? domain=0, bus=0, slot=16, func=2 >>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=c, irq=7 >>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf000, size ?5, enabled >>> pcib0: matched entry for 0.16.INTC >>> pcib0: slot 16 INTC hardwired to IRQ 21 >>> found-> vendor=0x1106, dev=0x3104, revid=0x90 >>> ? ? ? ? domain=0, bus=0, slot=16, func=4 >>> ? ? ? ? class=0c-03-20, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=d, irq=5 >>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>> ? ? ? ? map[10]: type Memory, range 32, base 0xdffff000, size ?8, enabled >>> pcib0: matched entry for 0.16.INTD >>> pcib0: slot 16 INTD hardwired to IRQ 23 >>> found-> vendor=0x1106, dev=0x8353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=17, func=0 >>> ? ? ? ? class=06-01-00, hdrtype=0x00, mfdev=1 >>> ? ? ? ? cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> found-> vendor=0x1106, dev=0xa353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=17, func=7 >>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0xb353, revid=0x00 >>> ? ? ? ? domain=0, bus=0, slot=19, func=0 >>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>> ? ? ? ? cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x1106, dev=0x3288, revid=0x10 >>> ? ? ? ? domain=0, bus=0, slot=20, func=0 >>> ? ? ? ? class=04-03-00, hdrtype=0x00, mfdev=0 >>> ? ? ? ? cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>> ? ? ? ? intpin=a, irq=10 >>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>> ? ? ? ? MSI supports 1 message, 64 bit >>> ? ? ? ? map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled >>> pcib0: matched entry for 0.20.INTA >>> pcib0: slot 20 INTA hardwired to IRQ 17 >>> NMI ISA 3c, EISA 0 >>> NMI ... going to debugger >>> [thread pid 0 tid 100000 ] >>> Stopped at ? ? ?0xc060098f = vsscanf+0x98f: ? ? movl ? ?%edx,0xfffffe8c(%ebp) >>> db> ps >>> ? pid ?ppid ?pgrp ? uid ? state ? wmesg ? ? wchan ? ?cmd >>> ? ? 5 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[xpt_thrd] >>> ? ? 4 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_down] >>> ? ? 3 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_up] >>> ? ? 2 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_event] >>> ? ?12 ? ? 0 ? ? 0 ? ? 0 ?WL ? ? ?(threaded) ? ? ? ? ?intr >>> 100021 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [irq9: acpi0] >>> 100016 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi2: cambio] >>> 100014 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: task queue] >>> 100013 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: Giant taskq] >>> 100011 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi5: +] >>> 100006 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi1: netisr 0] >>> 100005 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi4: clock] >>> 100004 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi3: vm] >>> ? ?11 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[idle: cpu0] >>> ? ? 1 ? ? 0 ? ? 0 ? ? 0 ??L ? ? ? ? ? ? ? ? ? ? ? ? ?[kernel] >>> ? ?10 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[audit] >>> ? ? 0 ? ? 0 ? ? 0 ? ? 0 ?RLs ? ? (threaded) ? ? ? ? ?kernel >>> 100020 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_2] >>> 100019 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_1] >>> 100018 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_0] >>> 100017 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[kqueue taskq] >>> 100012 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[thread taskq] >>> 100010 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[firmware taskq] >>> 100000 ? ? ? ? ? ? ? ? ? Run ? ? CPU 0 ? ? ? ? ? ? ? [swapper] >>> db> where >>> Tracing pid 0 tid 100000 td 0xc0934590 >>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f >>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 >>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 >>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a >>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 >>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e >>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f >>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb >>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 >>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 >>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 >>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c >>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 >>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 >>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 >>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 >>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe >>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 >>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 >>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e >>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 >>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd >>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 >>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 >>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc >>> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >>> begin() at 0xc0453005 = begin+0x2c >>> db> >>> _______________________________________________ >>> 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" > > -- > > ?Arno J. Klaassen > > ?SCITO S.A. > ?8 rue des Haies > ?F-75020 Paris, France > ?http://scito.com > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From ed at 80386.nl Tue Aug 11 19:52:42 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 11 19:52:49 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Message-ID: <20090811195240.GI1292@hoeg.nl> * Kip Macy wrote: > http://people.freebsd.org/~kmacy/flowtable_boot.patch + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) should probably read: + if (V_flowtable_enable == 0 || V_flowtable_ready == 0) Right? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090811/aaa777ef/attachment.pgp From mike at reifenberger.com Tue Aug 11 21:26:07 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Tue Aug 11 21:26:13 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> Message-ID: On Tue, 11 Aug 2009, Nick Hibma wrote: ... > to > > boot0cfg -s $oslice $NANO_DRIVE > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE > Why not: gpart set -a active -i 1 ${NANO_DRIVE} Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From julian at elischer.org Tue Aug 11 22:21:30 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 11 22:21:38 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <20090811195240.GI1292@hoeg.nl> References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> <20090811195240.GI1292@hoeg.nl> Message-ID: <4A81EEE8.5060405@elischer.org> Ed Schouten wrote: > * Kip Macy wrote: >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) > > should probably read: > > + if (V_flowtable_enable == 0 || V_flowtable_ready == 0) > > Right? > I prefer the first, with an extra closing paren. From kmacy at freebsd.org Tue Aug 11 22:56:23 2009 From: kmacy at freebsd.org (Kip Macy) Date: Tue Aug 11 22:56:30 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <4A81EEE8.5060405@elischer.org> References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> <20090811195240.GI1292@hoeg.nl> <4A81EEE8.5060405@elischer.org> Message-ID: <3c1674c90908111556t683fd2a8r49c1e70341d6dff1@mail.gmail.com> On Tue, Aug 11, 2009 at 3:21 PM, Julian Elischer wrote: > Ed Schouten wrote: >> >> * Kip Macy wrote: >>> >>> http://people.freebsd.org/~kmacy/flowtable_boot.patch >> >> + ? ? ? if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) >> >> should probably read: >> >> + ? ? ? if (V_flowtable_enable == 0 || V_flowtable_ready == 0) >> >> Right? >> > > > I prefer the first, with an extra closing paren. > Oops thanks. I updated the patch. -Kip From scottl at samsco.org Tue Aug 11 23:17:32 2009 From: scottl at samsco.org (Scott Long) Date: Tue Aug 11 23:17:41 2009 Subject: Install from NFS onto NFS fails on amd64 In-Reply-To: References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> Message-ID: <4A81F443.5030905@samsco.org> Rick Macklem wrote: > > > On Thu, 2 Jul 2009, Jilles Tjoelker wrote: > >> >> This could be because of NFS "sillyrename". To avoid some ESTALE errors, >> the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a >> file that is currently in use (in this case, the rm binary). Because the >> renamed file (name typically starts with .nfs) is in the same directory, >> this causes problems when removing directories. Once the file is no >> longer in use, it is finally deleted. >> > Yes, if some file that was in that directory is still open (or mmap'd and > the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" > until the v_usecount goes to 0 and then it's removed, which would explain > it. > >> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it >> is open. >> > Afraid not. NFSv4 has an Open, but it is an open share lock and not a > POSIX style open, so NFSv4 clients still do the silly rename. (ie. The > NFSv4 Remove Op is defined as removing the file and not just unlinking > it and the NFSv4 server isn't required to retain the file after removal > if it is Open'd by a client.) > I'd like to pop this issue back to the top of the stack. Doing an installworld to local disks on a NFS-root system used to be a convenient way to install new systems without requiring release bits and release media. So, this used to work, and now it doesn't. I'd like help in getting to the bottom of this and fixing it. Scott From arno at heho.snv.jussieu.fr Tue Aug 11 23:25:55 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Aug 11 23:26:04 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> (Kip Macy's message of "Tue\, 11 Aug 2009 12\:35\:18 -0700") References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Message-ID: Kip Macy writes: > Please try the following patch: > > http://people.freebsd.org/~kmacy/flowtable_boot.patch yeah, this works over here. Thank you very much. Just for completeness, here is my local patch; apart from the parenthesis issue I also needed to add the #define V_flowtable_ready VNET(flowtable_ready) in order to make it compile Best regards, Arno ### Index: net/flowtable.c =================================================================== --- net/flowtable.c (revision 196087) +++ net/flowtable.c (working copy) @@ -203,8 +203,10 @@ static VNET_DEFINE(int, flowtable_fin_wait_expire) = FIN_WAIT_IDLE; static VNET_DEFINE(int, flowtable_tcp_expire) = TCP_IDLE; static VNET_DEFINE(int, flowtable_nmbflows) = 4096; +static VNET_DEFINE(int, flowtable_ready) = 0; #define V_flowtable_enable VNET(flowtable_enable) +#define V_flowtable_ready VNET(flowtable_ready) #define V_flowtable_hits VNET(flowtable_hits) #define V_flowtable_lookups VNET(flowtable_lookups) #define V_flowtable_misses VNET(flowtable_misses) @@ -345,7 +347,7 @@ struct udphdr *uh; struct sctphdr *sh; - if (V_flowtable_enable == 0) + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0)) return (0); key[1] = key[0] = 0; @@ -799,6 +801,7 @@ NULL, NULL, NULL, NULL, 64, UMA_ZONE_MAXBUCKET); uma_zone_set_max(V_flow_ipv4_zone, V_flowtable_nmbflows); uma_zone_set_max(V_flow_ipv6_zone, V_flowtable_nmbflows); + V_flowtable_ready = 1; } VNET_SYSINIT(flowtable_init, SI_SUB_KTHREAD_INIT, SI_ORDER_ANY, > > > On Tue, Aug 11, 2009 at 9:27 AM, Arno J. > Klaassen wrote: >> >> Robert Noland writes: >> >>> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>>> Hello, >>>> >>>> I get the following panic when pxebooting a 8.0-BETA2 on a >>>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>>> and I defined CPUTYPE?=pentiumpro in make.conf. >>>> >>>> Let me know what I can provide more as info to get around this. >>> >>> I've seen this as well. ?You can disable apic which I see has been >>> suggested. ?The NMI seems to be generated by HWPMC_HOOKS, in my case >>> removing it from the GENERIC config allows it to boot and use apic. ?I'm >>> not certain what the correct fix is, but after talking to jkoshy@ we did >>> find the specific point in the HWPMC_HOOKS code that triggers this, >>> which can be disabled by testing for CPU_VENDOR_CENTAUR. >>> >>> The attached hack should get things booting... >> >> >> Correct. It now boots OK with apic enabled (but still panics >> at the 'flowtable bug'). >> Thanks. >> >> Arno >> >> >>> robert. >>> >>>> Thanks in advance. >>>> >>>> Best, Arno >>>> >>>> >>>> >>>> ##### >>>> >>>> OK boot -sv >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> SMAP type=01 base=0000000000000000 len=000000000009f800 >>>> SMAP type=02 base=000000000009f800 len=0000000000000800 >>>> SMAP type=02 base=00000000000f0000 len=0000000000010000 >>>> SMAP type=01 base=0000000000100000 len=000000007bde0000 >>>> SMAP type=04 base=000000007bee0000 len=0000000000003000 >>>> SMAP type=03 base=000000007bee3000 len=000000000000d000 >>>> SMAP type=02 base=000000007bef0000 len=0000000000010000 >>>> SMAP type=02 base=00000000e0000000 len=0000000010000000 >>>> SMAP type=02 base=00000000fec00000 len=0000000000001000 >>>> SMAP type=02 base=00000000fee00000 len=0000000000001000 >>>> SMAP type=02 base=00000000ffff0000 len=0000000000010000 >>>> Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>>> ? ? toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>>> ? ? ? ? MEMGUARD map base: 0xc4c00000 >>>> ? ? ? ? MEMGUARD map limit: 0xc6c01000 >>>> ? ? ? ? MEMGUARD map size: 33558528 (Bytes) >>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>>> ? Origin = "CentaurHauls" ?Id = 0x6d0 ?Stepping = 0 >>>> ? Features=0xa7c9bbff >>>> ? Features2=0x4181 >>>> ? VIA Padlock Features=0xffcc >>>> real memory ?= 2079195136 (1982 MB) >>>> Physical memory chunk(s): >>>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) >>>> avail memory = 2027855872 (1933 MB) >>>> Table 'FACP' at 0x7bee3080 >>>> Table 'MCFG' at 0x7bee6ec0 >>>> Table 'APIC' at 0x7bee6e40 >>>> MADT: Found table at 0x7bee6e40 >>>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>>> APIC: Using the MADT enumerator. >>>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>>> SMP: Added CPU 0 (AP) >>>> ACPI APIC Table: >>>> APIC: CPU 0 has ACPI ID 0 >>>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>>> bios32: Entry = 0xf9580 (c00f9580) ?Rev = 0 ?Len = 1 >>>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>>> pnpbios: Entry = f0000:a140 ?Rev = 1.0 >>>> Other BIOS signatures found: >>>> ULE: setup cpu 0 >>>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 ?AWRDACPI 00001000 MSFT 03000000) >>>> ACPI: FACS 0x7bee0000 00040 >>>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>>> ioapic0: Routing external 8259A's -> intpin 0 >>>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>>> MADT: Interrupt override: source 0, irq 2 >>>> ioapic0: Routing IRQ 0 -> intpin 2 >>>> MADT: Interrupt override: source 9, irq 9 >>>> ioapic0: intpin 9 trigger: level >>>> ioapic0: intpin 9 polarity: low >>>> lapic0: Routing NMI -> LINT1 >>>> lapic0: LINT1 trigger: edge >>>> lapic0: LINT1 polarity: high >>>> ioapic0 irqs 0-23 on motherboard >>>> ioapic1 irqs 24-47 on motherboard >>>> cpu0 BSP: >>>> ? ? ?ID: 0x00000000 ? VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >>>> ? lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >>>> ? timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >>>> null: >>>> nfslock: pseudo-device >>>> random: >>>> io: >>>> kbd: new array size 4 >>>> kbd1 at kbdmux0 >>>> mem: >>>> npx0: INT 16 interface >>>> acpi0: on motherboard >>>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>>> pcibios: BIOS version 3.00 >>>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>>> acpi0: [MPSAFE] >>>> acpi0: [ITHREAD] >>>> acpi0: Power Button (fixed) >>>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>>> acpi0: reservation of 0, a0000 (3) failed >>>> acpi0: reservation of 100000, 7bde0000 (3) failed >>>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>> pci_link0: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link1: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link2: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link3: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ? ?5 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link4: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link5: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link6: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> pci_link7: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>> acpi_button0: on acpi0 >>>> acpi_button1: on acpi0 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pci0: domain=0, physical bus=0 >>>> found-> vendor=0x1106, dev=0x0353, revid=0x11 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=0 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x1353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=1 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x2353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=2 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x3353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=3 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x4353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=4 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x5353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=5 >>>> ? ? ? ? class=08-00-20, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x6353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=6 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x7353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=0, func=7 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x1122, revid=0x11 >>>> ? ? ? ? domain=0, bus=0, slot=1, func=0 >>>> ? ? ? ? class=03-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=a, irq=10 >>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>> ? ? ? ? MSI supports 1 message >>>> ? ? ? ? map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled >>>> ? ? ? ? map[14]: type Memory, range 32, base 0xde000000, size 24, enabled >>>> ? ? ? ? map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled >>>> pcib0: matched entry for 0.1.INTA >>>> pcib0: slot 1 INTA hardwired to IRQ 16 >>>> found-> vendor=0x1106, dev=0xc353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=2, func=0 >>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=a, irq=11 >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.2.INTA >>>> pcib0: slot 2 INTA hardwired to IRQ 27 >>>> found-> vendor=0x1106, dev=0xe353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=3, func=0 >>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=a, irq=11 >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.3.INTA >>>> pcib0: slot 3 INTA hardwired to IRQ 31 >>>> found-> vendor=0x1106, dev=0xf353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=3, func=1 >>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=b, irq=11 >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.3.INTB >>>> pcib0: slot 3 INTB hardwired to IRQ 39 >>>> found-> vendor=0x1106, dev=0x5324, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=15, func=0 >>>> ? ? ? ? class=01-01-8a, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xfc00, size ?4, enabled >>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>> ? ? ? ? domain=0, bus=0, slot=16, func=0 >>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=a, irq=10 >>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf800, size ?5, enabled >>>> pcib0: matched entry for 0.16.INTA >>>> pcib0: slot 16 INTA hardwired to IRQ 20 >>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>> ? ? ? ? domain=0, bus=0, slot=16, func=1 >>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=b, irq=11 >>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf400, size ?5, enabled >>>> pcib0: matched entry for 0.16.INTB >>>> pcib0: slot 16 INTB hardwired to IRQ 22 >>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>> ? ? ? ? domain=0, bus=0, slot=16, func=2 >>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=c, irq=7 >>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf000, size ?5, enabled >>>> pcib0: matched entry for 0.16.INTC >>>> pcib0: slot 16 INTC hardwired to IRQ 21 >>>> found-> vendor=0x1106, dev=0x3104, revid=0x90 >>>> ? ? ? ? domain=0, bus=0, slot=16, func=4 >>>> ? ? ? ? class=0c-03-20, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=d, irq=5 >>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>> ? ? ? ? map[10]: type Memory, range 32, base 0xdffff000, size ?8, enabled >>>> pcib0: matched entry for 0.16.INTD >>>> pcib0: slot 16 INTD hardwired to IRQ 23 >>>> found-> vendor=0x1106, dev=0x8353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=17, func=0 >>>> ? ? ? ? class=06-01-00, hdrtype=0x00, mfdev=1 >>>> ? ? ? ? cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> found-> vendor=0x1106, dev=0xa353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=17, func=7 >>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0xb353, revid=0x00 >>>> ? ? ? ? domain=0, bus=0, slot=19, func=0 >>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>>> ? ? ? ? cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>> found-> vendor=0x1106, dev=0x3288, revid=0x10 >>>> ? ? ? ? domain=0, bus=0, slot=20, func=0 >>>> ? ? ? ? class=04-03-00, hdrtype=0x00, mfdev=0 >>>> ? ? ? ? cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>> ? ? ? ? intpin=a, irq=10 >>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>> ? ? ? ? MSI supports 1 message, 64 bit >>>> ? ? ? ? map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled >>>> pcib0: matched entry for 0.20.INTA >>>> pcib0: slot 20 INTA hardwired to IRQ 17 >>>> NMI ISA 3c, EISA 0 >>>> NMI ... going to debugger >>>> [thread pid 0 tid 100000 ] >>>> Stopped at ? ? ?0xc060098f = vsscanf+0x98f: ? ? movl ? ?%edx,0xfffffe8c(%ebp) >>>> db> ps >>>> ? pid ?ppid ?pgrp ? uid ? state ? wmesg ? ? wchan ? ?cmd >>>> ? ? 5 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[xpt_thrd] >>>> ? ? 4 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_down] >>>> ? ? 3 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_up] >>>> ? ? 2 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_event] >>>> ? ?12 ? ? 0 ? ? 0 ? ? 0 ?WL ? ? ?(threaded) ? ? ? ? ?intr >>>> 100021 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [irq9: acpi0] >>>> 100016 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi2: cambio] >>>> 100014 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: task queue] >>>> 100013 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: Giant taskq] >>>> 100011 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi5: +] >>>> 100006 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi1: netisr 0] >>>> 100005 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi4: clock] >>>> 100004 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi3: vm] >>>> ? ?11 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[idle: cpu0] >>>> ? ? 1 ? ? 0 ? ? 0 ? ? 0 ??L ? ? ? ? ? ? ? ? ? ? ? ? ?[kernel] >>>> ? ?10 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[audit] >>>> ? ? 0 ? ? 0 ? ? 0 ? ? 0 ?RLs ? ? (threaded) ? ? ? ? ?kernel >>>> 100020 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_2] >>>> 100019 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_1] >>>> 100018 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_0] >>>> 100017 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[kqueue taskq] >>>> 100012 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[thread taskq] >>>> 100010 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[firmware taskq] >>>> 100000 ? ? ? ? ? ? ? ? ? Run ? ? CPU 0 ? ? ? ? ? ? ? [swapper] >>>> db> where >>>> Tracing pid 0 tid 100000 td 0xc0934590 >>>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f >>>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 >>>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 >>>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a >>>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 >>>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e >>>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f >>>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb >>>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 >>>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 >>>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 >>>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c >>>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 >>>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 >>>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 >>>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 >>>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe >>>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 >>>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 >>>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e >>>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 >>>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd >>>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 >>>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 >>>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc >>>> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >>>> begin() at 0xc0453005 = begin+0x2c >>>> db> >>>> _______________________________________________ >>>> 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" >> >> -- >> >> ?Arno J. Klaassen >> >> ?SCITO S.A. >> ?8 rue des Haies >> ?F-75020 Paris, France >> ?http://scito.com >> _______________________________________________ >> 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" >> -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From cjk at home.kreklow.us Tue Aug 11 23:55:09 2009 From: cjk at home.kreklow.us (Collin Kreklow) Date: Tue Aug 11 23:55:16 2009 Subject: LOR wlan0 wi0 In-Reply-To: <20090808134101.44d7d210@vaio> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> Message-ID: <20090811235507.GA33894@srv.home.kreklow.us> On Sat, Aug 08, 2009 at 01:41:01PM -0700, Robert wrote: > > The interface card is old. It shows to be a Netgear MA401. I have > ordered a newer model of the Netgear card. It is a WG511T which is > supposed to have an atheros chipset. I should receive this card in about > a week. I really do not know if any of this is relevant to my problem. > FWIW, I've found the WG511T and it's PCI sibling WG311T to be some of the most stable wireless cards available under FreeBSD. The ath driver is very capable with these cards. I've recently had bad experiences with ipw, wpi, and ral based cards prompting me to pick up a few spare 311s for my AP "just in case." I think you won't be disappointed. - Collin From kmacy at freebsd.org Wed Aug 12 05:07:50 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed Aug 12 05:07:59 2009 Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless In-Reply-To: References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Message-ID: <3c1674c90908112207k7aa4ce4age21ce6538d7e5367@mail.gmail.com> The patch on freefall was updated to have that earlier today. I'll pass it on to re@ Thanks, Kip On Tue, Aug 11, 2009 at 4:25 PM, Arno J. Klaassen wrote: > Kip Macy writes: > >> Please try the following patch: >> >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > yeah, this works over here. Thank you very much. > > Just for completeness, here is my local patch; apart > from the parenthesis issue I also needed to add > the > ?#define V_flowtable_ready VNET(flowtable_ready) > in order to make it compile > > Best regards, > > Arno > > ### > Index: net/flowtable.c > =================================================================== > --- net/flowtable.c ? ? (revision 196087) > +++ net/flowtable.c ? ? (working copy) > @@ -203,8 +203,10 @@ > ?static VNET_DEFINE(int, flowtable_fin_wait_expire) = FIN_WAIT_IDLE; > ?static VNET_DEFINE(int, flowtable_tcp_expire) = TCP_IDLE; > ?static VNET_DEFINE(int, flowtable_nmbflows) = 4096; > +static VNET_DEFINE(int, flowtable_ready) = 0; > > ?#define ? ? ? ?V_flowtable_enable ? ? ? ? ? ? ?VNET(flowtable_enable) > +#define ? ? ? ?V_flowtable_ready ? ? ? ? ? ? ? VNET(flowtable_ready) > ?#define ? ? ? ?V_flowtable_hits ? ? ? ? ? ? ? ?VNET(flowtable_hits) > ?#define ? ? ? ?V_flowtable_lookups ? ? ? ? ? ? VNET(flowtable_lookups) > ?#define ? ? ? ?V_flowtable_misses ? ? ? ? ? ? ?VNET(flowtable_misses) > @@ -345,7 +347,7 @@ > ? ? ? ?struct udphdr *uh; > ? ? ? ?struct sctphdr *sh; > > - ? ? ? if (V_flowtable_enable == 0) > + ? ? ? if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0)) > ? ? ? ? ? ? ? ?return (0); > > ? ? ? ?key[1] = key[0] = 0; > @@ -799,6 +801,7 @@ > ? ? ? ? ? ?NULL, NULL, NULL, NULL, 64, UMA_ZONE_MAXBUCKET); > ? ? ? ?uma_zone_set_max(V_flow_ipv4_zone, V_flowtable_nmbflows); > ? ? ? ?uma_zone_set_max(V_flow_ipv6_zone, V_flowtable_nmbflows); > + ? ? ? V_flowtable_ready = 1; > ?} > > ?VNET_SYSINIT(flowtable_init, SI_SUB_KTHREAD_INIT, SI_ORDER_ANY, > >> >> >> On Tue, Aug 11, 2009 at 9:27 AM, Arno J. >> Klaassen wrote: >>> >>> Robert Noland writes: >>> >>>> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>>>> Hello, >>>>> >>>>> I get the following panic when pxebooting a 8.0-BETA2 on a >>>>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>>>> and I defined CPUTYPE?=pentiumpro in make.conf. >>>>> >>>>> Let me know what I can provide more as info to get around this. >>>> >>>> I've seen this as well. ?You can disable apic which I see has been >>>> suggested. ?The NMI seems to be generated by HWPMC_HOOKS, in my case >>>> removing it from the GENERIC config allows it to boot and use apic. ?I'm >>>> not certain what the correct fix is, but after talking to jkoshy@ we did >>>> find the specific point in the HWPMC_HOOKS code that triggers this, >>>> which can be disabled by testing for CPU_VENDOR_CENTAUR. >>>> >>>> The attached hack should get things booting... >>> >>> >>> Correct. It now boots OK with apic enabled (but still panics >>> at the 'flowtable bug'). >>> Thanks. >>> >>> Arno >>> >>> >>>> robert. >>>> >>>>> Thanks in advance. >>>>> >>>>> Best, Arno >>>>> >>>>> >>>>> >>>>> ##### >>>>> >>>>> OK boot -sv >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> SMAP type=01 base=0000000000000000 len=000000000009f800 >>>>> SMAP type=02 base=000000000009f800 len=0000000000000800 >>>>> SMAP type=02 base=00000000000f0000 len=0000000000010000 >>>>> SMAP type=01 base=0000000000100000 len=000000007bde0000 >>>>> SMAP type=04 base=000000007bee0000 len=0000000000003000 >>>>> SMAP type=03 base=000000007bee3000 len=000000000000d000 >>>>> SMAP type=02 base=000000007bef0000 len=0000000000010000 >>>>> SMAP type=02 base=00000000e0000000 len=0000000010000000 >>>>> SMAP type=02 base=00000000fec00000 len=0000000000001000 >>>>> SMAP type=02 base=00000000fee00000 len=0000000000001000 >>>>> SMAP type=02 base=00000000ffff0000 len=0000000000010000 >>>>> Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>>>> ? ? toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>>>> WARNING: WITNESS option enabled, expect reduced performance. >>>>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>>>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>>>> ? ? ? ? MEMGUARD map base: 0xc4c00000 >>>>> ? ? ? ? MEMGUARD map limit: 0xc6c01000 >>>>> ? ? ? ? MEMGUARD map size: 33558528 (Bytes) >>>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>>>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>>>> ? Origin = "CentaurHauls" ?Id = 0x6d0 ?Stepping = 0 >>>>> ? Features=0xa7c9bbff >>>>> ? Features2=0x4181 >>>>> ? VIA Padlock Features=0xffcc >>>>> real memory ?= 2079195136 (1982 MB) >>>>> Physical memory chunk(s): >>>>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>>>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>>>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) >>>>> avail memory = 2027855872 (1933 MB) >>>>> Table 'FACP' at 0x7bee3080 >>>>> Table 'MCFG' at 0x7bee6ec0 >>>>> Table 'APIC' at 0x7bee6e40 >>>>> MADT: Found table at 0x7bee6e40 >>>>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>>>> APIC: Using the MADT enumerator. >>>>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>>>> SMP: Added CPU 0 (AP) >>>>> ACPI APIC Table: >>>>> APIC: CPU 0 has ACPI ID 0 >>>>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>>>> bios32: Entry = 0xf9580 (c00f9580) ?Rev = 0 ?Len = 1 >>>>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>>>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>>>> pnpbios: Entry = f0000:a140 ?Rev = 1.0 >>>>> Other BIOS signatures found: >>>>> ULE: setup cpu 0 >>>>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>>>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 ?AWRDACPI 00001000 MSFT 03000000) >>>>> ACPI: FACS 0x7bee0000 00040 >>>>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 ?AWRDACPI 42302E31 AWRD 00000000) >>>>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>>>> ioapic0: Routing external 8259A's -> intpin 0 >>>>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>>>> MADT: Interrupt override: source 0, irq 2 >>>>> ioapic0: Routing IRQ 0 -> intpin 2 >>>>> MADT: Interrupt override: source 9, irq 9 >>>>> ioapic0: intpin 9 trigger: level >>>>> ioapic0: intpin 9 polarity: low >>>>> lapic0: Routing NMI -> LINT1 >>>>> lapic0: LINT1 trigger: edge >>>>> lapic0: LINT1 polarity: high >>>>> ioapic0 irqs 0-23 on motherboard >>>>> ioapic1 irqs 24-47 on motherboard >>>>> cpu0 BSP: >>>>> ? ? ?ID: 0x00000000 ? VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >>>>> ? lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >>>>> ? timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >>>>> null: >>>>> nfslock: pseudo-device >>>>> random: >>>>> io: >>>>> kbd: new array size 4 >>>>> kbd1 at kbdmux0 >>>>> mem: >>>>> npx0: INT 16 interface >>>>> acpi0: on motherboard >>>>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>>>> pcibios: BIOS version 3.00 >>>>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>>>> acpi0: [MPSAFE] >>>>> acpi0: [ITHREAD] >>>>> acpi0: Power Button (fixed) >>>>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>>>> acpi0: reservation of 0, a0000 (3) failed >>>>> acpi0: reservation of 100000, 7bde0000 (3) failed >>>>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>> pci_link0: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ? 10 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link1: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link2: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ? ?7 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link3: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ? ?5 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link4: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link5: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link6: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> pci_link7: ? ? ? ?Index ?IRQ ?Rtd ?Ref ?IRQs >>>>> ? Initial Probe ? ? ? 0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? Validation ? ? ? ? ?0 ? 11 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> ? After Disable ? ? ? 0 ?255 ? N ? ? 0 ?3 4 6 7 10 11 12 >>>>> acpi_button0: on acpi0 >>>>> acpi_button1: on acpi0 >>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>> pci0: on pcib0 >>>>> pci0: domain=0, physical bus=0 >>>>> found-> vendor=0x1106, dev=0x0353, revid=0x11 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=0 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x1353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=1 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x2353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=2 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x3353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=3 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x4353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=4 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x5353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=5 >>>>> ? ? ? ? class=08-00-20, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x6353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=6 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x7353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=0, func=7 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x1122, revid=0x11 >>>>> ? ? ? ? domain=0, bus=0, slot=1, func=0 >>>>> ? ? ? ? class=03-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=a, irq=10 >>>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>>> ? ? ? ? MSI supports 1 message >>>>> ? ? ? ? map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled >>>>> ? ? ? ? map[14]: type Memory, range 32, base 0xde000000, size 24, enabled >>>>> ? ? ? ? map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled >>>>> pcib0: matched entry for 0.1.INTA >>>>> pcib0: slot 1 INTA hardwired to IRQ 16 >>>>> found-> vendor=0x1106, dev=0xc353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=2, func=0 >>>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=a, irq=11 >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.2.INTA >>>>> pcib0: slot 2 INTA hardwired to IRQ 27 >>>>> found-> vendor=0x1106, dev=0xe353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=3, func=0 >>>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=a, irq=11 >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.3.INTA >>>>> pcib0: slot 3 INTA hardwired to IRQ 31 >>>>> found-> vendor=0x1106, dev=0xf353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=3, func=1 >>>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=b, irq=11 >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> ? ? ? ? MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.3.INTB >>>>> pcib0: slot 3 INTB hardwired to IRQ 39 >>>>> found-> vendor=0x1106, dev=0x5324, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=15, func=0 >>>>> ? ? ? ? class=01-01-8a, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xfc00, size ?4, enabled >>>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>>> ? ? ? ? domain=0, bus=0, slot=16, func=0 >>>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=a, irq=10 >>>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf800, size ?5, enabled >>>>> pcib0: matched entry for 0.16.INTA >>>>> pcib0: slot 16 INTA hardwired to IRQ 20 >>>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>>> ? ? ? ? domain=0, bus=0, slot=16, func=1 >>>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=b, irq=11 >>>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf400, size ?5, enabled >>>>> pcib0: matched entry for 0.16.INTB >>>>> pcib0: slot 16 INTB hardwired to IRQ 22 >>>>> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >>>>> ? ? ? ? domain=0, bus=0, slot=16, func=2 >>>>> ? ? ? ? class=0c-03-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=c, irq=7 >>>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>>> ? ? ? ? map[20]: type I/O Port, range 32, base 0xf000, size ?5, enabled >>>>> pcib0: matched entry for 0.16.INTC >>>>> pcib0: slot 16 INTC hardwired to IRQ 21 >>>>> found-> vendor=0x1106, dev=0x3104, revid=0x90 >>>>> ? ? ? ? domain=0, bus=0, slot=16, func=4 >>>>> ? ? ? ? class=0c-03-20, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=d, irq=5 >>>>> ? ? ? ? powerspec 2 ?supports D0 D1 D2 D3 ?current D0 >>>>> ? ? ? ? map[10]: type Memory, range 32, base 0xdffff000, size ?8, enabled >>>>> pcib0: matched entry for 0.16.INTD >>>>> pcib0: slot 16 INTD hardwired to IRQ 23 >>>>> found-> vendor=0x1106, dev=0x8353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=17, func=0 >>>>> ? ? ? ? class=06-01-00, hdrtype=0x00, mfdev=1 >>>>> ? ? ? ? cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> found-> vendor=0x1106, dev=0xa353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=17, func=7 >>>>> ? ? ? ? class=06-00-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0xb353, revid=0x00 >>>>> ? ? ? ? domain=0, bus=0, slot=19, func=0 >>>>> ? ? ? ? class=06-04-00, hdrtype=0x01, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >>>>> found-> vendor=0x1106, dev=0x3288, revid=0x10 >>>>> ? ? ? ? domain=0, bus=0, slot=20, func=0 >>>>> ? ? ? ? class=04-03-00, hdrtype=0x00, mfdev=0 >>>>> ? ? ? ? cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >>>>> ? ? ? ? lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >>>>> ? ? ? ? intpin=a, irq=10 >>>>> ? ? ? ? powerspec 2 ?supports D0 D3 ?current D0 >>>>> ? ? ? ? MSI supports 1 message, 64 bit >>>>> ? ? ? ? map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled >>>>> pcib0: matched entry for 0.20.INTA >>>>> pcib0: slot 20 INTA hardwired to IRQ 17 >>>>> NMI ISA 3c, EISA 0 >>>>> NMI ... going to debugger >>>>> [thread pid 0 tid 100000 ] >>>>> Stopped at ? ? ?0xc060098f = vsscanf+0x98f: ? ? movl ? ?%edx,0xfffffe8c(%ebp) >>>>> db> ps >>>>> ? pid ?ppid ?pgrp ? uid ? state ? wmesg ? ? wchan ? ?cmd >>>>> ? ? 5 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[xpt_thrd] >>>>> ? ? 4 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_down] >>>>> ? ? 3 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_up] >>>>> ? ? 2 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[g_event] >>>>> ? ?12 ? ? 0 ? ? 0 ? ? 0 ?WL ? ? ?(threaded) ? ? ? ? ?intr >>>>> 100021 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [irq9: acpi0] >>>>> 100016 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi2: cambio] >>>>> 100014 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: task queue] >>>>> 100013 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi6: Giant taskq] >>>>> 100011 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi5: +] >>>>> 100006 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi1: netisr 0] >>>>> 100005 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi4: clock] >>>>> 100004 ? ? ? ? ? ? ? ? ? I ? ? ? ? ? ? ? ? ? ? ? ? ? [swi3: vm] >>>>> ? ?11 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[idle: cpu0] >>>>> ? ? 1 ? ? 0 ? ? 0 ? ? 0 ??L ? ? ? ? ? ? ? ? ? ? ? ? ?[kernel] >>>>> ? ?10 ? ? 0 ? ? 0 ? ? 0 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?[audit] >>>>> ? ? 0 ? ? 0 ? ? 0 ? ? 0 ?RLs ? ? (threaded) ? ? ? ? ?kernel >>>>> 100020 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_2] >>>>> 100019 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_1] >>>>> 100018 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[acpi_task_0] >>>>> 100017 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[kqueue taskq] >>>>> 100012 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[thread taskq] >>>>> 100010 ? ? ? ? ? ? ? ? ? RunQ ? ? ? ? ? ? ? ? ? ? ? ?[firmware taskq] >>>>> 100000 ? ? ? ? ? ? ? ? ? Run ? ? CPU 0 ? ? ? ? ? ? ? [swapper] >>>>> db> where >>>>> Tracing pid 0 tid 100000 td 0xc0934590 >>>>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f >>>>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 >>>>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 >>>>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a >>>>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 >>>>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e >>>>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f >>>>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb >>>>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 >>>>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 >>>>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 >>>>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c >>>>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 >>>>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>>>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 >>>>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 >>>>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 >>>>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 >>>>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe >>>>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 >>>>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 >>>>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e >>>>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 >>>>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 >>>>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd >>>>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 >>>>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 >>>>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc >>>>> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >>>>> begin() at 0xc0453005 = begin+0x2c >>>>> db> >>>>> _______________________________________________ >>>>> 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" >>> >>> -- >>> >>> ?Arno J. Klaassen >>> >>> ?SCITO S.A. >>> ?8 rue des Haies >>> ?F-75020 Paris, France >>> ?http://scito.com >>> _______________________________________________ >>> 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" >>> > > -- > > ?Arno J. Klaassen > > ?SCITO S.A. > ?8 rue des Haies > ?F-75020 Paris, France > ?http://scito.com > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From rwatson at FreeBSD.org Wed Aug 12 12:29:36 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 12 12:29:43 2009 Subject: Call for regression and performance testing - 8.0 Message-ID: Dear all: As we're approaching 8.0 BETA3, now would be a really good time to start identifying functional and performance regressions from the 7.x series. We've done a mixed job at this in the past, but when it comes to "I'll do better some day", there's no time like the present :-). Some notes: Functional testing We actually have a sizable regression test suite in src/tools/regression -- some of these tools will have broken as a result of 8-CURRENT development, so the first task may be to fix them. The next is to run them on 7-STABLE and 8-CURRENT and decide if things have gotten worse -- or maybe we have a bug to fix in both. Pick the tool of your choice, and give it a spin. More than one person per tool is fine, because that way we get more diverse testing. Performance testing On the performance front, life is always a bit more tricky -- performance testing is a subtle art. However, the most clear lessons are that (a) testing with diverse workloads and diverse environments is extremely important, (b) you should do multiple runs and use ministat(1) to analyze results, and (c) that you want to compare apples with apples -- use the same hardware/configuration wherever possible. Watch out for annoying nits such as partition layout affecting I/O throughput for two different installs on the same disk. Pick something you think is important to you: bytes/sec over TCP on loopback, web hits/sec, NFS ops/sec, disk I/O transactions/sec, and do some comparison between 7.2 and 8.0. If you find improvement -- great! If you find a regression, please start a thread on current@ to help get it diagnosed. And if you want help doing performance measurement for a particular workload that isn't well studied, send some e-mail to performance@ to ask for advice on how best to measure it. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From rdivacky at FreeBSD.org Wed Aug 12 13:02:04 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Aug 12 13:02:10 2009 Subject: Call for regression and performance testing - 8.0 In-Reply-To: References: Message-ID: <20090812125937.GA95810@freebsd.org> > Performance testing > > On the performance front, life is always a bit more tricky -- performance > testing is a subtle art. However, the most clear lessons are that (a) > testing with diverse workloads and diverse environments is extremely > important, (b) you should do multiple runs and use ministat(1) to analyze > results, and (c) that you want to compare apples with apples -- use the > same hardware/configuration wherever possible. Watch out for annoying nits > such as partition layout affecting I/O throughput for two different > installs on the same disk. > > Pick something you think is important to you: bytes/sec over TCP on > loopback, web hits/sec, NFS ops/sec, disk I/O transactions/sec, and do some > comparison between 7.2 and 8.0. If you find improvement -- great! If you > find a regression, please start a thread on current@ to help get it > diagnosed. And if you want help doing performance measurement for a > particular workload that isn't well studied, send some e-mail to > performance@ to ask for advice on how best to measure it. what happened to the performance tracking project? that would ease finding performance regressions... From mexas at bristol.ac.uk Wed Aug 12 13:12:28 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Aug 12 13:12:42 2009 Subject: ia64: port www/kazekahase panic: Inconsistent high FP state Message-ID: <20090812131220.GA1205@mech-cluster241.men.bris.ac.uk> This is a core.txt.0 file, created with db> panic savecore crashinfo ######################## mech-cluster241.men.bris.ac.uk dumped core - see /usr//vmcore.0 Wed 12 Aug 2009 14:05:54 BST FreeBSD mech-cluster241.men.bris.ac.uk 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Wed Aug 12 12:42:09 BST 2009 mexas@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 panic: Inconsistent high FP state 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 "ia64-marcel-freebsd"... GDB can't read core files on this machine. (kgdb) No stack. (kgdb) ------------------------------------------------------------------------ ps -axl Segmentation fault (core dumped) ------------------------------------------------------------------------ vmstat -s 0 cpu context switches 0 device interrupts 0 software interrupts 0 traps 0 system calls 0 kernel threads created 0 fork() calls 0 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 0 vnode pager pageins 0 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 475 pages reactivated 0 copy-on-write faults 0 copy-on-write optimized faults 0 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 0 total VM faults taken 0 pages affected by kernel thread creation 0 pages affected by fork() 0 pages affected by vfork() 0 pages affected by rfork() 1304 pages cached 0 pages freed 0 pages freed by daemon 53749 pages freed by exiting processes 10359 pages active 8144 pages inactive 805 pages in VM cache 12228 pages wired down 975185 pages free 8192 bytes per page 94338 total name lookups cache hits (89% pos + 6% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) filedesc 86 45K - 1352 512,1024 kenv 16 9K - 17 16,32,64,128,8192 kqueue 10 12K - 182 256,2048 proc-args 44 2K - 6814 16,32,64,128,256 CAM XPT 44 17K - 33781 16,32,64,128,256,2048 ithread 62 9K - 62 32,128,256 CAM periph 10 3K - 74 16,32,64,256 PUC 4 1K - 4 32,512 KTRACE 100 13K - 100 128 entropy 1024 64K - 1024 64 linker 35 3K - 57 16,32,64,512 lockf 20 3K - 200 64,128 UART 15 8K - 15 16,512,1024 ip6ndp 4 1K - 4 64,128 temp 222 386K - 4440 16,32,64,128,256,512,1024,2048,4096,8192 devbuf 3651 7491K - 3691 16,32,64,128,512,2048 acpidev 56 4K - 56 64 module 141 18K - 141 128 mtx_pool 2 16K - 2 8192 USBdev 24 10K - 57 64,128,512,1024 USB 21 7K - 21 16,32,64,2048 subproc 196 385K - 1460 512,4096 proc 2 16K - 2 8192 session 28 4K - 44 128 pgrp 36 5K - 157 128 cred 76 12K - 13570 64,256 uidinfo 6 3K - 24 128,2048 plimit 12 3K - 308 256 DEVFS1 135 68K - 139 512 sysctltmp 0 0K - 656 16,32,64,128 sysctloid 1766 87K - 1810 16,32,64,128 sysctl 0 0K - 1355 16,32,64 callout 1 512K - 1 umtx 152 19K - 152 128 p1003.1b 1 1K - 1 16 SWAP 4 2337K - 4 64 DEVFS3 158 40K - 163 256 bus-sc 28 140K - 1041 16,32,64,128,256,512,8192 bus 390 44K - 2395 16,32,64,128,256,512,1024,2048 devstat 12 49K - 12 32,8192 eventhandler 60 5K - 60 64,128 kobj 76 304K - 139 4096 Per-cpu 1 1K - 1 32 DEVFS 13 1K - 14 16,128 rman 78 9K - 90 16,32,128 DEVFSP 0 0K - 33 64 sbuf 0 0K - 947 16,32,64,128,256,512,1024,2048,4096,8192 msdosfs_node 4 1K - 4 256 msdosfs_fat 1 4K - 1 4096 stack 0 0K - 2 256 taskqueue 11 1K - 11 16,32,128 Unitno 7 1K - 17 32,64 msdosfs_mount 1 1K - 1 512 pfs_nodes 20 5K - 20 256 Witness 1 128K - 1 iov 0 0K - 2750 16,64,128,256,512 select 46 6K - 46 128 ioctlops 0 0K - 12889 16,32,64,128,512,1024,2048 msg 4 30K - 4 2048,4096,8192 sem 4 11K - 4 512,1024,8192 shm 2 26K - 3 2048 tty 10 10K - 12 512,1024 pts 5 2K - 5 256 mbuf_tag 0 0K - 1 32 ksem 1 8K - 1 8192 shmfd 1 8K - 1 8192 pcb 32 157K - 186 16,32,128,1024,2048,4096,8192 soname 20 2K - 912 16,32,64,128 acl 0 0K - 2 4096 biobuf 4 8K - 12 2048 vfscache 1 1024K - 1 vfs_hash 1 512K - 1 vnodes 2 1K - 2 256 GEOM 318 52K - 1382 16,32,64,128,256,512,1024,8192 vnodemarker 0 0K - 716 512 mount 99 5K - 142 16,32,64,128,256 ether_multi 20 1K - 22 16,32,64 ifaddr 48 13K - 48 32,64,128,256,512,4096 ifnet 4 7K - 4 128,2048 clone 4 16K - 4 4096 arpcom 2 1K - 2 16 lltable 13 5K - 13 256,512 SCSI sa 1 2K - 26 32,2048,8192 ddb_capture 1 48K - 1 acpica 1431 125K - 414333 16,32,64,128,256,512,1024 acpitask 1 2K - 1 2048 mirror_data 18 6K - 790 64,256,512 routetbl 21 4K - 83 32,64,128,256,512 igmp 3 1K - 3 256 in_multi 3 1K - 3 256 sctp_iter 0 0K - 4 256 sctp_ifn 3 1K - 3 128 sctp_ifa 5 1K - 5 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 4 16 hostcache 1 32K - 1 syncache 1 96K - 1 CAM dev queue 3 1K - 3 128 acpisem 161 21K - 161 128 in6_multi 12 2K - 12 32,256 CAM queue 17 7K - 562 16,32,64,2048 mld 3 1K - 3 128 audit_evclass 172 6K - 211 32 savedino 0 0K -