From randy at psg.com Mon Jun 1 00:26:37 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 00:26:51 2009 Subject: kern/134011: [hang] swap_pager_getswapspace(4): failed In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> Message-ID: and again, but i got a debugger prompt! swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getsw eaatalp trsapp 1a2: pcagee (fault whi3le )in: ke rnfela moidel udcp id s=w a1;p a_pipc aidge = r01_ fagulte vtirtsuawl aaddpresssp = a0x0c d a(ul3t )co:de =f suaperivlisoer rdea datsa,w paagep n_otp paregseernt _ingsterutctisonw paointpers =p 0ax2c0:0exf(ff3fff)ff:80a4eac0 stack pointer = 0x28:0xffffff807a02eab0 frame pointer = 0x28:0xffffff807 a0fa2ielace0 ecod ssegwmeant p =_ bpasae g0xe0,r l_imgite 0txfsfffwfa, tpypes 0px1ab de e=( D1PL6 0), :pr es f1,a illoneg 1d, f3s2 w0, agrapn _1 pproacegsseorr e_flaggs e= tinstewrrauptp esnabpleda, creesum(e,3 )IO:PL =f 0 cesirrelnte pdro s s = w148a (pspa__zipo) a[thread pid 148 tid 100134 ] Stopped at fletcher_2_native+0x20: addq (%rdi),%rcx db> trace Tracing pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- db> alltrace Tracing command nfprofile pid 3400 tid 100316 td 0xffffff0076469000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_getswapspace() at swp_pager_getswapspace+0x34 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_contig_launder() at vm_contig_launder+0x1de zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_read() at dbuf_read+0x1e9 dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x9a dmu_tx_count_write() at dmu_tx_count_write+0x291 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (4, FreeBSD ELF64, write), rip = 0x80088016c, rsp = 0x7fffffffe388, rbp = 0x9 --- Tracing command exim-4.69-3 pid 3375 tid 100300 td 0xffffff0080204000 Tracing command exim-4.69-3 pid 3373 tid 100306 td 0xffffff0076416ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command perl pid 3367 tid 100299 td 0xffffff0080204390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_strategy() at swp_pager_strategy+0x24 swap_pager_getpages() at swap_pager_getpages+0x31f vm_fault() at vm_fault+0x653 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8006dbeca, rsp = 0x7fffffffeb60, rbp = 0x10c1ff8 --- Tracing command exim-4.69-3 pid 3366 tid 100308 td 0xffffff0076416390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command sh pid 3365 tid 100307 td 0xffffff0076416720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9d8, rbp = 0xd25 --- Tracing command cron pid 3364 tid 100161 td 0xffffff0006aeaab0 Tracing command httpd pid 3359 tid 100199 td 0xffffff0006f66720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3358 tid 100287 td 0xffffff0080207390 Tracing command httpd pid 3357 tid 100327 td 0xffffff00148e1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3348 tid 100231 td 0xffffff0076469390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3346 tid 100089 td 0xffffff0006072ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command exim-4.69-3 pid 3345 tid 100304 td 0xffffff0080222720 Tracing command exim-4.69-3 pid 3344 tid 100295 td 0xffffff0080205390 Tracing command exim_tidydb pid 3343 tid 100321 td 0xffffff009a115000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x800d7f8f4, rsp = 0x7fffffffe748, rbp = 0x3000 --- Tracing command sh pid 3341 tid 100297 td 0xffffff0080204ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe678, rbp = 0x8a9 --- Tracing command httpd pid 2331 tid 100069 td 0xffffff0004fb2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command mail pid 2227 tid 100278 td 0xffffff0080223ab0 Tracing command sh pid 2226 tid 100150 td 0xffffff0006b05390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe558, rbp = 0x8a9 --- Tracing command sh pid 2225 tid 100280 td 0xffffff0080223390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe238, rbp = 0x8a9 --- Tracing command sh pid 2218 tid 100274 td 0xffffff0066a07390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command sh pid 2217 tid 100312 td 0xffffff00ce0a7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command cron pid 2216 tid 100185 td 0xffffff0006f70000 Tracing command sshguard pid 2135 tid 100315 td 0xffffff009a114ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80084139c, rsp = 0x7fffffbfef38, rbp = 0x4a231c83 --- Tracing command sshguard pid 2135 tid 100284 td 0xffffff0080222000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe pipe_read() at pipe_read+0x2c4 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x80085e18c, rsp = 0x7fffffffe878, rbp = 0x1 --- Tracing command httpd pid 2104 tid 100285 td 0xffffff0080207ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8052d3480, rsp = 0x7fffffffe8b8, rbp = 0x805bc1218 --- Tracing command httpd pid 1839 tid 100251 td 0xffffff0066a08ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command emacs pid 1647 tid 100290 td 0xffffff0080206720 Tracing command httpd pid 1615 tid 100296 td 0xffffff0080205000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 1612 tid 100298 td 0xffffff0080204720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command bash pid 1466 tid 100232 td 0xffffff005700a390 Tracing command sshd pid 1464 tid 100238 td 0xffffff0066a0f000 Tracing command inet_gethost pid 1455 tid 100277 td 0xffffff005700d720 Tracing command inet_gethost pid 1454 tid 100276 td 0xffffff005700dab0 Tracing command inet_gethost pid 1453 tid 100091 td 0xffffff0006072390 Tracing command inet_gethost pid 1452 tid 100247 td 0xffffff0066a0bab0 Tracing command inet_gethost pid 1451 tid 100275 td 0xffffff0066a07000 Tracing command getty pid 1440 tid 100227 td 0xffffff005700b720 Tracing command getty pid 1439 tid 100244 td 0xffffff0066a0c720 Tracing command getty pid 1438 tid 100248 td 0xffffff0066a0b720 Tracing command getty pid 1437 tid 100166 td 0xffffff000639dab0 Tracing command getty pid 1436 tid 100233 td 0xffffff005700a000 Tracing command getty pid 1435 tid 100240 td 0xffffff0066a0e720 Tracing command getty pid 1434 tid 100246 td 0xffffff0066a0c000 Tracing command getty pid 1433 tid 100245 td 0xffffff0066a0c390 Tracing command getty pid 1432 tid 100243 td 0xffffff0066a0cab0 Tracing command getty pid 1431 tid 100242 td 0xffffff0066a0e000 Tracing command perl5.8.9 pid 1392 tid 100237 td 0xffffff0066a0f390 Tracing command perl5.8.9 pid 1391 tid 100239 td 0xffffff0066a0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800c1fe4c, rsp = 0x7fffffffeb08, rbp = 0x7fffffffeb9c --- Tracing command nfcapd pid 1389 tid 100158 td 0xffffff0006aeb720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command nfcapd pid 1386 tid 100203 td 0xffffff004851a720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command perl5.8.9 pid 1383 tid 100236 td 0xffffff0004fde390 Tracing command perl5.8.9 pid 1382 tid 100230 td 0xffffff005700aab0 Tracing command perl5.8.9 pid 1381 tid 100235 td 0xffffff0048145720 Tracing command httpd pid 1379 tid 100178 td 0xffffff00067feab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9d8, rbp = 0x7fffffffea5c --- Tracing command perl5.8.9 pid 1375 tid 100202 td 0xffffff004851aab0 Tracing command httpd pid 1374 tid 100082 td 0xffffff0004fadab0 Tracing command dhcpd pid 1368 tid 100224 td 0xffffff005700c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007af10c, rsp = 0x7fffffffea38, rbp = 0x8 --- Tracing command cron pid 1357 tid 100229 td 0xffffff005700b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80093739c, rsp = 0x7fffffffeb28, rbp = 0x2c --- Tracing command sshd pid 1347 tid 100228 td 0xffffff005700b390 Tracing command httpd pid 1323 tid 100225 td 0xffffff005700c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80130510c, rsp = 0x7fffffffea48, rbp = 0 --- Tracing command sc_serv pid 1321 tid 100219 td 0xffffff005700d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1320 tid 100218 td 0xffffff005700d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1319 tid 100217 td 0xffffff0006f70720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1318 tid 100216 td 0xffffff0006f70ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1317 tid 100215 td 0xffffff0048162000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1316 tid 100214 td 0xffffff0048162390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1315 tid 100213 td 0xffffff0048162720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1314 tid 100212 td 0xffffff0048162ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1313 tid 100211 td 0xffffff0048422000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1312 tid 100177 td 0xffffff0006f28000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x354ca79c, rbp = 0 --- Tracing command sc_serv pid 1311 tid 100182 td 0xffffff0006b05ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x314cc40c, rbp = 0x7d0 --- Tracing command sc_serv pid 1310 tid 100171 td 0xffffff0006ec9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2d4cc3ec, rbp = 0x2d4cc440 --- Tracing command asterisk pid 1303 tid 100271 td 0xffffff0066a0fab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800e0439c, rsp = 0x7fffff7f1b78, rbp = 0x7fffff7f1c70 --- Tracing command asterisk pid 1303 tid 100267 td 0xffffff00765a9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffff82eea8, rbp = 0 --- Tracing command asterisk pid 1303 tid 100266 td 0xffffff00765aa000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 do_cv_wait() at do_cv_wait+0x57a __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff86be28, rbp = 0x8010060c0 --- Tracing command asterisk pid 1303 tid 100265 td 0xffffff00765aa390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8a8d98, rbp = 0x801006280 --- Tracing command asterisk pid 1303 tid 100264 td 0xffffff00765aa720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8e5d98, rbp = 0x801006440 --- Tracing command asterisk pid 1303 tid 100263 td 0xffffff00765aaab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff922d98, rbp = 0x801006600 --- Tracing command asterisk pid 1303 tid 100262 td 0xffffff00765ab000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff95fd98, rbp = 0x8010067c0 --- Tracing command asterisk pid 1303 tid 100261 td 0xffffff00765ab390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff99cd98, rbp = 0x801006980 --- Tracing command asterisk pid 1303 tid 100260 td 0xffffff00765ab720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff9d9d98, rbp = 0x801006b40 --- Tracing command asterisk pid 1303 tid 100259 td 0xffffff00765abab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa16d98, rbp = 0x801006d00 --- Tracing command asterisk pid 1303 tid 100258 td 0xffffff00765ad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa53d98, rbp = 0x801006ec0 --- Tracing command asterisk pid 1303 tid 100257 td 0xffffff00765ad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa90d98, rbp = 0x801007080 --- Tracing command asterisk pid 1303 tid 100256 td 0xffffff0004fb2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffacdd98, rbp = 0x801007240 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command mysqld pid 1288 tid 100207 td 0xffffff004851a000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffffbfebc8, rbp = 0x801608e40 --- Tracing command mysqld pid 1288 tid 100116 td 0xffffff0006049ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffffffe558, rbp = 0xb --- Tracing command sc_serv pid 1266 tid 100198 td 0xffffff0006f66ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1265 tid 100197 td 0xffffff00480ac000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1264 tid 100186 td 0xffffff00480a8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1263 tid 100187 td 0xffffff00480a8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1262 tid 100196 td 0xffffff00480ac390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1261 tid 100092 td 0xffffff0006072000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1260 tid 100195 td 0xffffff00480ac720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1259 tid 100194 td 0xffffff00480acab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1258 tid 100193 td 0xffffff0006e39000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1257 tid 100192 td 0xffffff0006e39390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1256 tid 100191 td 0xffffff0006e39720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1255 tid 100190 td 0xffffff0006e39ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1254 tid 100189 td 0xffffff00480a8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1253 tid 100188 td 0xffffff00480a8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1252 tid 100078 td 0xffffff0006022390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1251 tid 100179 td 0xffffff00067fe720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1250 tid 100184 td 0xffffff0006f70390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1249 tid 100167 td 0xffffff000639d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1139 tid 100165 td 0xffffff0006aea000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1134 tid 100162 td 0xffffff0006aea720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1129 tid 100100 td 0xffffff0006044000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1124 tid 100121 td 0xffffff00060cf720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1119 tid 100099 td 0xffffff0006044390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1114 tid 100079 td 0xffffff0004fb0000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1109 tid 100098 td 0xffffff0006044720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1104 tid 100153 td 0xffffff0006b04720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1099 tid 100120 td 0xffffff00060cfab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1094 tid 100115 td 0xffffff0006099000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1089 tid 100075 td 0xffffff0004fb0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1084 tid 100074 td 0xffffff0004fb0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1079 tid 100085 td 0xffffff0004fad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1074 tid 100154 td 0xffffff0006b04390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1069 tid 100114 td 0xffffff0006099390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command irrd pid 1058 tid 100102 td 0xffffff000609d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80088e10c, rsp = 0x7fffffffda48, rbp = 0x400 --- Tracing command beam pid 1051 tid 100155 td 0xffffff0006021390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b931ec, rsp = 0x7fffffbfee88, rbp = 0x800f08e40 --- Tracing command beam pid 1051 tid 100093 td 0xffffff000604cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x4e9067, rsp = 0x7fffffffc260, rbp = 0x7fffffffc290 --- Tracing command epmd pid 1049 tid 100117 td 0xffffff0006049720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80096810c, rsp = 0x7fffffffe8c8, rbp = 0x3ff --- Tracing command ntpd pid 999 tid 100086 td 0xffffff0004fad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d4910c, rsp = 0x7fffffffec18, rbp = 0x7fffffffed40 --- Tracing command smartd pid 941 tid 100084 td 0xffffff0006021720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800ca039c, rsp = 0x7fffffffeaa8, rbp = 0x4a231d9b --- Tracing command tac_plus pid 922 tid 100151 td 0xffffff0006b05000 Tracing command md0 pid 853 tid 100090 td 0xffffff0006072720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b md_kthread() at md_kthread+0x15a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f52d40, rbp = 0 --- Tracing command unbound pid 816 tid 100096 td 0xffffff000604c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x44eb53, rsp = 0x7fffffffe408, rbp = 0x80173b650 --- Tracing command syslogd pid 787 tid 100070 td 0xffffff0004fb1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_contig_launder() at vm_contig_launder+0xb5 zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_hold_impl() at dbuf_hold_impl+0x1ea dbuf_hold_level() at dbuf_hold_level+0x1a dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x52 dmu_tx_count_write() at dmu_tx_count_write+0x178 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 writev() at writev+0x41 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (121, FreeBSD ELF64, writev), rip = 0x800834d3c, rsp = 0x7fffffffcaf8, rbp = 0 --- Tracing command devd pid 665 tid 100073 td 0xffffff0004fb1000 Tracing command zil_clean pid 179 tid 100113 td 0xffffff0006099720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc5d40, rbp = 0 --- Tracing command zil_clean pid 178 tid 100083 td 0xffffff0004fad720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f2fd40, rbp = 0 --- Tracing command zil_clean pid 177 tid 100112 td 0xffffff0006099ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc0d40, rbp = 0 --- Tracing command zil_clean pid 176 tid 100111 td 0xffffff000609b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fbbd40, rbp = 0 --- Tracing command zil_clean pid 175 tid 100109 td 0xffffff000609b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb1d40, rbp = 0 --- Tracing command zil_clean pid 174 tid 100080 td 0xffffff0006022000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f20d40, rbp = 0 --- Tracing command zil_clean pid 173 tid 100108 td 0xffffff000609bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079facd40, rbp = 0 --- Tracing command zil_clean pid 172 tid 100104 td 0xffffff000609cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f98d40, rbp = 0 --- Tracing command zil_clean pid 171 tid 100072 td 0xffffff0004fb1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ef8d40, rbp = 0 --- Tracing command zil_clean pid 170 tid 100110 td 0xffffff000609b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb6d40, rbp = 0 --- Tracing command txg_thread_enter pid 168 tid 100107 td 0xffffff000609c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xee spa_sync() at spa_sync+0x355 txg_sync_thread() at txg_sync_thread+0x28f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a07dd40, rbp = 0 --- Tracing command txg_thread_enter pid 167 tid 100106 td 0xffffff000609c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fa2d40, rbp = 0 --- Tracing command vdev:worker ad10s1 pid 166 tid 100105 td 0xffffff000609c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f9dd40, rbp = 0 --- Tracing command vdev:worker ad6s1 pid 165 tid 100077 td 0xffffff0004fb0390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f11d40, rbp = 0 --- Tracing command vdev:worker ad8s2 pid 164 tid 100087 td 0xffffff0006049390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f43d40, rbp = 0 --- Tracing command vdev:worker ad4s2 pid 163 tid 100149 td 0xffffff00060d0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a079d40, rbp = 0 --- Tracing command spa_zio pid 162 tid 100148 td 0xffffff00060d0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a074d40, rbp = 0 --- Tracing command spa_zio pid 161 tid 100147 td 0xffffff0006399000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06fd40, rbp = 0 --- Tracing command spa_zio pid 160 tid 100146 td 0xffffff0006399390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06ad40, rbp = 0 --- Tracing command spa_zio pid 159 tid 100145 td 0xffffff0006399720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a065d40, rbp = 0 --- Tracing command spa_zio pid 158 tid 100144 td 0xffffff0006399ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a060d40, rbp = 0 --- Tracing command spa_zio pid 157 tid 100143 td 0xffffff000639b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a05bd40, rbp = 0 --- Tracing command spa_zio pid 156 tid 100142 td 0xffffff000639b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a056d40, rbp = 0 --- Tracing command spa_zio pid 155 tid 100141 td 0xffffff000639b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a051d40, rbp = 0 --- Tracing command spa_zio pid 154 tid 100140 td 0xffffff000639bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a04cd40, rbp = 0 --- Tracing command spa_zio pid 153 tid 100139 td 0xffffff000639c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a047d40, rbp = 0 --- Tracing command spa_zio pid 152 tid 100138 td 0xffffff000639c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a042d40, rbp = 0 --- Tracing command spa_zio pid 151 tid 100137 td 0xffffff000639c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a03dd40, rbp = 0 --- Tracing command spa_zio pid 150 tid 100136 td 0xffffff000639cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sx_xlock_hard() at _sx_xlock_hard+0x1a7 _sx_xlock() at _sx_xlock+0xc1 dbuf_write_ready() at dbuf_write_ready+0xbf arc_write_ready() at arc_write_ready+0x2c zio_ready() at zio_ready+0x3a zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a038d40, rbp = 0 --- Tracing command spa_zio pid 149 tid 100135 td 0xffffff000639d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a033d40, rbp = 0 --- Tracing command spa_zio pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- Tracing command spa_zio pid 147 tid 100133 td 0xffffff000609d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a029d40, rbp = 0 --- Tracing command spa_zio pid 146 tid 100132 td 0xffffff000609dab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a024d40, rbp = 0 --- Tracing command spa_zio pid 145 tid 100131 td 0xffffff00060c8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01fd40, rbp = 0 --- Tracing command spa_zio pid 144 tid 100130 td 0xffffff00060c8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01ad40, rbp = 0 --- Tracing command spa_zio pid 143 tid 100129 td 0xffffff00060c8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a015d40, rbp = 0 --- Tracing command spa_zio pid 142 tid 100128 td 0xffffff00060c8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a010d40, rbp = 0 --- Tracing command spa_zio pid 141 tid 100127 td 0xffffff00060ca000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a00bd40, rbp = 0 --- Tracing command spa_zio pid 140 tid 100126 td 0xffffff00060ca390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a006d40, rbp = 0 --- Tracing command spa_zio pid 139 tid 100125 td 0xffffff00060ca720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a001d40, rbp = 0 --- Tracing command spa_zio pid 138 tid 100124 td 0xffffff00060caab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ffcd40, rbp = 0 --- Tracing command spa_zio pid 137 tid 100123 td 0xffffff00060cf000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ff7d40, rbp = 0 --- Tracing command flowcleaner pid 44 tid 100068 td 0xffffff0004f0b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 flowtable_cleaner() at flowtable_cleaner+0x13a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077be1d40, rbp = 0 --- Tracing command softdepflush pid 43 tid 100067 td 0xffffff0004f0b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 softdep_flush() at softdep_flush+0x2c0 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bdcd40, rbp = 0 --- Tracing command syncer pid 42 tid 100066 td 0xffffff0004f0b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c sched_sync() at sched_sync+0x4de fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd7d40, rbp = 0 --- Tracing command vnlru pid 41 tid 100065 td 0xffffff0004f0bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vnlru_proc() at vnlru_proc+0x607 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd2d40, rbp = 0 --- Tracing command vaclean pid 40 tid 100064 td 0xffffff0004f0c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c vn_rele_async_cleaner() at vn_rele_async_cleaner+0x119 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bcdd40, rbp = 0 --- Tracing command bufdaemon pid 39 tid 100063 td 0xffffff0004f0c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 buf_daemon() at buf_daemon+0x14a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc8d40, rbp = 0 --- Tracing command pagezero pid 38 tid 100062 td 0xffffff0004f0c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vm_pagezero() at vm_pagezero+0x73 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc3d40, rbp = 0 --- Tracing command vmdaemon pid 37 tid 100061 td 0xffffff0004f0cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bbed40, rbp = 0 --- Tracing command pagedaemon pid 36 tid 100060 td 0xffffff0004f0e000 cpustop_handler() at cpustop_handler+0x3b ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x1b8 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8049f404, rsp = 0xffffffff808e6820, rbp = 0xffffff8077bb94b0 --- DELAY() at DELAY+0x64 ns8250_putc() at ns8250_putc+0x9a uart_cnputc() at uart_cnputc+0x4e cnputc() at cnputc+0x49 putchar() at putchar+0x6a kvprintf() at kvprintf+0x81 vprintf() at vprintf+0x3e printf() at printf+0x67 swp_pager_getswapspace() at swp_pager_getswapspace+0xc7 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_pageout_clean() at vm_pageout_clean+0xfc vm_pageout() at vm_pageout+0x1168 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb9d40, rbp = 0 --- Tracing command g_mirror boot pid 35 tid 100059 td 0xffffff0004f0e390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b g_mirror_worker() at g_mirror_worker+0xb1c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb4d40, rbp = 0 --- Tracing command l2arc_feed_thread pid 34 tid 100058 td 0xffffff0004f0e720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c l2arc_feed_thread() at l2arc_feed_thread+0x169 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bafd40, rbp = 0 --- Tracing command arc_reclaim_thread pid 9 tid 100057 td 0xffffff0004f0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c arc_reclaim_thread() at arc_reclaim_thread+0x2ba fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077baad40, rbp = 0 --- Tracing command usbus4 pid 33 tid 100056 td 0xffffff0004ec6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba5d40, rbp = 0 --- Tracing command usbus4 pid 32 tid 100055 td 0xffffff0004ec6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba0d40, rbp = 0 --- Tracing command usbus4 pid 31 tid 100054 td 0xffffff0004ec6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b9bd40, rbp = 0 --- Tracing command usbus4 pid 30 tid 100053 td 0xffffff0004ee8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b96d40, rbp = 0 --- Tracing command usbus3 pid 29 tid 100052 td 0xffffff0004ee8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b91d40, rbp = 0 --- Tracing command usbus3 pid 28 tid 100051 td 0xffffff0004ee8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b8cd40, rbp = 0 --- Tracing command usbus3 pid 27 tid 100050 td 0xffffff0004ee8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b87d40, rbp = 0 --- Tracing command usbus3 pid 26 tid 100049 td 0xffffff0004ee9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b82d40, rbp = 0 --- Tracing command usbus2 pid 25 tid 100048 td 0xffffff0004ee9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b7dd40, rbp = 0 --- Tracing command usbus2 pid 24 tid 100047 td 0xffffff0004ee9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b78d40, rbp = 0 --- Tracing command usbus2 pid 23 tid 100046 td 0xffffff0004ee9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b73d40, rbp = 0 --- Tracing command usbus2 pid 22 tid 100045 td 0xffffff00015b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b6ed40, rbp = 0 --- Tracing command usbus1 pid 21 tid 100044 td 0xffffff0004ec3000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b69d40, rbp = 0 --- Tracing command usbus1 pid 20 tid 100043 td 0xffffff0004ec3390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b64d40, rbp = 0 --- Tracing command usbus1 pid 19 tid 100042 td 0xffffff0004ec3720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5fd40, rbp = 0 --- Tracing command usbus1 pid 18 tid 100041 td 0xffffff0004ec3ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5ad40, rbp = 0 --- Tracing command usbus0 pid 17 tid 100040 td 0xffffff0004ec4000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b55d40, rbp = 0 --- Tracing command usbus0 pid 16 tid 100039 td 0xffffff0004ec4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b50d40, rbp = 0 --- Tracing command usbus0 pid 15 tid 100038 td 0xffffff0004ec4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b4bd40, rbp = 0 --- Tracing command usbus0 pid 14 tid 100037 td 0xffffff0004ec4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b46d40, rbp = 0 --- Tracing command sctp_iterator pid 8 tid 100036 td 0xffffff0004ec6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b sctp_iterator_thread() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b41d40, rbp = 0 --- Tracing command xpt_thrd pid 7 tid 100020 td 0xffffff0001563000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b xpt_scanner_thread() at xpt_scanner_thread+0x3a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000076d40, rbp = 0 --- Tracing command system_taskq pid 6 tid 100015 td 0xffffff00014d1720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800005dd40, rbp = 0 --- Tracing command system_taskq pid 5 tid 100014 td 0xffffff00014d1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000058d40, rbp = 0 --- Tracing command yarrow pid 13 tid 100013 td 0xffffff00014d2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 random_kthread() at random_kthread+0x1ad fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000053d40, rbp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xffffff00014b6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_down() at g_io_schedule_down+0x250 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000049d40, rbp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xffffff00014b6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_up() at g_io_schedule_up+0x154 g_up_procbody() at g_up_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000044d40, rbp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xffffff00014b6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_event_procbody() at g_event_procbody+0xa1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003fd40, rbp = 0 --- Tracing command intr pid 12 tid 100035 td 0xffffff0001563720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b39d40, rbp = 0 --- Tracing command intr pid 12 tid 100034 td 0xffffff0001563ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100033 td 0xffffff00015b2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075b6fd40, rbp = 0 --- Tracing command intr pid 12 tid 100032 td 0xffffff00015b2390 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100031 td 0xffffff00015b2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xffffff00015b2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807566ad40, rbp = 0 --- Tracing command intr pid 12 tid 100029 td 0xffffff00015b4000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100026 td 0xffffff00014d2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100021 td 0xffffff0001561ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100019 td 0xffffff0001563390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000071d40, rbp = 0 --- Tracing command intr pid 12 tid 100018 td 0xffffff00014c7ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100016 td 0xffffff00014d1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000062d40, rbp = 0 --- Tracing command intr pid 12 tid 100008 td 0xffffff00014c7000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003ad40, rbp = 0 --- Tracing command intr pid 12 tid 100007 td 0xffffff00014c7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000035d40, rbp = 0 --- Tracing command intr pid 12 tid 100006 td 0xffffff00014c7720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000030d40, rbp = 0 --- Tracing command intr pid 12 tid 100005 td 0xffffff00014b4000 fork_trampoline() at fork_trampoline Tracing command idle pid 11 tid 100004 td 0xffffff00014b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000026d40, rbp = 0 --- Tracing command idle pid 11 tid 100003 td 0xffffff00014b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000021d40, rbp = 0 --- Tracing command init pid 1 tid 100002 td 0xffffff00014b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40c62c, rsp = 0x7fffffffe808, rbp = 0x401d40 --- Tracing command audit pid 10 tid 100001 td 0xffffff00014b6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a audit_worker() at audit_worker+0x77 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000017d40, rbp = 0 --- Tracing command kernel pid 0 tid 100028 td 0xffffff00015b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800009ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100027 td 0xffffff00015b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000099d40, rbp = 0 --- Tracing command kernel pid 0 tid 100025 td 0xffffff00014d2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008fd40, rbp = 0 --- Tracing command kernel pid 0 tid 100024 td 0xffffff0001561000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008ad40, rbp = 0 --- Tracing command kernel pid 0 tid 100023 td 0xffffff0001561390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000085d40, rbp = 0 --- Tracing command kernel pid 0 tid 100022 td 0xffffff0001561720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000080d40, rbp = 0 --- Tracing command kernel pid 0 tid 100017 td 0xffffff00014d1000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000067d40, rbp = 0 --- Tracing command kernel pid 0 tid 100012 td 0xffffff00014d2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800004ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100000 td 0xffffffff806d8920 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 scheduler() at scheduler+0x292 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> From randy at psg.com Mon Jun 1 00:29:58 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 00:30:31 2009 Subject: installworld failure In-Reply-To: References: Message-ID: > ===> usr.bin/ee (install) > install -s -o root -g wheel -m 555 ee /usr/bin > cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > gencat:No such file or directory > *** Error code 1 > > Stop in /usr/src/usr.bin/ee. > *** Error code 1 > > Stop in /usr/src/usr.bin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 new cvsup rm -rf /usr/obj no help, repeats randy From kip.macy at gmail.com Mon Jun 1 00:31:46 2009 From: kip.macy at gmail.com (Kip Macy) Date: Mon Jun 1 00:31:56 2009 Subject: kern/134011: [hang] swap_pager_getswapspace(4): failed In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> Message-ID: <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> Are your sources from CVS or svn? The backtrace indicates that you have code that I backed out a little over a week ago. On Sun, May 31, 2009 at 5:26 PM, Randy Bush wrote: > and again, but i got a debugger prompt! swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getsw eaatalp trsapp 1a2: pcagee (fault whi3le )in: ke rnfela moidel udcp id s=w a1;p a_pipc aidge = r01_ fagulte vtirtsuawl aaddpresssp = a0x0c d a(ul3t )co:de =f suaperivlisoer rdea datsa,w paagep n_otp paregseernt _ingsterutctisonw paointpers =p 0ax2c0:0exf(ff3fff)ff:80a4eac0 stack pointer = 0x28:0xffffff807a02eab0 frame pointer = 0x28:0xffffff807 a0fa2ielace0 ecod ssegwmeant p =_ bpasae g0xe0,r l_imgite 0txfsfffwfa, tpypes 0px1ab de e=( D1PL6 0), :pr es f1,a illoneg 1d, f3s2 w0, agrapn _1 pproacegsseorr e_flaggs e= tinstewrrauptp esnabpleda, creesum(e,3 )IO:PL =f 0 cesirrelnte pdro s s = w148a (pspa__zipo) a[thread pid 148 tid 100134 ] Stopped at fletcher_2_native+0x20: addq (%rdi),%rcx db> trace Tracing pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- db> alltrace Tracing command nfprofile pid 3400 tid 100316 td 0xffffff0076469000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_getswapspace() at swp_pager_getswapspace+0x34 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_contig_launder() at vm_contig_launder+0x1de zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_read() at dbuf_read+0x1e9 dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x9a dmu_tx_count_write() at dmu_tx_count_write+0x291 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (4, FreeBSD ELF64, write), rip = 0x80088016c, rsp = 0x7fffffffe388, rbp = 0x9 --- Tracing command exim-4.69-3 pid 3375 tid 100300 td 0xffffff0080204000 Tracing command exim-4.69-3 pid 3373 tid 100306 td 0xffffff0076416ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command perl pid 3367 tid 100299 td 0xffffff0080204390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_strategy() at swp_pager_strategy+0x24 swap_pager_getpages() at swap_pager_getpages+0x31f vm_fault() at vm_fault+0x653 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8006dbeca, rsp = 0x7fffffffeb60, rbp = 0x10c1ff8 --- Tracing command exim-4.69-3 pid 3366 tid 100308 td 0xffffff0076416390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command sh pid 3365 tid 100307 td 0xffffff0076416720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9d8, rbp = 0xd25 --- Tracing command cron pid 3364 tid 100161 td 0xffffff0006aeaab0 Tracing command httpd pid 3359 tid 100199 td 0xffffff0006f66720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3358 tid 100287 td 0xffffff0080207390 Tracing command httpd pid 3357 tid 100327 td 0xffffff00148e1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3348 tid 100231 td 0xffffff0076469390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3346 tid 100089 td 0xffffff0006072ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command exim-4.69-3 pid 3345 tid 100304 td 0xffffff0080222720 Tracing command exim-4.69-3 pid 3344 tid 100295 td 0xffffff0080205390 Tracing command exim_tidydb pid 3343 tid 100321 td 0xffffff009a115000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x800d7f8f4, rsp = 0x7fffffffe748, rbp = 0x3000 --- Tracing command sh pid 3341 tid 100297 td 0xffffff0080204ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe678, rbp = 0x8a9 --- Tracing command httpd pid 2331 tid 100069 td 0xffffff0004fb2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command mail pid 2227 tid 100278 td 0xffffff0080223ab0 Tracing command sh pid 2226 tid 100150 td 0xffffff0006b05390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe558, rbp = 0x8a9 --- Tracing command sh pid 2225 tid 100280 td 0xffffff0080223390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe238, rbp = 0x8a9 --- Tracing command sh pid 2218 tid 100274 td 0xffffff0066a07390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command sh pid 2217 tid 100312 td 0xffffff00ce0a7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command cron pid 2216 tid 100185 td 0xffffff0006f70000 Tracing command sshguard pid 2135 tid 100315 td 0xffffff009a114ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80084139c, rsp = 0x7fffffbfef38, rbp = 0x4a231c83 --- Tracing command sshguard pid 2135 tid 100284 td 0xffffff0080222000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe pipe_read() at pipe_read+0x2c4 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x80085e18c, rsp = 0x7fffffffe878, rbp = 0x1 --- Tracing command httpd pid 2104 tid 100285 td 0xffffff0080207ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8052d3480, rsp = 0x7fffffffe8b8, rbp = 0x805bc1218 --- Tracing command httpd pid 1839 tid 100251 td 0xffffff0066a08ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command emacs pid 1647 tid 100290 td 0xffffff0080206720 Tracing command httpd pid 1615 tid 100296 td 0xffffff0080205000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 1612 tid 100298 td 0xffffff0080204720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command bash pid 1466 tid 100232 td 0xffffff005700a390 Tracing command sshd pid 1464 tid 100238 td 0xffffff0066a0f000 Tracing command inet_gethost pid 1455 tid 100277 td 0xffffff005700d720 Tracing command inet_gethost pid 1454 tid 100276 td 0xffffff005700dab0 Tracing command inet_gethost pid 1453 tid 100091 td 0xffffff0006072390 Tracing command inet_gethost pid 1452 tid 100247 td 0xffffff0066a0bab0 Tracing command inet_gethost pid 1451 tid 100275 td 0xffffff0066a07000 Tracing command getty pid 1440 tid 100227 td 0xffffff005700b720 Tracing command getty pid 1439 tid 100244 td 0xffffff0066a0c720 Tracing command getty pid 1438 tid 100248 td 0xffffff0066a0b720 Tracing command getty pid 1437 tid 100166 td 0xffffff000639dab0 Tracing command getty pid 1436 tid 100233 td 0xffffff005700a000 Tracing command getty pid 1435 tid 100240 td 0xffffff0066a0e720 Tracing command getty pid 1434 tid 100246 td 0xffffff0066a0c000 Tracing command getty pid 1433 tid 100245 td 0xffffff0066a0c390 Tracing command getty pid 1432 tid 100243 td 0xffffff0066a0cab0 Tracing command getty pid 1431 tid 100242 td 0xffffff0066a0e000 Tracing command perl5.8.9 pid 1392 tid 100237 td 0xffffff0066a0f390 Tracing command perl5.8.9 pid 1391 tid 100239 td 0xffffff0066a0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800c1fe4c, rsp = 0x7fffffffeb08, rbp = 0x7fffffffeb9c --- Tracing command nfcapd pid 1389 tid 100158 td 0xffffff0006aeb720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command nfcapd pid 1386 tid 100203 td 0xffffff004851a720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command perl5.8.9 pid 1383 tid 100236 td 0xffffff0004fde390 Tracing command perl5.8.9 pid 1382 tid 100230 td 0xffffff005700aab0 Tracing command perl5.8.9 pid 1381 tid 100235 td 0xffffff0048145720 Tracing command httpd pid 1379 tid 100178 td 0xffffff00067feab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9d8, rbp = 0x7fffffffea5c --- Tracing command perl5.8.9 pid 1375 tid 100202 td 0xffffff004851aab0 Tracing command httpd pid 1374 tid 100082 td 0xffffff0004fadab0 Tracing command dhcpd pid 1368 tid 100224 td 0xffffff005700c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007af10c, rsp = 0x7fffffffea38, rbp = 0x8 --- Tracing command cron pid 1357 tid 100229 td 0xffffff005700b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80093739c, rsp = 0x7fffffffeb28, rbp = 0x2c --- Tracing command sshd pid 1347 tid 100228 td 0xffffff005700b390 Tracing command httpd pid 1323 tid 100225 td 0xffffff005700c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80130510c, rsp = 0x7fffffffea48, rbp = 0 --- Tracing command sc_serv pid 1321 tid 100219 td 0xffffff005700d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1320 tid 100218 td 0xffffff005700d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1319 tid 100217 td 0xffffff0006f70720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1318 tid 100216 td 0xffffff0006f70ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1317 tid 100215 td 0xffffff0048162000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1316 tid 100214 td 0xffffff0048162390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1315 tid 100213 td 0xffffff0048162720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1314 tid 100212 td 0xffffff0048162ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1313 tid 100211 td 0xffffff0048422000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1312 tid 100177 td 0xffffff0006f28000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x354ca79c, rbp = 0 --- Tracing command sc_serv pid 1311 tid 100182 td 0xffffff0006b05ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x314cc40c, rbp = 0x7d0 --- Tracing command sc_serv pid 1310 tid 100171 td 0xffffff0006ec9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2d4cc3ec, rbp = 0x2d4cc440 --- Tracing command asterisk pid 1303 tid 100271 td 0xffffff0066a0fab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800e0439c, rsp = 0x7fffff7f1b78, rbp = 0x7fffff7f1c70 --- Tracing command asterisk pid 1303 tid 100267 td 0xffffff00765a9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffff82eea8, rbp = 0 --- Tracing command asterisk pid 1303 tid 100266 td 0xffffff00765aa000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 do_cv_wait() at do_cv_wait+0x57a __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff86be28, rbp = 0x8010060c0 --- Tracing command asterisk pid 1303 tid 100265 td 0xffffff00765aa390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8a8d98, rbp = 0x801006280 --- Tracing command asterisk pid 1303 tid 100264 td 0xffffff00765aa720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8e5d98, rbp = 0x801006440 --- Tracing command asterisk pid 1303 tid 100263 td 0xffffff00765aaab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff922d98, rbp = 0x801006600 --- Tracing command asterisk pid 1303 tid 100262 td 0xffffff00765ab000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff95fd98, rbp = 0x8010067c0 --- Tracing command asterisk pid 1303 tid 100261 td 0xffffff00765ab390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff99cd98, rbp = 0x801006980 --- Tracing command asterisk pid 1303 tid 100260 td 0xffffff00765ab720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff9d9d98, rbp = 0x801006b40 --- Tracing command asterisk pid 1303 tid 100259 td 0xffffff00765abab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa16d98, rbp = 0x801006d00 --- Tracing command asterisk pid 1303 tid 100258 td 0xffffff00765ad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa53d98, rbp = 0x801006ec0 --- Tracing command asterisk pid 1303 tid 100257 td 0xffffff00765ad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa90d98, rbp = 0x801007080 --- Tracing command asterisk pid 1303 tid 100256 td 0xffffff0004fb2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffacdd98, rbp = 0x801007240 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command mysqld pid 1288 tid 100207 td 0xffffff004851a000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffffbfebc8, rbp = 0x801608e40 --- Tracing command mysqld pid 1288 tid 100116 td 0xffffff0006049ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffffffe558, rbp = 0xb --- Tracing command sc_serv pid 1266 tid 100198 td 0xffffff0006f66ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1265 tid 100197 td 0xffffff00480ac000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1264 tid 100186 td 0xffffff00480a8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1263 tid 100187 td 0xffffff00480a8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1262 tid 100196 td 0xffffff00480ac390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1261 tid 100092 td 0xffffff0006072000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1260 tid 100195 td 0xffffff00480ac720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1259 tid 100194 td 0xffffff00480acab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1258 tid 100193 td 0xffffff0006e39000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1257 tid 100192 td 0xffffff0006e39390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1256 tid 100191 td 0xffffff0006e39720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1255 tid 100190 td 0xffffff0006e39ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1254 tid 100189 td 0xffffff00480a8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1253 tid 100188 td 0xffffff00480a8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1252 tid 100078 td 0xffffff0006022390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1251 tid 100179 td 0xffffff00067fe720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1250 tid 100184 td 0xffffff0006f70390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1249 tid 100167 td 0xffffff000639d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1139 tid 100165 td 0xffffff0006aea000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1134 tid 100162 td 0xffffff0006aea720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1129 tid 100100 td 0xffffff0006044000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1124 tid 100121 td 0xffffff00060cf720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1119 tid 100099 td 0xffffff0006044390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1114 tid 100079 td 0xffffff0004fb0000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1109 tid 100098 td 0xffffff0006044720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1104 tid 100153 td 0xffffff0006b04720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1099 tid 100120 td 0xffffff00060cfab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1094 tid 100115 td 0xffffff0006099000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1089 tid 100075 td 0xffffff0004fb0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1084 tid 100074 td 0xffffff0004fb0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1079 tid 100085 td 0xffffff0004fad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1074 tid 100154 td 0xffffff0006b04390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1069 tid 100114 td 0xffffff0006099390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command irrd pid 1058 tid 100102 td 0xffffff000609d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80088e10c, rsp = 0x7fffffffda48, rbp = 0x400 --- Tracing command beam pid 1051 tid 100155 td 0xffffff0006021390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b931ec, rsp = 0x7fffffbfee88, rbp = 0x800f08e40 --- Tracing command beam pid 1051 tid 100093 td 0xffffff000604cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x4e9067, rsp = 0x7fffffffc260, rbp = 0x7fffffffc290 --- Tracing command epmd pid 1049 tid 100117 td 0xffffff0006049720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80096810c, rsp = 0x7fffffffe8c8, rbp = 0x3ff --- Tracing command ntpd pid 999 tid 100086 td 0xffffff0004fad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d4910c, rsp = 0x7fffffffec18, rbp = 0x7fffffffed40 --- Tracing command smartd pid 941 tid 100084 td 0xffffff0006021720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800ca039c, rsp = 0x7fffffffeaa8, rbp = 0x4a231d9b --- Tracing command tac_plus pid 922 tid 100151 td 0xffffff0006b05000 Tracing command md0 pid 853 tid 100090 td 0xffffff0006072720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b md_kthread() at md_kthread+0x15a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f52d40, rbp = 0 --- Tracing command unbound pid 816 tid 100096 td 0xffffff000604c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x44eb53, rsp = 0x7fffffffe408, rbp = 0x80173b650 --- Tracing command syslogd pid 787 tid 100070 td 0xffffff0004fb1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_contig_launder() at vm_contig_launder+0xb5 zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_hold_impl() at dbuf_hold_impl+0x1ea dbuf_hold_level() at dbuf_hold_level+0x1a dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x52 dmu_tx_count_write() at dmu_tx_count_write+0x178 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 writev() at writev+0x41 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (121, FreeBSD ELF64, writev), rip = 0x800834d3c, rsp = 0x7fffffffcaf8, rbp = 0 --- Tracing command devd pid 665 tid 100073 td 0xffffff0004fb1000 Tracing command zil_clean pid 179 tid 100113 td 0xffffff0006099720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc5d40, rbp = 0 --- Tracing command zil_clean pid 178 tid 100083 td 0xffffff0004fad720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f2fd40, rbp = 0 --- Tracing command zil_clean pid 177 tid 100112 td 0xffffff0006099ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc0d40, rbp = 0 --- Tracing command zil_clean pid 176 tid 100111 td 0xffffff000609b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fbbd40, rbp = 0 --- Tracing command zil_clean pid 175 tid 100109 td 0xffffff000609b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb1d40, rbp = 0 --- Tracing command zil_clean pid 174 tid 100080 td 0xffffff0006022000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f20d40, rbp = 0 --- Tracing command zil_clean pid 173 tid 100108 td 0xffffff000609bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079facd40, rbp = 0 --- Tracing command zil_clean pid 172 tid 100104 td 0xffffff000609cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f98d40, rbp = 0 --- Tracing command zil_clean pid 171 tid 100072 td 0xffffff0004fb1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ef8d40, rbp = 0 --- Tracing command zil_clean pid 170 tid 100110 td 0xffffff000609b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb6d40, rbp = 0 --- Tracing command txg_thread_enter pid 168 tid 100107 td 0xffffff000609c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xee spa_sync() at spa_sync+0x355 txg_sync_thread() at txg_sync_thread+0x28f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a07dd40, rbp = 0 --- Tracing command txg_thread_enter pid 167 tid 100106 td 0xffffff000609c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fa2d40, rbp = 0 --- Tracing command vdev:worker ad10s1 pid 166 tid 100105 td 0xffffff000609c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f9dd40, rbp = 0 --- Tracing command vdev:worker ad6s1 pid 165 tid 100077 td 0xffffff0004fb0390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f11d40, rbp = 0 --- Tracing command vdev:worker ad8s2 pid 164 tid 100087 td 0xffffff0006049390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f43d40, rbp = 0 --- Tracing command vdev:worker ad4s2 pid 163 tid 100149 td 0xffffff00060d0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a079d40, rbp = 0 --- Tracing command spa_zio pid 162 tid 100148 td 0xffffff00060d0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a074d40, rbp = 0 --- Tracing command spa_zio pid 161 tid 100147 td 0xffffff0006399000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06fd40, rbp = 0 --- Tracing command spa_zio pid 160 tid 100146 td 0xffffff0006399390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06ad40, rbp = 0 --- Tracing command spa_zio pid 159 tid 100145 td 0xffffff0006399720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a065d40, rbp = 0 --- Tracing command spa_zio pid 158 tid 100144 td 0xffffff0006399ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a060d40, rbp = 0 --- Tracing command spa_zio pid 157 tid 100143 td 0xffffff000639b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a05bd40, rbp = 0 --- Tracing command spa_zio pid 156 tid 100142 td 0xffffff000639b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a056d40, rbp = 0 --- Tracing command spa_zio pid 155 tid 100141 td 0xffffff000639b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a051d40, rbp = 0 --- Tracing command spa_zio pid 154 tid 100140 td 0xffffff000639bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a04cd40, rbp = 0 --- Tracing command spa_zio pid 153 tid 100139 td 0xffffff000639c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a047d40, rbp = 0 --- Tracing command spa_zio pid 152 tid 100138 td 0xffffff000639c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a042d40, rbp = 0 --- Tracing command spa_zio pid 151 tid 100137 td 0xffffff000639c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a03dd40, rbp = 0 --- Tracing command spa_zio pid 150 tid 100136 td 0xffffff000639cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sx_xlock_hard() at _sx_xlock_hard+0x1a7 _sx_xlock() at _sx_xlock+0xc1 dbuf_write_ready() at dbuf_write_ready+0xbf arc_write_ready() at arc_write_ready+0x2c zio_ready() at zio_ready+0x3a zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a038d40, rbp = 0 --- Tracing command spa_zio pid 149 tid 100135 td 0xffffff000639d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a033d40, rbp = 0 --- Tracing command spa_zio pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- Tracing command spa_zio pid 147 tid 100133 td 0xffffff000609d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a029d40, rbp = 0 --- Tracing command spa_zio pid 146 tid 100132 td 0xffffff000609dab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a024d40, rbp = 0 --- Tracing command spa_zio pid 145 tid 100131 td 0xffffff00060c8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01fd40, rbp = 0 --- Tracing command spa_zio pid 144 tid 100130 td 0xffffff00060c8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01ad40, rbp = 0 --- Tracing command spa_zio pid 143 tid 100129 td 0xffffff00060c8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a015d40, rbp = 0 --- Tracing command spa_zio pid 142 tid 100128 td 0xffffff00060c8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a010d40, rbp = 0 --- Tracing command spa_zio pid 141 tid 100127 td 0xffffff00060ca000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a00bd40, rbp = 0 --- Tracing command spa_zio pid 140 tid 100126 td 0xffffff00060ca390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a006d40, rbp = 0 --- Tracing command spa_zio pid 139 tid 100125 td 0xffffff00060ca720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a001d40, rbp = 0 --- Tracing command spa_zio pid 138 tid 100124 td 0xffffff00060caab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ffcd40, rbp = 0 --- Tracing command spa_zio pid 137 tid 100123 td 0xffffff00060cf000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ff7d40, rbp = 0 --- Tracing command flowcleaner pid 44 tid 100068 td 0xffffff0004f0b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 flowtable_cleaner() at flowtable_cleaner+0x13a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077be1d40, rbp = 0 --- Tracing command softdepflush pid 43 tid 100067 td 0xffffff0004f0b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 softdep_flush() at softdep_flush+0x2c0 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bdcd40, rbp = 0 --- Tracing command syncer pid 42 tid 100066 td 0xffffff0004f0b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c sched_sync() at sched_sync+0x4de fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd7d40, rbp = 0 --- Tracing command vnlru pid 41 tid 100065 td 0xffffff0004f0bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vnlru_proc() at vnlru_proc+0x607 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd2d40, rbp = 0 --- Tracing command vaclean pid 40 tid 100064 td 0xffffff0004f0c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c vn_rele_async_cleaner() at vn_rele_async_cleaner+0x119 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bcdd40, rbp = 0 --- Tracing command bufdaemon pid 39 tid 100063 td 0xffffff0004f0c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 buf_daemon() at buf_daemon+0x14a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc8d40, rbp = 0 --- Tracing command pagezero pid 38 tid 100062 td 0xffffff0004f0c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vm_pagezero() at vm_pagezero+0x73 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc3d40, rbp = 0 --- Tracing command vmdaemon pid 37 tid 100061 td 0xffffff0004f0cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bbed40, rbp = 0 --- Tracing command pagedaemon pid 36 tid 100060 td 0xffffff0004f0e000 cpustop_handler() at cpustop_handler+0x3b ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x1b8 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8049f404, rsp = 0xffffffff808e6820, rbp = 0xffffff8077bb94b0 --- DELAY() at DELAY+0x64 ns8250_putc() at ns8250_putc+0x9a uart_cnputc() at uart_cnputc+0x4e cnputc() at cnputc+0x49 putchar() at putchar+0x6a kvprintf() at kvprintf+0x81 vprintf() at vprintf+0x3e printf() at printf+0x67 swp_pager_getswapspace() at swp_pager_getswapspace+0xc7 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_pageout_clean() at vm_pageout_clean+0xfc vm_pageout() at vm_pageout+0x1168 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb9d40, rbp = 0 --- Tracing command g_mirror boot pid 35 tid 100059 td 0xffffff0004f0e390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b g_mirror_worker() at g_mirror_worker+0xb1c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb4d40, rbp = 0 --- Tracing command l2arc_feed_thread pid 34 tid 100058 td 0xffffff0004f0e720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c l2arc_feed_thread() at l2arc_feed_thread+0x169 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bafd40, rbp = 0 --- Tracing command arc_reclaim_thread pid 9 tid 100057 td 0xffffff0004f0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c arc_reclaim_thread() at arc_reclaim_thread+0x2ba fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077baad40, rbp = 0 --- Tracing command usbus4 pid 33 tid 100056 td 0xffffff0004ec6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba5d40, rbp = 0 --- Tracing command usbus4 pid 32 tid 100055 td 0xffffff0004ec6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba0d40, rbp = 0 --- Tracing command usbus4 pid 31 tid 100054 td 0xffffff0004ec6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b9bd40, rbp = 0 --- Tracing command usbus4 pid 30 tid 100053 td 0xffffff0004ee8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b96d40, rbp = 0 --- Tracing command usbus3 pid 29 tid 100052 td 0xffffff0004ee8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b91d40, rbp = 0 --- Tracing command usbus3 pid 28 tid 100051 td 0xffffff0004ee8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b8cd40, rbp = 0 --- Tracing command usbus3 pid 27 tid 100050 td 0xffffff0004ee8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b87d40, rbp = 0 --- Tracing command usbus3 pid 26 tid 100049 td 0xffffff0004ee9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b82d40, rbp = 0 --- Tracing command usbus2 pid 25 tid 100048 td 0xffffff0004ee9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b7dd40, rbp = 0 --- Tracing command usbus2 pid 24 tid 100047 td 0xffffff0004ee9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b78d40, rbp = 0 --- Tracing command usbus2 pid 23 tid 100046 td 0xffffff0004ee9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b73d40, rbp = 0 --- Tracing command usbus2 pid 22 tid 100045 td 0xffffff00015b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b6ed40, rbp = 0 --- Tracing command usbus1 pid 21 tid 100044 td 0xffffff0004ec3000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b69d40, rbp = 0 --- Tracing command usbus1 pid 20 tid 100043 td 0xffffff0004ec3390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b64d40, rbp = 0 --- Tracing command usbus1 pid 19 tid 100042 td 0xffffff0004ec3720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5fd40, rbp = 0 --- Tracing command usbus1 pid 18 tid 100041 td 0xffffff0004ec3ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5ad40, rbp = 0 --- Tracing command usbus0 pid 17 tid 100040 td 0xffffff0004ec4000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b55d40, rbp = 0 --- Tracing command usbus0 pid 16 tid 100039 td 0xffffff0004ec4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b50d40, rbp = 0 --- Tracing command usbus0 pid 15 tid 100038 td 0xffffff0004ec4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b4bd40, rbp = 0 --- Tracing command usbus0 pid 14 tid 100037 td 0xffffff0004ec4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b46d40, rbp = 0 --- Tracing command sctp_iterator pid 8 tid 100036 td 0xffffff0004ec6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b sctp_iterator_thread() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b41d40, rbp = 0 --- Tracing command xpt_thrd pid 7 tid 100020 td 0xffffff0001563000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b xpt_scanner_thread() at xpt_scanner_thread+0x3a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000076d40, rbp = 0 --- Tracing command system_taskq pid 6 tid 100015 td 0xffffff00014d1720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800005dd40, rbp = 0 --- Tracing command system_taskq pid 5 tid 100014 td 0xffffff00014d1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000058d40, rbp = 0 --- Tracing command yarrow pid 13 tid 100013 td 0xffffff00014d2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 random_kthread() at random_kthread+0x1ad fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000053d40, rbp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xffffff00014b6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_down() at g_io_schedule_down+0x250 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000049d40, rbp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xffffff00014b6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_up() at g_io_schedule_up+0x154 g_up_procbody() at g_up_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000044d40, rbp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xffffff00014b6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_event_procbody() at g_event_procbody+0xa1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003fd40, rbp = 0 --- Tracing command intr pid 12 tid 100035 td 0xffffff0001563720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b39d40, rbp = 0 --- Tracing command intr pid 12 tid 100034 td 0xffffff0001563ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100033 td 0xffffff00015b2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075b6fd40, rbp = 0 --- Tracing command intr pid 12 tid 100032 td 0xffffff00015b2390 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100031 td 0xffffff00015b2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xffffff00015b2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807566ad40, rbp = 0 --- Tracing command intr pid 12 tid 100029 td 0xffffff00015b4000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100026 td 0xffffff00014d2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100021 td 0xffffff0001561ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100019 td 0xffffff0001563390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000071d40, rbp = 0 --- Tracing command intr pid 12 tid 100018 td 0xffffff00014c7ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100016 td 0xffffff00014d1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000062d40, rbp = 0 --- Tracing command intr pid 12 tid 100008 td 0xffffff00014c7000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003ad40, rbp = 0 --- Tracing command intr pid 12 tid 100007 td 0xffffff00014c7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000035d40, rbp = 0 --- Tracing command intr pid 12 tid 100006 td 0xffffff00014c7720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000030d40, rbp = 0 --- Tracing command intr pid 12 tid 100005 td 0xffffff00014b4000 fork_trampoline() at fork_trampoline Tracing command idle pid 11 tid 100004 td 0xffffff00014b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000026d40, rbp = 0 --- Tracing command idle pid 11 tid 100003 td 0xffffff00014b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000021d40, rbp = 0 --- Tracing command init pid 1 tid 100002 td 0xffffff00014b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40c62c, rsp = 0x7fffffffe808, rbp = 0x401d40 --- Tracing command audit pid 10 tid 100001 td 0xffffff00014b6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a audit_worker() at audit_worker+0x77 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000017d40, rbp = 0 --- Tracing command kernel pid 0 tid 100028 td 0xffffff00015b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800009ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100027 td 0xffffff00015b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000099d40, rbp = 0 --- Tracing command kernel pid 0 tid 100025 td 0xffffff00014d2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008fd40, rbp = 0 --- Tracing command kernel pid 0 tid 100024 td 0xffffff0001561000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008ad40, rbp = 0 --- Tracing command kernel pid 0 tid 100023 td 0xffffff0001561390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000085d40, rbp = 0 --- Tracing command kernel pid 0 tid 100022 td 0xffffff0001561720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000080d40, rbp = 0 --- Tracing command kernel pid 0 tid 100017 td 0xffffff00014d1000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000067d40, rbp = 0 --- Tracing command kernel pid 0 tid 100012 td 0xffffff00014d2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800004ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100000 td 0xffffffff806d8920 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 scheduler() at scheduler+0x292 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> -- 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 onemda at gmail.com Mon Jun 1 00:38:39 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Jun 1 00:38:46 2009 Subject: installworld failure In-Reply-To: References: Message-ID: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> On 6/1/09, Randy Bush wrote: >> ===> usr.bin/ee (install) >> install -s -o root -g wheel -m 555 ee /usr/bin >> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg >> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg >> gencat:No such file or directory >> *** Error code 1 >> >> Stop in /usr/src/usr.bin/ee. >> *** Error code 1 >> >> Stop in /usr/src/usr.bin. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 > > new cvsup > rm -rf /usr/obj > > no help, repeats You should have gencat allready installed: cd /usr/src/usr.bin/gencat && make install -- Paul From randy at psg.com Mon Jun 1 00:44:11 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 00:44:18 2009 Subject: kern/134011: [hang] swap_pager_getswapspace(4): failed In-Reply-To: <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> Message-ID: > Are your sources from CVS or svn? cvs > The backtrace indicates that you have code that I backed out a little > over a week ago. i will cvsup again randy From randy at psg.com Mon Jun 1 00:45:53 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 00:46:01 2009 Subject: installworld failure In-Reply-To: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: >>> ===> usr.bin/ee (install) >>> install -s -o root -g wheel -m 555 ee /usr/bin >>> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg >>> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg >>> gencat:No such file or directory >>> *** Error code 1 >>> >>> Stop in /usr/src/usr.bin/ee. >>> *** Error code 1 >>> >>> Stop in /usr/src/usr.bin. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >> >> new cvsup >> rm -rf /usr/obj >> >> no help, repeats > > You should have gencat allready installed: > > cd /usr/src/usr.bin/gencat && make install gencat is installed. it is whining that it can not find the file randy From deeptech71 at gmail.com Mon Jun 1 00:47:43 2009 From: deeptech71 at gmail.com (deeptech71@gmail.com) Date: Mon Jun 1 00:47:50 2009 Subject: panic: igmp_v3_dispatch_general_query: called when version 2 In-Reply-To: <4A22E2F1.6070404@incunabulum.net> References: <4A1DD57A.7010704@gmail.com> <4A1E9831.4010606@incunabulum.net> <4A1EC8FB.6090206@gmail.com> <4A1FBFF5.6090103@incunabulum.net> <4A20791D.5070209@gmail.com> <4A22E2F1.6070404@incunabulum.net> Message-ID: <4A2325F1.8010300@gmail.com> Bruce Simpson wrote: > deeptech71@gmail.com wrote: >> Bruce Simpson wrote: >>> I may not get free time to fix this right away, are you able to test a >>> patch when I can make one available? >> >> Sure. > > Thanks. Can you please test this patch and let me know if it works for you? OK, applied, but what now? If you are sure that you have fixed the bug, but just want me to run a "crash test" before commiting, then all I can say is there's nothing wrong yet, I'll keep running the patch until something comes up, like a panic (and report it). Otherwise I can't test wether the patch does avoid the non-reproducable panic. From samuel at boivie.org Mon Jun 1 01:13:42 2009 From: samuel at boivie.org (Samuel Boivie) Date: Mon Jun 1 01:53:59 2009 Subject: Removal of legacy USB stack Message-ID: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> It seems to me as if ports/x11/kdebase4 and probably friends still depend on the old usb stack, and hence fail to compile now (after the removal on May 27). Is it as easy as fixing the port to point at the new one or are the differences between the stacks still there? Samuel From kmacy at freebsd.org Mon Jun 1 02:04:24 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 1 02:04:31 2009 Subject: kern/134011: [hang] swap_pager_getswapspace(4): failed In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> Message-ID: <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> On Sun, May 31, 2009 at 5:44 PM, Randy Bush wrote: >> Are your sources from CVS or svn? > > cvs > >> The backtrace indicates that you have code that I backed out a little >> over a week ago. > > i will cvsup again > That won't help. CVS is missing changes from svn. Peter - What would cause cvs to miss fall out of sync? Cheers, Kip From randy at psg.com Mon Jun 1 02:16:23 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 02:16:30 2009 Subject: kern/134011: [hang] swap_pager_getswapspace(4): failed In-Reply-To: <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> Message-ID: > CVS is missing changes from svn. oh goodie! and no extra charge! :) i think i will go work on something else for a bit. thanks for the warning. randy From thompsa at FreeBSD.org Mon Jun 1 02:17:02 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Jun 1 02:17:09 2009 Subject: Removal of legacy USB stack In-Reply-To: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> References: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> Message-ID: <20090601021654.GA99430@citylink.fud.org.nz> On Mon, Jun 01, 2009 at 02:57:49AM +0200, Samuel Boivie wrote: > It seems to me as if ports/x11/kdebase4 and probably friends still depend > on the old usb stack, and hence fail to compile now (after the removal on > May 27). Is it as easy as fixing the port to point at the new one or are > the differences between the stacks still there? Since Feb 23rd the old usb stack hasnt been compiled in so while kdebase4 continued to compile by using the header files it would not actually be able to talk usb. The best way is to update the port to use libusb. cheers, Andrew From tinderbox at freebsd.org Mon Jun 1 04:23:04 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 1 04:23:22 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090601042258.909C77302F@freebsd-current.sentex.ca> TB --- 2009-06-01 03:37:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 03:37:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-01 03:37:32 - cleaning the object tree TB --- 2009-06-01 03:37:41 - cvsupping the source tree TB --- 2009-06-01 03:37:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-01 03:37:49 - building world TB --- 2009-06-01 03:37:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 03:37:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 03:37:49 - TARGET=ia64 TB --- 2009-06-01 03:37:49 - TARGET_ARCH=ia64 TB --- 2009-06-01 03:37:49 - TZ=UTC TB --- 2009-06-01 03:37:49 - __MAKE_CONF=/dev/null TB --- 2009-06-01 03:37:49 - cd /src TB --- 2009-06-01 03:37:49 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 03:37:50 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/bind/bind9 (all) cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind9/ lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token *** Error code 1 Stop in /src/lib/bind/bind9. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 04:22:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 04:22:58 - ERROR: failed to build world TB --- 2009-06-01 04:22:58 - 2173.84 user 195.73 system 2725.93 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From kmacy at freebsd.org Mon Jun 1 04:39:28 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 1 04:39:35 2009 Subject: Bug in recent large_alloc changes to the ZFS zio code? In-Reply-To: <20090531074907.GA26858@ichotolot.servalan.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> <20090531074907.GA26858@ichotolot.servalan.com> Message-ID: <3c1674c90905312139p6ad5020dgb82f0740f75fd096@mail.gmail.com> On Sun, May 31, 2009 at 12:49 AM, Richard Todd wrote: > On Sat, May 30, 2009 at 11:54:47PM -0700, Kip Macy wrote: >> http://svn.freebsd.org/changeset/base/192360 >> > > Ah. ?Hmm. ?So if I'm reading this right, you already backed out that change > in the master SVN repo, right? ?Well, *something* weird's going on, because > that change never seems to have made it to the CVS version of the repo or to > the cvsup sites, because I'm not seeing it there; see for yourself at > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > . ?The commit log for 192360 never showed up in CVSROOT-src/commitlogs/sys > either. ?So it looks like bits are falling on the floor somewhere between > the SVN and CVS repos. > > Yup. This is causing problems for other ZFS users on head. It looks like if you use ZFS on head you need to use svn. I'm not in a position to fix this issue. Cheers, Kip From dougb at FreeBSD.org Mon Jun 1 05:28:34 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 05:28:53 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090601042258.909C77302F@freebsd-current.sentex.ca> References: <20090601042258.909C77302F@freebsd-current.sentex.ca> Message-ID: <4A2360BC.8040109@FreeBSD.org> FYI, I'm aware of this issue and I've filed a bug report with the ISC folks. If anyone has a bright idea on how to fix it I'm all ears, but I tried everything I can think of already and no luck so far. Sorry for the inconvenience, Doug FreeBSD Tinderbox wrote: > TB --- 2009-06-01 03:37:32 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-06-01 03:37:32 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-06-01 03:37:32 - cleaning the object tree > TB --- 2009-06-01 03:37:41 - cvsupping the source tree > TB --- 2009-06-01 03:37:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-06-01 03:37:49 - building world > TB --- 2009-06-01 03:37:49 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-06-01 03:37:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-06-01 03:37:49 - TARGET=ia64 > TB --- 2009-06-01 03:37:49 - TARGET_ARCH=ia64 > TB --- 2009-06-01 03:37:49 - TZ=UTC > TB --- 2009-06-01 03:37:49 - __MAKE_CONF=/dev/null > TB --- 2009-06-01 03:37:49 - cd /src > TB --- 2009-06-01 03:37:49 - /usr/bin/make -B buildworld >>>> World build started on Mon Jun 1 03:37:50 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries > [...] > ===> lib/bind/bind9 (all) > cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind 9/ > lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c > In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, > from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, > from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token > *** Error code 1 > > Stop in /src/lib/bind/bind9. > *** Error code 1 > > Stop in /src/lib/bind. > *** Error code 1 > > Stop in /src/lib. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-06-01 04:22:58 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-06-01 04:22:58 - ERROR: failed to build world > TB --- 2009-06-01 04:22:58 - 2173.84 user 195.73 system 2725.93 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full > _______________________________________________ > 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" > -- This .signature sanitized for your protection From zec at freebsd.org Mon Jun 1 07:20:43 2009 From: zec at freebsd.org (Marko Zec) Date: Mon Jun 1 07:20:50 2009 Subject: making world on 7.2 to update to 8.0-current In-Reply-To: <200905311205.02507.r.neese@gmail.com> References: <200905311205.02507.r.neese@gmail.com> Message-ID: <200906010920.08263.zec@freebsd.org> On Sunday 31 May 2009 18:05:02 Richard Neese wrote: > when running make buildworld on 7.2 to update to 8.0 current I get the > fallowing error This is already fixed by r193177, pls. update your sources. Marko > ===> usr.bin/kdump (all) > cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - > I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c > /usr/src/usr.bin/kdump/kdump.c > cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - > I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c > ioctl.c: In function 'ioctlname': > ioctl.c:1089: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > ioctl.c:1405: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > ioctl.c:2679: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > *** Error code 1 > > Stop in /usr/src/usr.bin/kdump. > *** Error code 1 > > switch-1# uname -a > FreeBSD switch-1.daemonswitch.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue > May 12 14:35:01 EDT 2009 > root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER i386 > > 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-RELEASE #0: Tue May 12 14:35:01 EDT 2009 > root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ (2099.96-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 > > Features=0x178bfbffA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > real memory = 518979584 (494 MB) > avail memory = 498069504 (474 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From rea-fbsd at codelabs.ru Mon Jun 1 08:30:39 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 1 08:30:48 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <4A2360BC.8040109@FreeBSD.org> References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> Message-ID: Doug, good day. Sun, May 31, 2009 at 10:01:48PM -0700, Doug Barton wrote: > FYI, I'm aware of this issue and I've filed a bug report with the ISC > folks. If anyone has a bright idea on how to fix it I'm all ears, but > I tried everything I can think of already and no luck so far. Seems like GCC likes to see __attribute__ stuff only for function prototypes, not for declarations. The attached patch seems to fix the stuff, but I have no ia64 system to test on. Quick test with 'make ISC_ATOMIC_ARCH=ia64' eliminates errors. This is very weird (judging by the GCC's manual) since the simplest C program, ----- int main(void) { return 0; } void foo(void) __attribute__ ((unused)) { return; } ----- but ICC 10.x produces the same error and happily chewes __attribute__ on the function prototype. Anyway, I see no warnings even without '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks like no-op nowadays. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: isc-unused.diff Type: text/x-diff Size: 1509 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090601/2eb22ff3/isc-unused.bin From christoph.mallon at gmx.de Mon Jun 1 09:39:13 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Mon Jun 1 09:39:25 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> Message-ID: <4A239B7C.8020403@gmx.de> Eygene Ryabinkin schrieb: > This is very weird (judging by the GCC's manual) since the simplest C > program, > ----- > int main(void) > { > return 0; > } > > void foo(void) __attribute__ ((unused)) > { > return; > } > ----- > but ICC 10.x produces the same error and happily chewes __attribute__ > on the function prototype. Anyway, I see no warnings even without > '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks > like no-op nowadays. There is no warning about foo() being unused, because it is not static. Christoph From hlh at restart.be Mon Jun 1 10:22:46 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 10:22:52 2009 Subject: /boot/loader can't load kernel if too many pool/devices Message-ID: <4A23ABF2.3070601@restart.be> Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error "can't boot 'kernel'" if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/loader from 8.0-CURRENT. Henri From rwatson at FreeBSD.org Mon Jun 1 10:44:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 10:45:03 2009 Subject: New NETISR implementation, but same defaults Message-ID: As a HEADS up to 8-CURRENT followers: I've replaced the NETISR implementation there as part of on-going work to improve network stack parallelism, details below. In practice, most behavior remains identical in the default configuration (direct dispatch, single netisr thread that's not bound to a CPU, etc), but people will want to watch out for problems. Some default queue limits have been raised. More functional changes to take advantage of these features, such as deferred ethernet dispatch and software flow ID generation, will follow as patches, but probably not ship in 8.0 out of the box. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 1 Jun 2009 10:41:38 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r193219 - in head/sys: kern net netatalk netinet netinet6 netipsec netipx netnatm sys Author: rwatson Date: Mon Jun 1 10:41:38 2009 New Revision: 193219 URL: http://svn.freebsd.org/changeset/base/193219 Log: Reimplement the netisr framework in order to support parallel netisr threads: - Support up to one netisr thread per CPU, each processings its own workstream, or set of per-protocol queues. Threads may be bound to specific CPUs, or allowed to migrate, based on a global policy. In the future it would be desirable to support topology-centric policies, such as "one netisr per package". - Allow each protocol to advertise an ordering policy, which can currently be one of: NETISR_POLICY_SOURCE: packets must maintain ordering with respect to an implicit or explicit source (such as an interface or socket). NETISR_POLICY_FLOW: make use of mbuf flow identifiers to place work, as well as allowing protocols to provide a flow generation function for mbufs without flow identifers (m2flow). Falls back on NETISR_POLICY_SOURCE if now flow ID is available. NETISR_POLICY_CPU: allow protocols to inspect and assign a CPU for each packet handled by netisr (m2cpuid). - Provide utility functions for querying the number of workstreams being used, as well as a mapping function from workstream to CPU ID, which protocols may use in work placement decisions. - Add explicit interfaces to get and set per-protocol queue limits, and get and clear drop counters, which query data or apply changes across all workstreams. - Add a more extensible netisr registration interface, in which protocols declare 'struct netisr_handler' structures for each registered NETISR_ type. These include name, handler function, optional mbuf to flow ID function, optional mbuf to CPU ID function, queue limit, and ordering policy. Padding is present to allow these to be expanded in the future. If no queue limit is declared, then a default is used. - Queue limits are now per-workstream, and raised from the previous IFQ_MAXLEN default of 50 to 256. - All protocols are updated to use the new registration interface, and with the exception of netnatm, default queue limits. Most protocols register as NETISR_POLICY_SOURCE, except IPv4 and IPv6, which use NETISR_POLICY_FLOW, and will therefore take advantage of driver- generated flow IDs if present. - Formalize a non-packet based interface between interface polling and the netisr, rather than having polling pretend to be two protocols. Provide two explicit hooks in the netisr worker for start and end events for runs: netisr_poll() and netisr_pollmore(), as well as a function, netisr_sched_poll(), to allow the polling code to schedule netisr execution. DEVICE_POLLING still embeds single-netisr assumptions in its implementation, so for now if it is compiled into the kernel, a single and un-bound netisr thread is enforced regardless of tunable configuration. In the default configuration, the new netisr implementation maintains the same basic assumptions as the previous implementation: a single, un-bound worker thread processes all deferred work, and direct dispatch is enabled by default wherever possible. Performance measurement shows a marginal performance improvement over the old implementation due to the use of batched dequeue. An rmlock is used to synchronize use and registration/unregistration using the framework; currently, synchronized use is disabled (replicating current netisr policy) due to a measurable 3%-6% hit in ping-pong micro-benchmarking. It will be enabled once further rmlock optimization has taken place. However, in practice, netisrs are rarely registered or unregistered at runtime. A new man page for netisr will follow, but since one doesn't currently exist, it hasn't been updated. This change is not appropriate for MFC, although the polling shutdown handler should be merged to 7-STABLE. Bump __FreeBSD_version. Reviewed by: bz Modified: head/sys/kern/kern_poll.c head/sys/net/netisr.c head/sys/net/netisr.h head/sys/net/rtsock.c head/sys/netatalk/ddp_usrreq.c head/sys/netinet/if_ether.c head/sys/netinet/igmp.c head/sys/netinet/ip_divert.c head/sys/netinet/ip_input.c head/sys/netinet6/ip6_input.c head/sys/netinet6/vinet6.h head/sys/netipsec/ipsec_input.c head/sys/netipx/ipx_input.c head/sys/netnatm/natm_proto.c head/sys/sys/param.h head/sys/sys/pcpu.h Modified: head/sys/kern/kern_poll.c ============================================================================== --- head/sys/kern/kern_poll.c Mon Jun 1 10:30:52 2009 (r193218) +++ head/sys/kern/kern_poll.c Mon Jun 1 10:41:38 2009 (r193219) @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include /* needed by net/if.h */ #include @@ -48,8 +49,6 @@ __FBSDID("$FreeBSD$"); #include #include -static void netisr_poll(void); /* the two netisr handlers */ -static void netisr_pollmore(void); static int poll_switch(SYSCTL_HANDLER_ARGS); void hardclock_device_poll(void); /* hook from hardclock */ @@ -110,6 +109,10 @@ SYSCTL_NODE(_kern, OID_AUTO, polling, CT SYSCTL_UINT(_kern_polling, OID_AUTO, burst, CTLFLAG_RD, &poll_burst, 0, "Current polling burst size"); +static int netisr_poll_scheduled; +static int netisr_pollmore_scheduled; +static int poll_shutting_down; + static int poll_burst_max_sysctl(SYSCTL_HANDLER_ARGS) { uint32_t val = poll_burst_max; @@ -260,12 +263,19 @@ struct pollrec { static struct pollrec pr[POLL_LIST_LEN]; static void +poll_shutdown(void *arg, int howto) +{ + + poll_shutting_down = 1; +} + +static void init_device_poll(void) { mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); - netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, 0); - netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, 0); + EVENTHANDLER_REGISTER(shutdown_post_sync, poll_shutdown, NULL, + SHUTDOWN_PRI_LAST); } SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, NULL); @@ -289,7 +299,7 @@ hardclock_device_poll(void) static struct timeval prev_t, t; int delta; - if (poll_handlers == 0) + if (poll_handlers == 0 || poll_shutting_down) return; microuptime(&t); @@ -314,7 +324,9 @@ hardclock_device_poll(void) if (phase != 0) suspect++; phase = 1; - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); phase = 2; } if (pending_polls++ > 0) @@ -365,9 +377,16 @@ netisr_pollmore() int kern_load; mtx_lock(&poll_mtx); + if (!netisr_pollmore_scheduled) { + mtx_unlock(&poll_mtx); + return; + } + netisr_pollmore_scheduled = 0; phase = 5; if (residual_burst > 0) { - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); mtx_unlock(&poll_mtx); /* will run immediately on return, followed by netisrs */ return; @@ -397,23 +416,29 @@ netisr_pollmore() poll_burst -= (poll_burst / 8); if (poll_burst < 1) poll_burst = 1; - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); phase = 6; } mtx_unlock(&poll_mtx); } /* - * netisr_poll is scheduled by schednetisr when appropriate, typically once - * per tick. + * netisr_poll is typically scheduled once per tick. */ -static void +void netisr_poll(void) { int i, cycles; enum poll_cmd arg = POLL_ONLY; mtx_lock(&poll_mtx); + if (!netisr_poll_scheduled) { + mtx_unlock(&poll_mtx); + return; + } + netisr_poll_scheduled = 0; phase = 3; if (residual_burst == 0) { /* first call in this tick */ microuptime(&poll_start_t); Modified: head/sys/net/netisr.c ============================================================================== --- head/sys/net/netisr.c Mon Jun 1 10:30:52 2009 (r193218) +++ head/sys/net/netisr.c Mon Jun 1 10:41:38 2009 (r193219) @@ -1,6 +1,5 @@ /*- - * Copyright (c) 2001,2002,2003 Jonathan Lemon - * Copyright (c) 1997, Stefan Esser + * Copyright (c) 2007-2009 Robert N. M. Watson * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -23,230 +22,1103 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * netisr is a packet dispatch service, allowing synchronous (directly + * dispatched) and asynchronous (deferred dispatch) processing of packets by + * registered protocol handlers. Callers pass a protocol identifier and + * packet to netisr, along with a direct dispatch hint, and work will either + * be immediately processed with the registered handler, or passed to a + * kernel software interrupt (SWI) thread for deferred dispatch. Callers + * will generally select one or the other based on: + * + * - Might directly dispatching a netisr handler lead to code reentrance or + * lock recursion, such as entering the socket code from the socket code. + * - Might directly dispatching a netisr handler lead to recursive + * processing, such as when decapsulating several wrapped layers of tunnel + * information (IPSEC within IPSEC within ...). * - * $FreeBSD$ + * Maintaining ordering for protocol streams is a critical design concern. + * Enforcing ordering limits the opportunity for concurrency, but maintains + * the strong ordering requirements found in some protocols, such as TCP. Of + * related concern is CPU affinity--it is desirable to process all data + * associated with a particular stream on the same CPU over time in order to + * avoid acquiring locks associated with the connection on different CPUs, + * keep connection data in one cache, and to generally encourage associated + * user threads to live on the same CPU as the stream. It's also desirable + * to avoid lock migration and contention where locks are associated with + * more than one flow. + * + * netisr supports several policy variations, represented by the + * NETISR_POLICY_* constants, allowing protocols to play a varying role in + * identifying flows, assigning work to CPUs, etc. These are described in + * detail in netisr.h. */ +#include "opt_ddb.h" #include "opt_device_polling.h" #include #include -#include -#include -#include #include #include +#include #include -#include +#include +#include #include -#include -#include +#include +#include +#include +#include #include -#include +#include #include -#include -#include -#include -#include -#include +#ifdef DDB +#include +#endif #include -#include #include #include -volatile unsigned int netisr; /* scheduling bits for network */ +/*- + * Synchronize use and modification of the registered netisr data structures; + * acquire a read lock while modifying the set of registered protocols to + * prevent partially registered or unregistered protocols from being run. + * + * The following data structures and fields are protected by this lock: + * + * - The np array, including all fields of struct netisr_proto. + * - The nws array, including all fields of struct netisr_worker. + * - The nws_array array. + * + * Note: the NETISR_LOCKING define controls whether read locks are acquired + * in packet processing paths requiring netisr registration stability. This + * is disabled by default as it can lead to a measurable performance + * degradation even with rmlocks (3%-6% for loopback ping-pong traffic), and + * because netisr registration and unregistration is extremely rare at + * runtime. If it becomes more common, this decision should be revisited. + * + * XXXRW: rmlocks don't support assertions. + */ +static struct rmlock netisr_rmlock; +#define NETISR_LOCK_INIT() rm_init_flags(&netisr_rmlock, "netisr", \ + RM_NOWITNESS) +#define NETISR_LOCK_ASSERT() +#define NETISR_RLOCK(tracker) rm_rlock(&netisr_rmlock, (tracker)) +#define NETISR_RUNLOCK(tracker) rm_runlock(&netisr_rmlock, (tracker)) +#define NETISR_WLOCK() rm_wlock(&netisr_rmlock) +#define NETISR_WUNLOCK() rm_wunlock(&netisr_rmlock) +/* #define NETISR_LOCKING */ + +SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr"); + +/*- + * Three direct dispatch policies are supported: + * + * - Always defer: all work is scheduled for a netisr, regardless of context. + * (!direct) + * + * - Hybrid: if the executing context allows direct dispatch, and we're + * running on the CPU the work would be done on, then direct dispatch if it + * wouldn't violate ordering constraints on the workstream. + * (direct && !direct_force) + * + * - Always direct: if the executing context allows direct dispatch, always + * direct dispatch. (direct && direct_force) + * + * Notice that changing the global policy could lead to short periods of + * misordered processing, but this is considered acceptable as compared to + * the complexity of enforcing ordering during policy changes. + */ +static int netisr_direct_force = 1; /* Always direct dispatch. */ +TUNABLE_INT("net.isr.direct_force", &netisr_direct_force); +SYSCTL_INT(_net_isr, OID_AUTO, direct_force, CTLFLAG_RW, + &netisr_direct_force, 0, "Force direct dispatch"); + +static int netisr_direct = 1; /* Enable direct dispatch. */ +TUNABLE_INT("net.isr.direct", &netisr_direct); +SYSCTL_INT(_net_isr, OID_AUTO, direct, CTLFLAG_RW, + &netisr_direct, 0, "Enable direct dispatch"); + +/* + * Allow the administrator to limit the number of threads (CPUs) to use for + * netisr. We don't check netisr_maxthreads before creating the thread for + * CPU 0, so in practice we ignore values <= 1. This must be set at boot. + * We will create at most one thread per CPU. + */ +static int netisr_maxthreads = 1; /* Max number of threads. */ +TUNABLE_INT("net.isr.maxthreads", &netisr_maxthreads); +SYSCTL_INT(_net_isr, OID_AUTO, maxthreads, CTLFLAG_RD, + &netisr_maxthreads, 0, + "Use at most this many CPUs for netisr processing"); + +static int netisr_bindthreads = 0; /* Bind threads to CPUs. */ +TUNABLE_INT("net.isr.bindthreads", &netisr_bindthreads); +SYSCTL_INT(_net_isr, OID_AUTO, bindthreads, CTLFLAG_RD, + &netisr_bindthreads, 0, "Bind netisr threads to CPUs."); + +/* + * Limit per-workstream queues to at most net.isr.maxqlimit, both for initial + * configuration and later modification using netisr_setqlimit(). + */ +#define NETISR_DEFAULT_MAXQLIMIT 10240 +static u_int netisr_maxqlimit = NETISR_DEFAULT_MAXQLIMIT; +TUNABLE_INT("net.isr.maxqlimit", &netisr_maxqlimit); +SYSCTL_INT(_net_isr, OID_AUTO, maxqlimit, CTLFLAG_RD, + &netisr_maxqlimit, 0, + "Maximum netisr per-protocol, per-CPU queue depth."); + +/* + * The default per-workstream queue limit for protocols that don't initialize + * the nh_qlimit field of their struct netisr_handler. If this is set above + * netisr_maxqlimit, we truncate it to the maximum during boot. + */ +#define NETISR_DEFAULT_DEFAULTQLIMIT 256 +static u_int netisr_defaultqlimit = NETISR_DEFAULT_DEFAULTQLIMIT; +TUNABLE_INT("net.isr.defaultqlimit", &netisr_defaultqlimit); +SYSCTL_INT(_net_isr, OID_AUTO, defaultqlimit, CTLFLAG_RD, + &netisr_defaultqlimit, 0, + "Default netisr per-protocol, per-CPU queue limit if not set by protocol"); + +/* + * Each protocol is described by a struct netisr_proto, which holds all + * global per-protocol information. This data structure is set up by + * netisr_register(), and derived from the public struct netisr_handler. + */ +struct netisr_proto { + const char *np_name; /* Character string protocol name. */ + netisr_handler_t *np_handler; /* Protocol handler. */ + netisr_m2flow_t *np_m2flow; /* Query flow for untagged packet. */ + netisr_m2cpuid_t *np_m2cpuid; /* Query CPU to process packet on. */ + u_int np_qlimit; /* Maximum per-CPU queue depth. */ + u_int np_policy; /* Work placement policy. */ +}; + +#define NETISR_MAXPROT 32 /* Compile-time limit. */ + +/* + * The np array describes all registered protocols, indexed by protocol + * number. + */ +static struct netisr_proto np[NETISR_MAXPROT]; + +/* + * Protocol-specific work for each workstream is described by struct + * netisr_work. Each work descriptor consists of an mbuf queue and + * statistics. + */ +struct netisr_work { + /* + * Packet queue, linked by m_nextpkt. + */ + struct mbuf *nw_head; + struct mbuf *nw_tail; + u_int nw_len; + u_int nw_qlimit; + u_int nw_watermark; + + /* + * Statistics -- written unlocked, but mostly from curcpu. + */ + u_int64_t nw_dispatched; /* Number of direct dispatches. */ + u_int64_t nw_hybrid_dispatched; /* "" hybrid dispatches. */ + u_int64_t nw_qdrops; /* "" drops. */ + u_int64_t nw_queued; /* "" enqueues. */ + u_int64_t nw_handled; /* "" handled in worker. */ +}; + +/* + * Workstreams hold a set of ordered work across each protocol, and are + * described by netisr_workstream. Each workstream is associated with a + * worker thread, which in turn is pinned to a CPU. Work associated with a + * workstream can be processd in other threads during direct dispatch; + * concurrent processing is prevented by the NWS_RUNNING flag, which + * indicates that a thread is already processing the work queue. + */ +struct netisr_workstream { + struct intr_event *nws_intr_event; /* Handler for stream. */ + void *nws_swi_cookie; /* swi(9) cookie for stream. */ + struct mtx nws_mtx; /* Synchronize work. */ + u_int nws_cpu; /* CPU pinning. */ + u_int nws_flags; /* Wakeup flags. */ + u_int nws_pendingbits; /* Scheduled protocols. */ + + /* + * Each protocol has per-workstream data. + */ + struct netisr_work nws_work[NETISR_MAXPROT]; +} __aligned(CACHE_LINE_SIZE); + +/* + * Per-CPU workstream data, indexed by CPU ID. + */ +static struct netisr_workstream nws[MAXCPU]; + +/* + * Map contiguous values between 0 and nws_count into CPU IDs appropriate for + * indexing the nws[] array. This allows constructions of the form + * nws[nws_array(arbitraryvalue % nws_count)]. + */ +static u_int nws_array[MAXCPU]; + +/* + * Number of registered workstreams. Will be at most the number of running + * CPUs once fully started. + */ +static u_int nws_count; +SYSCTL_INT(_net_isr, OID_AUTO, numthreads, CTLFLAG_RD, + &nws_count, 0, "Number of extant netisr threads."); + +/* + * Per-workstream flags. + */ +#define NWS_RUNNING 0x00000001 /* Currently running in a thread. */ +#define NWS_DISPATCHING 0x00000002 /* Currently being direct-dispatched. */ +#define NWS_SCHEDULED 0x00000004 /* Signal issued. */ + +/* + * Synchronization for each workstream: a mutex protects all mutable fields + * in each stream, including per-protocol state (mbuf queues). The SWI is + * woken up if asynchronous dispatch is required. + */ +#define NWS_LOCK(s) mtx_lock(&(s)->nws_mtx) +#define NWS_LOCK_ASSERT(s) mtx_assert(&(s)->nws_mtx, MA_OWNED) +#define NWS_UNLOCK(s) mtx_unlock(&(s)->nws_mtx) +#define NWS_SIGNAL(s) swi_sched((s)->nws_swi_cookie, 0) -struct netisr { - netisr_t *ni_handler; - struct ifqueue *ni_queue; - int ni_flags; -} netisrs[32]; +/* + * Utility routines for protocols that implement their own mapping of flows + * to CPUs. + */ +u_int +netisr_get_cpucount(void) +{ + + return (nws_count); +} -static void *net_ih; +u_int +netisr_get_cpuid(u_int cpunumber) +{ + + KASSERT(cpunumber < nws_count, ("%s: %u > %u", __func__, cpunumber, + nws_count)); + + return (nws_array[cpunumber]); +} + +/* + * The default implementation of -> CPU ID mapping. + * + * Non-static so that protocols can use it to map their own work to specific + * CPUs in a manner consistent to netisr for affinity purposes. + */ +u_int +netisr_default_flow2cpu(u_int flowid) +{ + return (nws_array[flowid % nws_count]); +} + +/* + * Register a new netisr handler, which requires initializing per-protocol + * fields for each workstream. All netisr work is briefly suspended while + * the protocol is installed. + */ void -legacy_setsoftnet(void) +netisr_register(const struct netisr_handler *nhp) { - swi_sched(net_ih, 0); + struct netisr_work *npwp; + const char *name; + u_int i, proto; + + proto = nhp->nh_proto; + name = nhp->nh_name; + + /* + * Test that the requested registration is valid. + */ + KASSERT(nhp->nh_name != NULL, + ("%s: nh_name NULL for %u", __func__, proto)); + KASSERT(nhp->nh_handler != NULL, + ("%s: nh_handler NULL for %s", __func__, name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_SOURCE || + nhp->nh_policy == NETISR_POLICY_FLOW || + nhp->nh_policy == NETISR_POLICY_CPU, + ("%s: unsupported nh_policy %u for %s", __func__, + nhp->nh_policy, name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_FLOW || + nhp->nh_m2flow == NULL, + ("%s: nh_policy != FLOW but m2flow defined for %s", __func__, + name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_CPU || nhp->nh_m2cpuid == NULL, + ("%s: nh_policy != CPU but m2cpuid defined for %s", __func__, + name)); + KASSERT(nhp->nh_policy != NETISR_POLICY_CPU || nhp->nh_m2cpuid != NULL, + ("%s: nh_policy == CPU but m2cpuid not defined for %s", __func__, + name)); + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u, %s): protocol too big", __func__, proto, name)); + + /* + * Test that no existing registration exists for this protocol. + */ + NETISR_WLOCK(); + KASSERT(np[proto].np_name == NULL, + ("%s(%u, %s): name present", __func__, proto, name)); + KASSERT(np[proto].np_handler == NULL, + ("%s(%u, %s): handler present", __func__, proto, name)); + + np[proto].np_name = name; + np[proto].np_handler = nhp->nh_handler; + np[proto].np_m2flow = nhp->nh_m2flow; + np[proto].np_m2cpuid = nhp->nh_m2cpuid; + if (nhp->nh_qlimit == 0) + np[proto].np_qlimit = netisr_defaultqlimit; + else if (nhp->nh_qlimit > netisr_maxqlimit) { + printf("%s: %s requested queue limit %u capped to " + "net.isr.maxqlimit %u\n", __func__, name, nhp->nh_qlimit, + netisr_maxqlimit); + np[proto].np_qlimit = netisr_maxqlimit; + } else + np[proto].np_qlimit = nhp->nh_qlimit; + np[proto].np_policy = nhp->nh_policy; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + bzero(npwp, sizeof(*npwp)); + npwp->nw_qlimit = np[proto].np_qlimit; + } + NETISR_WUNLOCK(); } +/* + * Clear drop counters across all workstreams for a protocol. + */ void -netisr_register(int num, netisr_t *handler, struct ifqueue *inq, int flags) +netisr_clearqdrops(const struct netisr_handler *nhp) { - - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - KASSERT(flags == 0, ("netisr_register: bad flags 0x%x\n", flags)); - netisrs[num].ni_handler = handler; - netisrs[num].ni_queue = inq; - netisrs[num].ni_flags = flags; + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + npwp->nw_qdrops = 0; + } + NETISR_WUNLOCK(); } +/* + * Query the current drop counters across all workstreams for a protocol. + */ void -netisr_unregister(int num) +netisr_getqdrops(const struct netisr_handler *nhp, u_int64_t *qdropp) { - struct netisr *ni; - - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - ni = &netisrs[num]; - ni->ni_handler = NULL; - if (ni->ni_queue != NULL) - IF_DRAIN(ni->ni_queue); - ni->ni_queue = NULL; + struct netisr_work *npwp; + struct rm_priotracker tracker; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + *qdropp = 0; + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_RLOCK(&tracker); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + *qdropp += npwp->nw_qdrops; + } + NETISR_RUNLOCK(&tracker); } -struct isrstat { - int isrs_count; /* dispatch count */ - int isrs_directed; /* ...directly dispatched */ - int isrs_deferred; /* ...queued instead */ - int isrs_queued; /* intentionally queueued */ - int isrs_drop; /* dropped 'cuz no handler */ - int isrs_swi_count; /* swi_net handlers called */ -}; -static struct isrstat isrstat; +/* + * Query the current queue limit for per-workstream queues for a protocol. + */ +void +netisr_getqlimit(const struct netisr_handler *nhp, u_int *qlimitp) +{ + struct rm_priotracker tracker; +#ifdef INVARIANTS + const char *name; +#endif + u_int proto; -SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr counters"); + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); -static int netisr_direct = 1; -SYSCTL_INT(_net_isr, OID_AUTO, direct, CTLFLAG_RW, - &netisr_direct, 0, "enable direct dispatch"); -TUNABLE_INT("net.isr.direct", &netisr_direct); + NETISR_RLOCK(&tracker); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + *qlimitp = np[proto].np_qlimit; + NETISR_RUNLOCK(&tracker); +} + +/* + * Update the queue limit across per-workstream queues for a protocol. We + * simply change the limits, and don't drain overflowed packets as they will + * (hopefully) take care of themselves shortly. + */ +int +netisr_setqlimit(const struct netisr_handler *nhp, u_int qlimit) +{ + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + if (qlimit > netisr_maxqlimit) + return (EINVAL); + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + np[proto].np_qlimit = qlimit; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + npwp->nw_qlimit = qlimit; + } + NETISR_WUNLOCK(); + return (0); +} -SYSCTL_INT(_net_isr, OID_AUTO, count, CTLFLAG_RD, - &isrstat.isrs_count, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, directed, CTLFLAG_RD, - &isrstat.isrs_directed, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, deferred, CTLFLAG_RD, - &isrstat.isrs_deferred, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, queued, CTLFLAG_RD, - &isrstat.isrs_queued, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, drop, CTLFLAG_RD, - &isrstat.isrs_drop, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, swi_count, CTLFLAG_RD, - &isrstat.isrs_swi_count, 0, ""); - -/* - * Process all packets currently present in a netisr queue. Used to - * drain an existing set of packets waiting for processing when we - * begin direct dispatch, to avoid processing packets out of order. +/* + * Drain all packets currently held in a particular protocol work queue. */ static void -netisr_processqueue(struct netisr *ni) +netisr_drain_proto(struct netisr_work *npwp) { struct mbuf *m; - for (;;) { - IF_DEQUEUE(ni->ni_queue, m); - if (m == NULL) - break; - VNET_ASSERT(m->m_pkthdr.rcvif != NULL); - CURVNET_SET(m->m_pkthdr.rcvif->if_vnet); - ni->ni_handler(m); - CURVNET_RESTORE(); + /* + * We would assert the lock on the workstream but it's not passed in. + */ + while ((m = npwp->nw_head) != NULL) { + npwp->nw_head = m->m_nextpkt; + m->m_nextpkt = NULL; + if (npwp->nw_head == NULL) + npwp->nw_tail = NULL; + npwp->nw_len--; + m_freem(m); } + KASSERT(npwp->nw_tail == NULL, ("%s: tail", __func__)); + KASSERT(npwp->nw_len == 0, ("%s: len", __func__)); } /* - * Call the netisr directly instead of queueing the packet, if possible. + * Remove the registration of a network protocol, which requires clearing + * per-protocol fields across all workstreams, including freeing all mbufs in + * the queues at time of unregister. All work in netisr is briefly suspended + * while this takes place. */ void -netisr_dispatch(int num, struct mbuf *m) +netisr_unregister(const struct netisr_handler *nhp) { - struct netisr *ni; - - isrstat.isrs_count++; /* XXX redundant */ - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - ni = &netisrs[num]; - if (ni->ni_queue == NULL) { - isrstat.isrs_drop++; - m_freem(m); - return; + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + np[proto].np_name = NULL; + np[proto].np_handler = NULL; + np[proto].np_m2flow = NULL; + np[proto].np_m2cpuid = NULL; + np[proto].np_qlimit = 0; + np[proto].np_policy = 0; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + netisr_drain_proto(npwp); + bzero(npwp, sizeof(*npwp)); } + NETISR_WUNLOCK(); +} + +/* + * Look up the workstream given a packet and source identifier. Do this by + * checking the protocol's policy, and optionally call out to the protocol + * for assistance if required. + */ +static struct mbuf * +netisr_select_cpuid(struct netisr_proto *npp, uintptr_t source, + struct mbuf *m, u_int *cpuidp) +{ + struct ifnet *ifp; + + NETISR_LOCK_ASSERT(); /* - * Directly dispatch handling of this packet, if permitted by global - * policy. Source ordering is maintained by virtue of callers - * consistently calling one of queued or direct dispatch. + * In the event we have only one worker, shortcut and deliver to it + * without further ado. */ - if (netisr_direct) { - isrstat.isrs_directed++; - ni->ni_handler(m); + if (nws_count == 1) { + *cpuidp = nws_array[0]; + return (m); + } + + /* + * What happens next depends on the policy selected by the protocol. + * If we want to support per-interface policies, we should do that + * here first. + */ + switch (npp->np_policy) { + case NETISR_POLICY_CPU: + return (npp->np_m2cpuid(m, source, cpuidp)); + + case NETISR_POLICY_FLOW: + if (!(m->m_flags & M_FLOWID) && npp->np_m2flow != NULL) { + m = npp->np_m2flow(m, source); + if (m == NULL) + return (NULL); + } + if (m->m_flags & M_FLOWID) { + *cpuidp = + netisr_default_flow2cpu(m->m_pkthdr.flowid); + return (m); + } + /* FALLTHROUGH */ + + case NETISR_POLICY_SOURCE: + ifp = m->m_pkthdr.rcvif; + if (ifp != NULL) + *cpuidp = nws_array[(ifp->if_index + source) % + nws_count]; + else + *cpuidp = nws_array[source % nws_count]; + return (m); + + default: + panic("%s: invalid policy %u for %s", __func__, + npp->np_policy, npp->np_name); + } +} + +/* + * Process packets associated with a workstream and protocol. For reasons of + * fairness, we process up to one complete netisr queue at a time, moving the + * queue to a stack-local queue for processing, but do not loop refreshing + * from the global queue. The caller is responsible for deciding whether to + * loop, and for setting the NWS_RUNNING flag. The passed workstream will be + * locked on entry and relocked before return, but will be released while + * processing. The number of packets processed is returned. + */ +static u_int +netisr_process_workstream_proto(struct netisr_workstream *nwsp, u_int proto) +{ + struct netisr_work local_npw, *npwp; + u_int handled; + struct mbuf *m; + + NETISR_LOCK_ASSERT(); + NWS_LOCK_ASSERT(nwsp); + + KASSERT(nwsp->nws_flags & NWS_RUNNING, + ("%s(%u): not running", __func__, proto)); + KASSERT(proto >= 0 && proto < NETISR_MAXPROT, + ("%s(%u): invalid proto\n", __func__, proto)); + + npwp = &nwsp->nws_work[proto]; + if (npwp->nw_len == 0) + return (0); + + /* + * Move the global work queue to a thread-local work queue. + * + * Notice that this means the effective maximum length of the queue + * is actually twice that of the maximum queue length specified in + * the protocol registration call. + */ + handled = npwp->nw_len; + local_npw = *npwp; + npwp->nw_head = NULL; + npwp->nw_tail = NULL; + npwp->nw_len = 0; + nwsp->nws_pendingbits &= ~(1 << proto); + NWS_UNLOCK(nwsp); + while ((m = local_npw.nw_head) != NULL) { + local_npw.nw_head = m->m_nextpkt; + m->m_nextpkt = NULL; + if (local_npw.nw_head == NULL) + local_npw.nw_tail = NULL; + local_npw.nw_len--; + VNET_ASSERT(m->m_pkthdr.rcvif != NULL); + CURVNET_SET(m->m_pkthdr.rcvif->if_vnet); + np[proto].np_handler(m); + CURVNET_RESTORE(); + } + KASSERT(local_npw.nw_len == 0, + ("%s(%u): len %u", __func__, proto, local_npw.nw_len)); + NWS_LOCK(nwsp); + npwp->nw_handled += handled; + return (handled); +} + +/* + * SWI handler for netisr -- processes prackets in a set of workstreams that + * it owns, woken up by calls to NWS_SIGNAL(). If this workstream is already + * being direct dispatched, go back to sleep and wait for the dispatching + * thread to wake us up again. + */ +static void +swi_net(void *arg) +{ +#ifdef NETISR_LOCKING + struct rm_priotracker tracker; +#endif + struct netisr_workstream *nwsp; + u_int bits, prot; + + nwsp = arg; + +#ifdef DEVICE_POLLING + KASSERT(nws_count == 1, + ("%s: device_polling but nws_count != 1", __func__)); + netisr_poll(); +#endif +#ifdef NETISR_LOCKING + NETISR_RLOCK(&tracker); +#endif + NWS_LOCK(nwsp); + KASSERT(!(nwsp->nws_flags & NWS_RUNNING), ("swi_net: running")); + if (nwsp->nws_flags & NWS_DISPATCHING) + goto out; + nwsp->nws_flags |= NWS_RUNNING; + nwsp->nws_flags &= ~NWS_SCHEDULED; + while ((bits = nwsp->nws_pendingbits) != 0) { + while ((prot = ffs(bits)) != 0) { + prot--; + bits &= ~(1 << prot); + (void)netisr_process_workstream_proto(nwsp, prot); + } + } + nwsp->nws_flags &= ~NWS_RUNNING; +out: + NWS_UNLOCK(nwsp); +#ifdef NETISR_LOCKING + NETISR_RUNLOCK(&tracker); +#endif +#ifdef DEVICE_POLLING + netisr_pollmore(); +#endif +} + +static int +netisr_queue_workstream(struct netisr_workstream *nwsp, u_int proto, + struct netisr_work *npwp, struct mbuf *m, int *dosignalp) +{ + + NWS_LOCK_ASSERT(nwsp); + + *dosignalp = 0; + if (npwp->nw_len < npwp->nw_qlimit) { + m->m_nextpkt = NULL; + if (npwp->nw_head == NULL) { + npwp->nw_head = m; + npwp->nw_tail = m; + } else { + npwp->nw_tail->m_nextpkt = m; + npwp->nw_tail = m; + } + npwp->nw_len++; + if (npwp->nw_len > npwp->nw_watermark) + npwp->nw_watermark = npwp->nw_len; + nwsp->nws_pendingbits |= (1 << proto); + if (!(nwsp->nws_flags & + (NWS_RUNNING | NWS_DISPATCHING | NWS_SCHEDULED))) { + nwsp->nws_flags |= NWS_SCHEDULED; + *dosignalp = 1; /* Defer until unlocked. */ + } *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From rea-fbsd at codelabs.ru Mon Jun 1 11:06:15 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 1 11:06:48 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <4A239B7C.8020403@gmx.de> References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> <4A239B7C.8020403@gmx.de> Message-ID: Christoph, good day. Mon, Jun 01, 2009 at 11:12:28AM +0200, Christoph Mallon wrote: > Eygene Ryabinkin schrieb: > > This is very weird (judging by the GCC's manual) since the simplest C > > program, > > ----- > > int main(void) > > { > > return 0; > > } > > > > void foo(void) __attribute__ ((unused)) > > { > > return; > > } > > ----- > > but ICC 10.x produces the same error and happily chewes __attribute__ > > on the function prototype. Anyway, I see no warnings even without > > '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks > > like no-op nowadays. > > There is no warning about foo() being unused, because it is not static. Yes, you're perfectly right. Thanks for education! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From ohartman at mail.zedat.fu-berlin.de Mon Jun 1 08:13:08 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Mon Jun 1 11:23:25 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <3bbf2fe10905300951o3beea201j72b6e6b96f85c05a@mail.gmail.com> References: <4A2120D5.50300@mail.zedat.fu-berlin.de> <3bbf2fe10905300848s6342a7b1l32340baee8e7e8f1@mail.gmail.com> <4A215D7F.7020807@mail.zedat.fu-berlin.de> <3bbf2fe10905300944r96ae931re4475c78d9be3aa8@mail.gmail.com> <3bbf2fe10905300951o3beea201j72b6e6b96f85c05a@mail.gmail.com> Message-ID: <4A238D95.9020209@mail.zedat.fu-berlin.de> Attilio Rao wrote: > 2009/5/30 Attilio Rao : > >> 2009/5/30 O. Hartmann : >> >>> Attilio Rao wrote: >>> >>>> 2009/5/30 O. Hartmann : >>>> >>>> >>>>> Hello. >>>>> I realized a significant slowdown of FreeBSD 8.0-CURRENT/amd64 on every >>>>> box I run. I have the most recent FreeBSD 8.0-CURRENT/amd64 with custom >>>>> kernel and switched off every debugging. I see a drastic slowdown >>>>> whenever heavy I/O on UFS2 and ZFS partitions is performed and whenever >>>>> some compilation is done (compiling world and kernel). This is horrible >>>>> on a single core Athlon64 CPU with 2GB RAM as well as on a 4 core Q6600 >>>>> with 8GB and a server with 2 x 4-cores and 16GB RAM. >>>>> >>>>> I can not say clearly whether I/O is the bottleneck. Maybe something >>>>> with the memory subsystem, when it comes to compiler runs, when no disk >>>>> I/O is done but the box is still horrible slow. This behaviour occured >>>>> several weeks ago, not being able to specify it more precisely. >>>>> >>>>> AQre there any issues at the moment? >>>>> >>>>> >>>> Your kernel is compiled from which date? >>>> >>>> Thanks, >>>> Attilio >>>> >>>> >>>> >>>> >>> Most recent, say: yesterday! As well as world. >>> >> Can you try to revert only r193011 and see if something changes? >> > > Also, did you compile the single-core athlon64 without the option SMP? > > Thanks, > Attilio > > > Yes, I did of course compile kernel on UP without option SMP and of those with more than on logical core with SMP on. I will try to revert to r193011. Oliver From ohartman at mail.zedat.fu-berlin.de Mon Jun 1 08:30:23 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Mon Jun 1 11:23:41 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> Message-ID: <4A23919F.8050905@mail.zedat.fu-berlin.de> Kip Macy wrote: >> I'm running the r193133 amd64 with a custom kernel and all debugging off >> on an AMD Athlon64 3400+ single-core, and I haven't noticed any significant >> slowing, although I haven't been doing any systematic benchmarking. >> >> What would be the penalties of running an SMP -CURRENT kernel on >> single-core hardware with no hyperthreading? Can anyone quantify the >> typical added overhead? Or, counterintuitively, would an SMP kernel >> be better in some ways? >> >> > > He is trying to diagnose if the problem was introduced by enabling > adaptive spinning on sx locks. They're only enabled on SMP kernels. > > Cheers, > Kip > Well, no SMP on UP AMD CPUs without SMT means no usage of the sx locks. As far as I know, the sx locks were introduced a couple of days ago, weren't they? To avoid any kind of misunderstanding, there is no permanent 'slowdown', it occurs especially whenever the system's compiler builds world or a kernel or heavy I/O activities occur. It seems my boxes, especially the UP box, is freezing, no reaction on X11. Well, first time I thought it is related to UP, low memory or especially new drm code used with X11 for acceleration, but I also realized those 'slowdown-incidents' on boxes with multicores, 8 or more GB of RAM and no X11 installed and running. This performance impact in situations whenever building a world is significant. We did not change the compiler, it is still the old gcc 4.2, so I do not expect an impact from new high-memory and cpu-consuming optimization routines. I do not even benchmark my boxes day for day, but I usually do a set of the same work on those boxes used for scientific work, so while building world even on SMP boxes and working after installation with the same software set reveals some weirdness in some points. I thought this is due some use-uninterruptable debugging switches, some wrote the malloc code is about to change and so on so I was wondering if there is something temporarely going on at the moment where some hints could prevent me from building a world within this testing phase. Just speculation. Greetings, Oliver From ohartman at mail.zedat.fu-berlin.de Mon Jun 1 08:36:51 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Mon Jun 1 11:23:53 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <15091.46749.qm@web39108.mail.mud.yahoo.com> References: <15091.46749.qm@web39108.mail.mud.yahoo.com> Message-ID: <4A239323.1090707@mail.zedat.fu-berlin.de> bf wrote: > > --- On Sat, 5/30/09, Kip Macy wrote: > > >> From: Kip Macy >> Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 >> To: "bf" >> Cc: freebsd-current@freebsd.org, attilio@freebsd.org, ohartman@mail.zedat.fu-berlin.de >> Date: Saturday, May 30, 2009, 11:55 PM >> >>> I'm running the r193133 amd64 with a custom kernel and >>> >> all debugging off >> >>> on an AMD Athlon64 3400+ single-core, and I haven't >>> >> noticed any significant >> >>> slowing, although I haven't been doing any systematic >>> >> benchmarking. >> >>> What would be the penalties of running an SMP -CURRENT >>> >> kernel on >> >>> single-core hardware with no hyperthreading? Can >>> >> anyone quantify the >> >>> typical added overhead? Or, counterintuitively, >>> >> would an SMP kernel >> >>> be better in some ways? >>> >>> >> He is trying to diagnose if the problem was introduced by >> enabling >> adaptive spinning on sx locks. They're only enabled on SMP >> kernels. >> >> Cheers, >> Kip >> >> > > So I inferred from his request to have Oliver (the original poster) > revert r193011. But it seems unlikely that this is solely or even mostly > responsible for the slowdown, as Oliver reported that it first began > to occur several weeks ago, and Attilio only committed r193011 on Friday > -- unless Oliver independently added ADAPTIVE_SX to his custom kernel > a few weeks ago. In any event, I'm still interested in any reports of > the relative performance of SMP vs. UP kernels on UP hardware that > anyone is able to share. > > Thanks, > b. > > > > Would the addition of ADAPTIVE_SX to a SMP kernel or kernel of any kind have perfomance issues, also performance gains? From imb at protected-networks.net Mon Jun 1 11:53:51 2009 From: imb at protected-networks.net (Michael Butler) Date: Mon Jun 1 11:53:57 2009 Subject: fusefs-kmod now broken Message-ID: <4A23C147.2000607@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Recent changes to VFS appear to have broken the FUSE kernel module :-( cc -O2 -pipe -march=prescott -fno-strict-aliasing -march=prescott - -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ - -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 - --param large-function-growth=1000 -fno-common -mno-align-long-strings - -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 - -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 - -fstack-protector -Wall -Wredundant-decls -Wnested-externs - -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c fuse_io.c cc1: warnings being treated as errors fuse_io.c: In function 'fuse_write_biobackend': fuse_io.c:752: warning: implicit declaration of function 'vfs_bio_set_validclean' fuse_io.c:752: warning: nested extern declaration of 'vfs_bio_set_validclean' *** Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module. *** Error code 1 Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkojwUcACgkQQv9rrgRC1JK0WwCfaG8Qt74iZ/QQ9x3LSIB0TyLG Zj4AoJRI2UIFhRBZPbOMsaec3CpMgTNj =o2IF -----END PGP SIGNATURE----- From avg at icyb.net.ua Mon Jun 1 12:05:46 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Jun 1 12:05:59 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <2492E55D-5C36-4A93-BB69-B1539AAB0087@mukaibo.com> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> <4A1E9B34.3040202@icyb.net.ua> <2492E55D-5C36-4A93-BB69-B1539AAB0087@mukaibo.com> Message-ID: <4A23C409.70704@icyb.net.ua> on 30/05/2009 03:44 Timothy Mukaibo said the following: > Hello Andriy, > > timothy@tinkysama:~$ cat /boot/loader.conf > snd_hda_load="YES" > uscanner_load="YES" > > Here's the dmesg: it didn't look like a verbose one... -- Andriy Gapon From randy at psg.com Mon Jun 1 12:26:34 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 12:26:40 2009 Subject: segfault in buildworld while creating osreldate.h Message-ID: amd64 fresh svn of head made and installed kernel. rebooted. ... ===> gnu/usr.bin/texinfo (installincludes) ===> gnu/usr.bin/texinfo/libtxi (installincludes) ===> gnu/usr.bin/texinfo/makeinfo (installincludes) ===> gnu/usr.bin/texinfo/info (installincludes) ===> gnu/usr.bin/texinfo/infokey (installincludes) ===> gnu/usr.bin/texinfo/install-info (installincludes) ===> gnu/usr.bin/texinfo/texindex (installincludes) ===> gnu/usr.bin/texinfo/doc (installincludes) ===> include (includes) cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh Segmentation fault (core dumped) *** Error code 139 it left no core randy From rwatson at FreeBSD.org Mon Jun 1 13:07:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 13:17:12 2009 Subject: yakpf In-Reply-To: References: Message-ID: On Mon, 1 Jun 2009, Randy Bush wrote: >> Is it possible to use options KDB_TRACE and KDB_PANIC to dump a stack trace >> to the serial console to use as a starting point for debugging? > > increase size or weight of clue bat please. > > /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 > > /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 Probably on myself. What I was actually looking for KDB_TRACE and KDB_UNATTENDED, which should print a stack trace and reboot on panic. Robert N M Watson Computer Laboratory University of Cambridge From pluknet at gmail.com Mon Jun 1 13:20:13 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jun 1 13:20:20 2009 Subject: fusefs-kmod now broken In-Reply-To: <4A23C147.2000607@protected-networks.net> References: <4A23C147.2000607@protected-networks.net> Message-ID: 2009/6/1 Michael Butler : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Recent changes to VFS appear to have broken the FUSE kernel module :-( > > cc -O2 -pipe -march=prescott -fno-strict-aliasing -march=prescott > - -Werror -D_KERNEL -DKLD_MODULE -nostdinc ?-I../include -I. -I@ > - -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > - --param large-function-growth=1000 -fno-common ?-mno-align-long-strings > - -mpreferred-stack-boundary=2 ?-mno-mmx -mno-3dnow -mno-sse -mno-sse2 > - -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 > - -fstack-protector -Wall -Wredundant-decls -Wnested-externs > - -Wstrict-prototypes ?-Wmissing-prototypes -Wpointer-arith -Winline > - -Wcast-qual ?-Wundef -Wno-pointer-sign -fformat-extensions -c fuse_io.c > cc1: warnings being treated as errors > fuse_io.c: In function 'fuse_write_biobackend': > fuse_io.c:752: warning: implicit declaration of function > 'vfs_bio_set_validclean' > fuse_io.c:752: warning: nested extern declaration of > 'vfs_bio_set_validclean' > *** Error code 1 I guess you can safely substitute that with 'vfs_bio_set_valid' and friends. As at whole AFAICS that's already out of sync with -current VM. -- wbr, pluknet -------------- next part -------------- A non-text attachment was scrubbed... Name: fusefs_kmod.diff Type: application/octet-stream Size: 3445 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090601/b136485a/fusefs_kmod.obj From avg at icyb.net.ua Mon Jun 1 13:20:39 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Jun 1 13:20:49 2009 Subject: fsck_y_enable: use -C Message-ID: <4A23D5A4.6020009@icyb.net.ua> What about the following patch? I believe that the idea behind fsck_y_enable is to try to make unattended systems with rw filesystems as recoverable as possible at the cost of potential damage to the data. The new "-C" option should not interfere with this goal, but should reduce recovery time, because currently fsck -y checks *all* filesystems from fstab, even those that are ro or clean: -C Check if the ?clean? flag is set in the superblock and skip file system checks if file system was properly dismounted and marked clean. diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck index bf51089..c0cb359 100755 --- a/etc/rc.d/fsck +++ b/etc/rc.d/fsck @@ -45,7 +45,7 @@ fsck_start() 8) if checkyesno fsck_y_enable; then echo "File system preen failed, trying fsck -y." - fsck -y + fsck -y -C case $? in 0) ;; -- Andriy Gapon From rwatson at FreeBSD.org Mon Jun 1 14:03:26 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 14:03:33 2009 Subject: Processes stuck in [vmo_de] Message-ID: Was doing a local build on a VMWare 8.x image today, and ran into this: rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../dev/ath -I../../../dev/ath/ath_hal -I../../../contrib/ngatm -I../../../dev/twa -I../../../gnu/fs/xfs/FreeBSD -I../../../gnu/fs/xfs/FreeBSD/support -I../../../gnu/fs/xfs -I../../../contrib/opensolaris/compat -I../../../dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k ^Z Suspended robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> bg [1] make depend & robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> fg make depend load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k ^C load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k ^C^C^C load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k ^C^C^C (another pty) robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/sys> ps axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND ... 1001 5038 5037 0 76 0 5592 3012 pause Ss 4 0:00.00 -tcsh (tcsh 1001 5054 5038 0 76 0 8032 6764 wait S+ 4 0:00.00 make depend 1001 5098 5054 0 76 0 3572 1796 wait S+ 4 0:00.00 [sh] 1001 5099 5098 0 76 0 0 8 vmo_de D+ 4 0:00.00 [sh] And unfortunately: robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> su Password: load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k FreeBSD cinnamon-freebsd 8.0-CURRENT FreeBSD 8.0-CURRENT #5 r193116M: Sun May 31 10:14:00 BST 2009 robert@cinnamon-freebsd:/usr/home/robert/freebsd/svncommit/base/projects/pnet/sys/i386/compile/GENERIC i386 This appears to be head from a few days ago, but I don't have a specific source code date. Unfortunately, no BREAK_TO_DEBUGGER, and I can't su to enter via debug.kdb.enter. Robert N M Watson Computer Laboratory University of Cambridge From randy at psg.com Mon Jun 1 14:29:31 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 14:29:38 2009 Subject: installworld failure In-Reply-To: References: Message-ID: > 8-current a few hours old, i386 > ===> usr.bin/ee (install) > install -s -o root -g wheel -m 555 ee /usr/bin > cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > gencat:No such file or directory > *** Error code 1 another 8-current, and amd64 freshly svn ==> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib ln -fs /lib/libc.so.7 /usr/lib/libc.so install -o root -g wheel -m 444 libc_pic.a /usr/lib gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg gencat:No such file or directory *** Error code 1 gencat and the file both exist /usr/src# gencat FOO /usr/src/lib/libc/nls/be_BY.UTF-8.msg /usr/src# ls -l FOO -rw-r--r-- 1 root wheel 7551 Jun 1 14:27 FOO pr filed randy From rwatson at FreeBSD.org Mon Jun 1 14:56:48 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 14:56:55 2009 Subject: scheduler IPIs during shutdown (was: svn commit: r193170 - projects/pnet/sys/kern (fwd)) In-Reply-To: References: Message-ID: On Sun, 31 May 2009, Robert Watson wrote: > - System shutdown kicks off, and CPU 0 starts IPIing CPUs to shut them down, > which apparently can occur while holding the thread lock: Just ran into a very similar issue on another i386 box, this one a VMWare VM -- hand transcribed, I'm afraid: db> bt Tracing pid 1 tid 100002 td 0xc456fd80 kdb_enter() panic() _mtx_lock_spin_failed() _thread_lock_flags() hardclock_cpu() hardclock() lapic_handle_timer() Xtimerint() --- interrupt DELAY() cpu_reset() shutdown_reset() boot() reboot() syscall() Xint0x80_syscall() db> show alllocks Process 1 (init) thread 0xc456fd80 (100002) exclusive sleep mutx Giant (Giant) ... db> trace 100003 <-- idle thread on cpu 1 cpustop_handler() ipi_nmi_handler() trap() calltrap() --- trap 0x13 tdq_move() sched_idletd() fork_exit() fork_trampoline() It looks like (a) we should really be disabling interrupts before the DELAY() so we don't have to deal with hardclock, and (b) perhaps an NMI for cpustop isn't the right thing, since it stops CPUs while they hold spinlocks? Robert N M Watson Computer Laboratory University of Cambridge > > db> trace 100005 > Tracing pid 11 tid 100005 td 0xc4d546c0 > cpustop_handler(2,c4a53b64,c0b70cad,c0d9c680,c4a53ae4,...) at > cpustop_handler+0x32 > ipi_nmi_handler(c0d9c680,c4a53ae4,2,f,c4d52a90,...) at ipi_nmi_handler+0x2f > trap(c4a53b70) at trap+0x2d > calltrap() at calltrap+0x6 > --- trap 0x13, eip = 0xc0887a61, esp = 0xc4a53bb0, ebp = 0xc4a53bdc --- > sched_switch(c4d546c0,0,60c,187,5dd9d2a1,...) at sched_switch+0x401 > mi_switch(60c,0,c0c3d1ae,813,1,...) at mi_switch+0x200 > sched_preempt(c4d546c0,1,c4d54d80,c4a53cb4,c0b5428e,...) at > sched_preempt+0x9f > ipi_bitmap_handler(8,28,28,31,c0d8e500,...) at ipi_bitmap_handler+0x34 > Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x2e > --- interrupt, eip = 0xc0856a17, esp = 0xc4a53c8c, ebp = 0xc4a53cb4 --- > _thread_lock_flags(c4d546c0,0,c0c3d1ae,a04,c4d546c0,...) at > _thread_lock_flags+0x177 > sched_idletd(0,c4a53d38,c0c36ad3,335,c4d52a90,...) at sched_idletd+0x251 > fork_exit(c0888510,0,c4a53d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc4a53d70, ebp = 0 --- > > > - hardclock fires on CPU 0 and tries to schedule a SWI -- typically softclock > or netisr, which bumps into the "leaked" thread lock: > > db> bt > Tracing pid 1 tid 100002 td 0xc4d54d80 > kdb_enter(c0c3b5e5,c0c3b5e5,c0c39ccd,c4a49ad0,0,...) at kdb_enter+0x3a > panic(c0c39ccd,c4d546c0,c0d8eb44,c4d546c0,186a5,...) at panic+0x136 > _mtx_lock_spin_failed(1,9,c0c36d52,320,0,...) at _mtx_lock_spin_failed+0x51 > _thread_lock_flags(c4d54240,0,c0c36d52,320,dd313180,...) at > _thread_lock_flags+0x175 > intr_event_schedule_thread(c4a49b58,c4a49b68,c0915dc4,c4d3a180,0,...) at > intr_event_schedule_thread+0xc7 > swi_sched(c4d3a180,0,c4a49b74,c0859a2f,c0d893d4,...) at swi_sched+0x28 > netisr_sched_poll(c0d893d4,c4a49b88,c0824064,0,2,...) at > netisr_sched_poll+0x24 > hardclock_device_poll(0,2) at hardclock_device_poll+0xcf > hardclock(0,c0b74a49,0,27f,5dd9e8a2,...) at hardclock+0x44 > lapic_handle_timer(c4a49bb0) at lapic_handle_timer+0x9f > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip = 0xc0b74a49, esp = 0xc4a49bf0, ebp = 0xc4a49c0c --- > DELAY(f4240,0,c4d40980,c4a49c2c,c08653d3,...) at DELAY+0x89 > cpu_reset(f4240,c4a49c68,c0865eaf,0,0,...) at cpu_reset+0xd5 > shutdown_reset(0,0,c0c3b4a3,1a7,0,...) at shutdown_reset+0x23 > boot(c0d89210,0,c0c3b4a3,ad,c4a49d2c,...) at boot+0x75f > reboot(c4d54d80,c4a49cf8,4,c0c428a4,c0d1dc28,...) at reboot+0x4b > syscall(c4a49d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > Possibly hardclock should simply know not to kick off softclock at that point > in the shutdown (just like I've taught it not to kick off netisr in the > device_polling code in my branch), but more generally, sched_ule probably > needs to not hold the per-cpu runqueue lock, and/or sched_ule needs to not > try to start work on CPUs that aren't running. If the SWI is pinned on or > bound to an already shut down CPU, then we should in fact panic, but > otherwise it seems it should preempt the current thread and run it on the CPU > managing the shutdown. > > Or, we could go with the old-world order view and not allow interrupts to > fire, but I wonder if all our device drivers would be comfortable with that. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 31 May 2009 13:52:17 +0000 (UTC) > From: Robert Watson > To: src-committers@freebsd.org, svn-src-projects@freebsd.org > Subject: svn commit: r193170 - projects/pnet/sys/kern > > Author: rwatson > Date: Sun May 31 13:52:17 2009 > New Revision: 193170 > URL: http://svn.freebsd.org/changeset/base/193170 > > Log: > Add a shutdown handler for device polling -- don't issue wakeups to the > netisr once file systems are done syncing, otherwise the scheduler may > generate IPIs to CPUs that have already been shutdown, leading to a > panic. > > As similar panics (spin lock 0xc0d8e500 (sched lock 1) held by > 0xc4d546c0 (tid 100005) too long) have been reported on both 7.x and 8.x > in other code, we might want to think about whether there's some missing > scheduler shutdown logic to handle this case for unpinned/unbound > threads by migrating them to the CPU managing the shutdown and allowing > them to preempt. > > Modified: > projects/pnet/sys/kern/kern_poll.c > > Modified: projects/pnet/sys/kern/kern_poll.c > ============================================================================== > --- projects/pnet/sys/kern/kern_poll.c Sun May 31 12:36:14 2009 > (r193169) > +++ projects/pnet/sys/kern/kern_poll.c Sun May 31 13:52:17 2009 > (r193170) > @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include /* needed by net/if.h > */ > #include > @@ -110,6 +111,7 @@ SYSCTL_UINT(_kern_polling, OID_AUTO, bur > > static int netisr_poll_scheduled; > static int netisr_pollmore_scheduled; > +static int poll_shutting_down; > > static int poll_burst_max_sysctl(SYSCTL_HANDLER_ARGS) > { > @@ -261,10 +263,19 @@ struct pollrec { > static struct pollrec pr[POLL_LIST_LEN]; > > static void > +poll_shutdown(void *arg, int howto) > +{ > + > + poll_shutting_down = 1; > +} > + > +static void > init_device_poll(void) > { > > mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); > + EVENTHANDLER_REGISTER(shutdown_post_sync, poll_shutdown, NULL, > + SHUTDOWN_PRI_LAST); > } > SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, > NULL); > > @@ -288,7 +299,7 @@ hardclock_device_poll(void) > static struct timeval prev_t, t; > int delta; > > - if (poll_handlers == 0) > + if (poll_handlers == 0 || poll_shutting_down) > return; > > microuptime(&t); > _______________________________________________ > 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 rea-fbsd at codelabs.ru Mon Jun 1 14:58:46 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 1 14:58:53 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: Randy, good day. Mon, Jun 01, 2009 at 09:45:52AM +0900, Randy Bush wrote: > >>> ===> usr.bin/ee (install) > >>> install -s -o root -g wheel -m 555 ee /usr/bin > >>> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > >>> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > >>> gencat:No such file or directory [...] > > > > You should have gencat allready installed: > > > > cd /usr/src/usr.bin/gencat && make install > > gencat is installed. it is whining that it can not find the file May be gencat is installed, but 'make install' could not find it: message "gencat:No such file or directory" comes from make, not from gencat itself. Will you be able to run 'make clean; make; make install' from /usr/src/usr.bin/ee to see if the problem is specific to the 'make installworld' or shows even for manual installation? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From avg at freebsd.org Mon Jun 1 15:07:56 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 15:08:09 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A1FD687.5070502@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> Message-ID: <4A23EEC8.2040208@freebsd.org> on 29/05/2009 15:35 Andriy Gapon said the following: > So anyone else feels that this is a bug? > > on 28/05/2009 16:55 Andriy Gapon said the following: >> on 28/05/2009 16:26 Henri Hennebert said the following: >>> (gdb) bt >>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >> I find the above part interesting. >> Could this be because of the following discrepancy: >> >> 1) >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >> extern void __assert(const char *, const char *, int); >> 2) >> lib/libc/gen/assert.c: >> void >> __assert(func, file, line, failedexpr) >> const char *func, *file; >> int line; >> const char *failedexpr; >> >>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 I propose the following patch for this issue. It fixes mismatch between __assert extern declaration in zfs code and actual signature in libc code. I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that those checks are not needed with compilers that can be used to compile FreeBSD. Besides, both branches of __STDC_VERSION__ check were exactly the same. Henri, if you still experience that crash of zpool command, could you please try the patch and see if you have a nicer assert message and stacktrace now? Sorry, that this is still not a fix for the real issue. diff --git a/cddl/contrib/opensolaris/head/assert.h b/cddl/contrib/opensolaris/head/assert.h index 394820a..c2a4936 100644 --- a/cddl/contrib/opensolaris/head/assert.h +++ b/cddl/contrib/opensolaris/head/assert.h @@ -37,15 +37,7 @@ extern "C" { #endif -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -extern void __assert(const char *, const char *, int); -#else -extern void __assert(const char *, const char *, int); -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -extern void _assert(); -#endif +extern void __assert(const char *, const char *, int, const char *); #ifdef __cplusplus } @@ -68,14 +60,6 @@ extern void _assert(); #else -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #endif /* NDEBUG */ diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h index 7ae7f9d..631e302 100644 --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); #define fm_panic panic /* This definition is copied from assert.h. */ -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ - +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #define VERIFY verify #define ASSERT assert -extern void __assert(const char *, const char *, int); +extern void __assert(const char *, const char *, int, const char *); #ifdef lint #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ #LEFT, #OP, #RIGHT, \ (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ - __assert(__buf, __FILE__, __LINE__); \ + __assert(__func__, __FILE__, __LINE__, __buf); \ } \ _NOTE(CONSTCOND) } while (0) /* END CSTYLED */ -- Andriy Gapon From avg at freebsd.org Mon Jun 1 15:17:49 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 15:17:55 2009 Subject: fixing kobj signatures In-Reply-To: <4A202148.9090108@gmail.com> References: <4A1FEE04.1060202@freebsd.org> <4A202148.9090108@gmail.com> Message-ID: <4A23F119.5050103@freebsd.org> on 29/05/2009 20:54 Ulf Lilleengen said the following: Andriy Gapon wrote: [...] > The current diff here: > http://people.freebsd.org/~avg/ > > It is quite arbitrarily split into the following files: > kobj-agp.diff > kobj-arm.diff > kobj-linker.diff > kobj-other.diff > kobj-sound.diff I have uploaded updated diffs that account for comments from jhb and lulf. -- Andriy Gapon From onemda at gmail.com Mon Jun 1 15:22:58 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Jun 1 15:23:04 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A23D5A4.6020009@icyb.net.ua> References: <4A23D5A4.6020009@icyb.net.ua> Message-ID: <3a142e750906010822s8538b65kdd529d2267ec7d41@mail.gmail.com> On 6/1/09, Andriy Gapon wrote: > > What about the following patch? > I believe that the idea behind fsck_y_enable is to try to make unattended > systems > with rw filesystems as recoverable as possible at the cost of potential > damage to > the data. The new "-C" option should not interfere with this goal, but > should > reduce recovery time, because currently fsck -y checks *all* filesystems > from > fstab, even those that are ro or clean: > > -C Check if the ?clean? flag is set in the superblock and skip file > system checks if file system was properly dismounted and marked > clean. > > > diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck > index bf51089..c0cb359 100755 > --- a/etc/rc.d/fsck > +++ b/etc/rc.d/fsck > @@ -45,7 +45,7 @@ fsck_start() > 8) > if checkyesno fsck_y_enable; then > echo "File system preen failed, trying fsck -y." > - fsck -y > + fsck -y -C > case $? in > 0) > ;; > > -- > Andriy Gapon > _______________________________________________ > 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" > +1 -- Paul From avg at freebsd.org Mon Jun 1 15:33:16 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 15:33:23 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A23D5A4.6020009@icyb.net.ua> References: <4A23D5A4.6020009@icyb.net.ua> Message-ID: <4A23F4B8.7000002@freebsd.org> on 01/06/2009 16:20 Andriy Gapon said the following: > What about the following patch? > I believe that the idea behind fsck_y_enable is to try to make unattended systems > with rw filesystems as recoverable as possible at the cost of potential damage to > the data. The new "-C" option should not interfere with this goal, but should > reduce recovery time, because currently fsck -y checks *all* filesystems from > fstab, even those that are ro or clean: > > -C Check if the ?clean? flag is set in the superblock and skip file > system checks if file system was properly dismounted and marked > clean. > One potential issue that I've just thought of is that fsck_msdosfs doesn't seem to support this option (even in a dummy way), so it would be a problem for those who have msdos filesystems in fstab and also have fsck_y_enable. > diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck > index bf51089..c0cb359 100755 > --- a/etc/rc.d/fsck > +++ b/etc/rc.d/fsck > @@ -45,7 +45,7 @@ fsck_start() > 8) > if checkyesno fsck_y_enable; then > echo "File system preen failed, trying fsck -y." > - fsck -y > + fsck -y -C > case $? in > 0) > ;; > -- Andriy Gapon From hselasky at c2i.net Mon Jun 1 15:53:26 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 1 15:53:33 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: References: Message-ID: <200906011757.31908.hselasky@c2i.net> On Monday 01 June 2009, Robert Watson wrote: > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. In practice, most behavior remains identical > in the default configuration (direct dispatch, single netisr thread that's > not bound to a CPU, etc), but people will want to watch out for problems. > Some default queue limits have been raised. > > More functional changes to take advantage of these features, such as > deferred ethernet dispatch and software flow ID generation, will follow as > patches, but probably not ship in 8.0 out of the box. > Hi, Having WITNESS and INVARIANTS in the kernel config I get a panic about a NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 has been properly setup. CPU: 2-HTT Workaround: net.isr.direct=0 net.isr.direct_force=0 --HPS From hlh at restart.be Mon Jun 1 16:12:30 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 16:12:38 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A23EEC8.2040208@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> Message-ID: <4A23FDE5.1040101@restart.be> Andriy Gapon wrote: > on 29/05/2009 15:35 Andriy Gapon said the following: >> So anyone else feels that this is a bug? >> >> on 28/05/2009 16:55 Andriy Gapon said the following: >>> on 28/05/2009 16:26 Henri Hennebert said the following: >>>> (gdb) bt >>>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >>> I find the above part interesting. >>> Could this be because of the following discrepancy: >>> >>> 1) >>> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >>> extern void __assert(const char *, const char *, int); >>> 2) >>> lib/libc/gen/assert.c: >>> void >>> __assert(func, file, line, failedexpr) >>> const char *func, *file; >>> int line; >>> const char *failedexpr; >>> >>>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 > > I propose the following patch for this issue. > It fixes mismatch between __assert extern declaration in zfs code and actual > signature in libc code. > I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that > those checks are not needed with compilers that can be used to compile FreeBSD. > Besides, both branches of __STDC_VERSION__ check were exactly the same. > > Henri, > > if you still experience that crash of zpool command, could you please try the > patch and see if you have a nicer assert message and stacktrace now? > Sorry, that this is still not a fix for the real issue. > > diff --git a/cddl/contrib/opensolaris/head/assert.h > b/cddl/contrib/opensolaris/head/assert.h > index 394820a..c2a4936 100644 > --- a/cddl/contrib/opensolaris/head/assert.h > +++ b/cddl/contrib/opensolaris/head/assert.h > @@ -37,15 +37,7 @@ > extern "C" { > #endif > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -extern void __assert(const char *, const char *, int); > -#else > -extern void __assert(const char *, const char *, int); > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -extern void _assert(); > -#endif > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef __cplusplus > } > @@ -68,14 +60,6 @@ extern void _assert(); > > #else > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #endif /* NDEBUG */ > diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > index 7ae7f9d..631e302 100644 > --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); > #define fm_panic panic > > /* This definition is copied from assert.h. */ > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > - > +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #define VERIFY verify > #define ASSERT assert > > -extern void __assert(const char *, const char *, int); > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef lint > #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) > @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); > (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ > #LEFT, #OP, #RIGHT, \ > (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ > - __assert(__buf, __FILE__, __LINE__); \ > + __assert(__func__, __FILE__, __LINE__, __buf); \ > } \ > _NOTE(CONSTCOND) } while (0) > /* END CSTYLED */ > > Here is the new bt after the patch [root@avoriaz libzpool]# gdb zdb 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 "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100178] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100178)] [New Thread 0x801802240 (LWP 100345)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100346)] [New Thread 0x801802560 (LWP 100347)] [New Thread 0x8018026f0 (LWP 100348)] [New Thread 0x801802880 (LWP 100349)] [New Thread 0x801802a10 (LWP 100350)] [New Thread 0x801802ba0 (LWP 100351)] [New Thread 0x801802d30 (LWP 100352)] [New Thread 0x801802ec0 (LWP 100353)] [New Thread 0x801803050 (LWP 100354)] [New Thread 0x8018031e0 (LWP 100355)] [New Thread 0x801803370 (LWP 100356)] [New Thread 0x801803500 (LWP 100357)] [New Thread 0x801803690 (LWP 100358)] [New Thread 0x801803820 (LWP 100359)] [New Thread 0x8018039b0 (LWP 100360)] [New Thread 0x801803b40 (LWP 100361)] [New Thread 0x801803cd0 (LWP 100362)] [New Thread 0x801803e60 (LWP 100363)] [New Thread 0x801803ff0 (LWP 100364)] [New Thread 0x801804180 (LWP 100365)] [New Thread 0x801804310 (LWP 100366)] [New Thread 0x8018044a0 (LWP 100367)] [New Thread 0x801804630 (LWP 100368)] [New Thread 0x8018047c0 (LWP 100369)] [New Thread 0x801804950 (LWP 100370)] [New Thread 0x801804ae0 (LWP 100371)] Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Program received signal SIGABRT, Aborted. [Switching to Thread 0x8018020b0 (LWP 100178)] 0x000000080121fadc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 #1 0x00000008012af06b in abort () from /lib/libc.so.7 #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #4 0x0000000801030287 in dsl_dataset_evict (db=Variable "db" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:266 #5 0x0000000801048b61 in dbuf_evict_user (db=0x8018ca960) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:215 #6 0x000000080104a8c3 in dbuf_rele (db=0x8018ca960, tag=Variable "tag" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1739 #7 0x0000000801029276 in dsl_pool_open (spa=0x8018a2000, txg=Variable "txg" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:139 #8 0x000000080101d503 in spa_load (spa=0x8018a2000, config=Variable "config" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1134 #9 0x000000080101e060 in spa_open_common (pool=0x7fffffffed6e "pool1", spapp=0x7fffffffeb08, tag=0x40b790, config=0x0) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1474 #10 0x0000000000408b41 in ?? () #11 0x00000000004036de in ?? () #12 0x0000000800534000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000002 in ?? () #15 0x00007fffffffed60 in ?? () #16 0x00007fffffffed6e in ?? () #17 0x0000000000000000 in ?? () #18 0x00007fffffffed74 in ?? () #19 0x00007fffffffed8a in ?? () #20 0x00007fffffffed95 in ?? () #21 0x00007fffffffedaf in ?? () #22 0x00007fffffffedda in ?? () #23 0x00007fffffffedf7 in ?? () #24 0x00007fffffffee0a in ?? () #25 0x00007fffffffee14 in ?? () #26 0x00007fffffffee1f in ?? () #27 0x00007fffffffee2b in ?? () #28 0x00007fffffffee40 in ?? () #29 0x00007fffffffee54 in ?? () #30 0x00007fffffffeeae in ?? () #31 0x00007fffffffeebd in ?? () #32 0x00007fffffffeec9 in ?? () #33 0x00007fffffffeee8 in ?? () #34 0x00007fffffffeef5 in ?? () #35 0x00007fffffffef0a in ?? () #36 0x00007fffffffef1c in ?? () #37 0x00007fffffffef25 in ?? () #38 0x00007fffffffef35 in ?? () #39 0x00007fffffffef3d in ?? () #40 0x00007fffffffef66 in ?? () #41 0x00007fffffffef73 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000003 in ?? () #44 0x0000000000400040 in ?? () #45 0x0000000000000004 in ?? () #46 0x0000000000000038 in ?? () #47 0x0000000000000005 in ?? () #48 0x0000000000000007 in ?? () #49 0x0000000000000006 in ?? () #50 0x0000000000001000 in ?? () #51 0x0000000000000008 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000009 in ?? () #54 0x0000000000403650 in ?? () #55 0x0000000000000007 in ?? () #56 0x000000080050c000 in ?? () #57 0x0000000000000000 in ?? () ---Type to continue, or q to quit---q Quit (gdb) q The program is running. Exit anyway? (y or n) yes [root@avoriaz libzpool]# Henri From bms at incunabulum.com Mon Jun 1 15:50:01 2009 From: bms at incunabulum.com (Bruce Simpson) Date: Mon Jun 1 16:12:44 2009 Subject: panic: igmp_v3_dispatch_general_query: called when version 2 In-Reply-To: <4A2325F1.8010300@gmail.com> References: <4A1DD57A.7010704@gmail.com> <4A1E9831.4010606@incunabulum.net> <4A1EC8FB.6090206@gmail.com> <4A1FBFF5.6090103@incunabulum.net> <4A20791D.5070209@gmail.com> <4A22E2F1.6070404@incunabulum.net> <4A2325F1.8010300@gmail.com> Message-ID: <4A23F421.8070809@incunabulum.com> deeptech71@gmail.com wrote: >> >> Thanks. Can you please test this patch and let me know if it works >> for you? > > OK, applied, but what now? If you are sure that you have fixed the > bug, but just want me to run a "crash test" before commiting, then all > I can say is there's nothing wrong yet, I'll keep running the patch > until something comes up, like a panic (and report it). Otherwise I > can't test wether the patch does avoid the non-reproducable panic. I believe (without reproducing it) that the problem was igmp_v3_cancel_link_timers() not cancelling the v3 link timer in all situations. The panic you saw was due to a v3 timer firing even though the timer should have been cancelled by reception of the v2 query from your university's LAN router. The RFC could be worded better about how the 'Older Querier' timer is heeded -- on re-reading it makes sense not to flap between IGMP versions -- the oldest version in use on the link persists for up to 260s with the default protocol timers, only switching version after the timer expires is best as it provides some built-in hysteresis. It sounds like the fix is OK. Obviously, let me know if you see problems again, I've checked the patch into HEAD now. thanks, BMS From avg at freebsd.org Mon Jun 1 16:23:04 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 16:23:31 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A23FDE5.1040101@restart.be> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> Message-ID: <4A240063.207@freebsd.org> on 01/06/2009 19:12 Henri Hennebert said the following: > Andriy Gapon wrote: >> I propose the following patch for this issue. >> It fixes mismatch between __assert extern declaration in zfs code and >> actual >> signature in libc code. >> I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. >> I think that >> those checks are not needed with compilers that can be used to compile >> FreeBSD. >> Besides, both branches of __STDC_VERSION__ check were exactly the same. >> >> Henri, >> >> if you still experience that crash of zpool command, could you please >> try the >> patch and see if you have a nicer assert message and stacktrace now? >> Sorry, that this is still not a fix for the real issue. >> > Here is the new bt after the patch Henri, thank you very much for testing! It look like the patch did its job. P.S. hopefully someone is looking into the cause of the assertion. > Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 112. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x8018020b0 (LWP 100178)] > 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > #1 0x00000008012af06b in abort () from /lib/libc.so.7 > #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 > #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at -- Andriy Gapon From dougb at FreeBSD.org Mon Jun 1 16:35:03 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 16:35:17 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A23F4B8.7000002@freebsd.org> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> Message-ID: <4A240331.1000803@FreeBSD.org> Andriy Gapon wrote: > on 01/06/2009 16:20 Andriy Gapon said the following: >> What about the following patch? >> I believe that the idea behind fsck_y_enable is to try to make unattended systems >> with rw filesystems as recoverable as possible at the cost of potential damage to >> the data. The new "-C" option should not interfere with this goal, but should >> reduce recovery time, because currently fsck -y checks *all* filesystems from >> fstab, even those that are ro or clean: >> >> -C Check if the ?clean? flag is set in the superblock and skip file >> system checks if file system was properly dismounted and marked >> clean. >> > > One potential issue that I've just thought of is that fsck_msdosfs doesn't seem to > support this option (even in a dummy way), so it would be a problem for those who > have msdos filesystems in fstab and also have fsck_y_enable. I'm a bit concerned that we keep the current option as it is, but I would support adding an fsck_y_enable_flags option to allow people to pass -C if they are sure it will work in their environment. Doug From onemda at gmail.com Mon Jun 1 16:39:02 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Jun 1 16:39:11 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A240331.1000803@FreeBSD.org> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> Message-ID: <3a142e750906010939t710f6abah286c8f23f54747ab@mail.gmail.com> On 6/1/09, Doug Barton wrote: > Andriy Gapon wrote: >> on 01/06/2009 16:20 Andriy Gapon said the following: >>> What about the following patch? >>> I believe that the idea behind fsck_y_enable is to try to make unattended >>> systems >>> with rw filesystems as recoverable as possible at the cost of potential >>> damage to >>> the data. The new "-C" option should not interfere with this goal, but >>> should >>> reduce recovery time, because currently fsck -y checks *all* filesystems >>> from >>> fstab, even those that are ro or clean: >>> >>> -C Check if the ?clean? flag is set in the superblock and skip file >>> system checks if file system was properly dismounted and marked >>> clean. >>> >> >> One potential issue that I've just thought of is that fsck_msdosfs doesn't >> seem to >> support this option (even in a dummy way), so it would be a problem for >> those who >> have msdos filesystems in fstab and also have fsck_y_enable. > > I'm a bit concerned that we keep the current option as it is, but I > would support adding an fsck_y_enable_flags option to allow people to > pass -C if they are sure it will work in their environment. IMHO that solution is much better, considering there is "-t" & "-T" flag. -- Paul From sam at errno.com Mon Jun 1 16:48:51 2009 From: sam at errno.com (Sam Leffler) Date: Mon Jun 1 16:48:58 2009 Subject: HEADS UP: net80211 data structure changes Message-ID: <4A240672.2050504@errno.com> Some public-facing data structures have changed that may affect statistics reported until you recompile programs (like ifconfig). Drivers will likewise need rebuilding. Ideally this stuff would be hidden behind proper KPI's and be transparent to user apps. If someone is interested in working on that please contact me. Sam From hselasky at c2i.net Mon Jun 1 16:53:27 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 1 16:53:34 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: References: Message-ID: <200906011757.31908.hselasky@c2i.net> On Monday 01 June 2009, Robert Watson wrote: > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. In practice, most behavior remains identical > in the default configuration (direct dispatch, single netisr thread that's > not bound to a CPU, etc), but people will want to watch out for problems. > Some default queue limits have been raised. > > More functional changes to take advantage of these features, such as > deferred ethernet dispatch and software flow ID generation, will follow as > patches, but probably not ship in 8.0 out of the box. > Hi, Having WITNESS and INVARIANTS in the kernel config I get a panic about a NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 has been properly setup. CPU: 2-HTT Workaround: net.isr.direct=0 net.isr.direct_force=0 --HPS From rwatson at FreeBSD.org Mon Jun 1 16:56:48 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 16:57:00 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: <200906011757.31908.hselasky@c2i.net> References: <200906011757.31908.hselasky@c2i.net> Message-ID: On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT Could you provide the trap information and a backtrace? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon Jun 1 16:56:48 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 16:57:01 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: <200906011757.31908.hselasky@c2i.net> References: <200906011757.31908.hselasky@c2i.net> Message-ID: On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT Could you provide the trap information and a backtrace? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From julian at elischer.org Mon Jun 1 17:11:03 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jun 1 17:11:10 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: References: Message-ID: <4A240BA6.4010805@elischer.org> Robert Watson wrote: > > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. does this mean you are departing immediately on a 4 week safari with no network? :-) From rwatson at FreeBSD.org Mon Jun 1 17:35:57 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 17:36:04 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: <4A240BA6.4010805@elischer.org> References: <4A240BA6.4010805@elischer.org> Message-ID: On Mon, 1 Jun 2009, Julian Elischer wrote: > Robert Watson wrote: > >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. > > does this mean you are departing immediately on a 4 week safari with no > network? :-) The great thing about network stack changes is that you can ensure there's no network :-). Robert From kvedulv at kvedulv.de Mon Jun 1 18:20:14 2009 From: kvedulv at kvedulv.de (Michael Moll) Date: Mon Jun 1 18:20:20 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS Message-ID: <20090601182012.GA21543@darkthrone.kvedulv.de> Hi, I'm getting the following crash on the NFS server with -CURRENT (r193229) as soon as I try to access a file on a ZFS filesystem via NFS: #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0x80562773 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0x8056297e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0x807b488c in trap_fatal (frame=0xfcc95718, eva=1660) at /usr/src/sys/i386/i386/trap.c:933 #4 0x807b4af0 in trap_pfault (frame=0xfcc95718, usermode=0, eva=1660) at /usr/src/sys/i386/i386/trap.c:846 #5 0x807b5492 in trap (frame=0xfcc95718) at /usr/src/sys/i386/i386/trap.c:528 #6 0x8079ceeb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0x8053d1bd in prison_priv_check (cred=0x85fe7000, priv=334) at /usr/src/sys/kern/kern_jail.c:3315 #8 0x8055631e in priv_check_cred (cred=0x85fe7000, priv=334, flags=0) at /usr/src/sys/kern/kern_priv.c:93 #9 0x8514412c in secpolicy_fs_owner () from /boot/kernel/zfs.ko #10 0x85144657 in secpolicy_vnode_access () from /boot/kernel/zfs.ko #11 0x851bfc5b in zfs_zaccess () from /boot/kernel/zfs.ko #12 0x851bfeeb in zfs_zaccess_rwx () from /boot/kernel/zfs.ko #13 0x851d55a4 in zfs_freebsd_access () from /boot/kernel/zfs.ko #14 0x807bf282 in VOP_ACCESS_APV (vop=0x85238640, a=0xfcc958cc) at vnode_if.c:571 #15 0x806e8057 in nfsrv_access (vp=0x80, accmode=-2062450688, cred=0x85fe7000, rdonly=0, override=0) at vnode_if.h:254 #16 0x806e87f1 in nfsrv3_access (nfsd=0xfcc95a9c, slp=0x0, mrq=0xfcc95a94) at /usr/src/sys/nfsserver/nfs_serv.c:238 #17 0x806f65a5 in nfssvc_program (rqst=0x86080800, xprt=0x85fe9e00) at /usr/src/sys/nfsserver/nfs_srvkrpc.c:410 #18 0x8071658f in svc_run_internal (pool=0x84d9e500, ismaster=1) at /usr/src/sys/rpc/svc.c:883 #19 0x807173fd in svc_run (pool=0x84d9e500) at /usr/src/sys/rpc/svc.c:1223 #20 0x806f5f6d in nfssvc_nfsd (td=Variable "td" is not available. ) at /usr/src/sys/nfsservc.c:199 #22 0x806f8158 in nfssvc (td=0x8549fb40, uap=0xfcc95cf8) at /usr/src/sys/nfs/nfs_nfssvc.c:90 #23 0x807b4e35 in syscall (frame=0xfcc95d38) at /usr/src/sys/i386/i386/trap.c:1073 #24 0x8079cf50 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #25 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Any ideas on this one? -- Michael Moll From rwatson at FreeBSD.org Mon Jun 1 18:41:47 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 18:41:59 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: <200906011757.31908.hselasky@c2i.net> References: <200906011757.31908.hselasky@c2i.net> Message-ID: On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT This should be fixed in r193243. I made a change shortly before merging that locks the current CPU's workstream before billing packets to it when direct dispatching, and this turns out to be incorrect, as on systems with fewer workers than CPUs, then we lock an uninitialized mutex. Let me know if the above change doesn't fix it. Robert N M Watson Computer Laboratory University of Cambridge > > Workaround: > > net.isr.direct=0 > net.isr.direct_force=0 > > --HPS > From rwatson at FreeBSD.org Mon Jun 1 18:41:47 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 1 18:42:00 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: <200906011757.31908.hselasky@c2i.net> References: <200906011757.31908.hselasky@c2i.net> Message-ID: On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT This should be fixed in r193243. I made a change shortly before merging that locks the current CPU's workstream before billing packets to it when direct dispatching, and this turns out to be incorrect, as on systems with fewer workers than CPUs, then we lock an uninitialized mutex. Let me know if the above change doesn't fix it. Robert N M Watson Computer Laboratory University of Cambridge > > Workaround: > > net.isr.direct=0 > net.isr.direct_force=0 > > --HPS > From tinderbox at freebsd.org Mon Jun 1 19:19:28 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 1 19:19:35 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090601191924.4E21C7302F@freebsd-current.sentex.ca> TB --- 2009-06-01 17:49:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 17:49:26 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-01 17:49:26 - cleaning the object tree TB --- 2009-06-01 17:50:00 - cvsupping the source tree TB --- 2009-06-01 17:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-01 17:50:11 - building world TB --- 2009-06-01 17:50:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 17:50:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 17:50:11 - TARGET=sun4v TB --- 2009-06-01 17:50:11 - TARGET_ARCH=sparc64 TB --- 2009-06-01 17:50:11 - TZ=UTC TB --- 2009-06-01 17:50:11 - __MAKE_CONF=/dev/null TB --- 2009-06-01 17:50:11 - cd /src TB --- 2009-06-01 17:50:11 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 17:50:14 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 1 19:04:25 UTC 2009 TB --- 2009-06-01 19:04:25 - generating LINT kernel config TB --- 2009-06-01 19:04:25 - cd /src/sys/sun4v/conf TB --- 2009-06-01 19:04:25 - /usr/bin/make -B LINT TB --- 2009-06-01 19:04:25 - building LINT kernel TB --- 2009-06-01 19:04:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 19:04:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 19:04:25 - TARGET=sun4v TB --- 2009-06-01 19:04:25 - TARGET_ARCH=sparc64 TB --- 2009-06-01 19:04:25 - TZ=UTC TB --- 2009-06-01 19:04:25 - __MAKE_CONF=/dev/null TB --- 2009-06-01 19:04:25 - cd /src TB --- 2009-06-01 19:04:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 1 19:04:25 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 19:19:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 19:19:24 - ERROR: failed to build lint kernel TB --- 2009-06-01 19:19:24 - 4649.84 user 424.29 system 5397.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From hselasky at c2i.net Mon Jun 1 20:10:55 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 1 20:11:51 2009 Subject: New NETISR implementation, but same defaults In-Reply-To: References: <200906011757.31908.hselasky@c2i.net> Message-ID: <200906012215.01494.hselasky@c2i.net> On Monday 01 June 2009, Robert Watson wrote: > On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > > On Monday 01 June 2009, Robert Watson wrote: > >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > >> implementation there as part of on-going work to improve network stack > >> parallelism, details below. In practice, most behavior remains > >> identical in the default configuration (direct dispatch, single netisr > >> thread that's not bound to a CPU, etc), but people will want to watch > >> out for problems. Some default queue limits have been raised. > >> > >> More functional changes to take advantage of these features, such as > >> deferred ethernet dispatch and software flow ID generation, will follow > >> as patches, but probably not ship in 8.0 out of the box. > > > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > > has been properly setup. CPU: 2-HTT > > This should be fixed in r193243. I made a change shortly before merging > that locks the current CPU's workstream before billing packets to it when > direct dispatching, and this turns out to be incorrect, as on systems with > fewer workers than CPUs, then we lock an uninitialized mutex. Let me know > if the above change doesn't fix it. Ok. BTW: I'm booted on a USB harddisk (USB2) and it does not support dump on USB disk yet. I will check if your r193243 does not fix it. Thanks. --HPS From randy at psg.com Mon Jun 1 20:36:32 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 20:36:39 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: >> gencat is installed. it is whining that it can not find the file > > May be gencat is installed, but 'make install' could not find it: > message "gencat:No such file or directory" comes from make, not > from gencat itself. > > Will you be able to run 'make clean; make; make install' from > /usr/src/usr.bin/ee to see if the problem is specific to the 'make > installworld' or shows even for manual installation? work0.psg.com:/usr/src# cd /usr/src/usr.bin/ee/ work0.psg.com:/usr/src/usr.bin/ee# make clean rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz work0.psg.com:/usr/src/usr.bin/ee# make make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop whack! now i need to find some place from which i can recover it randy From ed at 80386.nl Mon Jun 1 20:46:16 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jun 1 20:46:22 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: <20090601204614.GM48776@hoeg.nl> * Randy Bush wrote: > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop Can you give me the $FreeBSD$ tag of the Makefile? It should be (when using SVN): $FreeBSD: head/usr.bin/ee/Makefile 192914 2009-05-27 17:27:03Z ed $ -- 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/20090601/1b7229c4/attachment.pgp From randy at psg.com Mon Jun 1 20:49:14 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 20:49:25 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: >>> gencat is installed. it is whining that it can not find the file >> >> May be gencat is installed, but 'make install' could not find it: >> message "gencat:No such file or directory" comes from make, not >> from gencat itself. >> >> Will you be able to run 'make clean; make; make install' from >> /usr/src/usr.bin/ee to see if the problem is specific to the 'make >> installworld' or shows even for manual installation? > work0.psg.com:/usr/src# cd /usr/src/usr.bin/ee/ > work0.psg.com:/usr/src/usr.bin/ee# make clean > rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz > work0.psg.com:/usr/src/usr.bin/ee# make > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop recovered data ran just make install work0.psg.com:/usr/src/usr.bin/ee# make install install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg install -o root -g wheel -m 444 en_US.US-ASCII.cat /usr/share/nls/en_US.US-ASCII/ee.cat cat /usr/src/usr.bin/ee/nls/fr_FR.ISO8859-1/ee.msg > fr_FR.ISO8859-1.msg gencat fr_FR.ISO8859-1.cat fr_FR.ISO8859-1.msg install -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /usr/share/nls/fr_FR.ISO8859-1/ee.cat cat /usr/src/usr.bin/ee/nls/de_DE.ISO8859-1/ee.msg > de_DE.ISO8859-1.msg gencat de_DE.ISO8859-1.cat de_DE.ISO8859-1.msg install -o root -g wheel -m 444 de_DE.ISO8859-1.cat /usr/share/nls/de_DE.ISO8859-1/ee.cat cat /usr/src/usr.bin/ee/nls/pl_PL.ISO8859-2/ee.msg > pl_PL.ISO8859-2.msg gencat pl_PL.ISO8859-2.cat pl_PL.ISO8859-2.msg install -o root -g wheel -m 444 pl_PL.ISO8859-2.cat /usr/share/nls/pl_PL.ISO8859-2/ee.cat cat /usr/src/usr.bin/ee/nls/uk_UA.KOI8-U/ee.msg > uk_UA.KOI8-U.msg gencat uk_UA.KOI8-U.cat uk_UA.KOI8-U.msg install -o root -g wheel -m 444 uk_UA.KOI8-U.cat /usr/share/nls/uk_UA.KOI8-U/ee.cat cat /usr/src/usr.bin/ee/nls/ru_RU.KOI8-R/ee.msg > ru_RU.KOI8-R.msg gencat ru_RU.KOI8-R.cat ru_RU.KOI8-R.msg install -o root -g wheel -m 444 ru_RU.KOI8-R.cat /usr/share/nls/ru_RU.KOI8-R/ee.cat install -o root -g wheel -m 444 ee.1.gz /usr/share/man/man1 /usr/share/man/man1/ree.1.gz -> /usr/share/man/man1/ee.1.gz /usr/share/man/man1/edit.1.gz -> /usr/share/man/man1/ee.1.gz /usr/bin/ree -> /usr/bin/ee /usr/bin/edit -> /usr/bin/ee /usr/share/nls/en_US.ISO8859-1/ee.cat -> ../en_US.US-ASCII/ee.cat /usr/share/nls/en_US.ISO8859-15/ee.cat -> ../en_US.US-ASCII/ee.cat /usr/share/nls/fr_BE.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_BE.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CA.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CA.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CH.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CH.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_FR.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/de_AT.ISO8859-1/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_AT.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_CH.ISO8859-1/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_CH.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_DE.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat looks successful to me randy From randy at psg.com Mon Jun 1 20:50:59 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 20:51:06 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: <20090601204614.GM48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601204614.GM48776@hoeg.nl> Message-ID: >> make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop > Can you give me the $FreeBSD$ tag of the Makefile? It should be (when > using SVN): > $FreeBSD: head/usr.bin/ee/Makefile 192914 2009-05-27 17:27:03Z ed $ # $FreeBSD: src/usr.bin/ee/Makefile,v 1.26 2009/05/27 17:27:03 ed Exp $ From ed at 80386.nl Mon Jun 1 20:59:13 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jun 1 20:59:20 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> Message-ID: <20090601205912.GN48776@hoeg.nl> * Randy Bush wrote: > recovered data > > ran just make install > > work0.psg.com:/usr/src/usr.bin/ee# make install > So it's false alarm? Phew. :-) -- 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/20090601/22afca72/attachment.pgp From randy at psg.com Mon Jun 1 21:15:09 2009 From: randy at psg.com (Randy Bush) Date: Mon Jun 1 21:15:16 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: <20090601205912.GN48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> Message-ID: >> ran just make install >> work0.psg.com:/usr/src/usr.bin/ee# make install >> > So it's false alarm? Phew. :-) not false, just different. like what is killing the install? this is on two systems, and i am now afraid of updating anything. randy From tinderbox at freebsd.org Mon Jun 1 23:51:18 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 1 23:51:37 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090601235115.673C07302F@freebsd-current.sentex.ca> TB --- 2009-06-01 22:18:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 22:18:15 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-01 22:18:15 - cleaning the object tree TB --- 2009-06-01 22:18:52 - cvsupping the source tree TB --- 2009-06-01 22:18:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-01 22:19:06 - building world TB --- 2009-06-01 22:19:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 22:19:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 22:19:06 - TARGET=pc98 TB --- 2009-06-01 22:19:06 - TARGET_ARCH=i386 TB --- 2009-06-01 22:19:06 - TZ=UTC TB --- 2009-06-01 22:19:06 - __MAKE_CONF=/dev/null TB --- 2009-06-01 22:19:06 - cd /src TB --- 2009-06-01 22:19:06 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 22:19:08 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 1 23:42:40 UTC 2009 TB --- 2009-06-01 23:42:40 - generating LINT kernel config TB --- 2009-06-01 23:42:40 - cd /src/sys/pc98/conf TB --- 2009-06-01 23:42:40 - /usr/bin/make -B LINT TB --- 2009-06-01 23:42:40 - building LINT kernel TB --- 2009-06-01 23:42:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 23:42:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 23:42:40 - TARGET=pc98 TB --- 2009-06-01 23:42:40 - TARGET_ARCH=i386 TB --- 2009-06-01 23:42:40 - TZ=UTC TB --- 2009-06-01 23:42:40 - __MAKE_CONF=/dev/null TB --- 2009-06-01 23:42:40 - cd /src TB --- 2009-06-01 23:42:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 1 23:42:40 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 23:51:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 23:51:15 - ERROR: failed to build lint kernel TB --- 2009-06-01 23:51:15 - 4275.75 user 438.17 system 5580.19 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From gabor at FreeBSD.org Tue Jun 2 00:03:31 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 2 00:03:37 2009 Subject: RFC: Replacing bc/dc to BSDL versions Message-ID: <4A246C4D.6080409@FreeBSD.org> Hello, as you might know, I'm working on a BSDL grep. It isn't totally ready yet, because there are compatibility issues, which I have to resolve. But looking at another BSDL tools, I've found out that OpenBSD has BSDL bc and dc utilities. I've thought of replacing them. I think in the bc/dc case, such a strict GNU compatibility isn't necessary as in the case of grep, so we may replace them in base system. If there's no objection to replacing them, I'll post a patch for review. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From tinderbox at freebsd.org Tue Jun 2 02:32:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 02:33:10 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090602023255.0F3747302F@freebsd-current.sentex.ca> TB --- 2009-06-02 00:58:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 00:58:34 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-02 00:58:34 - cleaning the object tree TB --- 2009-06-02 00:58:57 - cvsupping the source tree TB --- 2009-06-02 00:58:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-02 00:59:11 - building world TB --- 2009-06-02 00:59:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 00:59:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 00:59:11 - TARGET=powerpc TB --- 2009-06-02 00:59:11 - TARGET_ARCH=powerpc TB --- 2009-06-02 00:59:11 - TZ=UTC TB --- 2009-06-02 00:59:11 - __MAKE_CONF=/dev/null TB --- 2009-06-02 00:59:11 - cd /src TB --- 2009-06-02 00:59:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 00:59:13 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 02:25:35 UTC 2009 TB --- 2009-06-02 02:25:35 - generating LINT kernel config TB --- 2009-06-02 02:25:35 - cd /src/sys/powerpc/conf TB --- 2009-06-02 02:25:35 - /usr/bin/make -B LINT TB --- 2009-06-02 02:25:35 - building LINT kernel TB --- 2009-06-02 02:25:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 02:25:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 02:25:35 - TARGET=powerpc TB --- 2009-06-02 02:25:35 - TARGET_ARCH=powerpc TB --- 2009-06-02 02:25:35 - TZ=UTC TB --- 2009-06-02 02:25:35 - __MAKE_CONF=/dev/null TB --- 2009-06-02 02:25:35 - cd /src TB --- 2009-06-02 02:25:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 02:25:35 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 02:32:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 02:32:54 - ERROR: failed to build lint kernel TB --- 2009-06-02 02:32:54 - 4436.53 user 413.77 system 5660.60 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From james-freebsd-current at jrv.org Tue Jun 2 02:51:41 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Tue Jun 2 02:51:48 2009 Subject: SATA port multipliers Message-ID: <4A2493BC.8020905@jrv.org> With this change (and other previously reported & PR'd patches) SATA port multipliers seem to be working for me, albeit half as fast as expected. The ata_identify() call was commented out in February apparently due to other problems it caused but it appears to be the only thing that scans for drives behind an enclosure. Index: sys/dev/ata/ata-all.c =================================================================== --- sys/dev/ata/ata-all.c (revision 192136) +++ sys/dev/ata/ata-all.c (working copy) @@ -291,7 +291,7 @@ ATA_LOCKING(dev, ATA_LF_UNLOCK); /* Add new children. */ -/* ata_identify(dev); */ + ata_identify(dev); if (bootverbose) device_printf(dev, "reinit done ..\n"); From james-freebsd-current at jrv.org Tue Jun 2 03:09:03 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Tue Jun 2 03:09:10 2009 Subject: ZFS panic under extreme circumstances (2/3 disks corrupted) In-Reply-To: References: <4E6E325D-BB18-4478-BCFD-633D6F4CFD88@exscape.org> Message-ID: <4A248F6E.5020701@jrv.org> Thomas Backman wrote: > I have another unfortunate thing to note regarding this: after a > reboot, it's even impossible to tell *which disk* has gone bad, even > if the pool is "uncleared" but otherwise "healed". It simply says that > a device has failed, with no clue as to which one, since they're all > "ONLINE"! Is there anything recorded in the pool history log about this? The pool errlog is documented to be rotated after every scrub. From tinderbox at freebsd.org Tue Jun 2 03:24:43 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 03:25:00 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090602032439.A6F8F7302F@freebsd-current.sentex.ca> TB --- 2009-06-02 01:53:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 01:53:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-02 01:53:56 - cleaning the object tree TB --- 2009-06-02 01:54:26 - cvsupping the source tree TB --- 2009-06-02 01:54:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-02 01:54:38 - building world TB --- 2009-06-02 01:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 01:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 01:54:38 - TARGET=sparc64 TB --- 2009-06-02 01:54:38 - TARGET_ARCH=sparc64 TB --- 2009-06-02 01:54:38 - TZ=UTC TB --- 2009-06-02 01:54:38 - __MAKE_CONF=/dev/null TB --- 2009-06-02 01:54:38 - cd /src TB --- 2009-06-02 01:54:38 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 01:54:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 03:16:26 UTC 2009 TB --- 2009-06-02 03:16:26 - generating LINT kernel config TB --- 2009-06-02 03:16:26 - cd /src/sys/sparc64/conf TB --- 2009-06-02 03:16:26 - /usr/bin/make -B LINT TB --- 2009-06-02 03:16:26 - building LINT kernel TB --- 2009-06-02 03:16:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 03:16:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 03:16:26 - TARGET=sparc64 TB --- 2009-06-02 03:16:26 - TARGET_ARCH=sparc64 TB --- 2009-06-02 03:16:26 - TZ=UTC TB --- 2009-06-02 03:16:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 03:16:26 - cd /src TB --- 2009-06-02 03:16:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 03:16:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 03:24:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 03:24:39 - ERROR: failed to build lint kernel TB --- 2009-06-02 03:24:39 - 4214.37 user 413.52 system 5443.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jun 2 03:59:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 03:59:40 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090602035919.5E0687302F@freebsd-current.sentex.ca> TB --- 2009-06-02 02:32:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 02:32:55 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 02:32:55 - cleaning the object tree TB --- 2009-06-02 02:33:34 - cvsupping the source tree TB --- 2009-06-02 02:33:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 02:33:44 - building world TB --- 2009-06-02 02:33:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 02:33:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 02:33:44 - TARGET=sun4v TB --- 2009-06-02 02:33:44 - TARGET_ARCH=sparc64 TB --- 2009-06-02 02:33:44 - TZ=UTC TB --- 2009-06-02 02:33:44 - __MAKE_CONF=/dev/null TB --- 2009-06-02 02:33:44 - cd /src TB --- 2009-06-02 02:33:44 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 02:33:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 03:52:26 UTC 2009 TB --- 2009-06-02 03:52:26 - generating LINT kernel config TB --- 2009-06-02 03:52:26 - cd /src/sys/sun4v/conf TB --- 2009-06-02 03:52:26 - /usr/bin/make -B LINT TB --- 2009-06-02 03:52:26 - building LINT kernel TB --- 2009-06-02 03:52:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 03:52:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 03:52:26 - TARGET=sun4v TB --- 2009-06-02 03:52:26 - TARGET_ARCH=sparc64 TB --- 2009-06-02 03:52:26 - TZ=UTC TB --- 2009-06-02 03:52:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 03:52:26 - cd /src TB --- 2009-06-02 03:52:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 03:52:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 03:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 03:59:19 - ERROR: failed to build lint kernel TB --- 2009-06-02 03:59:19 - 4193.07 user 412.66 system 5184.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From d9364104 at mail.nchu.edu.tw Tue Jun 2 04:20:30 2009 From: d9364104 at mail.nchu.edu.tw (Eric L. Chen) Date: Tue Jun 2 04:20:37 2009 Subject: Cannot add wlan to lagg automatically Message-ID: <1243914611.52975.7.camel@localhost> Hi, I just upgraded my laptop from 7-STABLE to 8-CURRENT for a couple days, I use lagg to connect ethernet and wireless lan. before upgrade it works fine. /etc/rc.conf : cloned_interfaces="bridge0 lagg0" ifconfig_bridge0="up" autobridge_interfaces="bridge0" autobridge_bridge0="lagg0 tap0 tap1" ifconfig_bfe0="ether 00:0b:6b:4f:28:b8 up" # Need use WLAN MAC for WPA ifconfig_wlan0="up WPA" ifconfig_lagg0="up laggproto failover laggport bfe0 laggport ath0 DHCP" --- While booted interface lagg0 have two member: bfe0 and ath0 After upgraded: cloned_interfaces="bridge0 lagg0" ifconfig_bridge0="up" autobridge_interfaces="bridge0" autobridge_bridge0="lagg0 tap0 tap1" ifconfig_bfe0="ether 00:0b:6b:4f:28:b8 up" # Need use WLAN MAC for WPA wlans_ath0="wlan0" ifconfig_wlan0="up WPA" ifconfig_lagg0="up laggproto failover laggport bfe0 laggport wlan0 DHCP" --- While booted interface lagg0 have only one member: bfe0. I need add wlan0 by hand every boot. Does settings changed in CURRENT? /Eric From mav at FreeBSD.org Tue Jun 2 05:39:50 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jun 2 05:39:56 2009 Subject: SATA port multipliers In-Reply-To: References: Message-ID: <4A24BB1F.5060403@FreeBSD.org> James R. Van Artsdalen wrote: > With this change (and other previously reported & PR'd patches) SATA > port multipliers seem to be working for me, albeit half as fast as expected. > > The ata_identify() call was commented out in February apparently due to > other problems it caused but it appears to be the only thing that scans > for drives behind an enclosure. > > Index: sys/dev/ata/ata-all.c > =================================================================== > --- sys/dev/ata/ata-all.c (revision 192136) > +++ sys/dev/ata/ata-all.c (working copy) > @@ -291,7 +291,7 @@ > ATA_LOCKING(dev, ATA_LF_UNLOCK); > > /* Add new children. */ > -/* ata_identify(dev); */ > + ata_identify(dev); > > if (bootverbose) > device_printf(dev, "reinit done ..\n"); ata_identify() also called in channel attach routine and it is enough to process port multipliers, same as usual drives. Calling it on reinit() would be good to be able to find new devices, but in current state it causes deadlock in some error conditions. -- Alexander Motin From freebsd.work at gmail.com Tue Jun 2 05:49:20 2009 From: freebsd.work at gmail.com (Sean P. Dew) Date: Tue Jun 2 05:49:27 2009 Subject: BTX/AMD64/E820 FreeBSD 7.2 Message-ID: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> I am trying to run FreeBSD on a hypervisor (custom written). The hypervisor steals some memory for itself and wants to hide it from FreeBSD so that the OS does not read or write to that memory. The hypervisor hooks the real mode IDT for INT15 and checks for E820 and SMAP in the correct registers, and returns the modified SMAP to the OS. The problem I am facing is when the kernel invokes getmemsize (sys_amd64:01104), it looks for the SMAP loaded by the BTX loader. In GetBiosMEM where it is actually loaded, the BTX loader is invoked which invokes the INT15 handler using a RET instead of an INT15. Is there someway to totally bypass the BTX loade or change that behavior using some #define in the kernel to make it use int15? Thanks From guru at unixarea.de Tue Jun 2 06:06:40 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Jun 2 06:06:47 2009 Subject: Dell M4400 && Xorg-vesa && 1920x1200 res? In-Reply-To: <20090516060753.GA5319@rebelion.Sisis.de> References: <20090514084617.GA3459@rebelion.Sisis.de> <200905141651.35948.shoesoft@gmx.net> <20090515125250.GA11380@rebelion.Sisis.de> <1242397462.1755.89.camel@balrog.2hip.net> <20090516060753.GA5319@rebelion.Sisis.de> Message-ID: <20090602060639.GA2260@current.Sisis.de> El d?a Saturday, May 16, 2009 a las 08:07:53AM +0200, Matthias Apitz escribi?: > El d?a Friday, May 15, 2009 a las 09:24:22AM -0500, Robert Noland escribi?: > > > > Yes, this worked; but it was terrible slow on window movements; > > > I've got a small fix for the driver x11-drivers/xf86-video-nv and the > > > card is now working as it should with the 'nv' module. > > > > What patch? If it needs review and committing upstream, please send it > > to me... > > > > robert. > > The mentioned patch is now available in src/nv_driver.c > > > Thanks for testing this! I'll update the driver with the device names > > for the IDs in the 0x065x range tomorrow when it's not 2 am. ;) > > You'll be able to point to the patch at [1] then. If you need it > > soon, I can push an official release so you don't have to ship a > > patched driver. > > http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/commit/?id=c8d6f7aa7c99a1b71289f8e8e07becc10f61f379 > The final word on this is that the original driver from Nvidia works as well; the drivers are at http://www.nvidia.com/object/unix.html and its latest version is 180.60. The actual version does not compile on CURRENT. One must disable the check for this version in the source NVIDIA-FreeBSD-x86-180.60/src/nv-freebsd.h: /* #if __FreeBSD_version >= 800000 #error This driver does not support FreeBSD 8.x/-CURRENT! #endif */ then it compiles and installs fine. There is as well a problem on laptops with huge amount of memory (mine has 4 GByte) which seems to be a known issue in http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 and hardlocks the system on start of X. One needs a setting in /boot/loader.conf of machdep.disable_mtrrs=1 with this all is fine and X comes up as it should. As well the nvidia-settings tool must be compiled directly from the source because the one in the ports has some library conflict. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From rea-fbsd at codelabs.ru Tue Jun 2 06:58:48 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jun 2 06:58:55 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> Message-ID: Randy, Tue, Jun 02, 2009 at 06:15:06AM +0900, Randy Bush wrote: > >> ran just make install > >> work0.psg.com:/usr/src/usr.bin/ee# make install > >> > > So it's false alarm? Phew. :-) > > not false, just different. like what is killing the install? Install is killed by the fact that there's no gencat ;)) From your original report, ----- 8-current a few hours old, i386 ===> usr.bin/ee (install) install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg gencat:No such file or directory *** Error code 1 ----- I see that even on this machine ee's build wasn't successful: 'install' phase should be making .msg files -- they are to be built at the 'build' phase. Next, when you succeeded to build ee: ----- > work0.psg.com:/usr/src/usr.bin/ee# make clean > rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz > work0.psg.com:/usr/src/usr.bin/ee# make > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop recovered data ran just make install work0.psg.com:/usr/src/usr.bin/ee# make install install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg ----- Do you really just run 'make install' after 'make clean' and failed 'make'? Or you took some additional steps? In any case, bare 'make install' just used bsd.*.mk files from /usr/share/mk. Now you need to repeat 'make buildworld'/'make installworld'. If you're up to it, please, do (on the system where build by-hand was successful) ----- make buildworld 2>&1 | tee build.log make installworld 2>&1 | tee install.log ----- and show the contents build.log and install.log. > this is on two systems, and i am now afraid of updating anything. If you hadn't touched your other machine on which ee install was failing too, please, do the following: ----- cat /usr/src/usr.bin/ee/Makefile ls -la /usr/src/usr.bin/ee ls -la /usr/obj/usr/src/usr.bin/ee ls -la /usr/src/contrib/ee ls -la /usr/src/usr/share/mk grep -r '$FreeBSD' /usr/src/share/mk ----- and show the results. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From lwindschuh at googlemail.com Tue Jun 2 07:26:54 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Tue Jun 2 07:27:01 2009 Subject: mksnap_ffs segfaults (was: Re: svn commit: r193051 - head/sbin/mksnap_ffs) Message-ID: <90a5caac0906020026t67d7d9ej225565b42898a4b7@mail.gmail.com> 2009/5/29 Pawel Jakub Dawidek : > Author: pjd > Date: Fri May 29 19:18:41 2009 > New Revision: 193051 > URL: http://svn.freebsd.org/changeset/base/193051 Hi Pawel. You forgot to initialize iov and iovlen. This makes mksnap_ffs crash on the first build_iovec() with malloc() debugging enabled. Index: src/sbin/mksnap_ffs/mksnap_ffs.c =================================================================== --- src/sbin/mksnap_ffs/mksnap_ffs.c (revision 193301) +++ src/sbin/mksnap_ffs/mksnap_ffs.c (working copy) @@ -66,8 +66,8 @@ struct statfs stfsbuf; struct group *grp; struct stat stbuf; - struct iovec *iov; - int fd, iovlen; + struct iovec *iov = NULL; + int fd, iovlen = 0; if (argc == 2) snapname = argv[1]; Lucius From serenity at exscape.org Tue Jun 2 08:01:30 2009 From: serenity at exscape.org (Thomas Backman) Date: Tue Jun 2 08:01:37 2009 Subject: ZFS panic under extreme circumstances (2/3 disks corrupted) In-Reply-To: <4A248F6E.5020701@jrv.org> References: <4E6E325D-BB18-4478-BCFD-633D6F4CFD88@exscape.org> <4A248F6E.5020701@jrv.org> Message-ID: <4EE92FAD-528E-4154-B608-D822720EAB26@exscape.org> On Jun 2, 2009, at 04:33 AM, James R. Van Artsdalen wrote: > Thomas Backman wrote: >> I have another unfortunate thing to note regarding this: after a >> reboot, it's even impossible to tell *which disk* has gone bad, even >> if the pool is "uncleared" but otherwise "healed". It simply says >> that >> a device has failed, with no clue as to which one, since they're all >> "ONLINE"! > > Is there anything recorded in the pool history log about this? > > The pool errlog is documented to be rotated after every scrub. I don't think so, and can't check (the "disks" are long gone from the VM), other than this message that I posted earlier in the thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007259.html Regards, Thomas From dfr at rabson.org Tue Jun 2 08:24:25 2009 From: dfr at rabson.org (Doug Rabson) Date: Tue Jun 2 08:24:36 2009 Subject: /boot/loader can't load kernel if too many pool/devices In-Reply-To: <4A23ABF2.3070601@restart.be> References: <4A23ABF2.3070601@restart.be> Message-ID: On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > Hello, > > During my tests (succesful) to directly boot from ZFS (with zfsboot > and gptzfsboot) I encounter the error "can't boot 'kernel'" if too > many devices/pools are connected to the machine. In my case: > > 2 SAS disks with 2 pools > 2 SATA disks with 2 pools > 1 USB key with one pool > > `heap` command: > > Active Allocations: 171/173 > 536576 bytes reserved 527800 bytes allocated > > `ls` command: > > open '/' failed: too many open files > > If I reboot without the USB key all is OK. > > If I reboot from the USB key after disconnecting 2 disks all is OK. > > By the way, the /boot/loader in 7.2-STABLE don't work, complains > about forth not found. > > The previous tests were made with 7.2-STABLE (May 31) with /boot/ > loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. From tinderbox at freebsd.org Tue Jun 2 08:34:41 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 08:34:48 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090602083437.4245F7302F@freebsd-current.sentex.ca> TB --- 2009-06-02 06:58:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 06:58:49 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-02 06:58:49 - cleaning the object tree TB --- 2009-06-02 06:59:15 - cvsupping the source tree TB --- 2009-06-02 06:59:16 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-02 06:59:23 - building world TB --- 2009-06-02 06:59:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 06:59:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 06:59:23 - TARGET=pc98 TB --- 2009-06-02 06:59:23 - TARGET_ARCH=i386 TB --- 2009-06-02 06:59:23 - TZ=UTC TB --- 2009-06-02 06:59:23 - __MAKE_CONF=/dev/null TB --- 2009-06-02 06:59:23 - cd /src TB --- 2009-06-02 06:59:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 06:59:24 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 08:26:26 UTC 2009 TB --- 2009-06-02 08:26:26 - generating LINT kernel config TB --- 2009-06-02 08:26:26 - cd /src/sys/pc98/conf TB --- 2009-06-02 08:26:26 - /usr/bin/make -B LINT TB --- 2009-06-02 08:26:26 - building LINT kernel TB --- 2009-06-02 08:26:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 08:26:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 08:26:26 - TARGET=pc98 TB --- 2009-06-02 08:26:26 - TARGET_ARCH=i386 TB --- 2009-06-02 08:26:26 - TZ=UTC TB --- 2009-06-02 08:26:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 08:26:26 - cd /src TB --- 2009-06-02 08:26:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 08:26:27 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 08:34:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 08:34:36 - ERROR: failed to build lint kernel TB --- 2009-06-02 08:34:36 - 4281.13 user 440.21 system 5747.23 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From h.schmalzbauer at omnilan.de Tue Jun 2 09:51:25 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Tue Jun 2 09:51:32 2009 Subject: HAL is blokcing growisofs [Was: Re: Various problems, atapi, acpi (S3), cpufreq (est)] In-Reply-To: <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> References: <4A12CBE9.5010206@omnilan.de> <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> Message-ID: <4A24F596.1010706@omnilan.de> Eygene Ryabinkin schrieb am 20.05.2009 11:28 (localtime): ... >> Using `growisofs -dvd-compat -speed=8 -Z /dev/cd1=/udfimage.iso` freezes >> the system. First it seems nothing happens but after some minutes the >> system is completely unresponsive, even mouse doesn't move any more. >> Here's some output I got at this event: >> ... >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - PREVENT_ALLOW taskqueue timeout - completing request >> directly >> acd1: WARNING - PREVENT_ALLOW freeing taskqueue zombie request >> acd1: WARNING - TEST_UNIT_READY taskqueue timeout - completing request >> directly >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - READ_TOC taskqueue timeout - completing request directly >> acd1: WARNING - READ_TOC freeing taskqueue zombie reques > > Could you try to add atapicam(4) device into your kernel and use > /dev/cdX instead of /dev/acdX for burning? I don't believe that this > will help you, given the messages you're receiving, but you can at least > give a shot for SCSI emulation on ATAPI devices. Accidentally I found out that growisofs works perfectly without HAL. As soon as hal is running I see the above error messages and no dvd burning is possible. Also USB-Flash-Disks don't work with -current and hal (everything compiled 2 days ago). As soon as I plug in the UFD all "hald-addon-storage: /dev/da1" (from fixed internal card reader) vanish and I can't use Thunars volume-mount feature. Should I open a ports/PR? Or is it likle to be a problem in -current? 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/20090602/b1ff1bdb/signature.pgp From hlh at restart.be Tue Jun 2 10:31:14 2009 From: hlh at restart.be (Henri Hennebert) Date: Tue Jun 2 10:31:23 2009 Subject: /boot/loader can't load kernel if too many pool/devices In-Reply-To: References: <4A23ABF2.3070601@restart.be> Message-ID: <4A24FF6E.7020209@restart.be> Doug Rabson wrote: > > On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > >> Hello, >> >> During my tests (succesful) to directly boot from ZFS (with zfsboot >> and gptzfsboot) I encounter the error "can't boot 'kernel'" if too >> many devices/pools are connected to the machine. In my case: >> >> 2 SAS disks with 2 pools >> 2 SATA disks with 2 pools >> 1 USB key with one pool >> >> `heap` command: >> >> Active Allocations: 171/173 >> 536576 bytes reserved 527800 bytes allocated >> >> `ls` command: >> >> open '/' failed: too many open files >> >> If I reboot without the USB key all is OK. >> >> If I reboot from the USB key after disconnecting 2 disks all is OK. >> >> By the way, the /boot/loader in 7.2-STABLE don't work, complains about >> forth not found. >> >> The previous tests were made with 7.2-STABLE (May 31) with >> /boot/loader from 8.0-CURRENT. > > I recently increased the number of file descriptors available for > /boot/loader. Could you rebuild and try again please. Make sure you > rebuild libstand.a as well as /boot/loader. > OK - I can boot with the USB key and 4 disks Thanks Henri From avg at icyb.net.ua Tue Jun 2 10:38:26 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Jun 2 10:38:34 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090601182012.GA21543@darkthrone.kvedulv.de> References: <20090601182012.GA21543@darkthrone.kvedulv.de> Message-ID: <4A25011D.5080603@icyb.net.ua> on 01/06/2009 21:20 Michael Moll said the following: > Hi, > > I'm getting the following crash on the NFS server with -CURRENT (r193229) > as soon as I try to access a file on a ZFS filesystem via NFS: [backtrace snipped] > Any ideas on this one? Could you please share panic message/header in addition to the backtrace? -- Andriy Gapon From ohartman at zedat.fu-berlin.de Tue Jun 2 10:54:51 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Jun 2 10:54:58 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world Message-ID: <4A2504AA.1020406@zedat.fu-berlin.de> Hello, since today I get this error when trying to mount a NFS filesystem from NFS server: [udp] foo:/home: RPCPROG_MNT: RPC: Timed out Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from today's buildworld/make kernel. nfsd is up and running and worked that way days before. I saw commitments of new NFSv4 code, are these causing this issue? Is 8.0 supposed to be offering nfsv4-server capabilities which I need to switch on anyway? I also tried mount -t newnfs on that NFS filesystem but without any success. Is this a fault of mine or are temporarely not-working-condition? I tried both ZFS and UFS2 NFS exports to get mounted, both are unwilling to mount with the above showed error. Regards, Oliver From kvedulv at kvedulv.de Tue Jun 2 11:09:54 2009 From: kvedulv at kvedulv.de (Michael Moll) Date: Tue Jun 2 11:10:01 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <4A25011D.5080603@icyb.net.ua> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <4A25011D.5080603@icyb.net.ua> Message-ID: <20090602110952.GB67463@darkthrone.kvedulv.de> Hi Andriy, On Tue, Jun 02, 2009 at 01:38:21PM +0300, Andriy Gapon wrote: > Could you please share panic message/header in addition to the backtrace? Oops, sorry... Here we go: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x67c fault code = supervisor read, page not present instruction pointer = 0x20:0x8053d1bd stack pointer = 0x28:0xfcc95758 frame pointer = 0x28:0xfcc95764 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 = 731 (nfsd: master) trap number = 12 panic: page fault Uptime: 15m2s Physical memory: 1974 MB Dumping 99 MB: 84 68 52 36 20 4 Best Regards -- Michael Moll From freebsd.work at gmail.com Tue Jun 2 06:50:14 2009 From: freebsd.work at gmail.com (Sean P. Dew) Date: Tue Jun 2 11:13:17 2009 Subject: VMX in kernel Message-ID: <45d874490906012350u11026416tf94f3cc44def2f37@mail.gmail.com> Is there any header file/example code for making VMX calls from the FreeBSD kernel? Does the compiler support any directives? Thanks From tinderbox at freebsd.org Tue Jun 2 11:16:37 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 11:16:56 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090602111633.A9B467302F@freebsd-current.sentex.ca> TB --- 2009-06-02 09:41:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 09:41:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-02 09:41:54 - cleaning the object tree TB --- 2009-06-02 09:42:13 - cvsupping the source tree TB --- 2009-06-02 09:42:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-02 09:42:22 - building world TB --- 2009-06-02 09:42:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 09:42:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 09:42:22 - TARGET=powerpc TB --- 2009-06-02 09:42:22 - TARGET_ARCH=powerpc TB --- 2009-06-02 09:42:22 - TZ=UTC TB --- 2009-06-02 09:42:22 - __MAKE_CONF=/dev/null TB --- 2009-06-02 09:42:22 - cd /src TB --- 2009-06-02 09:42:22 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 09:42:24 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 11:09:09 UTC 2009 TB --- 2009-06-02 11:09:09 - generating LINT kernel config TB --- 2009-06-02 11:09:09 - cd /src/sys/powerpc/conf TB --- 2009-06-02 11:09:09 - /usr/bin/make -B LINT TB --- 2009-06-02 11:09:09 - building LINT kernel TB --- 2009-06-02 11:09:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:09:09 - TARGET=powerpc TB --- 2009-06-02 11:09:09 - TARGET_ARCH=powerpc TB --- 2009-06-02 11:09:09 - TZ=UTC TB --- 2009-06-02 11:09:09 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:09:09 - cd /src TB --- 2009-06-02 11:09:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 11:09:09 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 11:16:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 11:16:33 - ERROR: failed to build lint kernel TB --- 2009-06-02 11:16:33 - 4435.65 user 412.15 system 5678.98 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From randy at psg.com Tue Jun 2 11:31:42 2009 From: randy at psg.com (Randy Bush) Date: Tue Jun 2 11:31:49 2009 Subject: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> Message-ID: exec summary: i may be out of the hole >>>> ran just make install >>>> work0.psg.com:/usr/src/usr.bin/ee# make install >>>> >>> So it's false alarm? Phew. :-) >> >> not false, just different. like what is killing the install? > > Install is killed by the fact that there's no gencat ;)) i figured i was in some version skew trap. so i started from again i svn sources and place same source tree on machine rip and work0. i make kernel on work0 and reboot log at http://archive.psg.com/2009.06.02/kernel.log.gz kernel conf at http://archive.psg.com/2009.06.02/WORK0 on work0, i make buildworld, which fails ===> gnu/usr.bin/texinfo/infokey (installincludes) ===> gnu/usr.bin/texinfo/install-info (installincludes) ===> gnu/usr.bin/texinfo/texindex (installincludes) ===> gnu/usr.bin/texinfo/doc (installincludes) ===> include (includes) cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh Segmentation fault (core dumped) *** Error code 139 log at http://archive.psg.com/2009.06.02/buildworld-work0.log.gz on rip, i make buildworld, log at http://archive.psg.com/2009.06.02/buildworld-rip.log.gz i rm -rf work0:/usr/obj i tar /usr/obj from rip to work0 on work0, i run make installworld which seems to ends bit unexpectedly, with a bunch of stuff after the usual makewhatis etc. cd /usr/src/usr.bin/ldd; PROG=ldd32 MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 VERSION="FreeBSD 8.0-CURRENT amd64 800096" MACHINE=i386 MACHINE_ARCH=i386 PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.7UCUwZK0 CC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" CXX="c++ -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" OB JC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" LD="ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32" AS="as --32" LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install install -s -o root -g wheel -m 555 ldd32 /usr/bin log at http://archive.psg.com/2009.06.02/installworld-work0.log.gz reboot asterisk starts mysql starts dhcpd starts ejabberd gets a core in beam httpd cores portupgrade -fav dies a horrible death cd /usr/ports/lang/ruby18 && make && make deinstall && make reinstall cd /usr/ports/ports-mgmt/portupgrade-devel && make && make deinstall && make reinstall portupgrade -fRv apache* i porupgrade apache and erlang and ejabberd and they work i think i may be out of the hole. randy From tinderbox at freebsd.org Tue Jun 2 12:06:18 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 12:06:52 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090602120612.37D267302F@freebsd-current.sentex.ca> TB --- 2009-06-02 10:35:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 10:35:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-02 10:35:20 - cleaning the object tree TB --- 2009-06-02 10:35:45 - cvsupping the source tree TB --- 2009-06-02 10:35:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-02 10:35:56 - building world TB --- 2009-06-02 10:35:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 10:35:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 10:35:56 - TARGET=sparc64 TB --- 2009-06-02 10:35:56 - TARGET_ARCH=sparc64 TB --- 2009-06-02 10:35:56 - TZ=UTC TB --- 2009-06-02 10:35:56 - __MAKE_CONF=/dev/null TB --- 2009-06-02 10:35:56 - cd /src TB --- 2009-06-02 10:35:56 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 10:35:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 11:57:50 UTC 2009 TB --- 2009-06-02 11:57:50 - generating LINT kernel config TB --- 2009-06-02 11:57:50 - cd /src/sys/sparc64/conf TB --- 2009-06-02 11:57:50 - /usr/bin/make -B LINT TB --- 2009-06-02 11:57:50 - building LINT kernel TB --- 2009-06-02 11:57:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:57:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:57:50 - TARGET=sparc64 TB --- 2009-06-02 11:57:50 - TARGET_ARCH=sparc64 TB --- 2009-06-02 11:57:50 - TZ=UTC TB --- 2009-06-02 11:57:50 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:57:50 - cd /src TB --- 2009-06-02 11:57:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 11:57:51 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 12:06:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 12:06:12 - ERROR: failed to build lint kernel TB --- 2009-06-02 12:06:12 - 4208.81 user 415.77 system 5451.59 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From Alexander at Leidinger.net Tue Jun 2 12:12:42 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Jun 2 12:12:49 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A240331.1000803@FreeBSD.org> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> Message-ID: <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> Quoting Doug Barton (from Mon, 01 Jun 2009 09:34:57 -0700): > Andriy Gapon wrote: >> on 01/06/2009 16:20 Andriy Gapon said the following: >>> What about the following patch? >>> I believe that the idea behind fsck_y_enable is to try to make >>> unattended systems >>> with rw filesystems as recoverable as possible at the cost of >>> potential damage to >>> the data. The new "-C" option should not interfere with this goal, >>> but should >>> reduce recovery time, because currently fsck -y checks *all* >>> filesystems from >>> fstab, even those that are ro or clean: >>> >>> -C Check if the ?clean? flag is set in the superblock and skip file >>> system checks if file system was properly dismounted and marked >>> clean. >>> >> >> One potential issue that I've just thought of is that fsck_msdosfs >> doesn't seem to >> support this option (even in a dummy way), so it would be a problem >> for those who >> have msdos filesystems in fstab and also have fsck_y_enable. > > I'm a bit concerned that we keep the current option as it is, but I > would support adding an fsck_y_enable_flags option to allow people to > pass -C if they are sure it will work in their environment. What about _flags and also adding a NOP for -C in fsck_msdosfs? Bye, Alexander. -- Another dream that failed. There's nothing sadder. -- Kirk, "This side of Paradise", stardate 3417.3 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From tinderbox at freebsd.org Tue Jun 2 12:42:44 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 12:43:01 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090602124239.E79987302F@freebsd-current.sentex.ca> TB --- 2009-06-02 11:16:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 11:16:33 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 11:16:33 - cleaning the object tree TB --- 2009-06-02 11:17:18 - cvsupping the source tree TB --- 2009-06-02 11:17:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 11:17:24 - building world TB --- 2009-06-02 11:17:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:17:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:17:24 - TARGET=sun4v TB --- 2009-06-02 11:17:24 - TARGET_ARCH=sparc64 TB --- 2009-06-02 11:17:24 - TZ=UTC TB --- 2009-06-02 11:17:24 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:17:24 - cd /src TB --- 2009-06-02 11:17:24 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 11:17:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 12:35:43 UTC 2009 TB --- 2009-06-02 12:35:43 - generating LINT kernel config TB --- 2009-06-02 12:35:43 - cd /src/sys/sun4v/conf TB --- 2009-06-02 12:35:43 - /usr/bin/make -B LINT TB --- 2009-06-02 12:35:43 - building LINT kernel TB --- 2009-06-02 12:35:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 12:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 12:35:43 - TARGET=sun4v TB --- 2009-06-02 12:35:43 - TARGET_ARCH=sparc64 TB --- 2009-06-02 12:35:43 - TZ=UTC TB --- 2009-06-02 12:35:43 - __MAKE_CONF=/dev/null TB --- 2009-06-02 12:35:43 - cd /src TB --- 2009-06-02 12:35:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 12:35:43 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 12:42:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 12:42:39 - ERROR: failed to build lint kernel TB --- 2009-06-02 12:42:39 - 4191.83 user 410.93 system 5165.93 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From rea-fbsd at codelabs.ru Tue Jun 2 12:48:28 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jun 2 12:48:35 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <20090602120612.37D267302F@freebsd-current.sentex.ca> References: <20090602120612.37D267302F@freebsd-current.sentex.ca> Message-ID: Tue, Jun 02, 2009 at 08:06:12AM -0400, FreeBSD Tinderbox wrote: > /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) > /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' > cc1: warnings being treated as errors > /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' > /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' > /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) > /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' > /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' > *** Error code 1 Perhaps the attached patch will fix the stuff? For enabled ACPI (__HAVE_ACPI) machine/stdarg.h is brought by contrib/dev/acpica/acpi.h, but seems like sparc64 nave no ACPI. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index 5055762..63d9cee 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #if defined(__i386__) || defined(__amd64__) #include From jhb at freebsd.org Tue Jun 2 13:41:25 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 2 13:41:47 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: References: <20090602120612.37D267302F@freebsd-current.sentex.ca> Message-ID: <200906020919.41339.jhb@freebsd.org> On Tuesday 02 June 2009 8:48:24 am Eygene Ryabinkin wrote: > Tue, Jun 02, 2009 at 08:06:12AM -0400, FreeBSD Tinderbox wrote: > > /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) > > /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' > > cc1: warnings being treated as errors > > /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' > > /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' > > /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) > > /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' > > /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' > > *** Error code 1 > > Perhaps the attached patch will fix the stuff? For enabled ACPI > (__HAVE_ACPI) machine/stdarg.h is brought by contrib/dev/acpica/acpi.h, > but seems like sparc64 nave no ACPI. I had already committed this, but thanks for the hint on why it compiled on amd64. -- John Baldwin From jhb at freebsd.org Tue Jun 2 13:41:26 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 2 13:41:48 2009 Subject: BTX/AMD64/E820 FreeBSD 7.2 In-Reply-To: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> References: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> Message-ID: <200906020925.26738.jhb@freebsd.org> On Tuesday 02 June 2009 1:18:04 am Sean P. Dew wrote: > I am trying to run FreeBSD on a hypervisor (custom written). The hypervisor > steals some memory for itself and wants to hide it from FreeBSD so that the > OS does not read or write to that memory. The hypervisor hooks the real mode > IDT for INT15 and checks for E820 and SMAP in the correct registers, and > returns the modified SMAP to the OS. The problem I am facing is when the > kernel invokes getmemsize (sys_amd64:01104), it looks for the SMAP loaded by > the BTX loader. In GetBiosMEM where it is actually loaded, the BTX loader is > invoked which invokes the INT15 handler using a RET instead of an INT15. Is > there someway to totally bypass the BTX loade or change that behavior using > some #define in the kernel to make it use int15? No. Assuming you have hooked the real mode entry point in the IDT table, that is the address that BTX is going to jump to. -- John Baldwin From avg at freebsd.org Tue Jun 2 14:06:24 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Jun 2 14:06:37 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A240063.207@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> Message-ID: <4A2531DA.2070608@freebsd.org> on 01/06/2009 19:22 Andriy Gapon said the following: > Henri, > > thank you very much for testing! > It look like the patch did its job. > > P.S. hopefully someone is looking into the cause of the assertion. I think I cracked it. This is where ds->ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x0000000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x0000000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(&ds->ds_lock)) (gdb) list 259 if (ds->ds_dir) 260 dsl_dir_close(ds->ds_dir, ds); 261 262 ASSERT(!list_link_active(&ds->ds_synced_link)); 263 264 if (mutex_owned(&ds->ds_lock)) 265 mutex_exit(&ds->ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon From avg at freebsd.org Tue Jun 2 14:14:21 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Jun 2 14:14:33 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A2531DA.2070608@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> <4A2531DA.2070608@freebsd.org> Message-ID: <4A2533B8.8040007@freebsd.org> on 02/06/2009 17:06 Andriy Gapon said the following: > So I am quite sure that mutex_owned should be defined as follows: > #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Actually: #define mutex_owned(l) pthread_mutex_isowned_np(&(l)->m_lock) And on dangers of ignored compiler warnings: /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type This is during libzpool compilation. -- Andriy Gapon From rmacklem at uoguelph.ca Tue Jun 2 14:34:23 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 14:34:30 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> References: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, O. Hartmann wrote: > Hello, > since today I get this error when trying to mount a NFS filesystem from NFS > server: > > [udp] foo:/home: RPCPROG_MNT: RPC: Timed out > > Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from > today's buildworld/make kernel. > > nfsd is up and running and worked that way days before. > > I saw commitments of new NFSv4 code, are these causing this issue? Is 8.0 > supposed to be offering nfsv4-server capabilities which I need to switch on > anyway? > By default, everything should work just like before, using the vanilla NFS server, etc. The message indicates that mountd wasn't responding. So, first off, check that it is running. I did integrate some changes into mountd for the new experimental nfs subsystem, but those should only be invoked if "-e" was provided on its command line. I'll go through the changes I made to mountd.c again, but it has been working ok for me. > I also tried mount -t newnfs on that NFS filesystem but without any success. > Is this a fault of mine or are temporarely not-working-condition? > Using "mount -t newnfs" uses the experimental nfs client instead of the regular one, but they should both work. The problem seems to be an unresponsive mountd. Let us know if you find out anything more about it, rick From ohartman at zedat.fu-berlin.de Tue Jun 2 15:14:46 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Jun 2 15:14:54 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: <4A254194.7080807@zedat.fu-berlin.de> Rick Macklem wrote: > > > On Tue, 2 Jun 2009, O. Hartmann wrote: > >> Hello, >> since today I get this error when trying to mount a NFS filesystem >> from NFS server: >> >> [udp] foo:/home: RPCPROG_MNT: RPC: Timed out >> >> Both boxes, cleint and server, are most recent FreeBSD >> 8.0-CURRENT/amd64 from today's buildworld/make kernel. >> >> nfsd is up and running and worked that way days before. >> >> I saw commitments of new NFSv4 code, are these causing this issue? Is >> 8.0 supposed to be offering nfsv4-server capabilities which I need to >> switch on anyway? >> > By default, everything should work just like before, using the vanilla NFS > server, etc. The message indicates that mountd wasn't responding. So, > first off, check that it is running. > > I did integrate some changes into mountd for the new experimental nfs > subsystem, but those should only be invoked if "-e" was provided on its > command line. > > I'll go through the changes I made to mountd.c again, but it has been > working ok for me. > >> I also tried mount -t newnfs on that NFS filesystem but without any >> success. Is this a fault of mine or are temporarely >> not-working-condition? >> > Using "mount -t newnfs" uses the experimental nfs client instead of the > regular one, but they should both work. The problem seems to be an > unresponsive mountd. > > Let us know if you find out anything more about it, 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" Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I do not know why udp is invoked automatically by now. But for short, we always did NFS mounts over tcp AND udp, so for tcp it worked again! Oliver From rmacklem at uoguelph.ca Tue Jun 2 15:42:00 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 15:42:07 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> References: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, O. Hartmann wrote: > Hello, > since today I get this error when trying to mount a NFS filesystem from NFS > server: > > [udp] foo:/home: RPCPROG_MNT: RPC: Timed out > > Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from > today's buildworld/make kernel. > What's the expression you guys use? "The pointy hat points at me." It looks like I broke parsing of /etc/exports for the case where there are continuation lines (I didn't have any of those in my test examples, but do now;-). Sorry about that. I'll be looking it over more carefully, but I'll bet that the following patch fixes the problem (and I'm guessing you do have contnuation lines in your /etc/exports?). Please try this patch and see if it helps, rick --- test patch for mountd.c --- --- mountd.c.sav 2009-06-02 11:28:19.000000000 -0400 +++ mountd.c 2009-06-02 11:36:53.000000000 -0400 @@ -1191,12 +1191,12 @@ got_nondir = 0; opt_flags = 0; ep = (struct exportlist *)NULL; - dirp = NULL; /* * Handle the V4 root dir. */ if (*cp == 'V' && *(cp + 1) == '4' && *(cp + 2) == ':') { + dirp = NULL; /* * V4: just indicates that it is the v4 root point, * so skip over that and set v4root_phase. From rmacklem at uoguelph.ca Tue Jun 2 15:52:26 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 15:52:33 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: <4A254194.7080807@zedat.fu-berlin.de> References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, O. Hartmann wrote: > > Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I > do not know why udp is invoked automatically by now. > > But for short, we always did NFS mounts over tcp AND udp, so for tcp it > worked again! > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is required, but you'd only get that if you had used "-o nfsv4" in your mount). I'll take another look at mount_nfs.c too (already caught a problem I introduced in mountd.c). Maybe I unintentionally changed one of the defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.) For udp to work, nfsd must have the "-u" argument. That might be why it wouldn't work? (Still doesn't explain why the default was udp and not tcp.) Anyhow, thanks for doing the testing and I'll email again if I find that I've screwed up the defaults for mount_nfs too. (Is that a "big pointy hat"?:-) rick From mav at FreeBSD.org Tue Jun 2 16:13:47 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jun 2 16:13:53 2009 Subject: WIP: ATA to CAM integration Message-ID: <4A254FB5.3030504@FreeBSD.org> Hi. After replying to several similar questions about my ATA plans last time, I have decided to announce things I am working on now together with Scott Long. While learning FreeBSD ATA implementation, I have found, that it has numerous deep problems, from quite fuzzy APIs to different issues in device detection and error recovery. Also, as soon as this infrastructure was written many years ago, it has completely no support for any kind of command queuing, which is normal for the most of modern drives and controllers. Fixing all of this require many significant changes. Also, you may know, that SAS controllers and expanders allow attaching SATA devices and port multipliers to them, by transporting ATA commands over SCSI (SAS) bus. ATAPI, same time, is the way to transport SCSI commands over ATA interface. So deep technologies interoperation pushes us to have similarly integrated infrastructures on software level. We are already have atapicam driver which is used to give CAM SCSI infrastructure access to ATAPI devices by translating drivers API and SCSI bus emulation. But it works only one way and also not perfect. Looking to all of this, I have decided to join Scott, to reanimate his project of making CAM a system's universal infrastructure for both SCSI and ATA. This project is not about some kind of SCSI-to-ATA translation, used by some OS, like OpenBSD. It is about extending CAM, to equally support both SCSI and ATA worlds natively and integrate them as tight as possible. This project is going to have several main steps: - separate SCSI command set and SCSI bus management code from abstract CAM code and create abstract transport API (this step is mostly done now by Scott), - implement ATA command set device drivers, ATA bus management code and ATA host controller drivers (this step is now in progress by me), - update CAM to use newbus, to make it's components interoperation more transparent and formalized (this is now in planning and preparation stage), - when mentioned above finished, port the rest of existing ATA controller drivers one by one to the new world order. Our code now lives in PERFORCE in scottl-camlock project branch. It is in early development, but we already have there working CAM driver for AHCI controller with command queuing and basic NCQ support, simple SATA bus management code and ATA disk driver. I am able now to boot my system and work from SATA drive on AHCI controller, using ATA disk driver, having command queuing and NCQ enabled, read and write disks with SATA ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only with CAM, without using any part of ATA infrastructure. -- Alexander Motin From julian at elischer.org Tue Jun 2 16:30:07 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Jun 2 16:30:19 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <4A254FB5.3030504@FreeBSD.org> References: <4A254FB5.3030504@FreeBSD.org> Message-ID: <4A25538E.5020302@elischer.org> Alexander Motin wrote: > Hi. > > After replying to several similar questions about my ATA plans last > time, I have decided to announce things I am working on now together > with Scott Long. > I can't imagine a team I'd rather have doing it. great news From dougb at FreeBSD.org Tue Jun 2 17:21:23 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 17:21:29 2009 Subject: fsck_y_enable: use -C In-Reply-To: <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> Message-ID: <4A255F8E.70604@FreeBSD.org> Alexander Leidinger wrote: > What about _flags and also adding a NOP for -C in fsck_msdosfs? Sounds great, I look forward to reviewing your patch. :) Doug From tinderbox at freebsd.org Tue Jun 2 17:31:27 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 17:31:46 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090602173120.D455B7302F@freebsd-current.sentex.ca> TB --- 2009-06-02 15:58:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 15:58:59 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-02 15:58:59 - cleaning the object tree TB --- 2009-06-02 15:59:24 - cvsupping the source tree TB --- 2009-06-02 15:59:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-02 15:59:31 - building world TB --- 2009-06-02 15:59:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 15:59:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 15:59:31 - TARGET=pc98 TB --- 2009-06-02 15:59:31 - TARGET_ARCH=i386 TB --- 2009-06-02 15:59:31 - TZ=UTC TB --- 2009-06-02 15:59:31 - __MAKE_CONF=/dev/null TB --- 2009-06-02 15:59:31 - cd /src TB --- 2009-06-02 15:59:31 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 15:59:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 17:23:04 UTC 2009 TB --- 2009-06-02 17:23:04 - generating LINT kernel config TB --- 2009-06-02 17:23:04 - cd /src/sys/pc98/conf TB --- 2009-06-02 17:23:04 - /usr/bin/make -B LINT TB --- 2009-06-02 17:23:04 - building LINT kernel TB --- 2009-06-02 17:23:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 17:23:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 17:23:04 - TARGET=pc98 TB --- 2009-06-02 17:23:04 - TARGET_ARCH=i386 TB --- 2009-06-02 17:23:04 - TZ=UTC TB --- 2009-06-02 17:23:04 - __MAKE_CONF=/dev/null TB --- 2009-06-02 17:23:04 - cd /src TB --- 2009-06-02 17:23:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 17:23:04 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 17:31:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 17:31:20 - ERROR: failed to build lint kernel TB --- 2009-06-02 17:31:20 - 4277.17 user 437.55 system 5540.73 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From dougb at FreeBSD.org Tue Jun 2 17:55:46 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 17:55:52 2009 Subject: RFC: Replacing bc/dc to BSDL versions In-Reply-To: <4A246C4D.6080409@FreeBSD.org> References: <4A246C4D.6080409@FreeBSD.org> Message-ID: <4A25679E.5060305@FreeBSD.org> Gabor Kovesdan wrote: > Hello, > > as you might know, I'm working on a BSDL grep. It isn't totally ready > yet, because there are compatibility issues, which I have to resolve. > But looking at another BSDL tools, I've found out that OpenBSD has BSDL > bc and dc utilities. I've thought of replacing them. I think in the > bc/dc case, such a strict GNU compatibility isn't necessary as in the > case of grep, so we may replace them in base system. If there's no > objection to replacing them, I'll post a patch for review. No objection, just a head's up that mergemaster uses bc so please be sure to test that as part of your process. Doug From lapo at lapo.it Tue Jun 2 18:27:14 2009 From: lapo at lapo.it (Lapo Luchini) Date: Tue Jun 2 18:27:32 2009 Subject: xorg loops In-Reply-To: <49DFBAEF.1080904@freebsd.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> Message-ID: <4A256867.8050808@lapo.it> Tim Kientzle wrote: > AllowEmptyInput hald Result > off enabled Mouse/keyboard delays/jerkiness > off disabled Works > on (default) enabled Works > on (default) disabled No mouse/keyboard Tim, I had your same symptoms (as far as "delays/jerkiness" can go): when using the USB external mouse and leaving it in *some* positions, the whole system was paused until I move the mouse even a little bit, at that point all "missing events" (i.e. all keypresses that didn't produce any output, or also all screen updates) are shown in fast-forward (e.g. the Firefox spinner of a loading tab was stopped until the mouse moved, and made the 3 missing turns rapidly, then all to normal). When the mouse was left in other positions, no problem was shown. After Googling your message I commented-out the AllowEmptyInput line in my xorg.conf and now both internal touchpad and external mouse work perfectly and don't "halt the event queue" (or what it was) anymore. I still wonder the reason behind this behavior but as long as it's working, I won't complain. -- Lapo Luchini - http://lapo.it/ ?Beware of bugs in the above code; I have only proved it correct, not tried it.? (Donald Knuth, 1977-03-22) From antab at valka.is Tue Jun 2 18:40:38 2009 From: antab at valka.is (Arnar Mar Sig) Date: Tue Jun 2 18:40:46 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Jun 2, 2009, at 5:53 PM, Rick Macklem wrote: > On Tue, 2 Jun 2009, O. Hartmann wrote: > >> >> Mounting via '-o nfsv3,tcp' in addition, everthing works all right >> again. I do not know why udp is invoked automatically by now. >> >> But for short, we always did NFS mounts over tcp AND udp, so for >> tcp it worked again! >> > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is > required, but you'd only get that if you had used "-o nfsv4" in your > mount). > > I'll take another look at mount_nfs.c too (already caught a problem I > introduced in mountd.c). Maybe I unintentionally changed one of the > defaults. (I think the default is supposed to be nfsv3,tcp but I'll > look.) > > For udp to work, nfsd must have the "-u" argument. That might be why > it > wouldn't work? (Still doesn't explain why the default was udp and not > tcp.) > > Anyhow, thanks for doing the testing and I'll email again if I find > that I've screwed up the defaults for mount_nfs too. (Is that a > "big pointy hat"?:-) I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD on May 31. I can see MNT RPC packet coming from the avr32 board and running mountd -d shows "mountd: mount successful" when the packet is received but no answer is transmitted, rpc is sent with udp. I can mount the same export from my osx workstation when using tcp. Arnar Mar Sig From guru at unixarea.de Tue Jun 2 19:09:27 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Jun 2 19:09:34 2009 Subject: xorg loops In-Reply-To: <4A256867.8050808@lapo.it> References: <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <4A256867.8050808@lapo.it> Message-ID: <20090602190923.GA3492@current.Sisis.de> El d?a Tuesday, June 02, 2009 a las 07:59:03PM +0200, Lapo Luchini escribi?: > Tim Kientzle wrote: > > AllowEmptyInput hald Result > > off enabled Mouse/keyboard delays/jerkiness > > off disabled Works > > on (default) enabled Works > > on (default) disabled No mouse/keyboard > > Tim, I had your same symptoms (as far as "delays/jerkiness" can go): > when using the USB external mouse and leaving it in *some* positions, > the whole system was paused until I move the mouse even a little bit, at > that point all "missing events" (i.e. all keypresses that didn't produce > any output, or also all screen updates) are shown in fast-forward (e.g. > the Firefox spinner of a loading tab was stopped until the mouse moved, > and made the 3 missing turns rapidly, then all to normal). When the > mouse was left in other positions, no problem was shown. > > After Googling your message I commented-out the AllowEmptyInput line in > my xorg.conf and now both internal touchpad and external mouse work > perfectly and don't "halt the event queue" (or what it was) anymore. > > I still wonder the reason behind this behavior but as long as it's > working, I won't complain. I have a *similar* problem; see my posting in -current with Subject: 'problem with mouse when hald is running': when hald is enabled certain events, for example the ButtonReleaseEvent of a mouse click, is delayed until you move the mouse pointer a bit; until now I have AllowEmptyInput set to 'false' and hald disabled, and it works; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From rwatson at FreeBSD.org Tue Jun 2 19:12:15 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jun 2 19:12:22 2009 Subject: HEADS UP: MAC enabled by default (was: svn commit: r193334 - in head/sys: amd64/conf i386/conf ia64/conf pc98/conf powerpc/conf sparc64/conf sun4v/conf (fwd)) Message-ID: As an FYI to -CURRENT users: I've enabled "options MAC" in the GENERIC kernel in order to allow MAC users to enable security policy modules without a kernel recompile. By default, it shouldn't change the behavior of the system, and should have negligible performance impact. However, if you run into problems, please let me know -- hopefully we'll have lots of time before 8.0 to shake them out. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Tue, 2 Jun 2009 18:31:08 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r193334 - in head/sys: amd64/conf i386/conf ia64/conf pc98/conf powerpc/conf sparc64/conf sun4v/conf Author: rwatson Date: Tue Jun 2 18:31:08 2009 New Revision: 193334 URL: http://svn.freebsd.org/changeset/base/193334 Log: Remove MAC kernel config files and add "options MAC" to GENERIC, with the goal of shipping 8.0 with MAC support in the default kernel. No policies will be compiled in or enabled by default, but it will now be possible to load them at boot or runtime without a kernel recompile. While the framework is not believed to impose measurable overhead when no policies are loaded (a result of optimization over the past few months in HEAD), we'll continue to benchmark and optimize as the release approaches. Please keep an eye out for performance or functionality regressions that could be a result of this change. Approved by: re (kensmith) Obtained from: TrustedBSD Project Deleted: head/sys/amd64/conf/MAC head/sys/i386/conf/MAC head/sys/ia64/conf/MAC head/sys/pc98/conf/MAC head/sys/powerpc/conf/MAC head/sys/sparc64/conf/MAC head/sys/sun4v/conf/MAC Modified: head/sys/amd64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/ia64/conf/GENERIC head/sys/pc98/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/sparc64/conf/GENERIC head/sys/sun4v/conf/GENERIC Modified: head/sys/amd64/conf/GENERIC ============================================================================== --- head/sys/amd64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/amd64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -70,6 +70,7 @@ options KBD_INSTALL_CDEV # install a CD options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks Modified: head/sys/i386/conf/GENERIC ============================================================================== --- head/sys/i386/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/i386/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -71,6 +71,7 @@ options KBD_INSTALL_CDEV # install a CD options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework #options KDTRACE_HOOKS # Kernel DTrace hooks # Debugging for use in -current Modified: head/sys/ia64/conf/GENERIC ============================================================================== --- head/sys/ia64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/ia64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -40,6 +40,7 @@ options INVARIANTS # Enable calls of ex options INVARIANT_SUPPORT # required by INVARIANTS options KDB # Enable kernel debugger support options KTRACE # ktrace(1) syscall trace support +options MAC # TrustedBSD MAC Framework options MD_ROOT # MD usable as root device options MSDOSFS # MSDOS Filesystem options NFSCLIENT # Network Filesystem Client Modified: head/sys/pc98/conf/GENERIC ============================================================================== --- head/sys/pc98/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/pc98/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -73,6 +73,7 @@ options _KPOSIX_PRIORITY_SCHEDULING # P options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. Modified: head/sys/powerpc/conf/GENERIC ============================================================================== --- head/sys/powerpc/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/powerpc/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -64,6 +64,7 @@ options SYSVSEM #SYSV-style semaphore options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB #Enable the kernel debugger Modified: head/sys/sparc64/conf/GENERIC ============================================================================== --- head/sys/sparc64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/sparc64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -65,6 +65,7 @@ options SYSVSEM # SYSV-style semaphor options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. Modified: head/sys/sun4v/conf/GENERIC ============================================================================== --- head/sys/sun4v/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/sun4v/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -66,6 +66,7 @@ options AHC_REG_PRETTY_PRINT # Print re options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. From dougb at FreeBSD.org Tue Jun 2 19:20:42 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 19:20:51 2009 Subject: Do you use a value other than AUTO for network_interfaces? Message-ID: <4A257B82.1000701@FreeBSD.org> Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug From rmacklem at uoguelph.ca Tue Jun 2 19:35:33 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 19:35:46 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, Arnar Mar Sig wrote: > > > I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD > on May 31. > > I can see MNT RPC packet coming from the avr32 board and running mountd -d > shows "mountd: mount successful" when the packet is received but no answer is > transmitted, rpc is sent with udp. > I can mount the same export from my osx workstation when using tcp. > Ok, I've poked at it a little more and the case that seems to be broken is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.) I haven't yet figured out why that case is broken, but I'll keep fiddling with it. (For me the getaddrinfo() fails for this case.) If you are not using the "-h" option on nfsd and udp isn't working, I haven't got an explanation, because it seems to work for me? rick From rwatson at FreeBSD.org Tue Jun 2 19:57:07 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jun 2 19:57:17 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, Rick Macklem wrote: >> Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I >> do not know why udp is invoked automatically by now. >> >> But for short, we always did NFS mounts over tcp AND udp, so for tcp it >> worked again! >> > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is > required, but you'd only get that if you had used "-o nfsv4" in your mount). > > I'll take another look at mount_nfs.c too (already caught a problem I > introduced in mountd.c). Maybe I unintentionally changed one of the > defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.) I'm running into a similar-sounding but odd problem on a diskless NFS client test box running 8.0, but talking to a server running 7.0: cheetah# mount -o rw -u / [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to send If I do a fresh file system mount it works fine: cheetah# mount 192.168.5.1:/zoo /zoo cheetah# mount 192.168.5.1:/zoo/cheetah on / (nfs, read-only) devfs on /dev (devfs, local) /dev/md0 on /var (ufs, local) /dev/md1 on /tmp (ufs, local) 192.168.5.1:/zoo on /zoo (nfs) This is with an approximately 26 May userspace. Robert N M Watson Computer Laboratory University of Cambridge > > For udp to work, nfsd must have the "-u" argument. That might be why it > wouldn't work? (Still doesn't explain why the default was udp and not > tcp.) > > Anyhow, thanks for doing the testing and I'll email again if I find > that I've screwed up the defaults for mount_nfs too. (Is that a > "big pointy hat"?:-) > > 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 mav at mavhome.dp.ua Tue Jun 2 15:54:55 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue Jun 2 20:34:10 2009 Subject: WIP: ATA to CAM integration Message-ID: <4A254B45.8050800@mavhome.dp.ua> Hi. After replying to several similar questions about my ATA plans last time, I have decided to announce things I am working on now together with Scott Long. While learning FreeBSD ATA implementation, I have found, that it has numerous deep problems, from quite fuzzy APIs to different issues in device detection and error recovery. Also, as soon as this infrastructure was written many years ago, it has completely no support for any kind of command queuing, which is normal for the most of modern drives and controllers. Fixing all of this require many significant changes. Also, you may know, that SAS controllers and expanders allow attaching SATA devices and port multipliers to them, by transporting ATA commands over SCSI (SAS) bus. ATAPI, same time, is the way to transport SCSI commands over ATA interface. So deep technologies interoperation pushes us to have similarly integrated infrastructures on software level. We are already have atapicam driver which is used to give CAM SCSI infrastructure access to ATAPI devices by translating drivers API and SCSI bus emulation. But it works only one way and also not perfect. Looking to all of this, I have decided to join Scott, to reanimate his project of making CAM a system's universal infrastructure for both SCSI and ATA. This project is not about some kind of SCSI-to-ATA translation, used by some OS, like OpenBSD. It is about extending CAM, to equally support both SCSI and ATA worlds natively and integrate them as tight as possible. This project is going to have several main steps: - separate SCSI command set and SCSI bus management code from abstract CAM code and create abstract transport API (this step is mostly done now by Scott), - implement ATA command set device drivers, ATA bus management code and ATA host controller drivers (this step is now in progress by me), - update CAM to use newbus, to make it's components interoperation more transparent and formalized (this is now in planning and preparation stage), - when mentioned above finished, port the rest of existing ATA controller drivers one by one to the new world order. Our code now lives in PERFORCE in scottl-camlock project branch. It is in early development, but we already have there working CAM driver for AHCI controller with command queuing and basic NCQ support, simple SATA bus management code and ATA disk driver. I am able now to boot my system and work from SATA drive on AHCI controller, using ATA disk driver, having command queuing and NCQ enabled, read and write disks with SATA ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only with CAM, without using any part of ATA infrastructure. -- Alexander Motin From dougb at FreeBSD.org Tue Jun 2 20:49:07 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 20:49:14 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <4A259039.8040001@FreeBSD.org> Ruben van Staveren wrote: > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. FYI, ipv6_network_interfaces exists for this purpose. Thanks for your post, it's good information to add to the pile. Doug From ruben at verweg.com Tue Jun 2 20:30:52 2009 From: ruben at verweg.com (Ruben van Staveren) Date: Tue Jun 2 20:49:48 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: On 2 Jun 2009, at 21:20, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I removed > that warning in HEAD Sunday, and there is no a discussion about > whether or not it should be put back, and whether or not there is any > need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces="AUTO" is already true for ipv6. with network_interfaces="bge0 lo0" network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. you want to have a system where one still can control which interfaces are explicitly configured or skipped, with no side effects of default actions > > > Thanks, > > Doug > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > Regards, Ruben From antab at valka.is Tue Jun 2 21:03:52 2009 From: antab at valka.is (Arnar Mar Sig) Date: Tue Jun 2 21:03:59 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: <63C3AB3D-5500-4693-BAD6-AE760F623B96@valka.is> On Jun 2, 2009, at 9:36 PM, Rick Macklem wrote: > > > On Tue, 2 Jun 2009, Arnar Mar Sig wrote: > >> >> >> I'm having troubles with nfsroot on avr32 after updating my dev box >> to HEAD on May 31. >> >> I can see MNT RPC packet coming from the avr32 board and running >> mountd -d shows "mountd: mount successful" when the packet is >> received but no answer is transmitted, rpc is sent with udp. >> I can mount the same export from my osx workstation when using tcp. >> > Ok, I've poked at it a little more and the case that seems to be > broken > is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or > with "-h 131.104.49.243" it seems to work. (This affects udp but not > tcp.) > > I haven't yet figured out why that case is broken, but I'll keep > fiddling > with it. (For me the getaddrinfo() fails for this case.) > > If you are not using the "-h" option on nfsd and udp isn't working, I > haven't got an explanation, because it seems to work for me? > > rick > I'm using the default "-u -t -n 4". I rebuilt everything with checkout from today and tested with osx and linux clients. both show the same results, viewing traffic with wireshark shows no response packet sent when using udp. osx: dumb:~ antab$ mount_nfs -o udp 192.168.1.254:/home/antab/avr32-root test/ mount_nfs: bad MNT RPC: RPC: Timed out\n mount_nfs: bad MNT RPC: RPC: Timed out\n mount_nfs: can't access /home/antab/avr32-root: Permission denied dumb:~ antab$ mount_nfs -o tcp 192.168.1.254:/home/antab/avr32-root test/ dumb:~ antab$ umount test/ Bad MNT RPC: RPC: Timed out (osx seems to always send the UMNT rpc with udp) linux: antab@thordis:~$ sudo mount -t nfs -o udp 192.168.1.254:/home/antab/ avr32-root test/ mount.nfs: mount system call failed antab@thordis:~$ sudo mount -t nfs -o tcp 192.168.1.254:/home/antab/ avr32-root test/ antab@thordis:~$ umount test/ Arnar Mar Sig From rmacklem at uoguelph.ca Tue Jun 2 21:05:19 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 21:05:26 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, Rick Macklem wrote: >> >> >> I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD >> on May 31. >> >> I can see MNT RPC packet coming from the avr32 board and running mountd -d >> shows "mountd: mount successful" when the packet is received but no answer >> is transmitted, rpc is sent with udp. >> I can mount the same export from my osx workstation when using tcp. >> > Ok, I've poked at it a little more and the case that seems to be broken > is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or > with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.) > > I haven't yet figured out why that case is broken, but I'll keep fiddling > with it. (For me the getaddrinfo() fails for this case.) > > If you are not using the "-h" option on nfsd and udp isn't working, I > haven't got an explanation, because it seems to work for me? > I typed the above (and the bit about /etc/exports continuation lines) before I had poked around with it enough. The continuation lines seem to work and the "-h nfs-server.cis.uoguelph.ca" message logged is just because I'm using ipv4 only. I seem to get udp mounts to work fine, but... I've seen what Robert mentioned. I had just assumed it was some weirdness in my local lan. I've found that, if you "ping " before doing the mount, it seems to always work. (I usually see it when mounting a Solaris10 client to the FreeBSD8 server and it eventually times out and retries successfully. I normally use tcp mounts, so I didn't "connect" that with this problem.) So, maybe it's some network interaction issue and not an obvious goof up by me w.r.t. changes in the utilities? (The changes I did shouldn't have had anything to do with the mount protocol code in them.) rick From rmacklem at uoguelph.ca Tue Jun 2 21:31:20 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Jun 2 21:31:27 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: On Tue, 2 Jun 2009, Robert Watson wrote: > > I'm running into a similar-sounding but odd problem on a diskless NFS client > test box running 8.0, but talking to a server running 7.0: > > cheetah# mount -o rw -u / > [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable > to send > > If I do a fresh file system mount it works fine: > I just saw one almost the same as this. When I did an nfsv3,tcp mount I got a similar message, but it was for the NFS NULL RPC. I left it and after a while it retried and succeeded. I tried rebooting the client and server a couple of times, but wasn't able to get it to happen again. So, I wonder if what the others were seeing was something similar? rick (ps: I'm running a current kernel and nfs related utilities, but really old Feb. userland for the rest.) From roberthuff at rcn.com Tue Jun 2 22:00:57 2009 From: roberthuff at rcn.com (Robert Huff) Date: Tue Jun 2 22:01:04 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: Message-ID: <18981.41237.246524.796@jerusalem.litteratus.org> Ruben van Staveren writes: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I removed > > that warning in HEAD Sunday, and there is no a discussion about > > whether or not it should be put back, and whether or not there is any > > need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. What he said. In my case complicated by the fact the interfaces in question do some wierd-ass initialization (which is legacy from like sometime in 5.x and might be unnecessary ... but it took a long time to get working and isn't broke). Robert Huff From brooks at freebsd.org Tue Jun 2 22:06:14 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:06:25 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602205125.GA75470@Grumpy.DynDNS.org> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> Message-ID: <20090602220624.GD15552@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote: > On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > > > >Up till Sunday in 8-current, and for a long time in general > > >network.subr (part of the rc.d system) has emitted a warning that > > >values of network_interfaces other than AUTO are deprecated. I > > >removed that warning in HEAD Sunday, and there is no a discussion > > >about whether or not it should be put back, and whether or not there > > >is any need for the user to specify the list of network interfaces at > > >all. > > > > Well, I do. > > > > I only want to configure only the interfaces that are connected and > > that I know about. especially in combination with IPv6 there is a nit > > that you'll get autoconfiguration for all interfaces unless they are > > all explicitly configured. > > And while I'm not currently using anything other than AUTO I would think > there is a security ramification if someone were to plug in to a > supposedly unused port, then reboot the machine to prompt AUTO to > configure their interface. > > Its not just a security thing, its an "idiot-proof" thing. If someone is > moving machines around I don't want them to come up and partially work > if the wires are plugged into the wrong holes. Would rather it be > completely broken. > > I think its good that there is an AUTO *option*. Is also OK that it be > the default. I don't think mandatory AUTO is good, if I want a port > disabled then I want it to stay disabled. To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. For the system to do something with an interface the following must be true: - It makes it in to the list of interfaces somehow (either by adding it to network_interfaces or leaving network_interfaces alone) - It actually exists or is create early in the process via cloned_interfaces, gif_interfaces, etc - The ifconfig_ variable is set (I think i can be "", but "up" is always a good choice if you just want a stub. - The ifconfig_ variable must not contain the NOAUTO keyword. If all of those things are true, the interface will be configured at startup or on insert. Otherwise, it won't be. -- Brooks [0] This is at least true in the IPv4 case, the IPv6 case really needs work. I thought someone had patches to bring the IPv6 support up to par with the IPv4 case, but they haven't been committed yet. -------------- 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/20090602/98afd370/attachment.pgp From brooks at freebsd.org Tue Jun 2 22:09:23 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:09:30 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602220933.GE15552@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > >> Up till Sunday in 8-current, and for a long time in general >> network.subr (part of the rc.d system) has emitted a warning that >> values of network_interfaces other than AUTO are deprecated. I removed >> that warning in HEAD Sunday, and there is no a discussion about >> whether or not it should be put back, and whether or not there is any >> need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and that I > know about. especially in combination with IPv6 there is a nit that you'll > get autoconfiguration for all interfaces unless they are all explicitly > configured. See my other post on why this is a needless worry for the IPv4 case. > e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a > ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only > I'll get autoconfiguration of v6 where I don't want it to be. > > > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. with network_interfaces="bge0 lo0" network.subr > nevertheless sees bge1, and no configuration and takes the responsibility > of starting ipv6 autoconfiguration for it. The IPv6 case is clearly a bug. We should really consolidate the two cases and I think there are patches to do so if someone wants to setup up and help get them in. -- Brooks -------------- 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/20090602/6b4126db/attachment.pgp From randy at psg.com Tue Jun 2 22:20:59 2009 From: randy at psg.com (Randy Bush) Date: Tue Jun 2 22:21:08 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. bingo! From randy at psg.com Tue Jun 2 22:22:35 2009 From: randy at psg.com (Randy Bush) Date: Tue Jun 2 22:22:52 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> Message-ID: > To repeat what I wrote earlier today on another list there's no need > to worry about hot plugged or newly added interfaces getting magically > configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? randy From tinderbox at freebsd.org Tue Jun 2 22:24:48 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 2 22:25:01 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090602222445.2F6017302F@freebsd-current.sentex.ca> TB --- 2009-06-02 20:49:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 20:49:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 20:49:59 - cleaning the object tree TB --- 2009-06-02 20:50:33 - cvsupping the source tree TB --- 2009-06-02 20:50:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 20:50:43 - building world TB --- 2009-06-02 20:50:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 20:50:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 20:50:43 - TARGET=sun4v TB --- 2009-06-02 20:50:43 - TARGET_ARCH=sparc64 TB --- 2009-06-02 20:50:43 - TZ=UTC TB --- 2009-06-02 20:50:43 - __MAKE_CONF=/dev/null TB --- 2009-06-02 20:50:43 - cd /src TB --- 2009-06-02 20:50:43 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 20:50:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 2 22:09:39 UTC 2009 TB --- 2009-06-02 22:09:39 - generating LINT kernel config TB --- 2009-06-02 22:09:39 - cd /src/sys/sun4v/conf TB --- 2009-06-02 22:09:39 - /usr/bin/make -B LINT TB --- 2009-06-02 22:09:39 - building LINT kernel TB --- 2009-06-02 22:09:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 22:09:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 22:09:39 - TARGET=sun4v TB --- 2009-06-02 22:09:39 - TARGET_ARCH=sparc64 TB --- 2009-06-02 22:09:39 - TZ=UTC TB --- 2009-06-02 22:09:39 - __MAKE_CONF=/dev/null TB --- 2009-06-02 22:09:39 - cd /src TB --- 2009-06-02 22:09:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 22:09:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 22:24:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 22:24:45 - ERROR: failed to build lint kernel TB --- 2009-06-02 22:24:45 - 4661.38 user 422.42 system 5685.48 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From brooks at freebsd.org Tue Jun 2 22:48:42 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:48:48 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> Message-ID: <20090602224852.GF15552@lor.one-eyed-alien.net> On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote: > > To repeat what I wrote earlier today on another list there's no need > > to worry about hot plugged or newly added interfaces getting magically > > configured to do dhcp or anything else[0]. > > such as detected by services such as bind/unbound? The rc system will do nothing with interfaces that don't pass the tests I enumerated so if you don't have an ifconfig_ interface there won't be any difference no matter how you set network_interfaces. I'd be rather supprised if bind did anything with interaces that weren't configured with an address (or even up in the case of correctly funtioning drivers). -- Brooks -------------- 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/20090602/6187a5e1/attachment.pgp From freebsd-lists-erik at erikosterholm.org Tue Jun 2 23:26:36 2009 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Tue Jun 2 23:26:48 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602230648.GB88740@barragry.com> On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I > removed that warning in HEAD Sunday, and there is no a discussion > about whether or not it should be put back, and whether or not there > is any need for the user to specify the list of network interfaces > at all. > > If you use a value of network_interfaces other than AUTO please > speak up so that we can make an intelligent decision about this > issue. > > Thanks, > > Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik From dkelly at hiwaay.net Tue Jun 2 21:19:28 2009 From: dkelly at hiwaay.net (David Kelly) Date: Wed Jun 3 01:41:05 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602205125.GA75470@Grumpy.DynDNS.org> On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > >Up till Sunday in 8-current, and for a long time in general > >network.subr (part of the rc.d system) has emitted a warning that > >values of network_interfaces other than AUTO are deprecated. I > >removed that warning in HEAD Sunday, and there is no a discussion > >about whether or not it should be put back, and whether or not there > >is any need for the user to specify the list of network interfaces at > >all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an "idiot-proof" thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. A quick glance of my 7.2-STABLE machine only found network_interfaces used in /etc/defaults/rc.conf. ipv6_network_interfaces is used in many places. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From benno at jeamland.net Wed Jun 3 03:18:49 2009 From: benno at jeamland.net (Benno Rice) Date: Wed Jun 3 03:18:55 2009 Subject: CFR: sanity checking arguments to kldload(8) Message-ID: The attached patch performs some sanity checking on arguments passed to kldload(8). Specifically, if an argument looks like a filename but lacks a path (eg, 'xfs.ko' as opposed to 'xfs' or './xfs.ko') it checks to see if a file with that name is in the current directory. If it is, it checks the current module path to see if a file with that name also exists there (possibly in an earlier entry if the current directory is in the module path), if so it warns the user that that module will be loaded and not the one in the current directory. If not, it tells the user how to use a path to load the module. A -q option is added to quieten the output if desired. Sample output: # sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # pwd /boot/kernel # kldload xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # cd /boot/modules # pwd /boot/modules # ls xfs.ko* xfs.ko.symbols* # kldload xfs.ko kldload: xfs.ko will be loaded from /boot/kernel, not the current directory kldload: to load from the current directory use ./xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # kldload -q xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # cd fnord # pwd /boot/modules/fnord # ls ibcs2.ko* ibcs2.ko.symbols* # ls /boot/kernel/ibcs2.ko ls: /boot/kernel/ibcs2.ko: No such file or directory # ls /boot/modules/ibcs2.ko ls: /boot/modules/ibcs2.ko: No such file or directory # kldload ibcs2.ko kldload: ibcs2.ko is not in the module path kldload: to load from the current directory use ./ibcs2.ko # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # kldload -q ibcs2.ko # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # kldload ./ibcs2.ko # kldstat Id Refs Address Size Name 1 6 0xc0400000 cc016c kernel 2 1 0xc3a09000 b000 ibcs2.ko # kldunload ibcs2 # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel -------------- next part -------------- A non-text attachment was scrubbed... Name: kldload.diff Type: application/octet-stream Size: 3506 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090603/0f1e2a5e/kldload.obj -------------- next part -------------- -- Benno Rice benno@jeamland.net From benno at jeamland.net Wed Jun 3 05:08:15 2009 From: benno at jeamland.net (Benno Rice) Date: Wed Jun 3 05:08:21 2009 Subject: CFR: sanity checking arguments to kldload(8) In-Reply-To: References: Message-ID: On 03/06/2009, at 1:03 PM, Benno Rice wrote: > The attached patch performs some sanity checking on arguments passed > to kldload(8). Specifically, if an argument looks like a filename > but lacks a path (eg, 'xfs.ko' as opposed to 'xfs' or './xfs.ko') it > checks to see if a file with that name is in the current directory. > If it is, it checks the current module path to see if a file with > that name also exists there (possibly in an earlier entry if the > current directory is in the module path), if so it warns the user > that that module will be loaded and not the one in the current > directory. If not, it tells the user how to use a path to load the > module. > > A -q option is added to quieten the output if desired. I've had some feedback that the instructions on how to load the module from the current directory should instead be in the manual page. I've done this and added extra verbiage to point out the potential source of confusion wherein bare filenames (eg. foo.ko as opposed to ./foo.ko) will only ever be loaded from the module path. Further comments appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: kldload-2.diff Type: application/octet-stream Size: 4730 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090603/dc1cdf8c/kldload-2.obj -------------- next part -------------- -- Benno Rice benno@jeamland.net From rea-fbsd at codelabs.ru Wed Jun 3 05:25:43 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 3 05:26:01 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <20090602222445.2F6017302F@freebsd-current.sentex.ca> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > *** Error code 1 > > Stop in /obj/sun4v/src/sys/LINT. This seems to be related to the recent NETISR changes, namely, the addition of the pc_netisr member to the struct pcpu: http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u I am not sure how large (void *) is on sun4v, but it seems to me that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h should be compensated for this change. Something like ----- #ifdef KTR #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) #else #define PCPU_MD_FIELDS_PAD 3 #endif ----- though I am not very sure about KTR's case. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From mcdouga9 at egr.msu.edu Wed Jun 3 06:16:53 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Wed Jun 3 06:17:56 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! In-Reply-To: <4A1AC253.6010306@egr.msu.edu> References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> Message-ID: <20090603061650.GC1122@egr.msu.edu> I figured it out. I needed "options COMPAT_IA32" in my kernel config. On Mon, May 25, 2009 at 12:07:47PM -0400, Adam McDougall wrote: > Hi, > When compiling I get the following error > > kBuild: Installing tstUtf8 => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 > > kBuild: Installing tstUuid => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid > > kBuild: Installing tstVMStructGC => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC > > kBuild: Generating tstVMStructSize - > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: > 1: Syntax error: "(" unexpected > kmk[2]: *** > [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > Error 2 > kmk[2]: *** Deleting file > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > > kmk[2]: *** Waiting for unfinished jobs.... > awk -f /usr/src/sys/conf/kmod_syms.awk > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > | xargs -J% objcopy % > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > awk: can't open file > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > source line number 10 > kmk[2]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: Entering directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > Stop in /root/vBox/virtualbox. > demophon# > > > demophon# uname -a > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 > 09:04:17 UTC 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > Any ideas? > > Cheers > Paul > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > I am getting this error too from the latest test port on amd64 7-stable and 8-current: kBuild: Installing tstVMStructGC => /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC kBuild: Generating tstVMStructSize - /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs.... kmk[2]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: Entering directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 The OS builds are 1-3 days old (full kernel + world) and ports were up to date. Help? Thanks. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From pluknet at gmail.com Wed Jun 3 07:09:06 2009 From: pluknet at gmail.com (pluknet) Date: Wed Jun 3 07:09:13 2009 Subject: xorg loops In-Reply-To: <4A256867.8050808@lapo.it> References: <49D8D03B.8090302@arcor.de> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <4A256867.8050808@lapo.it> Message-ID: 2009/6/2 Lapo Luchini : > Tim Kientzle wrote: >> AllowEmptyInput hald Result >> off enabled Mouse/keyboard delays/jerkiness >> off disabled Works >> on (default) enabled Works >> on (default) disabled No mouse/keyboard > > Tim, I had your same symptoms (as far as "delays/jerkiness" can go): > when using the USB external mouse and leaving it in *some* positions, > the whole system was paused until I move the mouse even a little bit, at > that point all "missing events" (i.e. all keypresses that didn't produce > any output, or also all screen updates) are shown in fast-forward (e.g. > the Firefox spinner of a loading tab was stopped until the mouse moved, > and made the 3 missing turns rapidly, then all to normal). When the > mouse was left in other positions, no problem was shown. > > After Googling your message I commented-out the AllowEmptyInput line in > my xorg.conf and now both internal touchpad and external mouse work > perfectly and don't "halt the event queue" (or what it was) anymore. > > I still wonder the reason behind this behavior but as long as it's > working, I won't complain. +1 That's exactly what helps me with this problem. -- wbr, pluknet From d9364104 at mail.nchu.edu.tw Wed Jun 3 07:19:15 2009 From: d9364104 at mail.nchu.edu.tw (Eric L. Chen) Date: Wed Jun 3 07:19:21 2009 Subject: Cannot run iperf with Atheros AR9160 Message-ID: <1244013545.2189.8.camel@localhost> Hi I have an Atheros AR9160 miniPCI board, installed in my Centrino laptop (but the laptop has only two antenna). When I run iperf (from ports benchmarks/iperf) to test 11n, the test cannot done. Console log says bb hang, but I can ping peer node without problems. I think AR9160 driver cannot work in heavy traffic loading. ~> uname -a FreeBSD lihong-nb 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Tue Jun 2 21:24:53 CST 2009 root@lihong-nb:/usr/obj/usr/src/sys/LIHONG-NB i386 dmesg: ath0: mem 0xc8200000-0xc820ffff irq 17 at device 3.0 on pci6 ath0: [ITHREAD] ath0: AR9160 mac 64.1 RF5133 phy 11.0 .... ath0: bb hang detected (0x80), reseting wlan0: link state changed to DOWN bfe0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80) wlan0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x80), reseting wlan0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x1), reseting ath0: bb hang detected (0x1) ath0: bb hang detected (0x1) iperf: ~> iperf -i 1 -t 10 -c 192.168.10.1 ------------------------------------------------------------ Client connecting to 192.168.10.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.10.114 port 60096 connected with 192.168.10.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 952 KBytes 7.80 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 1.0- 2.0 sec 712 KBytes 5.83 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 2.0- 3.0 sec 504 KBytes 4.13 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 3.0- 4.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 11.0-12.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 12.0-13.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 13.0-14.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 14.0-15.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 15.0-16.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 17.0-18.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 19.0-20.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 20.0-21.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 21.0-22.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 22.0-23.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 23.0-24.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 24.0-25.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 25.0-26.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-26.1 sec 2.12 MBytes 683 Kbits/sec From peterjeremy at optushome.com.au Wed Jun 3 07:52:09 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jun 3 07:52:16 2009 Subject: Hard hang with u3g and -current Message-ID: <20090603075205.GB27800@server.vk2pj.dyndns.org> I have a Huawei E169 3G modem which I'm using with the u3g driver on -current/i386 from about 4 weeks ago on my Aspire One (dual-core N270). If I access the stats port (/dev/cuaD0.2) then the system will randomly hang. The problem seems to occur more frequently when I'm using X but I've also seen it (once) when I was using a VTY. I'm not using hald. There doesn't seem to be a problem if I don't access /dev/cuaD0.2. When the system hangs, the 3G modem hangs up (though this may be the keepalive timer expiring at the remote end) and there's no response to the keyboard (Ctrl-Alt-Del and Ctrl-Alt-Fn from X; Ctrl-Alt-Esc and Alt-Fn from VTY; CapsLock, NumLock in either mode). The kernel still responds to pings over ethernet and I can change brightness via the keyboard so SMM is still working. Has anyone else seen anything like this? Can anyone suggest a way to track this down? I can't get to DDB, there's no serial, firewire, PCcard or similar I/O. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090603/e9a5c6c4/attachment.pgp From tinderbox at freebsd.org Wed Jun 3 08:43:15 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jun 3 08:43:22 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090603084312.346F47302F@freebsd-current.sentex.ca> TB --- 2009-06-03 07:11:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-03 07:11:10 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-03 07:11:10 - cleaning the object tree TB --- 2009-06-03 07:12:01 - cvsupping the source tree TB --- 2009-06-03 07:12:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-03 07:12:15 - building world TB --- 2009-06-03 07:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 07:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 07:12:15 - TARGET=sun4v TB --- 2009-06-03 07:12:15 - TARGET_ARCH=sparc64 TB --- 2009-06-03 07:12:15 - TZ=UTC TB --- 2009-06-03 07:12:15 - __MAKE_CONF=/dev/null TB --- 2009-06-03 07:12:15 - cd /src TB --- 2009-06-03 07:12:15 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 3 07:12:17 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jun 3 08:28:10 UTC 2009 TB --- 2009-06-03 08:28:10 - generating LINT kernel config TB --- 2009-06-03 08:28:10 - cd /src/sys/sun4v/conf TB --- 2009-06-03 08:28:10 - /usr/bin/make -B LINT TB --- 2009-06-03 08:28:10 - building LINT kernel TB --- 2009-06-03 08:28:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 08:28:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 08:28:10 - TARGET=sun4v TB --- 2009-06-03 08:28:10 - TARGET_ARCH=sparc64 TB --- 2009-06-03 08:28:10 - TZ=UTC TB --- 2009-06-03 08:28:10 - __MAKE_CONF=/dev/null TB --- 2009-06-03 08:28:10 - cd /src TB --- 2009-06-03 08:28:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 3 08:28:10 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-03 08:43:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-03 08:43:12 - ERROR: failed to build lint kernel TB --- 2009-06-03 08:43:12 - 4650.09 user 424.72 system 5521.49 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From paul at fletchermoorland.co.uk Wed Jun 3 09:13:56 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Wed Jun 3 09:14:04 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! In-Reply-To: <20090603061650.GC1122@egr.msu.edu> References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> <20090603061650.GC1122@egr.msu.edu> Message-ID: <4A263ECD.2070704@fletchermoorland.co.uk> That makes perfect sense. On my machine, I commented out 32bit compatibility as I figured I would not need it. This is the first time it has caught me out... Adam McDougall wrote: > I figured it out. I needed "options COMPAT_IA32" > in my kernel config. > > On Mon, May 25, 2009 at 12:07:47PM -0400, Adam McDougall wrote: > > > Hi, > > When compiling I get the following error > > > > kBuild: Installing tstUtf8 => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 > > > > kBuild: Installing tstUuid => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid > > > > kBuild: Installing tstVMStructGC => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC > > > > kBuild: Generating tstVMStructSize - > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > > > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: > > 1: Syntax error: "(" unexpected > > kmk[2]: *** > > [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > > Error 2 > > kmk[2]: *** Deleting file > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > > > > kmk[2]: *** Waiting for unfinished jobs.... > > awk -f /usr/src/sys/conf/kmod_syms.awk > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > | xargs -J% objcopy % > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > > > awk: can't open file > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > > > source line number 10 > > kmk[2]: Leaving directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk[2]: Entering directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk[2]: *** Exiting with status 2 > > kmk[1]: *** [pass_binaries_this] Error 2 > > kmk[1]: Leaving directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk: *** [pass_binaries_order] Error 2 > > *** Error code 2 > > > > Stop in /root/vBox/virtualbox. > > demophon# > > > > > > demophon# uname -a > > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 > > 09:04:17 UTC 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > > > Any ideas? > > > > Cheers > > Paul > > _______________________________________________ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > > I am getting this error too from the latest test port on amd64 7-stable > and 8-current: > > kBuild: Installing tstVMStructGC => > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC > kBuild: Generating tstVMStructSize - > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: > 1: Syntax error: "(" unexpected > kmk[2]: *** > [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > Error 2 > kmk[2]: *** Deleting file > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > kmk[2]: *** Waiting for unfinished jobs.... > kmk[2]: Leaving directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk[2]: Entering directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > > The OS builds are 1-3 days old (full kernel + world) and ports were up > to date. Help? Thanks. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From paul at fletchermoorland.co.uk Wed Jun 3 09:33:08 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Wed Jun 3 09:33:18 2009 Subject: Booting from ZFS RaidZ In-Reply-To: <9476D694-4825-4DDD-80AE-B34B367A85B4@rabson.org> References: <4A1D5E7B.4030605@fletchermoorland.co.uk> <4A1D9AC6.2020603@fletchermoorland.co.uk> <13C11BDA-1354-4108-B087-09956C2A8F63@rabson.org> <4A2018EE.5020204@fletchermoorland.co.uk> <9476D694-4825-4DDD-80AE-B34B367A85B4@rabson.org> Message-ID: <4A264350.2000908@fletchermoorland.co.uk> Doug Rabson wrote: > > On 29 May 2009, at 18:18, Paul Wootton wrote: > >> Doug Rabson wrote: >>> >>> On 27 May 2009, at 20:55, Paul Wootton wrote: >>> >>>> Doug Rabson wrote: >>>>> >>>>> On 27 May 2009, at 16:38, Paul Wootton wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> With the recent changes allowing RaidZ boot, I thought I would >>>>>> finally drop my mirror pack and go RaidZ. >>>>>> >>>>>> The only problem I now have is >>>>>> demophon# zpool set bootfs=DemoPool/root DemoPool >>>>>> cannot set property for 'DemoPool': operation not supported on >>>>>> this type of pool >>>>>> >>>>>> Is this still a work in progress, or do I have something a-miss? >>>>>> >>>>>> I am using current as of today >>>>>> "demophon# uname -a >>>>>> FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #17: Wed May 27 >>>>>> 13:18:06 BST 2009 >>>>>> paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64" >>>>> >>>>> This is a limitation which I will remove as soon as I have a >>>>> little time to work on it. Basically, Solaris can only boot from >>>>> simple structures such as mirrors and collections of mirrors. The >>>>> code enforces this by stopping you from setting the bootfs >>>>> property if the pool configuration is too complex for the Solaris >>>>> boot code. I will simply remove this limitation for FreeBSD since >>>>> we can now boot from any pool configuration. >>>>> >>>>> In the meantime, you can still boot if you put your root >>>>> filesystem files in the root of the pool. Not ideal I know but >>>>> I'll try to fix it properly soon. >>>>> >>>> >>>> This does seem to work correctly for me as I get a BTX crash (see >>>> below) >>>> >>>> Verifying DMI Poll Data ............. >>>> \ >>>> FreeBSD/i386 boot >>>> Default:DemoPool:/boot/kernel/kernel >>>> boot: >>>> | >>>> int=00000000 err=00000000 elf=00010083 eip=00192adf >>>> eax=00192e02a ebx=df5610ed ecx=d485b986 edx=00000000 >>>> esi=00000040 edi=000935d0 ebp=0009339c esp=00000000 >>>> cs=0008 ds=0010 es=0010 fs-0010 gs=0010 ss=0010 >>>> cs:eip=c5 e4 00 66 0f 73 dc 02-ff e4 b8 8d 8d bc f2 2a >>>> e9 ba e6 f4 2a 8a d8 24-df 86 c4 be 00 2b e9 8b >>>> ss:esp=16 e8 00 f0 16 e8 00 f0-c3 e2 00 f0 16 e8 00 f0 >>>> 16 e8 00 f0 54 ff 00 f0-b8 6e 00 f0 16 e8 00 f0 >>>> BTX halted >>> >>> How frustrating. Can you give me some idea on your ZFS pool >>> configuration. Also, if you can dig out the symbol table for >>> /boot/loader (it should be lurking somewhere in your /usr/obj tree >>> as loader.sym), it would be interesting to see where it crashed >>> (i.e. whats the closest symbol to the value of EIP above). >>> >>> _______________________________________________ >>> 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" >>> >> Erm, Opps.... Im an idiot.... >> I went back over my steps and realised the I had forgotten to do a >> "make distrib-dirs" and "make distribution" >> Now it boots the kernel but I can not get it to mount the root filing >> system. >> I have got a few more thinks to try before I throw my hands in the >> air, but unfortunately that will not be until after the weekend (the >> BSD is my main PC at work) > > What do you have in /etc/fstab for the root filesystem? I'm not > exactly sure if the root mounting code can cope with mounting the root > of the pool as root filesystem. You might try the attached patch which > should allow setting bootfs on raidz pools to something more useful > than the root. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I only have my swaps in the fstab file. This is the same as what i did for for my single and mirror setup. In /boot/loader.conf I specified "vfs.root.mountfrom=zfs:DemoPool/root" The kernel loads and then fails just before switching to user land with an error saying trying to mount root from zfs:DemoPool/root and failed. It then asks for user intervention and specify where to load root filing system from. Pressing ? lists all my drives and ufs slices, but not any zfs partitions. zfsroot is an ex-mirror setup, only running on one drive now. This boots fine and all is happy - again, nothing really in fstab but vfs.root.mountfrom=zfs:zfsroot/root in /boot/loader.conf During all the tests, I was swapping the mountpoints so not to cause conflicts with each other... As an experiment, I bootup from the raidz pool but changed to vfs.root.mountfrom=zfs:zfsroot/root The kernel loaded but as before, bombed out asking for user intervention for where to find root. Then is tried bootinng from the zfsroot single disk pool and set vfs.root.mountfrom=zfs:DemoPool/root. This booted up correctly and the machine was happy, although it meant that I had to use a none raidz drive to bootstrap - not really what I was looking for. I have bootfs=DemoPool/root on DemoPool. Any ideas? Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From rea-fbsd at codelabs.ru Wed Jun 3 09:54:36 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 3 09:54:43 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: Wed, Jun 03, 2009 at 09:25:38AM +0400, Eygene Ryabinkin wrote: > Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c > > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > > *** Error code 1 > > > > Stop in /obj/sun4v/src/sys/LINT. > > This seems to be related to the recent NETISR changes, namely, the > addition of the pc_netisr member to the struct pcpu: > http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u > > I am not sure how large (void *) is on sun4v, but it seems to me > that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h ^^^^^^^^^^^^ Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > should be compensated for this change. Something like > ----- > #ifdef KTR > #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) > #else > #define PCPU_MD_FIELDS_PAD 3 > #endif > ----- > though I am not very sure about KTR's case. KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just now we won't be able to reach this with the current definition for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative and that's bad. The attached patch should fix this (although I have no sun4v to test on, so take it with a grain of salt). By the way, having looked at sys/sys/pcpu.h, I see that there are parts of 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am missing something? Thanks. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- diff --git a/sys/sun4v/include/pcpu.h b/sys/sun4v/include/pcpu.h index 434f1cd..12eddf2 100644 --- a/sys/sun4v/include/pcpu.h +++ b/sys/sun4v/include/pcpu.h @@ -38,11 +38,20 @@ struct pmap; -#ifdef KTR -#define PCPU_MD_FIELDS_PAD (4 - (PCPU_NAME_LEN + 7) / 8) -#else -#define PCPU_MD_FIELDS_PAD 4 -#endif +/* Alignment requirements for 'struct pcpu', must be power of two. */ +#define PCPU_ALIGN (1<<6) +/* Bytes per one pad entry */ +#define PCPU_BPP 8 +/* Maximal size of padding */ +#define PCPU_MAXPAD (PCPU_ALIGN / PCPU_BPP) + +#if defined(KTR) +#define _KTR_PAD (PCPU_MAXPAD - ((PCPU_NAME_LEN + PCPU_BPP - 1)/PCPU_BPP) % PCPU_MAXPAD) +#else /* defined(KTR) */ +#define _KTR_PAD 0 +#endif /* defined(KTR) */ + +#define PCPU_MD_FIELDS_PAD ((3 + _KTR_PAD) % PCPU_MAXPAD) /* * Inside the kernel, the globally reserved register g7 is used to From rea-fbsd at codelabs.ru Wed Jun 3 10:16:00 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 3 10:16:18 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > Just now we won't be able to reach this with the current definition > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > become negative and that's bad. And while I am here: definition for PCPU_NAME_LEN seems to be wrong. It is intended to fit ("CPU %d", cpuid) where cpuid <= MAXCPU. If this is correct, then (sys/sys/pcpu.h, line 57) 1. sizeof(__XSTRING(MAXCPU) + 1) is a typo: typeof(__XSTRING(...) + 1) is 'char *', so sizeof() will return the size of the pointer, not the size of the string contents. The proper expression should be 'sizeof(__XSTRING(MAXCPU)) + 1'. 2. one should not add one, but substract it: sizeof() accounts for the trailing '\0' and we have two sizeof's, so the size of one '\0' should be substracted -- this will give the maximal string buffer length for CPU with its number, no less, no more. Does the attached patch looks sane? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 63c3fa3..98705eb 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -54,7 +54,7 @@ struct rm_queue { struct rm_queue* volatile rmq_prev; }; -#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU) + 1)) +#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU)) - 1) /* From kostikbel at gmail.com Wed Jun 3 11:57:28 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 3 11:57:35 2009 Subject: Hard hang with u3g and -current In-Reply-To: <20090603075205.GB27800@server.vk2pj.dyndns.org> References: <20090603075205.GB27800@server.vk2pj.dyndns.org> Message-ID: <20090603115722.GJ1927@deviant.kiev.zoral.com.ua> On Wed, Jun 03, 2009 at 05:52:05PM +1000, Peter Jeremy wrote: > I have a Huawei E169 3G modem which I'm using with the u3g driver on > -current/i386 from about 4 weeks ago on my Aspire One (dual-core > N270). If I access the stats port (/dev/cuaD0.2) then the system will > randomly hang. The problem seems to occur more frequently when I'm > using X but I've also seen it (once) when I was using a VTY. I'm not > using hald. There doesn't seem to be a problem if I don't access > /dev/cuaD0.2. > > When the system hangs, the 3G modem hangs up (though this may be the > keepalive timer expiring at the remote end) and there's no response to > the keyboard (Ctrl-Alt-Del and Ctrl-Alt-Fn from X; Ctrl-Alt-Esc and > Alt-Fn from VTY; CapsLock, NumLock in either mode). The kernel still > responds to pings over ethernet and I can change brightness via the > keyboard so SMM is still working. > > Has anyone else seen anything like this? > > Can anyone suggest a way to track this down? I can't get to DDB, there's > no serial, firewire, PCcard or similar I/O. I am not volunteering to do the debugging. I am only to suggest how to grab the debugging information for this case, that looks like a deadlock. Since parts of the network stack are functional, add ddb script to dump neccessary information, and trigger it by receiving some specially formatted ping packet. I higly suspect that you need at least backtraces of all threads and information on held locks. -------------- 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/20090603/658cfa2f/attachment.pgp From amdmi3 at amdmi3.ru Wed Jun 3 12:13:16 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed Jun 3 12:13:24 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090601182012.GA21543@darkthrone.kvedulv.de> References: <20090601182012.GA21543@darkthrone.kvedulv.de> Message-ID: <20090603121307.GA15659@hades.panopticon> * Michael Moll (kvedulv@kvedulv.de) wrote: Very same panic here. Also, for some reason writing dumps to disk don't work, it either stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum value it managed to write is ~800MB), or just freezes with buffer-related message (may try to reproduct panic to get it). That's -current from today, 8GB physmem, 10GB swap, disk plain 200GB ATA with bsdlabel. There are also 6 SATA disks with ZFS. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From brooks at freebsd.org Wed Jun 3 14:13:13 2009 From: brooks at freebsd.org (Brooks Davis) Date: Wed Jun 3 14:13:20 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602230648.GB88740@barragry.com> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> Message-ID: <20090603141321.GC28486@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I > > removed that warning in HEAD Sunday, and there is no a discussion > > about whether or not it should be put back, and whether or not there > > is any need for the user to specify the list of network interfaces > > at all. > > > > If you use a value of network_interfaces other than AUTO please > > speak up so that we can make an intelligent decision about this > > issue. > > > > Thanks, > > > > Doug > > I'll have to preface this by disclosing that I have not been running > -current, nor following any changes to the RC system. > > In 7.1, if you compile a custom kernel and comment out an interface > (such that it is compiled as a module), one way to ensure that the > module is loaded is to explicitly list it in network_interfaces. If > -current works the same way, then users will be required to modify > /boot/loader.conf in order to load the module. Could there could be > possible side-effects to this change, since the loading of the module > happens at a different time? Do you actually do this? > At best, users doing things the 'network_interfaces' way may be in for > a surprise when the update (remotely), and this may be worthy of a > note in UPDATING. > > If this has changed in 7.2 or -current, then I apologize for the > noise! The deprecation is a change relative to 7.0, but was in 7.1. -- Brooks -------------- 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/20090603/ff4e3648/attachment.pgp From wxs at FreeBSD.org Wed Jun 3 15:28:12 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jun 3 15:28:18 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603121307.GA15659@hades.panopticon> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> Message-ID: <20090603152810.GA21014@atarininja.org> On Wed, Jun 03, 2009 at 04:13:07PM +0400, Dmitry Marakasov wrote: > * Michael Moll (kvedulv@kvedulv.de) wrote: > > Very same panic here. > > Also, for some reason writing dumps to disk don't work, it either > stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum > value it managed to write is ~800MB), or just freezes with > buffer-related message (may try to reproduct panic to get it). I'm seeing the same thing but I got a useful vmcore and crash.txt out of it. I can put them online if anyone wants to see them. -- WXS From rmacklem at uoguelph.ca Wed Jun 3 15:51:52 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Jun 3 15:52:00 2009 Subject: NFS mounts default to a mix of udp and tcp Message-ID: Although it doesn't explain the problem with nfs mounts over udp where the mountd doesn't seem to reply, this might explain some of the confusion. Near the beginning of mount_nfs.c, "nfsproto" is initialized to IPPROTO_UDP and, as such, by default, the mount protocol and NFS Null RPC is done over "udp". However, the -current kernel code in sys/nfsclient/nfs_vfsops.c and the system call done by mount_nfs.c defaults to "tcp". Therefore, unless "udp" or "tcp" is explicitly specified as mount_nfs options, it uses "udp" for the mount protocol and Null RPC, then switches to "tcp" from there on. This wasn't something I changed, so I think it has been this way since the nmount() syscall was introduced. Seems like the default should be all "tcp" or all "udp". Which do you think it should be? rick ps: This would explain a case where a server only supports udp and the mount didn't explicitly specify "udp", but it doesn't explain why mounts seem to be intermittently failing. From ruben at verweg.com Wed Jun 3 14:48:28 2009 From: ruben at verweg.com (Ruben van Staveren) Date: Wed Jun 3 15:54:18 2009 Subject: On the topic of network_interfaces, optional full automatic renaming of interfaces Message-ID: Hi lists, Now the topic of network_interfaces has been mentioned, and the freeze for 8-stable is near I wonder if there is enough interest in the following feature to be included: http://ruben.is.verweg.com/stuff/freebsd/ifrename/ There is some dust there in that directory (It works, but is nowhere finished yet), but basically this early rc.d script takes the functionality of ifconfig_XXX_name a step further and enables optional automatic renaming of all ethernet capable interfaces, and enumerate them in the order probed by the kernel. A possible usage scenario is where you do massive imaging of a freebsd installation in where you don't know beforehand it will end up on hardware that has Broadcom or Intel NICs but it is for certain the cable will be connected to the first interface available and the same interface name can be referenced throughout all configuration files that need it (pf.conf, rc.conf(.local), /etc/rc.conf.d/network ) An other application usage is nailing down interface names using ethernet address, either because of correcting "mistakes" in the hardware (e.g. some Dell PowerEdges have the port labelled first to be probed as second and vice versa) or the necessity to only allow that interface to exist if it's MAC is the one that was configured (because of switch port ACL's) Regards, Ruben From sam at freebsd.org Wed Jun 3 16:02:41 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Jun 3 16:02:48 2009 Subject: Cannot run iperf with Atheros AR9160 In-Reply-To: <1244013545.2189.8.camel@localhost> References: <1244013545.2189.8.camel@localhost> Message-ID: <4A269E9E.1070304@freebsd.org> There are chip bugs Atheros won't disclose the WAR for so the driver is hobbled. In my testing the hangs were recovered w/ minimal impact. You will need to scrape the necessary crap from the linux driver to find what is amiss. Sam Eric L. Chen wrote: > Hi > I have an Atheros AR9160 miniPCI board, installed in my Centrino laptop > (but the laptop has only two antenna). > When I run iperf (from ports benchmarks/iperf) to test 11n, the test > cannot done. Console log says bb hang, but I can ping peer node without > problems. > I think AR9160 driver cannot work in heavy traffic loading. > ~> uname -a > FreeBSD lihong-nb 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Tue Jun 2 > 21:24:53 CST 2009 root@lihong-nb:/usr/obj/usr/src/sys/LIHONG-NB > i386 > > dmesg: > ath0: mem 0xc8200000-0xc820ffff irq 17 at device 3.0 on > pci6 > ath0: [ITHREAD] > ath0: AR9160 mac 64.1 RF5133 phy 11.0 > .... > ath0: bb hang detected (0x80), reseting > wlan0: link state changed to DOWN > bfe0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x80), reseting > ath0: bb hang detected (0x80) > wlan0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x80), reseting > wlan0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x1), reseting > ath0: bb hang detected (0x1) > ath0: bb hang detected (0x1) > > iperf: > ~> iperf -i 1 -t 10 -c 192.168.10.1 > ------------------------------------------------------------ > Client connecting to 192.168.10.1, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.10.114 port 60096 connected with 192.168.10.1 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 1.0 sec 952 KBytes 7.80 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 1.0- 2.0 sec 712 KBytes 5.83 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 2.0- 3.0 sec 504 KBytes 4.13 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 3.0- 4.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 11.0-12.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 12.0-13.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 13.0-14.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 14.0-15.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 15.0-16.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 17.0-18.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 19.0-20.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 20.0-21.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 21.0-22.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 22.0-23.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 23.0-24.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 24.0-25.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 25.0-26.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-26.1 sec 2.12 MBytes 683 Kbits/sec > > > _______________________________________________ > 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 antab at valka.is Wed Jun 3 16:04:21 2009 From: antab at valka.is (Arnar Mar Sig) Date: Wed Jun 3 16:04:27 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> Message-ID: <7846B8AD-A336-4BEB-B749-CD023DF13A9F@valka.is> On Jun 2, 2009, at 11:32 PM, Rick Macklem wrote: > > > On Tue, 2 Jun 2009, Robert Watson wrote: > >> >> I'm running into a similar-sounding but odd problem on a diskless >> NFS client test box running 8.0, but talking to a server running 7.0: >> >> cheetah# mount -o rw -u / >> [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - >> RPC: Unable to send >> >> If I do a fresh file system mount it works fine: >> > I just saw one almost the same as this. When I did an nfsv3,tcp > mount I > got a similar message, but it was for the NFS NULL RPC. > > I left it and after a while it retried and succeeded. > > I tried rebooting the client and server a couple of times, but wasn't > able to get it to happen again. > > So, I wonder if what the others were seeing was something similar? > rick > (ps: I'm running a current kernel and nfs related utilities, but > really > old Feb. userland for the rest.) I'm able to use udp mounts again after reverting to r192672. I also tried r192927 and it did not work. I did complete world when updating. Arnar Mar Sig From wxs at FreeBSD.org Wed Jun 3 16:09:46 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jun 3 16:09:53 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603152810.GA21014@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> Message-ID: <20090603160945.GC21014@atarininja.org> On Wed, Jun 03, 2009 at 11:28:10AM -0400, Wesley Shields wrote: > On Wed, Jun 03, 2009 at 04:13:07PM +0400, Dmitry Marakasov wrote: > > * Michael Moll (kvedulv@kvedulv.de) wrote: > > > > Very same panic here. > > > > Also, for some reason writing dumps to disk don't work, it either > > stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum > > value it managed to write is ~800MB), or just freezes with > > buffer-related message (may try to reproduct panic to get it). > > I'm seeing the same thing but I got a useful vmcore and crash.txt out of > it. I can put them online if anyone wants to see them. [ The panic message and backtrace from ddb is at http://people.freebsd.org/~wxs/crash.txt ] (kgdb) frame 12 #12 0xffffffff80572e7f in prison_priv_check (cred=0xffffff00168f5900, priv=334) at /usr/home/wxs/freebsd/src/head/sys/kern/kern_jail.c:3315 3315 switch (priv) { (kgdb) p priv $6 = 334 334 is PRIV_VFS_MOUNT_OWNER sys/kern/kern_jail.c: 3451 case PRIV_VFS_MOUNT_OWNER: 3452 if (cred->cr_prison->pr_allow & PR_ALLOW_MOUNT) 3453 return (0); 3454 else 3455 return (EPERM); (kgdb) p/x *cred $7 = {cr_ref = 0x1, cr_uid = 0x0, cr_ruid = 0x0, cr_svuid = 0x0, cr_ngroups = 0x1, cr_groups = {0x0 }, cr_rgid = 0x0, cr_svgid = 0x0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_vimage = 0x0, cr_flags = 0x0, cr_pspare = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 0x0, ai_mask = {am_success = 0x0, am_failure = 0x0}, ai_termid = {at_port = 0x0, at_type = 0x0, at_addr = {0x0, 0x0, 0x0, 0x0}}, ai_asid = 0x0, ai_flags = 0x0}} (kgdb) cred->cr_prison is null? It is my understanding that when not jailed cred->cr_prison should be &prison0 with the new hierarchical jails. The fact that it is null is causing prison_priv_check to enter the switch statement, leading to the crash. I'm not sure why cred->cr_prison is null in this case. -- WXS From aturetta at commit.it Wed Jun 3 16:36:56 2009 From: aturetta at commit.it (Angelo Turetta) Date: Wed Jun 3 16:37:09 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: <4A26A239.5050608@commit.it> Doug Barton wrote: > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces="lo0 em0 dmz" ifconfig_em0="up" cloned_interfaces="vlan0" ifconfig_vlan0_name="dmz" ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Ciao, Angelo. From amdmi3 at amdmi3.ru Wed Jun 3 17:20:42 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed Jun 3 17:20:50 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603160945.GC21014@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> Message-ID: <20090603172033.GC27282@hades.panopticon> * Wesley Shields (wxs@FreeBSD.org) wrote: Well, cred->cr_prison was the only thing to panic on in prison_priv_check, so that was obvious without the backtrace. I'll try to addd checking for null pointer here for now (as I'm more concerned in bringing my NAS back up). However, inability to dump properly still worries me. With this bug the box will not even reboot on panic :/ Switching to textdumps may be a temporary solution though. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From wxs at FreeBSD.org Wed Jun 3 17:40:24 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jun 3 17:40:31 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603172033.GC27282@hades.panopticon> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603172033.GC27282@hades.panopticon> Message-ID: <20090603174023.GA23095@atarininja.org> On Wed, Jun 03, 2009 at 09:20:33PM +0400, Dmitry Marakasov wrote: > * Wesley Shields (wxs@FreeBSD.org) wrote: > > Well, cred->cr_prison was the only thing to panic on in prison_priv_check, > so that was obvious without the backtrace. I'll try to addd checking > for null pointer here for now (as I'm more concerned in bringing > my NAS back up). Adding a check for null to jailed() in kern_jail.c will most likely work around the problem, but I was under the impression that cred->cr_prison should be &prison0 and never null with the new way of doing things. I'd still like to know why cr_prison is null. Of course, I have no idea what the implications of a null check in jailed() will be outside of this one scenario. -- WXS From tinderbox at freebsd.org Wed Jun 3 18:59:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jun 3 18:59:38 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090603185920.B5CF17302F@freebsd-current.sentex.ca> TB --- 2009-06-03 17:29:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-03 17:29:44 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-03 17:29:45 - cleaning the object tree TB --- 2009-06-03 17:30:14 - cvsupping the source tree TB --- 2009-06-03 17:30:14 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-03 17:30:22 - building world TB --- 2009-06-03 17:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 17:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 17:30:22 - TARGET=sun4v TB --- 2009-06-03 17:30:22 - TARGET_ARCH=sparc64 TB --- 2009-06-03 17:30:22 - TZ=UTC TB --- 2009-06-03 17:30:22 - __MAKE_CONF=/dev/null TB --- 2009-06-03 17:30:22 - cd /src TB --- 2009-06-03 17:30:22 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 3 17:30:23 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jun 3 18:44:17 UTC 2009 TB --- 2009-06-03 18:44:17 - generating LINT kernel config TB --- 2009-06-03 18:44:17 - cd /src/sys/sun4v/conf TB --- 2009-06-03 18:44:17 - /usr/bin/make -B LINT TB --- 2009-06-03 18:44:18 - building LINT kernel TB --- 2009-06-03 18:44:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 18:44:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 18:44:18 - TARGET=sun4v TB --- 2009-06-03 18:44:18 - TARGET_ARCH=sparc64 TB --- 2009-06-03 18:44:18 - TZ=UTC TB --- 2009-06-03 18:44:18 - __MAKE_CONF=/dev/null TB --- 2009-06-03 18:44:18 - cd /src TB --- 2009-06-03 18:44:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 3 18:44:18 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-03 18:59:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-03 18:59:20 - ERROR: failed to build lint kernel TB --- 2009-06-03 18:59:20 - 4644.33 user 426.38 system 5375.64 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From marius at alchemy.franken.de Wed Jun 3 20:00:18 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Jun 3 20:00:24 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: <20090603200013.GB43137@alchemy.franken.de> On Wed, Jun 03, 2009 at 02:15:55PM +0400, Eygene Ryabinkin wrote: > Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > > Just now we won't be able to reach this with the current definition > > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > > become negative and that's bad. > > And while I am here: definition for PCPU_NAME_LEN seems to be wrong. > It is intended to fit ("CPU %d", cpuid) where cpuid <= MAXCPU. If this > is correct, then (sys/sys/pcpu.h, line 57) > > 1. sizeof(__XSTRING(MAXCPU) + 1) is a typo: typeof(__XSTRING(...) + 1) > is 'char *', so sizeof() will return the size of the pointer, not > the size of the string contents. The proper expression should be > 'sizeof(__XSTRING(MAXCPU)) + 1'. > > 2. one should not add one, but substract it: sizeof() accounts for the > trailing '\0' and we have two sizeof's, so the size of one '\0' > should be substracted -- this will give the maximal string buffer > length for CPU with its number, no less, no more. > > Does the attached patch looks sane? > diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h > index 63c3fa3..98705eb 100644 > --- a/sys/sys/pcpu.h > +++ b/sys/sys/pcpu.h > @@ -54,7 +54,7 @@ struct rm_queue { > struct rm_queue* volatile rmq_prev; > }; > > -#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU) + 1)) > +#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU)) - 1) > > > /* This looks correct to me. Jeff? Marius From bz at FreeBSD.org Wed Jun 3 20:01:09 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Jun 3 20:01:17 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603160945.GC21014@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> Message-ID: <20090603184215.L12292@maildrop.int.zabbadoz.net> On Wed, 3 Jun 2009, Wesley Shields wrote: Hi, >>>>... > [ The panic message and backtrace from ddb is at > http://people.freebsd.org/~wxs/crash.txt ] > ... > cred->cr_prison is null? It is my understanding that when not jailed > cred->cr_prison should be &prison0 with the new hierarchical jails. The > fact that it is null is causing prison_priv_check to enter the switch > statement, leading to the crash. > > I'm not sure why cred->cr_prison is null in this case. The question here is not if cred->cr_prison can be null but where is the cred coming from? If you look at init_main.c around lines 440 - 457 you'll find prison0 being further initialized (cpuset) and p_ucred->cr_prison being set to &prsion0. And a bit further down in l470 td_ucred is initialized from that. cr_prison should thus always be setup. What you are looking at above looks like a crget() with only cr_ngroups updated. [removing a lot more text as I was going on debugging in a very small window] I would start looking at svc_getcred() and blame at least the AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From brooks at freebsd.org Wed Jun 3 20:05:10 2009 From: brooks at freebsd.org (Brooks Davis) Date: Wed Jun 3 20:05:21 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A26A239.5050608@commit.it> References: <4A257B82.1000701@FreeBSD.org> <4A26A239.5050608@commit.it> Message-ID: <20090603200459.GG28486@lor.one-eyed-alien.net> On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote: > Doug Barton wrote: >> If you use a value of network_interfaces other than AUTO please speak >> up so that we can make an intelligent decision about this issue. > > Maybe I am wrong, setting network_interfaces is the way I found I had to > use to be able to rename cloned interfaces. > > eg: > > network_interfaces="lo0 em0 dmz" > ifconfig_em0="up" > cloned_interfaces="vlan0" > > ifconfig_vlan0_name="dmz" > ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" > > I seem to remember I had to put that 'dmz' in network_interfaces, to make > everything happy at boot. I can do more tests if needed. Hmm, there might be a bug related to cloned interfaces and renaming. That should be easy to fix. -- Brooks -------------- 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/20090603/bf0204c3/attachment.pgp From marius at alchemy.franken.de Wed Jun 3 20:05:48 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Jun 3 20:06:07 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: <20090603194453.GA43137@alchemy.franken.de> On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > Wed, Jun 03, 2009 at 09:25:38AM +0400, Eygene Ryabinkin wrote: > > Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c > > > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > > > *** Error code 1 > > > > > > Stop in /obj/sun4v/src/sys/LINT. > > > > This seems to be related to the recent NETISR changes, namely, the > > addition of the pc_netisr member to the struct pcpu: > > http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u > > > > I am not sure how large (void *) is on sun4v, but it seems to me > > that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > > > should be compensated for this change. Something like > > ----- > > #ifdef KTR > > #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) > > #else > > #define PCPU_MD_FIELDS_PAD 3 > > #endif > > ----- > > though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > Just now we won't be able to reach this with the current definition > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > become negative and that's bad. If it actually becomes negative the build should break again, which IMO is sufficient protection. > > The attached patch should fix this (although I have no sun4v to test > on, so take it with a grain of salt). I think this is overengineered, especially if not also adjusting the padding for other macros which may change the size of both MD and MI parts of struct pcpu. > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > missing something? > It's just not taken into account but AFAICT also dead code. Marius From rwatson at FreeBSD.org Wed Jun 3 20:06:08 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 3 20:06:27 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: On Wed, 3 Jun 2009, Eygene Ryabinkin wrote: >> This seems to be related to the recent NETISR changes, namely, the >> addition of the pc_netisr member to the struct pcpu: >> http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u >> >> I am not sure how large (void *) is on sun4v, but it seems to me >> that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > >> should be compensated for this change. Something like >> ----- >> #ifdef KTR >> #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) >> #else >> #define PCPU_MD_FIELDS_PAD 3 >> #endif >> ----- >> though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just > now we won't be able to reach this with the current definition for > PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative > and that's bad. > > The attached patch should fix this (although I have no sun4v to test on, so > take it with a grain of salt). > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts of > 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never > compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU > constant for sun4v (inexisting or defined everytime) or I am missing > something? Is there a reason not just to use __aligned(64) or the like on the first entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes from causing similar discomfort for the MD pcpu parts? Also, do we know why these alignment/sizing requirements exist for struct pcpu on sun4v but not other platforms? If this is about packing pcpu structures into properly aligned cache lines, again __aligned() might be the right approach to take... Robert N M Watson Computer Laboratory University of Cambridge From marck at rinet.ru Wed Jun 3 20:19:38 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Jun 3 20:19:45 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A255F8E.70604@FreeBSD.org> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> Message-ID: On Tue, 2 Jun 2009, Doug Barton wrote: DB> Alexander Leidinger wrote: DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? DB> DB> Sounds great, I look forward to reviewing your patch. :) What do you think about attached one? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ -------------- next part -------------- Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.357 diff -u -r1.357 rc.conf --- etc/defaults/rc.conf 2 Jun 2009 22:15:47 -0000 1.357 +++ etc/defaults/rc.conf 3 Jun 2009 20:18:15 -0000 @@ -83,6 +83,7 @@ root_rw_mount="YES" # Set to NO to inhibit remounting root read-write. fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails. +fsck_y_flags="" # Additional flags for fsck -y background_fsck="YES" # Attempt to run fsck in the background where possible. background_fsck_delay="60" # Time to wait (seconds) before starting the fsck. netfs_types="nfs:NFS nfs4:NFS4 smbfs:SMB portalfs:PORTAL nwfs:NWFS" # Net filesystems. Index: etc/rc.d/fsck =================================================================== RCS file: /home/ncvs/src/etc/rc.d/fsck,v retrieving revision 1.13 diff -u -r1.13 fsck --- etc/rc.d/fsck 23 Jun 2008 04:46:54 -0000 1.13 +++ etc/rc.d/fsck 3 Jun 2009 20:18:15 -0000 @@ -44,8 +44,8 @@ ;; 8) if checkyesno fsck_y_enable; then - echo "File system preen failed, trying fsck -y." - fsck -y + echo "File system preen failed, trying fsck -y ${fsck_y_flags}" + fsck -y ${fsck_y_flags} case $? in 0) ;; Index: sbin/fsck_msdosfs/main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_msdosfs/main.c,v retrieving revision 1.15 diff -u -r1.15 main.c --- sbin/fsck_msdosfs/main.c 10 Feb 2005 09:39:51 -0000 1.15 +++ sbin/fsck_msdosfs/main.c 3 Jun 2009 20:18:15 -0000 @@ -74,8 +74,10 @@ int ch; skipclean = 1; - while ((ch = getopt(argc, argv, "fFnpy")) != -1) { + while ((ch = getopt(argc, argv, "CfFnpy")) != -1) { switch (ch) { + case 'C': /* for fsck_ffs compatibility */ + break; case 'f': skipclean = 0; break; Index: sbin/fsck_msdosfs/fsck_msdosfs.8 =================================================================== RCS file: /home/ncvs/src/sbin/fsck_msdosfs/fsck_msdosfs.8,v retrieving revision 1.15 diff -u -r1.15 fsck_msdosfs.8 --- sbin/fsck_msdosfs/fsck_msdosfs.8 10 Feb 2005 09:39:51 -0000 1.15 +++ sbin/fsck_msdosfs/fsck_msdosfs.8 3 Jun 2009 20:18:15 -0000 @@ -32,7 +32,7 @@ .\" .\" $FreeBSD: src/sbin/fsck_msdosfs/fsck_msdosfs.8,v 1.15 2005/02/10 09:39:51 ru Exp $ .\" -.Dd August 13, 1995 +.Dd June 4, 2009 .Dt FSCK_MSDOSFS 8 .Os .Sh NAME @@ -41,10 +41,10 @@ .Sh SYNOPSIS .Nm .Fl p -.Op Fl f +.Op Fl Cf .Ar filesystem ... .Nm -.Op Fl ny +.Op Fl Cny .Ar filesystem ... .Sh DESCRIPTION The @@ -80,6 +80,10 @@ .Pp The options are as follows: .Bl -tag -width indent +.It Fl C +Compatibility with the corresponding +.Xr fsck 8 +option (skip check if clean), defined to no-op. .It Fl F Compatibility with the wrapper .Xr fsck 8 From freebsd-lists-erik at erikosterholm.org Wed Jun 3 20:37:37 2009 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Wed Jun 3 20:37:50 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090603141321.GC28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> <20090603141321.GC28486@lor.one-eyed-alien.net> Message-ID: <20090603203736.GA23840@barragry.com> On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > > Up till Sunday in 8-current, and for a long time in general > > > network.subr (part of the rc.d system) has emitted a warning > > > that values of network_interfaces other than AUTO are > > > deprecated. I removed that warning in HEAD Sunday, and there is > > > no a discussion about whether or not it should be put back, and > > > whether or not there is any need for the user to specify the > > > list of network interfaces at all. > > > > > > If you use a value of network_interfaces other than AUTO please > > > speak up so that we can make an intelligent decision about this > > > issue. > > > > > > Thanks, > > > > > > Doug > > > > I'll have to preface this by disclosing that I have not been > > running -current, nor following any changes to the RC system. > > > > In 7.1, if you compile a custom kernel and comment out an > > interface (such that it is compiled as a module), one way to > > ensure that the module is loaded is to explicitly list it in > > network_interfaces. If -current works the same way, then users > > will be required to modify /boot/loader.conf in order to load the > > module. Could there could be possible side-effects to this > > change, since the loading of the module happens at a different > > time? > > Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik From xcllnt at mac.com Wed Jun 3 23:14:40 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jun 3 23:14:47 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Message-ID: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > Is there a reason not just to use __aligned(64) or the like on the > first entry of the MD PCPU structure for sun4v to avoid future MI > pcpu changes from causing similar discomfort for the MD pcpu parts? > Also, do we know why these alignment/sizing requirements exist for > struct pcpu on sun4v but not other platforms? If this is about > packing pcpu structures into properly aligned cache lines, again > __aligned() might be the right approach to take... Adding __aligned(xx) doesn't make it aligned. For example, malloc(3) only aligns at 16-byte boundaries, so any user-space structure that has __aligned(x>16) must manually make sure that this is actually the case by over-allocating and then adjusting the pointer to an x>16 aligned address. Likewise for the kernel, though it's easier in the kernel to get something that's page-aligned... FYI, -- Marcel Moolenaar xcllnt@mac.com From rwatson at FreeBSD.org Wed Jun 3 23:35:38 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 3 23:35:49 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> Message-ID: On Wed, 3 Jun 2009, Marcel Moolenaar wrote: >> Is there a reason not just to use __aligned(64) or the like on the first >> entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes >> from causing similar discomfort for the MD pcpu parts? Also, do we know >> why these alignment/sizing requirements exist for struct pcpu on sun4v but >> not other platforms? If this is about packing pcpu structures into >> properly aligned cache lines, again __aligned() might be the right approach >> to take... > > Adding __aligned(xx) doesn't make it aligned. For example, malloc(3) only > aligns at 16-byte boundaries, so any user-space structure that has > __aligned(x>16) must manually make sure that this is actually the case by > over-allocating and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel to get something > that's page-aligned... FYI, I wan't sure if that was the problem that caused the alignment code in this case. However, I agree that malloc(9)'s lack of alignment support is a problem, and one that should be pretty easy to resolve by simply putting a bit of over-allocation code in malloc(9), and adding a malloc_aligned(9) variation, or perhaps just an M_CACHEALIGN flag. Robert N M Watson Computer Laboratory University of Cambridge From amdmi3 at amdmi3.ru Wed Jun 3 23:52:36 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed Jun 3 23:52:44 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> References: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: <20090603235227.GB15659@hades.panopticon> * O. Hartmann (ohartman@zedat.fu-berlin.de) wrote: Just my 2 cents: the same behaviour, and while mount -o tcp succeeds, umounting behaves strangely: if I umount nfs filesystem, umount process hangs for some time, then exits with `umount: hive: RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually umounted immediately after umount is called. This all also breaks amd severely (however it already haven't been working on current for a long time for me). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From ler at lerctr.org Thu Jun 4 00:24:20 2009 From: ler at lerctr.org (Larry Rosenman) Date: Thu Jun 4 00:24:27 2009 Subject: ZFS / arc_max Message-ID: After Peter Wemm's post yesterday that he fixed some of the SVN->CVS breakage, I pulled a new csup of -CURRENT today. I recompiled everything, and installed it. It appears that something(tm) changed with regards to the vfs.zfs.arc_max tuneable, and this number looks more reasonable than "all of memory": vfs.zfs.arc_max: 4484431872 This is with 16G real in the box. I've removed my setting of this to 8G (as it seems to be ignored anyway). We'll see how the next few days goes. (BTW, on the older kernel, setting vfs.zfs.arc_max to 8G allowed the machine to stay up and do full backups, etc). Please let me know of anything else you need. -- 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 amdmi3 at amdmi3.ru Thu Jun 4 01:07:26 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Thu Jun 4 01:07:41 2009 Subject: libarchive extattr i386/amd64 syscall issue Message-ID: <20090604010719.GC15659@hades.panopticon> Hi! The problem: on recent current, 32bit bsdtar won't write archives when running under 64bit kernel, dying with exit code 140 and `Bad system call' message. I've ran into that using i386 tinderbox jail on amd64 host. The problem actually happens in libarchive: --- lib/libarchive/archive_read_disk_entry_from_file.c --- 484 if (!a->follow_symlinks) 485 list_size = extattr_list_link(path, namespace, NULL, 0); // <-- HERE 486 else 487 list_size = extattr_list_file(path, namespace, NULL, 0); --- lib/libarchive/archive_read_disk_entry_from_file.c --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From amdmi3 at amdmi3.ru Thu Jun 4 02:06:29 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Thu Jun 4 02:06:36 2009 Subject: libarchive extattr i386/amd64 syscall issue In-Reply-To: <20090604010719.GC15659@hades.panopticon> References: <20090604010719.GC15659@hades.panopticon> Message-ID: <20090604020622.GA19897@hades.panopticon> * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: For ones experiencing the same problem, this patch worked for me. It disables extattr support in libarchive, but tar now works. --- libarchive.patch begins here --- --- src/lib/libarchive/config_freebsd.h.orig 2009-06-04 05:03:22.000000000 +0400 +++ src/lib/libarchive/config_freebsd.h 2009-06-04 05:03:41.000000000 +0400 @@ -34,8 +34,8 @@ #define HAVE_ACL_SET_FD_NP 1 #define HAVE_ACL_SET_FILE 1 #define HAVE_ACL_USER 1 -#define HAVE_EXTATTR_GET_FILE 1 -#define HAVE_EXTATTR_LIST_FILE 1 +#define HAVE_EXTATTR_GET_FILE 0 +#define HAVE_EXTATTR_LIST_FILE 0 #define HAVE_EXTATTR_SET_FD 1 #define HAVE_EXTATTR_SET_FILE 1 #define HAVE_SYS_ACL_H 1 --- libarchive.patch ends here --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From rea-fbsd at codelabs.ru Thu Jun 4 03:26:23 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jun 4 03:26:29 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <20090603194453.GA43137@alchemy.franken.de> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> Message-ID: Marius, good day. First, thanks for committing the fix. Wed, Jun 03, 2009 at 09:44:53PM +0200, Marius Strobl wrote: > On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > > Just now we won't be able to reach this with the current definition > > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > > become negative and that's bad. > > If it actually becomes negative the build should break again, > which IMO is sufficient protection. Yes, "protection" is here. But it will break the build again and that's a bit uncomfortable. > > The attached patch should fix this (although I have no sun4v to test > > on, so take it with a grain of salt). > > I think this is overengineered, especially if not also > adjusting the padding for other macros which may change the > size of both MD and MI parts of struct pcpu. Hmm, don't fully understand about "other macros". Could you, please, provide an example? > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > missing something? > > It's just not taken into account but AFAICT also dead code. Yes, seems like so. John, may be we can eliminate the only reference to KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be unused (grep'ped -CURRENT sources). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From morganw at chemikals.org Thu Jun 4 04:08:06 2009 From: morganw at chemikals.org (Wes Morgan) Date: Thu Jun 4 04:08:13 2009 Subject: Panic in kern_jail prison_priv_check() Message-ID: I'm getting a reproducible panic trying to access an nfs-exported zfs filesystem with a kernel from a few hours ago, as well as one from over the weekend. Filesystem mounts ok, but accessing it causes an immediate panic. Looks like possibly a problem between zfs and the new jail code. Neither of the zfs functions involved have been changed in a way that would appear to affect this, though. Could be wrong! It may not be pertinent but I do have vfs.usermount enabled. The value for "priv" in prison_priv_check() is 334, PRIV_VFS_MOUNT_OWNER. The contents of the "credentials" is: $6 = {cr_ref = 1, cr_uid = 4294967294, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 1, cr_groups = {4294967294, 0, 2, 3, 4, 5, 6, 20, 25, 26, 31, 0, 0, 0, 0, 0}, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_vimage = 0x0, cr_flags = 0, cr_pspare = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 0, ai_mask = {am_success = 0, am_failure = 0}, ai_termid = {at_port = 0, at_type = 0, at_addr = {0, 0, 0, 0}}, ai_asid = 0, ai_flags = 0}} Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x6dc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803109e1 stack pointer = 0x28:0xffffff80c58de5a0 frame pointer = 0x28:0xffffff0006248a00 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 = 1186 (nfsd: service) trap number = 12 panic: page fault cpuid = 2 Syncing disks, vnodes remaining...0 All buffers synced. Uptime: 1m23s Physical memory: 8181 MB Dumping 1662 MB:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 (kgdb) #0 doadump () at pcpu.h:223 #1 0x0000000000000000 in ?? () #2 0xffffffff803335fd in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:420 #3 0xffffffff803338ed in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #4 0xffffffff804fdd68 in trap_fatal (frame=0xffffff80c58de4f0, eva=1756) at /usr/src/sys/amd64/amd64/trap.c:852 #5 0xffffffff804fdfcf in trap_pfault (frame=0xffffff80c58de4f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #6 0xffffffff804fe917 in trap (frame=0xffffff80c58de4f0) at /usr/src/sys/amd64/amd64/trap.c:494 #7 0xffffffff804da7e3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff803109e1 in prison_priv_check (cred=0xffffff0006248a00, priv=334) at /usr/src/sys/kern/kern_jail.c:3315 #9 0xffffffff80329380 in priv_check_cred (cred=0xffffff0006248a00, priv=334, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_priv.c:93 #10 0xffffffff808bf92e in secpolicy_vnode_access (cred=0xffffff0006248a00, vp=0xffffff0006a1d760, owner=Variable "owner" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:125 #11 0xffffffff809207f7 in zfs_zaccess (zp=0xffffff0006a1e758, mode=Variable "mode" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2435 #12 0xffffffff8093244e in zfs_freebsd_access (ap=Variable "ap" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1067 #13 0xffffffff805203d2 in VOP_ACCESS_APV (vop=Variable "vop" is not available. ) at vnode_if.c:571 #14 0xffffffff804495c2 in nfsrv_access (vp=0xffffff0006a1d760, accmode=128, cred=0xffffff0006248a00, rdonly=Variable "rdonly" is not available. ) at vnode_if.h:254 #15 0xffffffff80449c86 in nfsrv3_access (nfsd=0xffffff80c58dea10, slp=Variable "slp" is not available. ) at /usr/src/sys/nfsserver/nfs_serv.c:238 #16 0xffffffff8045618b in nfssvc_program (rqst=0xffffff000a366000, xprt=Variable "xprt" is not available. ) at /usr/src/sys/nfsserver/nfs_srvkrpc.c:410 #17 0xffffffff8047292a in svc_run_internal (pool=0xffffff00060eda00, ismaster=0) at /usr/src/sys/rpc/svc.c:883 #18 0xffffffff80472a9d in svc_thread_start (arg=Variable "arg" is not available. ) at /usr/src/sys/rpc/svc.c:1188 #19 0xffffffff8030d347 in fork_exit ( callout=0xffffffff80472a8f , arg=0xffffff00060eda00, frame=0xffffff80c58dec90) at /usr/src/sys/kern/kern_fork.c:829 #20 0xffffffff804dabee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 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-CURRENT #6: Wed Jun 3 19:46:36 CDT 2009 root@volatile:/usr/obj/usr/src/sys/VOLATILE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.68-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8287219712 (7903 MB) ACPI APIC Table: <090308 APIC1358> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard cryptosoft0: on motherboard acpi0: <090308 XSDT1358> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci7: on pcib1 mpt0: port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff,0xfbfe0000-0xfbfeffff irq 16 at device 0.0 on pci7 mpt0: [ITHREAD] mpt0: MPI Version=1.5.19.0 pcib2: irq 16 at device 28.0 on pci0 pci4: on pcib2 pcib3: at device 0.0 on pci4 pci6: on pcib3 mpt1: port 0xd800-0xd8ff mem 0xfbbfc000-0xfbbfffff,0xfbbe0000-0xfbbeffff irq 18 at device 6.0 on pci6 mpt1: [ITHREAD] mpt1: MPI Version=1.5.16.0 mpt1: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt1: 0 Active Volumes (2 Max) mpt1: 0 Hidden Drive Members (14 Max) Ambiguous scbus configuration for mpt1 bus 1, cannot wire down. The kernel config entry for scbus1 should specify a controller bus. Scbus will be assigned dynamically. pcib4: mem 0xfb7ffc00-0xfb7ffc7f irq 16 at device 0.1 on pci4 pci5: on pcib4 pcib5: irq 16 at device 28.4 on pci0 pci3: on pcib5 bge0: mem 0xfb6f0000-0xfb6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:22:15:56:bb:1e bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci2: on pcib6 bge1: mem 0xfb5f0000-0xfb5fffff irq 17 at device 0.0 on pci2 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:22:15:56:ba:24 bge1: [ITHREAD] uhci0: port 0xac00-0xac1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f00 usbus0: on uhci0 uhci1: port 0xb000-0xb01f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f00 usbus1: on uhci1 uhci2: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f00 usbus2: on uhci2 ehci0: mem 0xfb3ff800-0xfb3ffbff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci1: on pcib7 vgapci0: port 0xcc00-0xcc7f mem 0xf8000000-0xf9ffffff,0xfb4c0000-0xfb4fffff at device 3.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xfb3ffc00-0xfb3fffff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI v1.10 controller with 4 3Gbps ports, PM not supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 91, should be 90 [20070320] coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 152627MB at ata0-master UDMA100 ZFS filesystem version 13 ZFS storage pool version 13 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 acd0: DVDR at ata2-master SATA150 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing Enabled da1: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da2 at mpt0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing Enabled da2: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da3 at mpt0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing Enabled da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da4 at mpt0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing Enabled da4: 286188MB (586114704 512 byte sectors: 255H 63S/T 36483C) da6 at mpt0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing Enabled da6: 286188MB (586114704 512 byte sectors: 255H 63S/T 36483C) da7 at mpt0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device da7: 300.000MB/s transfers da7: Command Queueing Enabled da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da8 at mpt1 bus 0 target 0 lun 0 da8: Fixed Direct Access SCSI-5 device da8: 300.000MB/s transfers da8: Command Queueing Enabled da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da9 at mpt1 bus 0 target 1 lun 0 da9: Fixed Direct Access SCSI-5 device da9: 300.000MB/s transfers da9: Command Queueing Enabled da9: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da10 at mpt1 bus 0 target 2 lun 0 da10: Fixed Direct Access SCSI-5 device da10: 300.000MB/s transfers da10: Command Queueing Enabled da10: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da11 at mpt1 bus 0 target 3 lun 0 da11: Fixed Direct Access SCSI-5 device da11: 300.000MB/s transfers da11: Command Queueing Enabled da11: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da12 at mpt1 bus 0 target 4 lun 0 da12: Fixed Direct Access SCSI-5 device da12: 300.000MB/s transfers da12: Command Queueing Enabled da12: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da13 at mpt1 bus 0 target 5 lun 0 da13: Fixed Direct Access SCSI-5 device da13: 300.000MB/s transfers da13: Command Queueing Enabled da13: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da14 at mpt1 bus 0 target 6 lun 0 da14: Fixed Direct Access SCSI-5 device da14: 300.000MB/s transfers da14: Command Queueing Enabled da14: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da15 at mpt1 bus 0 target 7 lun 0 da15: Fixed Direct Access SCSI-5 device da15: 300.000MB/s transfers da15: Command Queueing Enabled da15: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! uhub3: 6 ports with 6 removable, self powered ugen0.2: at usbus0 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM: da7: partition 1 does not start on a track boundary. GEOM: da7: partition 1 does not end on a track boundary. Trying to mount root from zfs:root Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x6dc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803109e1 stack pointer = 0x28:0xffffff80c58de5a0 frame pointer = 0x28:0xffffff0006248a00 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 = 1186 (nfsd: service) trap number = 12 panic: page fault cpuid = 2 Syncing disks, vnodes remaining...0 All buffers synced. Uptime: 1m23s Physical memory: 8181 MB Dumping 1662 MB:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 From kientzle at freebsd.org Thu Jun 4 04:43:39 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu Jun 4 04:43:46 2009 Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) In-Reply-To: <20090604010719.GC15659@hades.panopticon> References: <20090604010719.GC15659@hades.panopticon> Message-ID: <4A2750F0.3070106@freebsd.org> Dmitry Marakasov wrote: > > The problem: on recent current, 32bit bsdtar won't write archives when > running under 64bit kernel, dying with exit code 140 and `Bad system call' > message. I've ran into that using i386 tinderbox jail on amd64 host. > The problem actually happens in libarchive: > > --- lib/libarchive/archive_read_disk_entry_from_file.c --- > 484 if (!a->follow_symlinks) > 485 list_size = extattr_list_link(path, namespace, NULL, 0); // <-- HERE > 486 else > 487 list_size = extattr_list_file(path, namespace, NULL, 0); > --- lib/libarchive/archive_read_disk_entry_from_file.c --- Yes, it looks like only about half of the extattr calls are actually connected in the freebsd32 compatibility layer. (see below) According to SVN history, peter@ reserved these slots back in December 2003 but no one ever went back and connected them up. I don't know if there was a reason for not connecting them or if simply no one remembered to do so. I would guess the latter; the ones that are connected were all implemented before mid-2002. I don't see any obvious reason these should not just work. If you're feeling adventurous, you could try copying the data from /usr/src/kern/syscalls.master and see what happens. I don't have a 64-bit system handy here or I would try this myself. You can test by going to /usr/src/lib/libarchive/test and running "make check". That will build and run the libarchive test suite, which does exercise the extended attribute support. (Of course, you should revert your change first so that the extended attribute support is actually compiled.) Let me know if you find anything, Tim $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int cmd, \ 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link From bruce at cran.org.uk Thu Jun 4 07:07:09 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Jun 4 07:07:15 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 4 In-Reply-To: <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> Message-ID: <20090604080706.56fbd83c@tau.draftnet> On Wed, 27 May 2009 17:09:30 +0100 "M. Vale" wrote: > Hi, maybe i've come a bit latter and miss something, but I'm trying > to build virtual box in FreeBSD 7.1p5 (64bits) and whem making > kbuild it stops with this error: > [...] > > /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: > *** target file `virtualbox' has both : and :: entries. > Stop . > kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' > gmake: *** > [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build] > Error 2 > ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk > *** Error code 2 > > Stop in /usr/ports/devel/kBuild. > " I'm running 8-CURRENT from about a week ago and I see a different failure when building devel/kBuild - but only when run from portmaster; it succeeds when I run "make" in /usr/ports/devel/kBuild Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/utils.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/strverscmp.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/obstack.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/getline.c kmk: *** No rule to make target `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild-0.1.5.p1/out/freebsd.amd64/release/obj/kUtil/kUtil.a', needed by `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild-0.1.5.p1/out/freebsd.amd64/release/obj/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kmk/kmk'. Stop. kmk: *** Waiting for unfinished jobs.... kmk: Leaving directory `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' kmk: Entering directory `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' kmk: *** Exiting with status 2 gmake: *** [/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build] Error 2 ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk *** Error code 2 Stop in /usr/ports/devel/kBuild. -- Bruce Cran From randy at psg.com Thu Jun 4 07:26:10 2009 From: randy at psg.com (Randy Bush) Date: Thu Jun 4 07:26:16 2009 Subject: yakpf In-Reply-To: References: Message-ID: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff8047c1da > stack pointer = 0x28:0xffffff807a156630 > frame pointer = 0x28:0xffffff807a1566f0 > 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 = 1385 (nfcapd) > trap number = 12 > panic: page fault > cpuid = 0 i have not seen this again since a recent svn and total rebuild. this message is an attempt to provoke the $dieties into causing it. randy From dfr at rabson.org Thu Jun 4 07:35:02 2009 From: dfr at rabson.org (Doug Rabson) Date: Thu Jun 4 07:35:14 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603184215.L12292@maildrop.int.zabbadoz.net> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> Message-ID: <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> On 3 Jun 2009, at 20:42, Bjoern A. Zeeb wrote: > On Wed, 3 Jun 2009, Wesley Shields wrote: > > Hi, > >>>>> ... > >> [ The panic message and backtrace from ddb is at >> http://people.freebsd.org/~wxs/crash.txt ] >> > ... >> cred->cr_prison is null? It is my understanding that when not jailed >> cred->cr_prison should be &prison0 with the new hierarchical jails. >> The >> fact that it is null is causing prison_priv_check to enter the switch >> statement, leading to the crash. >> >> I'm not sure why cred->cr_prison is null in this case. > > The question here is not if cred->cr_prison can be null but where is > the cred coming from? > > If you look at init_main.c around lines 440 - 457 you'll find prison0 > being further initialized (cpuset) and p_ucred->cr_prison being set to > &prsion0. And a bit further down in l470 td_ucred is initialized from > that. cr_prison should thus always be setup. > > What you are looking at above looks like a crget() with only > cr_ngroups updated. > > [removing a lot more text as I was going on debugging in a very small > window] > > I would start looking at svc_getcred() and blame at least the > AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. > I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. The NFS server is creating a ucred which describes the privileges to be given to the remote user. What is the correct way to do this and where can I read the documentation? From ed at 80386.nl Thu Jun 4 09:38:33 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jun 4 09:38:39 2009 Subject: Clang: now available from a SVN server near you! Message-ID: <20090604093831.GE48776@hoeg.nl> Good news everyone! As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch into SVN. Tuesday I finally had some time to do it, so here's the result: http://svn.freebsd.org/viewvc/base/projects/clangbsd/ You can now build your very own version of FreeBSD with Clang installed as /usr/bin/cc as follows: - Check out the clangbsd branch from our SVN repository: svn co svn://svn.freebsd.org/base/projects/clangbsd - Put this in /etc/src.conf: WITH_CLANG= WITH_CLANG_IS_CC= NO_WERROR= WERROR= - Just run `make buildworld' and `make installworld'. You probably don't want to install it on top of your running system. I strongly advise you to create a separate jail to do all your testing with. When using a jail, you probably want to add NO_FSCHG= to /etc/src.conf as well to keep `make installworld' happy. So far we've only done testing on amd64 and i386. A lot of ports are probably still broken. Caveat emptor. Beware of dog. Slippery when wet. -- 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/20090604/d457b4b6/attachment.pgp From rwatson at FreeBSD.org Thu Jun 4 10:28:34 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jun 4 10:28:40 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> Message-ID: On Thu, 4 Jun 2009, Doug Rabson wrote: >> I would start looking at svc_getcred() and blame at least the AUTH_UNIX >> case; end of rpc/svc_auth.c. This looks like a big NO-NO. I am pretty >> sure I'd also want to audit svc_rpc_gss(), just in case. > > The NFS server is creating a ucred which describes the privileges to be > given to the remote user. What is the correct way to do this and where can I > read the documentation? In practice, all credentials in the system are (often quite indirectly) derived from one of two root credentials, those belong to swapper and init. Typical practice, on initializing a kernel service, is to take an additional reference on the credential that configured the service and derive future credentials from it. I think this is what the old NFS code did, presumably either directly borrowing a proc 0 credential, or from the syscall turning on the NFS server. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Thu Jun 4 10:51:37 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jun 4 10:51:44 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> Message-ID: On Thu, 4 Jun 2009, Robert Watson wrote: >> The NFS server is creating a ucred which describes the privileges to be >> given to the remote user. What is the correct way to do this and where can >> I read the documentation? > > In practice, all credentials in the system are (often quite indirectly) > derived from one of two root credentials, those belong to swapper and init. > Typical practice, on initializing a kernel service, is to take an additional > reference on the credential that configured the service and derive future > credentials from it. I think this is what the old NFS code did, presumably > either directly borrowing a proc 0 credential, or from the syscall turning > on the NFS server. Thinking more formally about this, I guess the question is whether or not the NFS server should really be a "third" credential root. If so, we should provide a more formal mechanism for it to be set up so that it carries the proper extended credential state, such as Jail state, MAC state, audit stat, etc. Notice that similar code for proc0 and proc1 has explicit hooks for that: 452 /* Create credentials. */ 453 p->p_ucred = crget(); 454 p->p_ucred->cr_ngroups = 1; /* group 0 */ 455 p->p_ucred->cr_uidinfo = uifind(0); 456 p->p_ucred->cr_ruidinfo = uifind(0); 457 p->p_ucred->cr_prison = &prison0; 458 #ifdef VIMAGE 459 KASSERT(LIST_FIRST(&vimage_head) != NULL, ("vimage_head empty")); 460 P_TO_VIMAGE(p) = LIST_FIRST(&vimage_head); /* set ucred->cr_vimage */ 461 refcount_acquire(&P_TO_VIMAGE(p)->vi_ucredrefc); 462 LIST_FIRST(&vprocg_head)->nprocs++; 463 #endif 464 #ifdef AUDIT 465 audit_cred_kproc0(p->p_ucred); 466 #endif 467 #ifdef MAC 468 mac_cred_create_swapper(p->p_ucred); 469 #endif And for proc 1: 742 newcred = crget(); 743 PROC_LOCK(initproc); 744 initproc->p_flag |= P_SYSTEM | P_INMEM; 745 oldcred = initproc->p_ucred; 746 crcopy(newcred, oldcred); 747 #ifdef MAC 748 mac_cred_create_init(newcred); 749 #endif 750 #ifdef AUDIT 751 audit_cred_proc1(newcred); 752 #endif 753 initproc->p_ucred = newcred; Possibly we should actually add MAC and audit functions along similar lines, and initialize cr_prison to &prison0 for the NFS creds? On the other hand, if they may be used for network I/O, perhaps cr_prison and the others should be initialized based on the context in which nfsd is started, so that it takes on those security attributes. Robert N M Watson Computer Laboratory University of Cambridge From daryl at isletech.net Thu Jun 4 08:28:59 2009 From: daryl at isletech.net (Daryl Richards) Date: Thu Jun 4 11:14:01 2009 Subject: AOE on FreeBSD? In-Reply-To: References: <1009314136.20090531173617@serebryakov.spb.ru> Message-ID: I would be interested in this. On 31-May-09, at 1:22 PM, Stacey Son wrote: > Hi, > > I did some work on the AoE initiator years ago. I also created a > patch for one of the user level targets (see http://people.freebsd.org/~sson/aoe/vblade-freebsd.patch) > . If there is enough interest I could dust off this code and get > in ready to commit. I would estimate about two weeks given what I > have on my plate currently and what I believe needs to be rewritten > in the initiator. Is there a good amount of interest for this? > > Best Regards, > > -stacey. > > > On May 31, 2009, at 8:36 AM, Lev Serebryakov wrote: > >> Hello, Current. >> >> Information about AOE (ATA Over Ethernet) on FreeBSD >> (http://support.coraid.com/support/freebsd/) is outdated. >> Any news? Maybe, native (not third-party) client & target in >> pipeline? >> >> -- >> // Black Lion AKA Lev Serebryakov >> >> _______________________________________________ >> 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 >> " > > > _______________________________________________ > 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 tinderbox at freebsd.org Thu Jun 4 11:16:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jun 4 11:16:27 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090604111618.1AB9C7302F@freebsd-current.sentex.ca> TB --- 2009-06-04 09:05:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 09:05:31 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-04 09:05:31 - cleaning the object tree TB --- 2009-06-04 09:06:11 - cvsupping the source tree TB --- 2009-06-04 09:06:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-04 09:06:18 - building world TB --- 2009-06-04 09:06:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 09:06:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 09:06:18 - TARGET=ia64 TB --- 2009-06-04 09:06:18 - TARGET_ARCH=ia64 TB --- 2009-06-04 09:06:18 - TZ=UTC TB --- 2009-06-04 09:06:18 - __MAKE_CONF=/dev/null TB --- 2009-06-04 09:06:18 - cd /src TB --- 2009-06-04 09:06:18 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 09:06:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jun 4 10:56:12 UTC 2009 TB --- 2009-06-04 10:56:12 - generating LINT kernel config TB --- 2009-06-04 10:56:12 - cd /src/sys/ia64/conf TB --- 2009-06-04 10:56:12 - /usr/bin/make -B LINT TB --- 2009-06-04 10:56:12 - building LINT kernel TB --- 2009-06-04 10:56:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 10:56:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 10:56:12 - TARGET=ia64 TB --- 2009-06-04 10:56:12 - TARGET_ARCH=ia64 TB --- 2009-06-04 10:56:12 - TZ=UTC TB --- 2009-06-04 10:56:12 - __MAKE_CONF=/dev/null TB --- 2009-06-04 10:56:12 - cd /src TB --- 2009-06-04 10:56:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 10:56:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/nfsserver/nfs_srvsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/nfsserver/nfs_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/nfs/nfs_nfssvc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 11:16:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 11:16:17 - ERROR: failed to build lint kernel TB --- 2009-06-04 11:16:17 - 6418.38 user 459.55 system 7846.24 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From rdivacky at FreeBSD.org Thu Jun 4 11:34:41 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Thu Jun 4 11:34:48 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <20090604093831.GE48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> Message-ID: <20090604111801.GA91410@freebsd.org> On Thu, Jun 04, 2009 at 11:38:31AM +0200, Ed Schouten wrote: > Good news everyone! > > As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch > into SVN. Tuesday I finally had some time to do it, so here's the > result: > > http://svn.freebsd.org/viewvc/base/projects/clangbsd/ > > You can now build your very own version of FreeBSD with Clang installed > as /usr/bin/cc as follows: > > - Check out the clangbsd branch from our SVN repository: > svn co svn://svn.freebsd.org/base/projects/clangbsd > > - Put this in /etc/src.conf: > WITH_CLANG= > WITH_CLANG_IS_CC= > NO_WERROR= > WERROR= > > - Just run `make buildworld' and `make installworld'. it should be able to compile a bootable kernel on amd64/i386 as well.. so feel free to test that too :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090604/dbfd7301/attachment.pgp From marck at rinet.ru Thu Jun 4 12:14:05 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Jun 4 12:14:13 2009 Subject: fsck_y_enable: use -C In-Reply-To: <4A27B51B.8090504@gmail.com> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> <4A27B51B.8090504@gmail.com> Message-ID: On Thu, 4 Jun 2009, Andrew D. Boyd wrote: ADB> If you have a look at -F flag case in fsck_msdosfs/main.c it does not ADB> display -F in usage() nor in the man page. Well, man page *do* have a reference to -F option, though not in synopsis. I'm not sure was it intentional or not. ADB> ADB> Perhaps following that might be the way to go? ADB> ADB> Dmitry Morozovsky wrote: ADB> > On Tue, 2 Jun 2009, Doug Barton wrote: ADB> > ADB> > DB> Alexander Leidinger wrote: ADB> > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? ADB> > DB> ADB> > DB> Sounds great, I look forward to reviewing your patch. :) ADB> > ADB> > What do you think about attached one? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From jhb at freebsd.org Thu Jun 4 12:22:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 4 12:22:38 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> Message-ID: <200906040802.27057.jhb@freebsd.org> On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > > missing something? > > > > It's just not taken into account but AFAICT also dead code. > > Yes, seems like so. John, may be we can eliminate the only reference to > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > unused (grep'ped -CURRENT sources). Yes. -- John Baldwin From jhb at freebsd.org Thu Jun 4 12:22:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 4 12:22:38 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> Message-ID: <200906040802.27057.jhb@freebsd.org> On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > > missing something? > > > > It's just not taken into account but AFAICT also dead code. > > Yes, seems like so. John, may be we can eliminate the only reference to > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > unused (grep'ped -CURRENT sources). Yes. -- John Baldwin From jhb at freebsd.org Thu Jun 4 12:22:23 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 4 12:22:59 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> Message-ID: <200906040816.51244.jhb@freebsd.org> On Wednesday 03 June 2009 7:14:38 pm Marcel Moolenaar wrote: > > On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > > > Is there a reason not just to use __aligned(64) or the like on the > > first entry of the MD PCPU structure for sun4v to avoid future MI > > pcpu changes from causing similar discomfort for the MD pcpu parts? > > Also, do we know why these alignment/sizing requirements exist for > > struct pcpu on sun4v but not other platforms? If this is about > > packing pcpu structures into properly aligned cache lines, again > > __aligned() might be the right approach to take... > > Adding __aligned(xx) doesn't make it aligned. For example, > malloc(3) only aligns at 16-byte boundaries, so any > user-space structure that has __aligned(x>16) must manually > make sure that this is actually the case by over-allocating > and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel > to get something that's page-aligned... > FYI, Yes, but struct pcpu is a bit special I think. The MD code is responsible for allocating it (and in at least some cases it just allocates a complete page). As long as sun4v allocates struct pcpu on a 64 byte boundary, simply throwing __aligned() in will fix it. Also, since the existing code is just computing explicit padding space, it is already assuming the alignment of struct pcpu. It is simply implementing __aligned() in a harder-to-maintain way. It also doesn't make any sense the way it is doing it now since it is simply adding padding to the end of the structure. Perhaps it is attempting to round up the size of the entire structure? If so, that can easily be fixed in the MD code that allocates the structures by doing 'roundup(sizeof(struct pcpu), N)' when allocating the structure. The comments in pcpu.h seem to imply that it wants a section of the fields in the middle to be aligned to a certain boundary in which case I think the proper solution is to stick an __aligned() on the first such member and then to allocate the structures on a suitable alignment when allocating PCPU structures in the MD code. Presumably it would need the special work when allocating these structures even with the current hard-to-maintain padding hack. Again, that hack is no better than __aligned(), just a much bigger pain to maintain AFAICT. -- John Baldwin From jhb at freebsd.org Thu Jun 4 12:22:23 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 4 12:22:59 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> Message-ID: <200906040816.51244.jhb@freebsd.org> On Wednesday 03 June 2009 7:14:38 pm Marcel Moolenaar wrote: > > On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > > > Is there a reason not just to use __aligned(64) or the like on the > > first entry of the MD PCPU structure for sun4v to avoid future MI > > pcpu changes from causing similar discomfort for the MD pcpu parts? > > Also, do we know why these alignment/sizing requirements exist for > > struct pcpu on sun4v but not other platforms? If this is about > > packing pcpu structures into properly aligned cache lines, again > > __aligned() might be the right approach to take... > > Adding __aligned(xx) doesn't make it aligned. For example, > malloc(3) only aligns at 16-byte boundaries, so any > user-space structure that has __aligned(x>16) must manually > make sure that this is actually the case by over-allocating > and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel > to get something that's page-aligned... > FYI, Yes, but struct pcpu is a bit special I think. The MD code is responsible for allocating it (and in at least some cases it just allocates a complete page). As long as sun4v allocates struct pcpu on a 64 byte boundary, simply throwing __aligned() in will fix it. Also, since the existing code is just computing explicit padding space, it is already assuming the alignment of struct pcpu. It is simply implementing __aligned() in a harder-to-maintain way. It also doesn't make any sense the way it is doing it now since it is simply adding padding to the end of the structure. Perhaps it is attempting to round up the size of the entire structure? If so, that can easily be fixed in the MD code that allocates the structures by doing 'roundup(sizeof(struct pcpu), N)' when allocating the structure. The comments in pcpu.h seem to imply that it wants a section of the fields in the middle to be aligned to a certain boundary in which case I think the proper solution is to stick an __aligned() on the first such member and then to allocate the structures on a suitable alignment when allocating PCPU structures in the MD code. Presumably it would need the special work when allocating these structures even with the current hard-to-maintain padding hack. Again, that hack is no better than __aligned(), just a much bigger pain to maintain AFAICT. -- John Baldwin From decado at gmail.com Thu Jun 4 12:23:43 2009 From: decado at gmail.com (Andrew D. Boyd) Date: Thu Jun 4 12:23:50 2009 Subject: fsck_y_enable: use -C In-Reply-To: References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> Message-ID: <4A27B51B.8090504@gmail.com> If you have a look at -F flag case in fsck_msdosfs/main.c it does not display -F in usage() nor in the man page. Perhaps following that might be the way to go? Dmitry Morozovsky wrote: > On Tue, 2 Jun 2009, Doug Barton wrote: > > DB> Alexander Leidinger wrote: > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? > DB> > DB> Sounds great, I look forward to reviewing your patch. :) > > What do you think about attached 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 decado at gmail.com Thu Jun 4 12:35:21 2009 From: decado at gmail.com (Andrew D. Boyd) Date: Thu Jun 4 12:35:27 2009 Subject: fsck_y_enable: use -C In-Reply-To: References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> <4A27B51B.8090504@gmail.com> Message-ID: <4A27BF71.4030807@gmail.com> Ah my mistake. Probably best to go with what your patch. I'm thinking it is intentional so that the man page matches up with the usage. This patch would be helpful for me thanks for your work. Dmitry Morozovsky wrote: > On Thu, 4 Jun 2009, Andrew D. Boyd wrote: > > ADB> If you have a look at -F flag case in fsck_msdosfs/main.c it does not > ADB> display -F in usage() nor in the man page. > > Well, man page *do* have a reference to -F option, though not in synopsis. > I'm not sure was it intentional or not. > > ADB> > ADB> Perhaps following that might be the way to go? > ADB> > ADB> Dmitry Morozovsky wrote: > ADB> > On Tue, 2 Jun 2009, Doug Barton wrote: > ADB> > > ADB> > DB> Alexander Leidinger wrote: > ADB> > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? > ADB> > DB> > ADB> > DB> Sounds great, I look forward to reviewing your patch. :) > ADB> > > ADB> > What do you think about attached one? > From erik at cederstrand.dk Thu Jun 4 12:36:00 2009 From: erik at cederstrand.dk (Erik Cederstrand) Date: Thu Jun 4 12:36:21 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <20090604093831.GE48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> Message-ID: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> Den 04/06/2009 kl. 11.38 skrev Ed Schouten: > You can now build your very own version of FreeBSD with Clang > installed > as /usr/bin/cc as follows: Thanks for your hard work, Ed. This is great news! You might want to mention that a few parts are still GCC-compiled due to bugs in Clang ( see http://wiki.freebsd.org/ BuildingFreeBSDWithClang). Also, it's very encouraging that the ports run you did with Erwin (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005274.html ) compiles over 7000 ports with Clang. I've asked in the Clang list, but I'd like an opinion from FreeBSD folks, too: Clang supports LTO (http://llvm.org/docs/LinkTimeOptimization.html ), which has a potential for performance improvements. It doesn't work on FreeBSD because the linker we have (in binutils) doesn't know about the libLTO that LLVM provides. There's a new linker from GNU called Gold, but as far as I know it's GPLv3 licensed and therefore undesirable at least to have in base. LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html ) but "it doesn't interact correctly with conventional nm/ar/etc" (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html ). There's the ELF toolchain project (elftoolchain.sourceforge.net/) but a BSD-licensed ld hasn't been developed yet. What would be the best way to get LTO to work on FreeBSD? Thanks, Erik From rdivacky at FreeBSD.org Thu Jun 4 12:39:05 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Thu Jun 4 12:39:13 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> Message-ID: <20090604123801.GA34971@freebsd.org> On Thu, Jun 04, 2009 at 02:35:56PM +0200, Erik Cederstrand wrote: > Den 04/06/2009 kl. 11.38 skrev Ed Schouten: > > >You can now build your very own version of FreeBSD with Clang > >installed > >as /usr/bin/cc as follows: > > Thanks for your hard work, Ed. This is great news! > > You might want to mention that a few parts are still GCC-compiled due > to bugs in Clang ( see http://wiki.freebsd.org/ > BuildingFreeBSDWithClang). Also, it's very encouraging that the ports > run you did with Erwin > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005274.html ) > compiles over 7000 ports with Clang. > > I've asked in the Clang list, but I'd like an opinion from FreeBSD > folks, too: Clang supports LTO > (http://llvm.org/docs/LinkTimeOptimization.html ), which has a potential > for performance improvements. It doesn't work on FreeBSD because the > linker we have (in binutils) doesn't know about the libLTO that LLVM > provides. There's a new linker from GNU called Gold, but as far as I know > it's GPLv3 licensed and therefore undesirable at least to have in base. > LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html ) but "it doesn't > interact correctly with conventional nm/ar/etc" > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html ). > There's the ELF toolchain project (elftoolchain.sourceforge.net/) but a > BSD-licensed ld hasn't been developed yet. > > What would be the best way to get LTO to work on FreeBSD? you could use llvm-ld (see the wiki for instructions how to do it). there's also some effort to make gnu ld usable with llvm LTO and I guess the patch could be backported to our ld. I guess From tinderbox at freebsd.org Thu Jun 4 12:57:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jun 4 12:57:41 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090604125719.750EB7302F@freebsd-current.sentex.ca> TB --- 2009-06-04 11:16:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 11:16:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-04 11:16:18 - cleaning the object tree TB --- 2009-06-04 11:16:50 - cvsupping the source tree TB --- 2009-06-04 11:16:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-04 11:16:58 - building world TB --- 2009-06-04 11:16:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 11:16:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 11:16:58 - TARGET=powerpc TB --- 2009-06-04 11:16:58 - TARGET_ARCH=powerpc TB --- 2009-06-04 11:16:58 - TZ=UTC TB --- 2009-06-04 11:16:58 - __MAKE_CONF=/dev/null TB --- 2009-06-04 11:16:58 - cd /src TB --- 2009-06-04 11:16:58 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 11:17:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jun 4 12:42:28 UTC 2009 TB --- 2009-06-04 12:42:28 - generating LINT kernel config TB --- 2009-06-04 12:42:28 - cd /src/sys/powerpc/conf TB --- 2009-06-04 12:42:28 - /usr/bin/make -B LINT TB --- 2009-06-04 12:42:28 - building LINT kernel TB --- 2009-06-04 12:42:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 12:42:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 12:42:28 - TARGET=powerpc TB --- 2009-06-04 12:42:28 - TARGET_ARCH=powerpc TB --- 2009-06-04 12:42:28 - TZ=UTC TB --- 2009-06-04 12:42:28 - __MAKE_CONF=/dev/null TB --- 2009-06-04 12:42:28 - cd /src TB --- 2009-06-04 12:42:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 12:42:29 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_srvsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_nfssvc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 12:57:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 12:57:19 - ERROR: failed to build lint kernel TB --- 2009-06-04 12:57:19 - 4819.95 user 432.15 system 6060.87 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Thu Jun 4 13:17:50 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jun 4 13:18:34 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090604131747.900E17302F@freebsd-current.sentex.ca> TB --- 2009-06-04 11:40:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 11:40:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-04 11:40:30 - cleaning the object tree TB --- 2009-06-04 11:41:00 - cvsupping the source tree TB --- 2009-06-04 11:41:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-04 11:41:07 - building world TB --- 2009-06-04 11:41:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 11:41:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 11:41:07 - TARGET=sparc64 TB --- 2009-06-04 11:41:07 - TARGET_ARCH=sparc64 TB --- 2009-06-04 11:41:07 - TZ=UTC TB --- 2009-06-04 11:41:07 - __MAKE_CONF=/dev/null TB --- 2009-06-04 11:41:07 - cd /src TB --- 2009-06-04 11:41:07 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 11:41:08 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jun 4 13:02:39 UTC 2009 TB --- 2009-06-04 13:02:39 - generating LINT kernel config TB --- 2009-06-04 13:02:39 - cd /src/sys/sparc64/conf TB --- 2009-06-04 13:02:39 - /usr/bin/make -B LINT TB --- 2009-06-04 13:02:39 - building LINT kernel TB --- 2009-06-04 13:02:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 13:02:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 13:02:39 - TARGET=sparc64 TB --- 2009-06-04 13:02:39 - TARGET_ARCH=sparc64 TB --- 2009-06-04 13:02:39 - TZ=UTC TB --- 2009-06-04 13:02:39 - __MAKE_CONF=/dev/null TB --- 2009-06-04 13:02:39 - cd /src TB --- 2009-06-04 13:02:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 13:02:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_srvsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_nfssvc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 13:17:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 13:17:47 - ERROR: failed to build lint kernel TB --- 2009-06-04 13:17:47 - 4601.70 user 428.40 system 5837.15 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From kostikbel at gmail.com Thu Jun 4 13:54:10 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jun 4 13:54:17 2009 Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) In-Reply-To: <4A2750F0.3070106@freebsd.org> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> Message-ID: <20090604135402.GT1927@deviant.kiev.zoral.com.ua> On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > Dmitry Marakasov wrote: > > > >The problem: on recent current, 32bit bsdtar won't write archives when > >running under 64bit kernel, dying with exit code 140 and `Bad system call' > >message. I've ran into that using i386 tinderbox jail on amd64 host. > >The problem actually happens in libarchive: > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > 484 if (!a->follow_symlinks) > > 485 list_size = extattr_list_link(path, > > namespace, NULL, 0); // <-- HERE > > 486 else > > 487 list_size = extattr_list_file(path, > > namespace, NULL, 0); > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > Yes, it looks like only about half of the extattr calls are > actually connected in the freebsd32 compatibility layer. (see below) > According to SVN history, peter@ reserved these slots back > in December 2003 but no one ever went back and connected > them up. I don't know if there was a reason for not > connecting them or if simply no one remembered to do so. > I would guess the latter; the ones that are connected > were all implemented before mid-2002. > > I don't see any obvious reason these should not just > work. If you're feeling adventurous, you could try > copying the data from /usr/src/kern/syscalls.master > and see what happens. I don't have a 64-bit system > handy here or I would try this myself. > > You can test by going to /usr/src/lib/libarchive/test and > running "make check". That will build and run the libarchive > test suite, which does exercise the extended attribute support. > (Of course, you should revert your change first so that the > extended attribute support is actually compiled.) > > Let me know if you find anything, > > Tim > > > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int > cmd, \ > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link The size_t arguments need translation. Please try the patch below. diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/freebsd32_misc.c index 9301b8d..e8526de 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2719,6 +2719,73 @@ freebsd32_nmount(struct thread *td, return error; } +int +freebsd32_extattr_set_link(struct thread *td, + struct freebsd32_extattr_set_link_args *uap) +{ + struct extattr_set_link_args ap; + + ap.path = uap->path; + ap.attrnamespace = uap->attrnamespace; + ap.attrname = uap->attrname; + ap.data = uap->data; + ap.nbytes = uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_set_link(td, &ap)); +} + +int +freebsd32_extattr_get_link(struct thread *td, + struct freebsd32_extattr_get_link_args *uap) +{ + struct extattr_get_link_args ap; + + ap.path = uap->path; + ap.attrnamespace = uap->attrnamespace; + ap.attrname = uap->attrname; + ap.data = uap->data; + ap.nbytes = uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_get_link(td, &ap)); +} + +int +freebsd32_extattr_list_fd(struct thread *td, + struct freebsd32_extattr_list_fd_args *uap) +{ + struct extattr_list_fd_args ap; + + ap.fd = uap->fd; + ap.attrnamespace = uap->attrnamespace; + ap.data = uap->data; + ap.nbytes = uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_fd(td, &ap)); +} + +int +freebsd32_extattr_list_file(struct thread *td, + struct freebsd32_extattr_list_file_args *uap) +{ + struct extattr_list_file_args ap; + + ap.path = uap->path; + ap.attrnamespace = uap->attrnamespace; + ap.data = uap->data; + ap.nbytes = uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_file(td, &ap)); +} + +int +freebsd32_extattr_list_link(struct thread *td, + struct freebsd32_extattr_list_link_args *uap) +{ + struct extattr_list_link_args ap; + + ap.path = uap->path; + ap.attrnamespace = uap->attrnamespace; + ap.data = uap->data; + ap.nbytes = uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_link(td, &ap)); +} + #if 0 int freebsd32_xxx(struct thread *td, struct freebsd32_xxx_args *uap) diff --git a/sys/compat/freebsd32/freebsd32_proto.h b/sys/compat/freebsd32/freebsd32_proto.h index 5a12c5d..4365322 100644 --- a/sys/compat/freebsd32/freebsd32_proto.h +++ b/sys/compat/freebsd32/freebsd32_proto.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #ifndef _FREEBSD32_SYSPROTO_H_ @@ -317,6 +317,22 @@ struct freebsd32_sendfile_args { char sbytes_l_[PADL_(off_t *)]; off_t * sbytes; char sbytes_r_[PADR_(off_t *)]; char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; }; +struct freebsd32_extattr_set_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_r_[PADR_(int)]; + char attrname_l_[PADL_(const char *)]; const char * attrname; char attrname_r_[PADR_(const char *)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_get_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_r_[PADR_(int)]; + char attrname_l_[PADL_(const char *)]; const char * attrname; char attrname_r_[PADR_(const char *)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[PADR_(u_int32_t)]; +}; struct freebsd32_sigaction_args { char sig_l_[PADL_(int)]; int sig; char sig_r_[PADR_(int)]; char act_l_[PADL_(struct sigaction32 *)]; struct sigaction32 * act; char act_r_[PADR_(struct sigaction32 *)]; @@ -341,6 +357,27 @@ struct freebsd32_umtx_lock_args { struct freebsd32_umtx_unlock_args { char umtx_l_[PADL_(struct umtx *)]; struct umtx * umtx; char umtx_r_[PADR_(struct umtx *)]; }; +struct freebsd32_extattr_list_fd_args { + char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_list_file_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_list_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[PADR_(u_int32_t)]; +}; struct freebsd32_thr_suspend_args { char timeout_l_[PADL_(const struct timespec32 *)]; const struct timespec32 * timeout; char timeout_r_[PADR_(const struct timespec32 *)]; }; @@ -510,6 +547,8 @@ int freebsd32_aio_waitcomplete(struct thread *, struct freebsd32_aio_waitcomplet int freebsd32_kevent(struct thread *, struct freebsd32_kevent_args *); int freebsd32_nmount(struct thread *, struct freebsd32_nmount_args *); int freebsd32_sendfile(struct thread *, struct freebsd32_sendfile_args *); +int freebsd32_extattr_set_link(struct thread *, struct freebsd32_extattr_set_link_args *); +int freebsd32_extattr_get_link(struct thread *, struct freebsd32_extattr_get_link_args *); int freebsd32_sigaction(struct thread *, struct freebsd32_sigaction_args *); int freebsd32_sigreturn(struct thread *, struct freebsd32_sigreturn_args *); int freebsd32_getcontext(struct thread *, struct freebsd32_getcontext_args *); @@ -517,6 +556,9 @@ int freebsd32_setcontext(struct thread *, struct freebsd32_setcontext_args *); int freebsd32_swapcontext(struct thread *, struct freebsd32_swapcontext_args *); int freebsd32_umtx_lock(struct thread *, struct freebsd32_umtx_lock_args *); int freebsd32_umtx_unlock(struct thread *, struct freebsd32_umtx_unlock_args *); +int freebsd32_extattr_list_fd(struct thread *, struct freebsd32_extattr_list_fd_args *); +int freebsd32_extattr_list_file(struct thread *, struct freebsd32_extattr_list_file_args *); +int freebsd32_extattr_list_link(struct thread *, struct freebsd32_extattr_list_link_args *); int freebsd32_thr_suspend(struct thread *, struct freebsd32_thr_suspend_args *); int freebsd32_umtx_op(struct thread *, struct freebsd32_umtx_op_args *); int freebsd32_thr_new(struct thread *, struct freebsd32_thr_new_args *); @@ -739,6 +781,8 @@ int freebsd6_freebsd32_ftruncate(struct thread *, struct freebsd6_freebsd32_ftru #define FREEBSD32_SYS_AUE_freebsd32_kevent AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_nmount AUE_NMOUNT #define FREEBSD32_SYS_AUE_freebsd32_sendfile AUE_SENDFILE +#define FREEBSD32_SYS_AUE_freebsd32_extattr_set_link AUE_EXTATTR_SET_LINK +#define FREEBSD32_SYS_AUE_freebsd32_extattr_get_link AUE_EXTATTR_GET_LINK #define FREEBSD32_SYS_AUE_freebsd32_sigaction AUE_SIGACTION #define FREEBSD32_SYS_AUE_freebsd32_sigreturn AUE_SIGRETURN #define FREEBSD32_SYS_AUE_freebsd32_getcontext AUE_NULL @@ -746,6 +790,9 @@ int freebsd6_freebsd32_ftruncate(struct thread *, struct freebsd6_freebsd32_ftru #define FREEBSD32_SYS_AUE_freebsd32_swapcontext AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_lock AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_unlock AUE_NULL +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_fd AUE_EXTATTR_LIST_FD +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_file AUE_EXTATTR_LIST_FILE +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_link AUE_EXTATTR_LIST_LINK #define FREEBSD32_SYS_AUE_freebsd32_thr_suspend AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_op AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_thr_new AUE_NULL diff --git a/sys/compat/freebsd32/freebsd32_syscall.h b/sys/compat/freebsd32/freebsd32_syscall.h index 73fc7b3..c320178 100644 --- a/sys/compat/freebsd32/freebsd32_syscall.h +++ b/sys/compat/freebsd32/freebsd32_syscall.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #define FREEBSD32_SYS_syscall 0 @@ -303,6 +303,9 @@ #define FREEBSD32_SYS_statfs 396 #define FREEBSD32_SYS_fstatfs 397 #define FREEBSD32_SYS_fhstatfs 398 +#define FREEBSD32_SYS_freebsd32_extattr_set_link 412 +#define FREEBSD32_SYS_freebsd32_extattr_get_link 413 +#define FREEBSD32_SYS_extattr_delete_link 414 #define FREEBSD32_SYS_freebsd32_sigaction 416 #define FREEBSD32_SYS_freebsd32_sigreturn 417 #define FREEBSD32_SYS_freebsd32_getcontext 421 @@ -315,6 +318,9 @@ #define FREEBSD32_SYS_freebsd32_umtx_lock 434 #define FREEBSD32_SYS_freebsd32_umtx_unlock 435 #define FREEBSD32_SYS_jail_attach 436 +#define FREEBSD32_SYS_freebsd32_extattr_list_fd 437 +#define FREEBSD32_SYS_freebsd32_extattr_list_file 438 +#define FREEBSD32_SYS_freebsd32_extattr_list_link 439 #define FREEBSD32_SYS_freebsd32_thr_suspend 442 #define FREEBSD32_SYS_thr_wake 443 #define FREEBSD32_SYS_kldunloadf 444 diff --git a/sys/compat/freebsd32/freebsd32_syscalls.c b/sys/compat/freebsd32/freebsd32_syscalls.c index c31d080..ed0d24f 100644 --- a/sys/compat/freebsd32/freebsd32_syscalls.c +++ b/sys/compat/freebsd32/freebsd32_syscalls.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ const char *freebsd32_syscallnames[] = { @@ -419,9 +419,9 @@ const char *freebsd32_syscallnames[] = { "#409", /* 409 = __mac_get_pid */ "#410", /* 410 = __mac_get_link */ "#411", /* 411 = __mac_set_link */ - "#412", /* 412 = extattr_set_link */ - "#413", /* 413 = extattr_get_link */ - "#414", /* 414 = extattr_delete_link */ + "freebsd32_extattr_set_link", /* 412 = freebsd32_extattr_set_link */ + "freebsd32_extattr_get_link", /* 413 = freebsd32_extattr_get_link */ + "extattr_delete_link", /* 414 = extattr_delete_link */ "#415", /* 415 = __mac_execve */ "freebsd32_sigaction", /* 416 = freebsd32_sigaction */ "freebsd32_sigreturn", /* 417 = freebsd32_sigreturn */ @@ -444,9 +444,9 @@ const char *freebsd32_syscallnames[] = { "freebsd32_umtx_lock", /* 434 = freebsd32_umtx_lock */ "freebsd32_umtx_unlock", /* 435 = freebsd32_umtx_unlock */ "jail_attach", /* 436 = jail_attach */ - "#437", /* 437 = extattr_list_fd */ - "#438", /* 438 = extattr_list_file */ - "#439", /* 439 = extattr_list_link */ + "freebsd32_extattr_list_fd", /* 437 = freebsd32_extattr_list_fd */ + "freebsd32_extattr_list_file", /* 438 = freebsd32_extattr_list_file */ + "freebsd32_extattr_list_link", /* 439 = freebsd32_extattr_list_link */ "#440", /* 440 = kse_switchin */ "#441", /* 441 = ksem_timedwait */ "freebsd32_thr_suspend", /* 442 = freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/freebsd32_sysent.c b/sys/compat/freebsd32/freebsd32_sysent.c index a44eb58..6e3a787 100644 --- a/sys/compat/freebsd32/freebsd32_sysent.c +++ b/sys/compat/freebsd32/freebsd32_sysent.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #include "opt_compat.h" @@ -450,9 +450,9 @@ struct sysent freebsd32_sysent[] = { { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 409 = __mac_get_pid */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 410 = __mac_get_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 411 = __mac_set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 412 = extattr_set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 413 = extattr_get_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 414 = extattr_delete_link */ + { AS(freebsd32_extattr_set_link_args), (sy_call_t *)freebsd32_extattr_set_link, AUE_EXTATTR_SET_LINK, NULL, 0, 0, 0 }, /* 412 = freebsd32_extattr_set_link */ + { AS(freebsd32_extattr_get_link_args), (sy_call_t *)freebsd32_extattr_get_link, AUE_EXTATTR_GET_LINK, NULL, 0, 0, 0 }, /* 413 = freebsd32_extattr_get_link */ + { AS(extattr_delete_link_args), (sy_call_t *)extattr_delete_link, AUE_EXTATTR_DELETE_LINK, NULL, 0, 0, 0 }, /* 414 = extattr_delete_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 415 = __mac_execve */ { AS(freebsd32_sigaction_args), (sy_call_t *)freebsd32_sigaction, AUE_SIGACTION, NULL, 0, 0, 0 }, /* 416 = freebsd32_sigaction */ { AS(freebsd32_sigreturn_args), (sy_call_t *)freebsd32_sigreturn, AUE_SIGRETURN, NULL, 0, 0, 0 }, /* 417 = freebsd32_sigreturn */ @@ -475,9 +475,9 @@ struct sysent freebsd32_sysent[] = { { AS(freebsd32_umtx_lock_args), (sy_call_t *)freebsd32_umtx_lock, AUE_NULL, NULL, 0, 0, 0 }, /* 434 = freebsd32_umtx_lock */ { AS(freebsd32_umtx_unlock_args), (sy_call_t *)freebsd32_umtx_unlock, AUE_NULL, NULL, 0, 0, 0 }, /* 435 = freebsd32_umtx_unlock */ { AS(jail_attach_args), (sy_call_t *)jail_attach, AUE_NULL, NULL, 0, 0, 0 }, /* 436 = jail_attach */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 437 = extattr_list_fd */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 438 = extattr_list_file */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 439 = extattr_list_link */ + { AS(freebsd32_extattr_list_fd_args), (sy_call_t *)freebsd32_extattr_list_fd, AUE_EXTATTR_LIST_FD, NULL, 0, 0, 0 }, /* 437 = freebsd32_extattr_list_fd */ + { AS(freebsd32_extattr_list_file_args), (sy_call_t *)freebsd32_extattr_list_file, AUE_EXTATTR_LIST_FILE, NULL, 0, 0, 0 }, /* 438 = freebsd32_extattr_list_file */ + { AS(freebsd32_extattr_list_link_args), (sy_call_t *)freebsd32_extattr_list_link, AUE_EXTATTR_LIST_LINK, NULL, 0, 0, 0 }, /* 439 = freebsd32_extattr_list_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 440 = kse_switchin */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 441 = ksem_timedwait */ { AS(freebsd32_thr_suspend_args), (sy_call_t *)freebsd32_thr_suspend, AUE_NULL, NULL, 0, 0, 0 }, /* 442 = freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/syscalls.master index 50e30ad..234f3f1 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -708,9 +708,17 @@ 409 AUE_NULL UNIMPL __mac_get_pid 410 AUE_NULL UNIMPL __mac_get_link 411 AUE_NULL UNIMPL __mac_set_link -412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link -413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link -414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link +412 AUE_EXTATTR_SET_LINK STD { int freebsd32_extattr_set_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +413 AUE_EXTATTR_GET_LINK STD { ssize_t freebsd32_extattr_get_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +414 AUE_EXTATTR_DELETE_LINK NOPROTO { int extattr_delete_link( \ + const char *path, int attrnamespace, \ + const char *attrname); } 415 AUE_NULL UNIMPL __mac_execve 416 AUE_SIGACTION STD { int freebsd32_sigaction(int sig, \ struct sigaction32 *act, \ @@ -741,9 +749,17 @@ 434 AUE_NULL STD { int freebsd32_umtx_lock(struct umtx *umtx); } 435 AUE_NULL STD { int freebsd32_umtx_unlock(struct umtx *umtx); } 436 AUE_NULL NOPROTO { int jail_attach(int jid); } -437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd -438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file -439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link +437 AUE_EXTATTR_LIST_FD STD { ssize_t freebsd32_extattr_list_fd( \ + int fd, int attrnamespace, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +438 AUE_EXTATTR_LIST_FILE STD { ssize_t freebsd32_extattr_list_file( \ + const char *path, int attrnamespace, \ + void *data, u_int32_t nbyteslo, \ + u_int32_t nbyteshi); } +439 AUE_EXTATTR_LIST_LINK STD { ssize_t freebsd32_extattr_list_link( \ + const char *path, int attrnamespace, \ + void *data, u_int32_t nbyteslo, \ + u_int32_t nbyteshi); } 440 AUE_NULL UNIMPL kse_switchin 441 AUE_NULL UNIMPL ksem_timedwait 442 AUE_NULL STD { int freebsd32_thr_suspend( \ -------------- 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/20090604/4eda436d/attachment.pgp From marius at nuenneri.ch Thu Jun 4 15:47:00 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Jun 4 15:47:08 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <20090604093831.GE48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> Message-ID: Thanks to the team for this! On Thu, Jun 4, 2009 at 11:38, Ed Schouten wrote: > Good news everyone! > > As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch > into SVN. Tuesday I finally had some time to do it, so here's the > result: > > ? ? ? ?http://svn.freebsd.org/viewvc/base/projects/clangbsd/ > > You can now build your very own version of FreeBSD with Clang installed > as /usr/bin/cc as follows: > > - Check out the clangbsd branch from our SVN repository: > ?svn co svn://svn.freebsd.org/base/projects/clangbsd If one has a (recent) head checkout one can also use the faster and lighter svn switch svn://svn.freebsd.org/base/projects/clangbsd in the head working directory (less traffic for the server too). From rmacklem at uoguelph.ca Thu Jun 4 15:54:17 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Jun 4 15:54:25 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> Message-ID: On Thu, 4 Jun 2009, Robert Watson wrote: [good stuff snipped] > > Possibly we should actually add MAC and audit functions along similar lines, > and initialize cr_prison to &prison0 for the NFS creds? On the other hand, > if they may be used for network I/O, perhaps cr_prison and the others should > be initialized based on the context in which nfsd is started, so that it > takes on those security attributes. > The experimental server crdup()'s the credentials that nfsd has, but I have no idea if that's the correct thing to do? (and I've never done ZFS, so I don't know if that fixes the crashes, either). rick From kientzle at freebsd.org Thu Jun 4 16:06:56 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu Jun 4 16:07:03 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> Message-ID: <4A27F105.4040109@freebsd.org> Erik Cederstrand wrote: > > LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but "it > doesn't interact correctly with conventional nm/ar/etc" > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html). In what way does it not interact correctly? Kai Wang wrote a new libarchive-based ar/nm that's in -CURRENT; we could possibly augment those to work with llvm-ld or modify llvm-ld to work with them, depending on the nature of the disagreement. Tim From rmacklem at uoguelph.ca Thu Jun 4 18:35:07 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Jun 4 18:35:14 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090603184215.L12292@maildrop.int.zabbadoz.net> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> Message-ID: On Wed, 3 Jun 2009, Bjoern A. Zeeb wrote: > > I would start looking at svc_getcred() and blame at least the > AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. > I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. > Oh, just to clarify. Earlier to-day I mentioned that the experimental server used crdup() of the nfsd's cred. That is only for certain state recovery cases where it needs a credential to play with. Normally it uses whatever the sys/rpc layer has provided it, as above. Again, I have no idea if using crdup() is correct? rick From tinderbox at freebsd.org Thu Jun 4 19:07:43 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jun 4 19:08:00 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090604190736.050767302F@freebsd-current.sentex.ca> TB --- 2009-06-04 17:58:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 17:58:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-04 17:58:52 - cleaning the object tree TB --- 2009-06-04 17:59:23 - cvsupping the source tree TB --- 2009-06-04 17:59:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-04 17:59:31 - building world TB --- 2009-06-04 17:59:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 17:59:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 17:59:31 - TARGET=pc98 TB --- 2009-06-04 17:59:31 - TARGET_ARCH=i386 TB --- 2009-06-04 17:59:31 - TZ=UTC TB --- 2009-06-04 17:59:31 - __MAKE_CONF=/dev/null TB --- 2009-06-04 17:59:31 - cd /src TB --- 2009-06-04 17:59:31 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 17:59:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c /src/sbin/ifconfig/ifieee80211.c: In function 'iename': /src/sbin/ifconfig/ifieee80211.c:2891: error: 'IEEE80211_ELEMID_CHANSWITCHANN' undeclared (first use in this function) /src/sbin/ifconfig/ifieee80211.c:2891: error: (Each undeclared identifier is reported only once /src/sbin/ifconfig/ifieee80211.c:2891: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 19:07:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 19:07:35 - ERROR: failed to build world TB --- 2009-06-04 19:07:35 - 3154.11 user 326.84 system 4123.12 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Thu Jun 4 20:01:49 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jun 4 20:01:56 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090604200144.EAF4C7302F@freebsd-current.sentex.ca> TB --- 2009-06-04 18:37:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 18:37:57 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-04 18:37:57 - cleaning the object tree TB --- 2009-06-04 18:38:22 - cvsupping the source tree TB --- 2009-06-04 18:38:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-04 18:38:35 - building world TB --- 2009-06-04 18:38:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 18:38:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 18:38:35 - TARGET=ia64 TB --- 2009-06-04 18:38:35 - TARGET_ARCH=ia64 TB --- 2009-06-04 18:38:35 - TZ=UTC TB --- 2009-06-04 18:38:35 - __MAKE_CONF=/dev/null TB --- 2009-06-04 18:38:35 - cd /src TB --- 2009-06-04 18:38:35 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 18:38:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c /src/sbin/ifconfig/ifieee80211.c: In function 'iename': /src/sbin/ifconfig/ifieee80211.c:2891: error: 'IEEE80211_ELEMID_CHANSWITCHANN' undeclared (first use in this function) /src/sbin/ifconfig/ifieee80211.c:2891: error: (Each undeclared identifier is reported only once /src/sbin/ifconfig/ifieee80211.c:2891: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 20:01:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 20:01:44 - ERROR: failed to build world TB --- 2009-06-04 20:01:44 - 4064.43 user 327.82 system 5027.53 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From bzeeb-lists at lists.zabbadoz.net Thu Jun 4 20:25:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Jun 4 20:25:15 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> Message-ID: <20090604201810.K12292@maildrop.int.zabbadoz.net> On Thu, 4 Jun 2009, Robert Watson wrote: Hi, > Thinking more formally about this, I guess the question is whether or not the > NFS server should really be a "third" credential root. If so, we should I am not sure that would be a good idea or if it will actually be needed. I'd like to avoid adding more cases of this, especially outside init_main.c nfs server to my understanding is in no way special; nfs client would be as it can be used for the root fs. I wonder if the nfs server should use the credentials from the `prison' that triggered things off and that would be serving the data; that would probably also solve a few virtual network stack cases that are still left on my todo list. Unfortunately I'll still need stom time and probably a pencil to inhale the `new' way NFS works. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From naylor.b.david at gmail.com Thu Jun 4 21:42:37 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Thu Jun 4 21:57:50 2009 Subject: __getcwd panics [lock held] (r193174, r193186) Message-ID: <200906042321.44624.naylor.b.david@gmail.com> Hi, A recent change (r193174, r193186) in vfs_cache has been causing __getcwd to panic the system. The panic appears to trigger when I try install lang/ezm3 (with other things also happening). -- hand copied --- System call _getcwd returning with the following locks held: shared rw Name Cache (Name Cache) r = 0 (0xc0eced7c) locked @ /usr/src/sys/kern/vfs_cache.c:1104 panic: witness_warn --- above reproducible --- cpuid = 2 KDB: enter: panic [thread pid 23322 tid 100190 ] Stopped at kdb_enter+0x3a: movl $0, kdb_why db> cont Uptime 20m35s Physical memory: 3055 MB Dumping 271 MB: 256 240 224panic: bufwrite: buffer is not busy??? cpuid = 0 KDB: enter: panic [thread pid 25 tid 100055 ] Stopped at kdb_enter+0x3a: movl $0, kdb_why db> cont Uptime: 20m36s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs --- systems hangs here, does nothing else --- --- hard reset --- I reverst the change (and r193175) and the panic 'disappeared'. Willing to test patches. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090604/c7d47f69/attachment.pgp From marcus at marcuscom.com Thu Jun 4 22:11:27 2009 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Thu Jun 4 22:11:35 2009 Subject: __getcwd panics [lock held] (r193174, r193186) In-Reply-To: <200906042321.44624.naylor.b.david@gmail.com> References: <200906042321.44624.naylor.b.david@gmail.com> Message-ID: <1244153487.19104.16.camel@shumai.marcuscom.com> On Thu, 2009-06-04 at 23:21 +0200, David Naylor wrote: > Hi, > > A recent change (r193174, r193186) in vfs_cache has been causing __getcwd to > panic the system. The panic appears to trigger when I try install lang/ezm3 > (with other things also happening). Can you try this patch: http://people.freebsd.org/~marcus/vfs_cache.c.diff Joe > > -- hand copied --- > > System call _getcwd returning with the following locks held: > shared rw Name Cache (Name Cache) r = 0 (0xc0eced7c) locked > @ /usr/src/sys/kern/vfs_cache.c:1104 > panic: witness_warn > > --- above reproducible --- > > cpuid = 2 > KDB: enter: panic > [thread pid 23322 tid 100190 ] > Stopped at kdb_enter+0x3a: movl $0, kdb_why > db> cont > Uptime 20m35s > Physical memory: 3055 MB > Dumping 271 MB: 256 240 224panic: bufwrite: buffer is not busy??? > cpuid = 0 > KDB: enter: panic > [thread pid 25 tid 100055 ] > Stopped at kdb_enter+0x3a: movl $0, kdb_why > db> cont > Uptime: 20m36s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Stopping other CPUs > > --- systems hangs here, does nothing else --- > --- hard reset --- > > I reverst the change (and r193175) and the panic 'disappeared'. > > Willing to test patches. > > Regards, > > David -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090604/a2301a2a/attachment.pgp From amdmi3 at amdmi3.ru Fri Jun 5 01:53:27 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri Jun 5 01:53:39 2009 Subject: [ZFS] still kmem_too_small on recent current Message-ID: <20090605015317.GA23952@hades.panopticon> Hi! Just got a kmem_too_small panic on yesterday's current after writing 30GB disk image via NFS. This is amd64 system, with 8GB mem and those tunables: vm.kmem_size_max="2G" vm.kmem_size="2G" vfs.zfs.arc_max="1G" ZFS is 6x1TB raidz2. I have a coredump of it, so just ask if you need additional details. --- #0 doadump () at pcpu.h:223 #1 0xffffffff8054bec6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8054c356 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff806ed86e in kmem_malloc (map=0xffffff00010000e0, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:304 #4 0xffffffff806e5e75 in uma_large_malloc (size=131072, wait=2) at /usr/src/sys/vm/uma_core.c:3001 #5 0xffffffff8053b271 in malloc (size=131072, mtp=0xffffffff80e1a1e0, flags=2) at /usr/src/sys/kern/kern_malloc.c:391 #6 0xffffffff80d90ca6 in vdev_queue_io_to_issue (vq=0xffffff00065bf420, pending_limit=Variable "pending_limit" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 #7 0xffffffff80d90e1c in vdev_queue_io_done (zio=0xffffff018e1995a0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 #8 0xffffffff80da2370 in zio_vdev_io_done (zio=0xffffff013bc26870) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1845 #9 0xffffffff80da0a10 in zio_execute (zio=0xffffff013bc26870) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:996 #10 0xffffffff80d49f1c in taskq_thread (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 #11 0xffffffff80525fad in fork_exit (callout=0xffffffff80d49d48 , arg=0xffffff000188fd80, frame=0xffffff80c516cc90) at /usr/src/sys/kern/kern_fork.c:829 #12 0xffffffff8076d56e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 --- I've monitored kstat.zfs.misc.arcstats.size, top and vmstat during it, and here are the observations: - normal copying process uses ~1GB arc (sysctl) and ~1GB wired (top), which I assume includes arc. - actual disk writes are not continuous, ZFS writes data in >512MB packs. - usually those writes are pretty uniform (a write in ~10 seconds, while thoughput is 50MB/s, array can handle 400MB/s writes), but sometimes the write is either larger, or the disks can't keep up, or both - those moments are visible as much higher CPU load for 3-5 seconds, wired kicks up to 1700 mb and more, and arc decreases to ~800MB. I assume the latter is recently committed VM backpressure, and the former means panic if it rolls over kmem_max. Seems so, as I've just got another panic. Just curious, what uses that much memory in those moments? Here are last contents of ssh consoles: --- kstat.zfs.misc.arcstats.size: 804244704 kstat.zfs.misc.arcstats.size: 804244704 kstat.zfs.misc.arcstats.size: 804244704 --- procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad8 ad10 in sy cs us sy id 0 0 0 1017M 5348M 308 0 0 0 253 0 0 0 12 411 655 0 0 100 0 0 0 1017M 5348M 241 0 0 0 257 0 0 0 18 381 748 0 0 100 0 0 0 1017M 5348M 308 0 0 0 253 0 0 0 16 411 645 0 0 100 --- last pid: 7620; load averages: 1.91, 1.80, 1.42 up 0+00:48:56 05:44:11 83 processes: 1 running, 82 sleeping CPU: 0.2% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.8% idle Mem: 149M Active, 60M Inact, 2317M Wired, 1292K Cache, 821M Buf, 5347M Free Swap: 10G Total, 10G Free --- Will give it another go with 512MB arc and 4GB kmem. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From rea-fbsd at codelabs.ru Fri Jun 5 06:30:03 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jun 5 06:30:12 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <200906040802.27057.jhb@freebsd.org> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> <200906040802.27057.jhb@freebsd.org> Message-ID: Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > Yes, seems like so. John, may be we can eliminate the only reference to > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > unused (grep'ped -CURRENT sources). > > Yes. Fine. Then the attached patch should remove the stuff. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU.patch Type: text/x-diff Size: 1049 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090605/b0de0672/0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU-0001.bin From rea-fbsd at codelabs.ru Fri Jun 5 06:30:03 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jun 5 06:30:22 2009 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <200906040802.27057.jhb@freebsd.org> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> <200906040802.27057.jhb@freebsd.org> Message-ID: Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > Yes, seems like so. John, may be we can eliminate the only reference to > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > unused (grep'ped -CURRENT sources). > > Yes. Fine. Then the attached patch should remove the stuff. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU.patch Type: text/x-diff Size: 1049 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090605/b0de0672/0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU-0002.bin From dillon at apollo.backplane.com Fri Jun 5 07:14:21 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 5 07:14:34 2009 Subject: WIP: ATA to CAM integration References: <4A254B45.8050800@mavhome.dp.ua> Message-ID: <200906050703.n5573x5Q071765@apollo.backplane.com> :Hi. : :After replying to several similar questions about my ATA plans last :time, I have decided to announce things I am working on now together :with Scott Long. : :While learning FreeBSD ATA implementation, I have found, that it has :numerous deep problems, from quite fuzzy APIs to different issues in :device detection and error recovery. Also, as soon as this :infrastructure was written many years ago, it has completely no support :for any kind of command queuing, which is normal for the most of modern :drives and controllers. Fixing all of this require many significant changes. : :Also, you may know, that SAS controllers and expanders allow attaching :SATA devices and port multipliers to them, by transporting ATA commands :... :project of making CAM a system's universal infrastructure for both SCSI :and ATA. This project is not about some kind of SCSI-to-ATA translation, :used by some OS, like OpenBSD. It is about extending CAM, to equally :support both SCSI and ATA worlds natively and integrate them as tight as :possible. : :... :Our code now lives in PERFORCE in scottl-camlock project branch. It is :in early development, but we already have there working CAM driver for :AHCI controller with command queuing and basic NCQ support, simple SATA :bus management code and ATA disk driver. I am able now to boot my system :and work from SATA drive on AHCI controller, using ATA disk driver, :having command queuing and NCQ enabled, read and write disks with SATA :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only :with CAM, without using any part of ATA infrastructure. : :-- :Alexander Motin The biggest issue with AHCI (and ATA) interfacing is that AHCI devices attach either as DISK or ATAPI. A device which attaches as a DISK does not typically support ATAPI commands (though it would be an interesting experiment to see if some did). This means that no matter what you do a SCSI<->ATA translation layer needs to do some significant fake-ups for DISK attachments, similar to what OpenBSD does in their SCSI<->ATA layer. ATA DISK attachments simply do not support enough of the SCSI command set for direct integration into CAM (IMHO). The second biggest issue is that it is really unclear to me how the hell one probes an ATAPI device for NCQ support. The OpenBSD driver only uses AHCI-NCQ for DISK attachments, where the NCQ support is returned in the IDENTIFY command. I'm sure there must be a way to probe an ATAPI device for NCQ support but I don't know what it is. I don't think it is possible to get much cleaner then OpenBSD's AHCI driver (/usr/src/sys/dev/pci/ahci.c in OpenBSD). There is also a DragonFly port of the OpenBSD AHCI driver (/usr/src/sys/dev/disk/ahci in DragonFly) which you may want to look at. You are already familiar with OpenBSD's SCSI<->ATA layer (in /us/src/sys/dev/ata in OpenBSD). The DragonFly port of the OpenBSD driver will be done in about a week, and maybe a bit longer for the port-multiplier additions. It essentially works now. I'm still working on hot-plug support (the OpenBSD driver doesn't have it), some error reporting / SENSE issues, and CAM bus rescan. The DFly port is a closer match to FreeBSD since we use busdma and CAM. There are some API differences but far fewer verses the OpenBSD driver. It sounds like your own AHCI driver is well underway, though. Going with a separate AHCI-only driver and then just using the ATA driver to pick-up non-AHCI ATA ports is probably the correct way to go. That is what we intend to do. It's really amazing how *CLEAN* an AHCI-only driver is without all that old ATA hardware interfaces to deal with. The entire DragonFly driver is only 3700 lines of code. -- A couple of notes on the OpenBSD AHCI driver. OpenBSD only allocates a 24-entry PRDT (DMA chain) table per tag per port. The PRDT table can be up to 65535 entries and should be large enough to at least handle MAXPHYS transfers (56 entries would do the job). Their ATAPI implementation does not appear to do compatibility translations for INQUIRY, READ_6, or WRITE_6 (the DragonFly version does). OpenBSD's port reset code also doesn't work perfectly, something I will be fixing for hot plug support in the DragonFly port over the next week. The OpenBSD driver does not have port multiplier support but adding it to the DFly driver will be pretty easy... I just need some hardware to test it with (it's on the way). Unfortunately the AHCI-1.0 specfication says it cannot be used for high-performance multi-disk I/O because all parallel commands in operation are only allowed to go to a single target at a time. i.e. you can't mix parallel commands to different targets on the same port. That's a serious problem. (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything about that?). It is unclear to me from reading the specification as to whether AHCI-NCQ is supported for SATA ATAPI attachments. If anyone has an answer to that I'm looking for a way to probe the device's max-commands for ATAPI. for DISKs the IDENTIFY command has the necessary feature bits and information. I'm sure the host controller supports it natively but the real question is how to probe the capability on the attached device and whether the device(s) support it. Ultimately the best way to expand-out an AHCI interface is with SCSI pass-through over ATAPI, assuming NCQ can be supported somehow. The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0 spec). It is a bit annoying, actually, I wouldn't have though that Intel would have made such a basic mistake. All they had to do was implement 4 bits in the FIS and the problem would have been solved. Instead they have routing bits in a port register. Sigh. -Matt Matthew Dillon From erik at cederstrand.dk Fri Jun 5 07:45:47 2009 From: erik at cederstrand.dk (Erik Cederstrand) Date: Fri Jun 5 07:45:54 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <20090604123801.GA34971@freebsd.org> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> <20090604123801.GA34971@freebsd.org> Message-ID: Hi Roman Den 04/06/2009 kl. 14.38 skrev Roman Divacky: > > you could use llvm-ld (see the wiki for instructions how to do it). > there's also some > effort to make gnu ld usable with llvm LTO and I guess the patch > could be backported > to our ld. I guess As I understand the reply from Eli Friedman[1] this is not possible without at least some hacking. The LTO work in GNU ld[2] is under GPLv3[3], as is gold[4], which makes backporting patches a sticky issue. Erik [1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html [2] http://gcc.gnu.org/wiki/LinkTimeOptimization [3] http://gcc.gnu.org/svn/gcc/branches/lto/lto-plugin/lto-plugin.c [4] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/gold.cc?rev=1.63&content-type=text/x-cvsweb-markup&cvsroot=src From ticso at cicely7.cicely.de Fri Jun 5 09:06:36 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Fri Jun 5 09:06:43 2009 Subject: USB (internally fixed) card reader questions In-Reply-To: References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <200905301610.45520.hselasky@c2i.net> Message-ID: <20090605084841.GR12403@cicely7.cicely.de> On Sat, May 30, 2009 at 10:25:02AM -0400, Daniel Eischen wrote: > On Sat, 30 May 2009, Daniel Eischen wrote: > > >On Sat, 30 May 2009, Hans Petter Selasky wrote: > > > >>On Saturday 30 May 2009, Daniel Eischen wrote: > >>>On Sat, 30 May 2009, Hans Petter Selasky wrote: > >> > >>>It is not just USB flash cards. I have similar problem with > >>>external USB disk drives. See earlier (unanswered) posting: > >>> > >>> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006964.html > >>> > >>>And usbconfig(8) could be a little more helpful (the commands > >>>could use a description for what they do). > >> > >>I'm not sure who is at fault, USB or hald. It looks to me like hald does > >>not > >>detect that the flash card is plugged in during startup, and does not > >>mount > >>it. > > > >Is hald needed for this? I am not currently running X because > >it doesn't work any longer with my Intel 945GM chipset. > > > >I will try removing hald from the equation. > > Hmm, how about that! Removing hald (and dbus) solved the > problem. I can attach and detach the external drive without > any problems. It is just guessing, but maybe hald keeps the device opened, so GEOM never retastes the drive. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From vova at fbsd.ru Fri Jun 5 09:32:40 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Jun 5 09:32:53 2009 Subject: recent 8-current panics if load device modules from userspace under vmware Message-ID: <1244193043.2310.11.camel@localhost> Hi intsmb0: port 0x1040-0x104f at device 7.3 on pci0 panic: resource_list_alloc: resource entry is busy If load modules from startup scripts it panics with such message. (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0557413 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc055764d in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc057d176 in resource_list_alloc (rl=0xc38b2304, bus=0xc38f2c00, child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at /usr/src/sys/kern/subr_bus.c:2836 #4 0xc04d6f47 in pci_alloc_resource (dev=0xc38f2c00, child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at /usr/src/sys/dev/pci/pci.c:3599 #5 0xc057d08c in bus_alloc_resource (dev=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at bus_if.h:263 #6 0xc0639a3d in intsmb_attach (dev=0xc38f2e00) at bus.h:379 #7 0xc057bdff in device_attach (dev=0xc38f2e00) at device_if.h:178 #8 0xc057cd6c in device_probe_and_attach (dev=0xc38f2e00) at /usr/src/sys/kern/subr_bus.c:2473 #9 0xc04d63e5 in pci_driver_added (dev=0xc38f2c00, driver=0xc4053440) at /usr/src/sys/dev/pci/pci.c:2833 #10 0xc057a1a8 in devclass_driver_added (dc=0xc3840e00, driver=0xc4053440) at bus_if.h:183 #11 0xc057ab49 in devclass_add_driver (dc=0xc3840e00, driver=0xc4053440) at /usr/src/sys/kern/subr_bus.c:942 #12 0xc057b9b9 in driver_module_handler (mod=0xc3bafe40, what=0, arg=0xc40534fc) at /usr/src/sys/kern/subr_bus.c:3952 #13 0xc05480f5 in module_register_init (arg=0xc40534e4) at /usr/src/sys/kern/kern_module.c:124 #14 0xc05407bd in linker_load_module (kldname=Variable "kldname" is not available.) at /usr/src/sys/kern/kern_linker.c:234 #15 0xc0540cdc in kern_kldload (td=0xc3a4caf0, file=0xc3924000 "if_le", fileid=0xc3742c70) at /usr/src/sys/kern/kern_linker.c:1022 #16 0xc0540db4 in kldload (td=0xc3a4caf0, uap=0xc3742cf8) at /usr/src/sys/kern/kern_linker.c:1050 #17 0xc06c9157 in syscall (frame=0xc3742d38) at /usr/src/sys/i386/i386/trap.c:1073 #18 0xc06af7b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #19 0x00000033 in ?? () (kgdb) If I add same modules into loader.conf everything goes as expected. Modules tried: if_le, snd_es137x. It worked before right, for sure. I have vmware-specific script to boot my notebook under vmware time-to-time: $ cat /usr/local/etc/rc.d/011.vmware-setup.sh #!/bin/sh if /usr/local/sbin/vmware-checkvm > /dev/null; then echo "vmware configuration" ln -sf /etc/X11/xorg.conf.vmware /etc/X11/xorg.conf kldstat -q -m if_le || kldload if_le kldstat -q -m snd_es137x || kldload snd_es137x # start in-vm mouse /usr/sbin/moused -p /dev/psm0 -t auto & else echo "native configuration" ln -sf /etc/X11/xorg.conf.vbook /etc/X11/xorg.conf fi -- Vladimir B. Grebenschikov vova@fbsd.ru From jacques.fourie at gmail.com Fri Jun 5 11:18:29 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Jun 5 11:18:38 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 4 In-Reply-To: <1230326101.16303.1243663430565.JavaMail.apache@mail52.abv.bg> References: <1230326101.16303.1243663430565.JavaMail.apache@mail52.abv.bg> Message-ID: > Hi, > I've tried http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz out... > ?- it compiles fine (except for the iso I had to download manually) > ?- it panics when I try to load the kernel module, first I tried to load it with X running and the second time I tried to load it without X running, please find attached the output. > > about my machine: > $ uname -a > FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #7: Thu May 28 01:24:11 EEST 2009 ? ? mgp@mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE ?amd64 > > and also ports updated from 28th of May > > regards, > mgp > _______________________________________________ > 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" > The following patch fixes this issue for me. --- semevent-r0drv-freebsd.c.old 2009-06-05 12:48:55.841136475 +0200 +++ semevent-r0drv-freebsd.c 2009-06-05 12:15:08.610705499 +0200 @@ -181,7 +181,7 @@ rc = tsleep(pEventInt, /* block id */ fInterruptible ? PZERO | PCATCH : PZERO, "iprtev", - tvtohz(&tv)); + cMillies == RT_INDEFINITE_WAIT ? 0 : tvtohz(&tv)); mtx_lock_spin(&pEventInt->Mtx); Regards, Jacques From naylor.b.david at gmail.com Fri Jun 5 09:25:22 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Fri Jun 5 11:22:11 2009 Subject: __getcwd panics [lock held] (r193174, r193186) In-Reply-To: <1244153487.19104.16.camel@shumai.marcuscom.com> References: <200906042321.44624.naylor.b.david@gmail.com> <1244153487.19104.16.camel@shumai.marcuscom.com> Message-ID: <200906051126.22143.naylor.b.david@gmail.com> On Friday 05 June 2009 00:11:27 Joe Marcus Clarke wrote: > On Thu, 2009-06-04 at 23:21 +0200, David Naylor wrote: > > Hi, > > > > A recent change (r193174, r193186) in vfs_cache has been causing __getcwd > > to panic the system. The panic appears to trigger when I try install > > lang/ezm3 (with other things also happening). > > Can you try this patch: > > http://people.freebsd.org/~marcus/vfs_cache.c.diff Patch works. After an hour system still running (normally triggered at ~20mins). Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090605/dfff2545/attachment.pgp From h.schmalzbauer at omnilan.de Fri Jun 5 11:42:25 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Fri Jun 5 11:42:34 2009 Subject: AOE on FreeBSD? In-Reply-To: References: <1009314136.20090531173617@serebryakov.spb.ru> Message-ID: <4A290203.3070903@omnilan.de> Stacey Son schrieb am 31.05.2009 19:22 (localtime): ... > commit. I would estimate about two weeks given what I have on my > plate currently and what I believe needs to be rewritten in the > initiator. Is there a good amount of interest for this? I'd be very interested too, depending on the transfer rates we can expect. If I need a core2-duo CPU to get 50mByte/sec through a em<->em system it's not very interesting. If I can sturate the GbE Link with a 233MHz GEODE and em, it's _very_ interesting. Any experiences what to expect? 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/20090605/e34df505/signature.pgp From serenity at exscape.org Fri Jun 5 13:09:42 2009 From: serenity at exscape.org (Thomas Backman) Date: Fri Jun 5 13:09:59 2009 Subject: ZFS send/recv and overwriting of existing mounts Message-ID: <1F0CF2D2-D53D-4C3D-9936-8F429525D89F@exscape.org> Hey all, I was wondering if there could (should?) be some kind of protection of over-mounting/shadowing (whatever the term is; overriding an existing mount) in ZFS. Take this as an example (from my memory, as the shell history is gone due to the forceful shutdown): zfs create tank/test zfs snapshot tank/root@now zfs send -R tank/root@now | zfs recv -vf tank/test ... bam, you now have two filesystems mounted on /, an empty /dev directory unless you double-mount devfs as well, etc. Reboot, and the same thing happens - it mounts root from /boot/ loader.conf, then rc.conf executes and mounts the tank/test root copy over /, again hiding /dev and making your system non-bootable. The only solution I've found so far is to reboot to livefs and destroy the copy... Ugh. I was just gonna test to see if send -R worked on vanilla sources now (I've had to use a patch previously), which it did, but I didn't expect it to override my root! (Single-user might have worked, now that I think about it; still, that too requires downtime to fix something that shouldn't really happen.) I guess you COULD file this under the "feature, not a bug" section, but in cases like this, I'd say "bug". Regards, Thomas From jhb at freebsd.org Fri Jun 5 13:55:10 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 5 13:55:36 2009 Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) In-Reply-To: <20090604135402.GT1927@deviant.kiev.zoral.com.ua> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> Message-ID: <200906050945.52511.jhb@freebsd.org> On Thursday 04 June 2009 9:54:02 am Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > > Dmitry Marakasov wrote: > > > > > >The problem: on recent current, 32bit bsdtar won't write archives when > > >running under 64bit kernel, dying with exit code 140 and `Bad system call' > > >message. I've ran into that using i386 tinderbox jail on amd64 host. > > >The problem actually happens in libarchive: > > > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > 484 if (!a->follow_symlinks) > > > 485 list_size = extattr_list_link(path, > > > namespace, NULL, 0); // <-- HERE > > > 486 else > > > 487 list_size = extattr_list_file(path, > > > namespace, NULL, 0); > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > > Yes, it looks like only about half of the extattr calls are > > actually connected in the freebsd32 compatibility layer. (see below) > > According to SVN history, peter@ reserved these slots back > > in December 2003 but no one ever went back and connected > > them up. I don't know if there was a reason for not > > connecting them or if simply no one remembered to do so. > > I would guess the latter; the ones that are connected > > were all implemented before mid-2002. > > > > I don't see any obvious reason these should not just > > work. If you're feeling adventurous, you could try > > copying the data from /usr/src/kern/syscalls.master > > and see what happens. I don't have a 64-bit system > > handy here or I would try this myself. > > > > You can test by going to /usr/src/lib/libarchive/test and > > running "make check". That will build and run the libarchive > > test suite, which does exercise the extended attribute support. > > (Of course, you should revert your change first so that the > > extended attribute support is actually compiled.) > > > > Let me know if you find anything, > > > > Tim > > > > > > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int > > cmd, \ > > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ > > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ > > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link > > The size_t arguments need translation. Please try the patch below. Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need this sort of fixup. See 'read' and 'write' which just use the native versions for example. I don't think these calls need any sort of wrapper but the native versions should just work. -- John Baldwin From jhb at freebsd.org Fri Jun 5 13:55:13 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 5 13:55:48 2009 Subject: recent 8-current panics if load device modules from userspace under vmware In-Reply-To: <1244193043.2310.11.camel@localhost> References: <1244193043.2310.11.camel@localhost> Message-ID: <200906050955.02428.jhb@freebsd.org> On Friday 05 June 2009 5:10:43 am Vladimir Grebenschikov wrote: > Hi > > intsmb0: port 0x1040-0x104f at device 7.3 on pci0 > panic: resource_list_alloc: resource entry is busy > > If load modules from startup scripts it panics with such message. > > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc0557413 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc055764d in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc057d176 in resource_list_alloc (rl=0xc38b2304, bus=0xc38f2c00, > child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, > count=1, flags=2) at /usr/src/sys/kern/subr_bus.c:2836 > #4 0xc04d6f47 in pci_alloc_resource (dev=0xc38f2c00, child=0xc38f2e00, > type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) > at /usr/src/sys/dev/pci/pci.c:3599 > #5 0xc057d08c in bus_alloc_resource (dev=0xc38f2e00, type=4, rid=0xc3742934, > start=0, end=4294967295, count=1, flags=2) at bus_if.h:263 > #6 0xc0639a3d in intsmb_attach (dev=0xc38f2e00) at bus.h:379 > #7 0xc057bdff in device_attach (dev=0xc38f2e00) at device_if.h:178 > #8 0xc057cd6c in device_probe_and_attach (dev=0xc38f2e00) > at /usr/src/sys/kern/subr_bus.c:2473 > #9 0xc04d63e5 in pci_driver_added (dev=0xc38f2c00, driver=0xc4053440) > at /usr/src/sys/dev/pci/pci.c:2833 > #10 0xc057a1a8 in devclass_driver_added (dc=0xc3840e00, driver=0xc4053440) > at bus_if.h:183 > #11 0xc057ab49 in devclass_add_driver (dc=0xc3840e00, driver=0xc4053440) > at /usr/src/sys/kern/subr_bus.c:942 > #12 0xc057b9b9 in driver_module_handler (mod=0xc3bafe40, what=0, > arg=0xc40534fc) at /usr/src/sys/kern/subr_bus.c:3952 > #13 0xc05480f5 in module_register_init (arg=0xc40534e4) > at /usr/src/sys/kern/kern_module.c:124 > #14 0xc05407bd in linker_load_module (kldname=Variable "kldname" is not available.) > at /usr/src/sys/kern/kern_linker.c:234 > #15 0xc0540cdc in kern_kldload (td=0xc3a4caf0, file=0xc3924000 "if_le", > fileid=0xc3742c70) at /usr/src/sys/kern/kern_linker.c:1022 > #16 0xc0540db4 in kldload (td=0xc3a4caf0, uap=0xc3742cf8) > at /usr/src/sys/kern/kern_linker.c:1050 > #17 0xc06c9157 in syscall (frame=0xc3742d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #18 0xc06af7b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #19 0x00000033 in ?? () > (kgdb) > > If I add same modules into loader.conf everything goes as expected. > Modules tried: if_le, snd_es137x. Can you get devinfo -r output for 1) prior to loading the module that causes a panic and 2) when you load the modules from the loader. -- John Baldwin From amdmi3 at amdmi3.ru Fri Jun 5 14:02:12 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri Jun 5 14:02:20 2009 Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) In-Reply-To: <200906050945.52511.jhb@freebsd.org> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> <200906050945.52511.jhb@freebsd.org> Message-ID: <20090605140205.GB18653@hades.panopticon> * John Baldwin (jhb@freebsd.org) wrote: > Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need this > sort of fixup. See 'read' and 'write' which just use the native versions for > example. I don't think these calls need any sort of wrapper but the native > versions should just work. I'll try to build a jail to test it in the weekend. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From serenity at exscape.org Fri Jun 5 14:18:12 2009 From: serenity at exscape.org (Thomas Backman) Date: Fri Jun 5 14:18:20 2009 Subject: Fatal trap 12: page fault panic with recent kernel with ZFS In-Reply-To: <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> Message-ID: <3AB9BCA0-DCEA-4E64-A01D-8BA9B75C3ECD@exscape.org> On May 21, 2009, at 08:31 PM, Kip Macy wrote: >> Hey, I (not the OP) am still having trouble with this. The panics >> appear to >> be gone since I set arc_min to 30M and arc_max to 100M, though (2GB >> RAM). >> I get/got them during a full zfs send -R | zfs recv -Fvd of a >> ~3.3GB pool. >> The only modification I've done to the source tree is the >> libzfs_sendrecv >> patch here: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html > > > I'll apply the patch this weekend. > > If I get time I'll also try to reproduce your panic. > > > Thanks, > Kip Two weekends later and still the same deal with send | recv. ;) Just worried that this'll make it into 8.0-RELEASE, that's all. That would be bad. The patch linked above seems to solve the problem for me, anyway. I just tried a fresh build (sources from June 5th at 10AM CEST), without the patch, and I got the same core dump on zfs recv, with a SIGSEGV in strcmp(). (See the linked thread.) Applied the patch, rebuild libzfs, rebooted, and it works again. It seems something along the lines of zfs snapshot -r tank@initial-snapshot zfs send -R tank@initial-snapshot | zfs recv -vFd slave and then zfs snapshot -r tank@testsnap # some other, unrelated snapshot in between may or may not be needed to crash, I'm not sure zfs snapshot -r tank@second-snapshot zfs send -R -I initial-snapshot tank@second-snapshot | zfs recv -Fvd slave causes the core dump. Regards, Thomas From kostikbel at gmail.com Fri Jun 5 14:41:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jun 5 14:41:12 2009 Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) In-Reply-To: <200906050945.52511.jhb@freebsd.org> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> <200906050945.52511.jhb@freebsd.org> Message-ID: <20090605144052.GE1927@deviant.kiev.zoral.com.ua> On Fri, Jun 05, 2009 at 09:45:51AM -0400, John Baldwin wrote: > On Thursday 04 June 2009 9:54:02 am Kostik Belousov wrote: > > On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > > > Dmitry Marakasov wrote: > > > > > > > >The problem: on recent current, 32bit bsdtar won't write archives when > > > >running under 64bit kernel, dying with exit code 140 and `Bad system > call' > > > >message. I've ran into that using i386 tinderbox jail on amd64 host. > > > >The problem actually happens in libarchive: > > > > > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > > 484 if (!a->follow_symlinks) > > > > 485 list_size = extattr_list_link(path, > > > > namespace, NULL, 0); // <-- HERE > > > > 486 else > > > > 487 list_size = extattr_list_file(path, > > > > namespace, NULL, 0); > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > > > > Yes, it looks like only about half of the extattr calls are > > > actually connected in the freebsd32 compatibility layer. (see below) > > > According to SVN history, peter@ reserved these slots back > > > in December 2003 but no one ever went back and connected > > > them up. I don't know if there was a reason for not > > > connecting them or if simply no one remembered to do so. > > > I would guess the latter; the ones that are connected > > > were all implemented before mid-2002. > > > > > > I don't see any obvious reason these should not just > > > work. If you're feeling adventurous, you could try > > > copying the data from /usr/src/kern/syscalls.master > > > and see what happens. I don't have a 64-bit system > > > handy here or I would try this myself. > > > > > > You can test by going to /usr/src/lib/libarchive/test and > > > running "make check". That will build and run the libarchive > > > test suite, which does exercise the extended attribute support. > > > (Of course, you should revert your change first so that the > > > extended attribute support is actually compiled.) > > > > > > Let me know if you find anything, > > > > > > Tim > > > > > > > > > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > > > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int > > > cmd, \ > > > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > > > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > > > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > > > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > > > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ > > > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ > > > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > > > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > > > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > > > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > > > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > > > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link > > > > The size_t arguments need translation. Please try the patch below. > > Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need this > sort of fixup. See 'read' and 'write' which just use the native versions for > example. I don't think these calls need any sort of wrapper but the native > versions should just work. Yes, I obvioulsy confused it with off_t. diff --git a/sys/compat/freebsd32/freebsd32_proto.h b/sys/compat/freebsd32/freebsd32_proto.h index 5a12c5d..587fdc4 100644 --- a/sys/compat/freebsd32/freebsd32_proto.h +++ b/sys/compat/freebsd32/freebsd32_proto.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #ifndef _FREEBSD32_SYSPROTO_H_ diff --git a/sys/compat/freebsd32/freebsd32_syscall.h b/sys/compat/freebsd32/freebsd32_syscall.h index 73fc7b3..43a68b3 100644 --- a/sys/compat/freebsd32/freebsd32_syscall.h +++ b/sys/compat/freebsd32/freebsd32_syscall.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #define FREEBSD32_SYS_syscall 0 @@ -303,6 +303,9 @@ #define FREEBSD32_SYS_statfs 396 #define FREEBSD32_SYS_fstatfs 397 #define FREEBSD32_SYS_fhstatfs 398 +#define FREEBSD32_SYS_extattr_set_link 412 +#define FREEBSD32_SYS_extattr_get_link 413 +#define FREEBSD32_SYS_extattr_delete_link 414 #define FREEBSD32_SYS_freebsd32_sigaction 416 #define FREEBSD32_SYS_freebsd32_sigreturn 417 #define FREEBSD32_SYS_freebsd32_getcontext 421 @@ -315,6 +318,9 @@ #define FREEBSD32_SYS_freebsd32_umtx_lock 434 #define FREEBSD32_SYS_freebsd32_umtx_unlock 435 #define FREEBSD32_SYS_jail_attach 436 +#define FREEBSD32_SYS_extattr_list_fd 437 +#define FREEBSD32_SYS_extattr_list_file 438 +#define FREEBSD32_SYS_extattr_list_link 439 #define FREEBSD32_SYS_freebsd32_thr_suspend 442 #define FREEBSD32_SYS_thr_wake 443 #define FREEBSD32_SYS_kldunloadf 444 diff --git a/sys/compat/freebsd32/freebsd32_syscalls.c b/sys/compat/freebsd32/freebsd32_syscalls.c index c31d080..a69d907 100644 --- a/sys/compat/freebsd32/freebsd32_syscalls.c +++ b/sys/compat/freebsd32/freebsd32_syscalls.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ const char *freebsd32_syscallnames[] = { @@ -419,9 +419,9 @@ const char *freebsd32_syscallnames[] = { "#409", /* 409 = __mac_get_pid */ "#410", /* 410 = __mac_get_link */ "#411", /* 411 = __mac_set_link */ - "#412", /* 412 = extattr_set_link */ - "#413", /* 413 = extattr_get_link */ - "#414", /* 414 = extattr_delete_link */ + "extattr_set_link", /* 412 = extattr_set_link */ + "extattr_get_link", /* 413 = extattr_get_link */ + "extattr_delete_link", /* 414 = extattr_delete_link */ "#415", /* 415 = __mac_execve */ "freebsd32_sigaction", /* 416 = freebsd32_sigaction */ "freebsd32_sigreturn", /* 417 = freebsd32_sigreturn */ @@ -444,9 +444,9 @@ const char *freebsd32_syscallnames[] = { "freebsd32_umtx_lock", /* 434 = freebsd32_umtx_lock */ "freebsd32_umtx_unlock", /* 435 = freebsd32_umtx_unlock */ "jail_attach", /* 436 = jail_attach */ - "#437", /* 437 = extattr_list_fd */ - "#438", /* 438 = extattr_list_file */ - "#439", /* 439 = extattr_list_link */ + "extattr_list_fd", /* 437 = extattr_list_fd */ + "extattr_list_file", /* 438 = extattr_list_file */ + "extattr_list_link", /* 439 = extattr_list_link */ "#440", /* 440 = kse_switchin */ "#441", /* 441 = ksem_timedwait */ "freebsd32_thr_suspend", /* 442 = freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/freebsd32_sysent.c b/sys/compat/freebsd32/freebsd32_sysent.c index a44eb58..5d64fca 100644 --- a/sys/compat/freebsd32/freebsd32_sysent.c +++ b/sys/compat/freebsd32/freebsd32_sysent.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 2009-04-29 21:14:15Z jamie + * created from FreeBSD */ #include "opt_compat.h" @@ -450,9 +450,9 @@ struct sysent freebsd32_sysent[] = { { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 409 = __mac_get_pid */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 410 = __mac_get_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 411 = __mac_set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 412 = extattr_set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 413 = extattr_get_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 414 = extattr_delete_link */ + { AS(extattr_set_link_args), (sy_call_t *)extattr_set_link, AUE_EXTATTR_SET_LINK, NULL, 0, 0, 0 }, /* 412 = extattr_set_link */ + { AS(extattr_get_link_args), (sy_call_t *)extattr_get_link, AUE_EXTATTR_GET_LINK, NULL, 0, 0, 0 }, /* 413 = extattr_get_link */ + { AS(extattr_delete_link_args), (sy_call_t *)extattr_delete_link, AUE_EXTATTR_DELETE_LINK, NULL, 0, 0, 0 }, /* 414 = extattr_delete_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 415 = __mac_execve */ { AS(freebsd32_sigaction_args), (sy_call_t *)freebsd32_sigaction, AUE_SIGACTION, NULL, 0, 0, 0 }, /* 416 = freebsd32_sigaction */ { AS(freebsd32_sigreturn_args), (sy_call_t *)freebsd32_sigreturn, AUE_SIGRETURN, NULL, 0, 0, 0 }, /* 417 = freebsd32_sigreturn */ @@ -475,9 +475,9 @@ struct sysent freebsd32_sysent[] = { { AS(freebsd32_umtx_lock_args), (sy_call_t *)freebsd32_umtx_lock, AUE_NULL, NULL, 0, 0, 0 }, /* 434 = freebsd32_umtx_lock */ { AS(freebsd32_umtx_unlock_args), (sy_call_t *)freebsd32_umtx_unlock, AUE_NULL, NULL, 0, 0, 0 }, /* 435 = freebsd32_umtx_unlock */ { AS(jail_attach_args), (sy_call_t *)jail_attach, AUE_NULL, NULL, 0, 0, 0 }, /* 436 = jail_attach */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 437 = extattr_list_fd */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 438 = extattr_list_file */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 439 = extattr_list_link */ + { AS(extattr_list_fd_args), (sy_call_t *)extattr_list_fd, AUE_EXTATTR_LIST_FD, NULL, 0, 0, 0 }, /* 437 = extattr_list_fd */ + { AS(extattr_list_file_args), (sy_call_t *)extattr_list_file, AUE_EXTATTR_LIST_FILE, NULL, 0, 0, 0 }, /* 438 = extattr_list_file */ + { AS(extattr_list_link_args), (sy_call_t *)extattr_list_link, AUE_EXTATTR_LIST_LINK, NULL, 0, 0, 0 }, /* 439 = extattr_list_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 440 = kse_switchin */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 441 = ksem_timedwait */ { AS(freebsd32_thr_suspend_args), (sy_call_t *)freebsd32_thr_suspend, AUE_NULL, NULL, 0, 0, 0 }, /* 442 = freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/syscalls.master index 50e30ad..7da270b 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -708,9 +708,17 @@ 409 AUE_NULL UNIMPL __mac_get_pid 410 AUE_NULL UNIMPL __mac_get_link 411 AUE_NULL UNIMPL __mac_set_link -412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link -413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link -414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link +412 AUE_EXTATTR_SET_LINK NOPROTO { int extattr_set_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + size_t nbytes); } +413 AUE_EXTATTR_GET_LINK NOPROTO { ssize_t extattr_get_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + size_t nbytes); } +414 AUE_EXTATTR_DELETE_LINK NOPROTO { int extattr_delete_link( \ + const char *path, int attrnamespace, \ + const char *attrname); } 415 AUE_NULL UNIMPL __mac_execve 416 AUE_SIGACTION STD { int freebsd32_sigaction(int sig, \ struct sigaction32 *act, \ @@ -741,9 +749,15 @@ 434 AUE_NULL STD { int freebsd32_umtx_lock(struct umtx *umtx); } 435 AUE_NULL STD { int freebsd32_umtx_unlock(struct umtx *umtx); } 436 AUE_NULL NOPROTO { int jail_attach(int jid); } -437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd -438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file -439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link +437 AUE_EXTATTR_LIST_FD NOPROTO { ssize_t extattr_list_fd(int fd, \ + int attrnamespace, void *data, \ + size_t nbytes); } +438 AUE_EXTATTR_LIST_FILE NOPROTO { ssize_t extattr_list_file( \ + const char *path, int attrnamespace, \ + void *data, size_t nbytes); } +439 AUE_EXTATTR_LIST_LINK NOPROTO { ssize_t extattr_list_link( \ + const char *path, int attrnamespace, \ + void *data, size_t nbytes); } 440 AUE_NULL UNIMPL kse_switchin 441 AUE_NULL UNIMPL ksem_timedwait 442 AUE_NULL STD { int freebsd32_thr_suspend( \ -------------- 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/20090605/71258640/attachment.pgp From rmacklem at uoguelph.ca Fri Jun 5 15:15:54 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Jun 5 15:16:02 2009 Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world In-Reply-To: <20090603235227.GB15659@hades.panopticon> References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> Message-ID: On Thu, 4 Jun 2009, Dmitry Marakasov wrote: > * O. Hartmann (ohartman@zedat.fu-berlin.de) wrote: > > Just my 2 cents: the same behaviour, and while mount -o tcp succeeds, > umounting behaves strangely: if I umount nfs filesystem, umount > process hangs for some time, then exits with `umount: hive: > RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually > umounted immediately after umount is called. This all also breaks > amd severely (however it already haven't been working on current > for a long time for me). > That would be consistent with the problem being udp specific. An NFS server for v2,3 (NFSv4 is a different story) is "stateless" and doesn't know what mounted on it. All the "umount" does is tell the server's mountd daemon it has unmounted, so the server's mountd can maintain a table of mounts that can be queried via "showmount". The -current umount.c always does this via "udp", so it would fail. The only effect is that "showmount" might reply bogus info. It seems that the problem is specific to "udp" and some arches. (I can't reproduce it on i386 and at least one person sees it on amd64.) Maybe people who see the problem can post to the -current list, noting what arch they are using and network config (running virtualized, what net hardware, multiple net interfaces, etc). Hopefully there is some commonality among them? Thanks in advance for any help tracking this down, rick From deischen at freebsd.org Fri Jun 5 15:42:52 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Fri Jun 5 15:43:00 2009 Subject: USB (internally fixed) card reader questions In-Reply-To: <20090605084841.GR12403@cicely7.cicely.de> References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <200905301610.45520.hselasky@c2i.net> <20090605084841.GR12403@cicely7.cicely.de> Message-ID: On Fri, 5 Jun 2009, Bernd Walter wrote: > On Sat, May 30, 2009 at 10:25:02AM -0400, Daniel Eischen wrote: >> On Sat, 30 May 2009, Daniel Eischen wrote: >> >>> On Sat, 30 May 2009, Hans Petter Selasky wrote: >>> >>>> On Saturday 30 May 2009, Daniel Eischen wrote: >>>>> On Sat, 30 May 2009, Hans Petter Selasky wrote: >>>> >>>>> It is not just USB flash cards. I have similar problem with >>>>> external USB disk drives. See earlier (unanswered) posting: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006964.html >>>>> >>>>> And usbconfig(8) could be a little more helpful (the commands >>>>> could use a description for what they do). >>>> >>>> I'm not sure who is at fault, USB or hald. It looks to me like hald does >>>> not >>>> detect that the flash card is plugged in during startup, and does not >>>> mount >>>> it. >>> >>> Is hald needed for this? I am not currently running X because >>> it doesn't work any longer with my Intel 945GM chipset. >>> >>> I will try removing hald from the equation. >> >> Hmm, how about that! Removing hald (and dbus) solved the >> problem. I can attach and detach the external drive without >> any problems. > > It is just guessing, but maybe hald keeps the device opened, so GEOM > never retastes the drive. I don't know, but I was able to "dd if=/dev/da0 of=/tmp/da0.bb count=1" from a good and bad attachment. When the problem occurs, it seems like the data read by dd is skewed off by 12 bytes. The first 12 bytes are 0, followed by the same data (from byte 0) as the dd from the good attachment. [deischen@rigel ~]$ od -x da0.mbr.noworky 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 31fc 8ec0 8ec0 8ed8 0000040 bcd0 7c00 e689 00bf b906 0100 a5f3 fd89 0000060 08b1 abf3 45fe e9f2 8a00 46f6 20bb 0875 ... 0000720 02b1 8f80 00b6 0100 0001 fe06 043f 003f 0000740 0000 3986 0001 0000 0501 fe07 ffff 39c5 0000760 0001 f44f 01ba 0080 ffc1 fea5 ffff 2e14 [deischen@rigel ~]$ od -x da0.mbr.worky 0000000 31fc 8ec0 8ec0 8ed8 bcd0 7c00 e689 00bf 0000020 b906 0100 a5f3 fd89 08b1 abf3 45fe e9f2 0000040 8a00 46f6 20bb 0875 d284 0778 4e80 40bb 0000060 568a 88ba 0056 fae8 5200 c2bb 3107 88d2 ... 0000720 0501 fe07 ffff 39c5 0001 f44f 01ba 0080 0000740 ffc1 fea5 ffff 2e14 01bc 7275 0513 0000 0000760 0000 0000 0000 0000 0000 0000 0000 aa55 There are other side-effects from hald also. Trying to use camcontrol rescan, reset, and disconnecting/reconnecting the drive eventually leads to a hung system necessitating a reboot. Without hald, it seems I can connect/disconnect the drive as many times as I want. -- DE From dillon at apollo.backplane.com Fri Jun 5 16:01:02 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 5 16:01:10 2009 Subject: WIP: ATA to CAM integration References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> Message-ID: <200906051601.n55G10Mi075734@apollo.backplane.com> More on the port multiplier spec. It turns out that the port-multiplier port selector is in the command table, so it is per command-tag. There is confusion in the spec though: section 9.1: In this mode of operation, a communication path is opened between the HBA and a device through the Port Multiplier. Since Port Multipliers are meant to be simple, the burden of making a connection is on the AHCI software, to ensure that multiple commands are not outstanding to different devices behind the Port Multiplier. section 9.1.2: "Since queued commands result in two different operations (command issue, clear of BSY, then data transfer), if commands were sent to different ports, the Port Multiplier may issue FISes back to the HBA in an interleaved manner from different ports. This will break an HBA that only supports command-based switching. Therefore, when executing native command queueing commands, system software must only add commands to the command list that target a single port behind the Port Multiplier, wait for the commands to finish (PxSACT bits all cleared), then add commands for a different port. Additionally, the tags used must match the command slot entries." -- It's unclear to me what this means. Can we use NCQ to queue multiple commands to multiple ports behind a single port multiplier in parallel or can't we? It's very confusing. -Matt From gcorcoran at rcn.com Fri Jun 5 16:34:21 2009 From: gcorcoran at rcn.com (Gary Corcoran) Date: Fri Jun 5 16:34:29 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <200906051601.n55G10Mi075734@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> Message-ID: <4A294AD1.6040809@rcn.com> Matthew Dillon wrote: > More on the port multiplier spec. It turns out that the port-multiplier > port selector is in the command table, so it is per command-tag. There > is confusion in the spec though: > > section 9.1: > > In this mode of operation, a communication path is opened between the > HBA and a device through the Port Multiplier. Since Port Multipliers are > meant to be simple, the burden of making a connection is on the AHCI > software, to ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier. > > section 9.1.2: > > "Since queued commands result in two different operations (command issue, > clear of BSY, then data transfer), if commands were sent to different > ports, the Port Multiplier may issue FISes back to the HBA in > an interleaved manner from different ports. This will break an HBA that > only supports command-based switching. Therefore, when executing native > command queueing commands, system software must only add commands > to the command list that target a single port behind the Port Multiplier, > wait for the commands to finish (PxSACT bits all cleared), then add > commands for a different port. Additionally, the tags used > must match the command slot entries." > > -- > > It's unclear to me what this means. Can we use NCQ to queue multiple > commands to multiple ports behind a single port multiplier in parallel > or can't we? It's very confusing. As I read the above, this: > ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier combined with this: > system software must only add commands > to the command list that target a *single port* behind the Port Multiplier, > *wait for the commands to finish* suggests strongly that you many not send multiple commands out to a single port multiplier. However, I agree that it's not crystal clear, and may not be what was intended. Gary From mav at FreeBSD.org Fri Jun 5 17:05:44 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jun 5 17:05:55 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <4A294AD1.6040809@rcn.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> <4A294AD1.6040809@rcn.com> Message-ID: <4A29505E.6070902@FreeBSD.org> Gary Corcoran wrote: > suggests strongly that you many not send multiple commands out to a single > port multiplier. However, I agree that it's not crystal clear, and may not > be what was intended. AHCI rev. 1.3: 9.3 FIS-based Switching FIS-based switching requires the HBA to keep track of additional device specific context within each HBA port. The HBA must be able to issue commands to a device while there are still commands outstanding to other devices that are connected to the same host port through the Port Multiplier. The HBA must be able to switch DMA context on the fly; e.g. a Data FIS is received from target X, followed by a Data FIS from target X+1. 9.3.1.1.1 Enable When FIS-based switching is enabled, the hardware shall maintain a distinct BSY/DRQ bit for up to 16 devices. These bits are distinguished in the state machine as the pBsy and pDrq arrays. Hardware shall fetch commands in such a way as to try to ensure commands are issued to all devices that have BSY/DRQ cleared to ?0? and have commands in the command list. Instances of the BSY/DRQ bits are updated based on the Port Multiplier port field in Device to Host FISes. -- Alexander Motin From dillon at apollo.backplane.com Fri Jun 5 17:28:16 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 5 17:28:29 2009 Subject: WIP: ATA to CAM integration References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A294DC3.5010008@mavhome.dp.ua> Message-ID: <200906051728.n55HSFf0076644@apollo.backplane.com> :Latest AHCI specifications define feature named FIS Based Switching. It :allows controller independently track state of every device beyond port :multiplier. It should be quite easy to use it, but actually none of my :controllers have that capability. Damn. The FBSS capability bit is not set on my (AMD) MCP77 based AHCI SATA controller. That sucks. ahci0: ... ahci0: AHCI 1.2 capabilities 0xe3229f05, 6 port Do you know of any host controllers which support FBS ? Any of the Intel parts or machines per-chance? :As I have said, without controller FIS Based Switching capability it is :impossible. FBS defines separate memory areas for controller, to track :there state of each drive behind PM. Without it, only one drive can be :active at a time, as controller will not be able to track when each :drive is able to receive next command.. Now it makes sense... the 1.0 spec only had one RFIS per port. With only one RFIS area per port it is impossible to track multiple ports behind the PM simultaniously. The 1.3 specification (along with FBSS being set) has 16 RFIS areas per port, plus BSY bits for each, thus fixing the problem. This is really annoying. It effectively serializes access to multiple disks behind a port multiplier on non-FBSS controllers. That makes non-FBSS port-multiplied disk enclosures almost worthless from a performance standpoint. -Matt Matthew Dillon From scottl at samsco.org Fri Jun 5 17:33:01 2009 From: scottl at samsco.org (Scott Long) Date: Fri Jun 5 17:33:08 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> Message-ID: <4A2956C6.5070902@samsco.org> Matthew Dillon wrote: > :Hi. > : > :After replying to several similar questions about my ATA plans last > :time, I have decided to announce things I am working on now together > :with Scott Long. > : > :While learning FreeBSD ATA implementation, I have found, that it has > :numerous deep problems, from quite fuzzy APIs to different issues in > :device detection and error recovery. Also, as soon as this > :infrastructure was written many years ago, it has completely no support > :for any kind of command queuing, which is normal for the most of modern > :drives and controllers. Fixing all of this require many significant changes. > : > :Also, you may know, that SAS controllers and expanders allow attaching > :SATA devices and port multipliers to them, by transporting ATA commands > :... > :project of making CAM a system's universal infrastructure for both SCSI > :and ATA. This project is not about some kind of SCSI-to-ATA translation, > :used by some OS, like OpenBSD. It is about extending CAM, to equally > :support both SCSI and ATA worlds natively and integrate them as tight as > :possible. > : > :... > :Our code now lives in PERFORCE in scottl-camlock project branch. It is > :in early development, but we already have there working CAM driver for > :AHCI controller with command queuing and basic NCQ support, simple SATA > :bus management code and ATA disk driver. I am able now to boot my system > :and work from SATA drive on AHCI controller, using ATA disk driver, > :having command queuing and NCQ enabled, read and write disks with SATA > :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only > :with CAM, without using any part of ATA infrastructure. > : > :-- > :Alexander Motin > > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). CAM is being expanded to be a framework for scheduling, recovery, and topology management, agnostic to the transport and protocol being used. SPI and SCSI are being separated into transport and protocol modules, and Alexander has been amazing and kind enough to start a SATA transport and ATA protocol module. Unlike Linux, OpenBSD, or anything else out there, this is not a tacked-on library for speaking SCSI/SPI at the top level and then translating it to something else at a lower level. This is about speaking native SBP/RBP/ATA at the periph level and native SPI/PATA/SATA/FCAL/SMP/USB at the transport level. So, before you continue to cast ignorant doubts on our approach and hawk your incomplete wares, please at least look at what is being done on our end, and make an attempt to ask some reasonable questions. Scott From jkim at FreeBSD.org Fri Jun 5 18:59:18 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Jun 5 18:59:25 2009 Subject: [HEADSUP] ACPICA 20090521 imported on head Message-ID: <200906051459.05242.jkim@FreeBSD.org> I just committed ACPICA 20090521 on head. If you experience any regression after the commit, please let me know. Note it is little different from my usual patchsets, i.e., it does not include any enhancements. When everything is settled, I am going to commit the remaining patches as well. Cheers, Jung-uk Kim From dillon at apollo.backplane.com Fri Jun 5 19:17:40 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 5 19:17:50 2009 Subject: WIP: ATA to CAM integration References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> Message-ID: <200906051917.n55JHcLO077306@apollo.backplane.com> :CAM is being expanded to be a framework for scheduling, recovery, and :topology management, agnostic to the transport and protocol being used. :SPI and SCSI are being separated into transport and protocol modules, :and Alexander has been amazing and kind enough to start a SATA transport :and ATA protocol module. Unlike Linux, OpenBSD, or anything else out :there, this is not a tacked-on library for speaking SCSI/SPI at the top :level and then translating it to something else at a lower level. This :is about speaking native SBP/RBP/ATA at the periph level and native :SPI/PATA/SATA/FCAL/SMP/USB at the transport level. : :So, before you continue to cast ignorant doubts on our approach and hawk :your incomplete wares, please at least look at what is being done on our :end, and make an attempt to ask some reasonable questions. : :Scott Huh. Get up on the wrong side of the bed, Scott? Just remember who started making the shit comments this time. I have no interest with what FreeBSD is doing with CAM. My only interest vis-a-vie this thread are the AHCI driver efforts by the various BSDs, including ours. In particular, my interest is in NCQ, hot-plug support, and port multiplier support, as these three items can put SATA/AHCI on-par with dedicated SCSI controllers (at least once AHCI hardware revs past the original spec). It is something very important to all Open-Source OS projects as it consolidates the storage device driver spec and removes a huge thorn in the sides of all the projects with regards to the forward-support of new hardware. -- IMHO the only SCSI command non-SCSI devices have to fake-up is IDENTIFY. Everything else is a straight translation, and an easy one at that. Even SENSE doesn't need to be faked-up all that much, one just sets an AUTOSENSE flag bit and include the sense in the CCB. So interfacing to CAM is not really a big deal. The SCSI command set is the only cross-device portable command set that exists today, after all. The only problem I have with the original CAM is that it didn't use a dedicated thread for bus-reset/probe/scan/identify/attachment and detachment. That's the only reason the original API was such a bitch to deal with by device drivers. Fixing that fixes all the device interaction issues for attachment/detachment. The API doesn't actually change, but the recursive nature of the direct calls goes away and greatly simplifies device drivers. That's the only thing I see wrong with CAM, frankly. So I applaud your efforts on cleaning up the attach/detach stuff in FreeBSD, but it isn't my focus in this thread and not something I'm interested in doing for the DragonFly project, beyond what I mentioned above. Your comments are improper. -Matt Matthew Dillon From scottl at samsco.org Fri Jun 5 19:27:19 2009 From: scottl at samsco.org (Scott Long) Date: Fri Jun 5 19:27:31 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <4A29694B.2090606@elischer.org> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> Message-ID: <4A297187.2090701@samsco.org> Julian Elischer wrote: > Scott Long wrote: > >> >> So, before you continue to cast ignorant doubts on our approach and hawk >> your incomplete wares, please at least look at what is being done on our >> end, and make an attempt to ask some reasonable questions. >> > > I think that was a little of an over-reaction, and uncalled for.. > Matt's tone was very friendly. > > Every one of Matt's emails follow this formula: 1. I don't know how FOO works, but how you're doing it is wrong 2. Here's how I think FOO should work 3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. 1 and 2 are ignorant and worthless in a technical conversation, and 3 is off topic for FreeBSD mailing lists. So yes, I'm calling him out. Scott From scottl at samsco.org Fri Jun 5 19:28:38 2009 From: scottl at samsco.org (Scott Long) Date: Fri Jun 5 19:28:44 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <200906051917.n55JHcLO077306@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <200906051917.n55JHcLO077306@apollo.backplane.com> Message-ID: <4A2971DC.9060608@samsco.org> Matthew Dillon wrote: > :CAM is being expanded to be a framework for scheduling, recovery, and > :topology management, agnostic to the transport and protocol being used. > :SPI and SCSI are being separated into transport and protocol modules, > :and Alexander has been amazing and kind enough to start a SATA transport > :and ATA protocol module. Unlike Linux, OpenBSD, or anything else out > :there, this is not a tacked-on library for speaking SCSI/SPI at the top > :level and then translating it to something else at a lower level. This > :is about speaking native SBP/RBP/ATA at the periph level and native > :SPI/PATA/SATA/FCAL/SMP/USB at the transport level. > : > :So, before you continue to cast ignorant doubts on our approach and hawk > :your incomplete wares, please at least look at what is being done on our > :end, and make an attempt to ask some reasonable questions. > : > :Scott > > Huh. Get up on the wrong side of the bed, Scott? Just remember who > started making the shit comments this time. > > I have no interest with what FreeBSD is doing with CAM. If you have no interest with what FreeBSD is doing with CAM, then your discussion is off topic for this thread and this mailing list. Please take it somewhere more appropriate. Scott From dillon at apollo.backplane.com Fri Jun 5 19:48:46 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 5 19:48:53 2009 Subject: WIP: ATA to CAM integration References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> <4A297187.2090701@samsco.org> Message-ID: <200906051948.n55Jmh8X077810@apollo.backplane.com> :Every one of Matt's emails follow this formula: : :1. I don't know how FOO works, but how you're doing it is wrong :2. Here's how I think FOO should work :3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. : :1 and 2 are ignorant and worthless in a technical conversation, and 3 is :off topic for FreeBSD mailing lists. So yes, I'm calling him out. : :Scott Well, so far about the only one talking shit here is you, Scott. Insofar as 3. goes, I already provided references to that code, because the purpose is to share code. I wonder if you even bothered to look at it. Judging from your comments, I guess not. It isn't quite in the decrepit shape you make it out to be. I mean, come on, not even the ATA driver has hot-plug support (not without crashing, anyhow), and I would not characterize IT as being decrepit! It was simply a code reference, along with OpenBSD's code reference. For anyone writing a driver having multiple code references is always beneficial, it saves a lot of time and puts things in context. After all, OpenBSD's and Linux's AHCI driver is what really opened up the space for the rest of us. OpenBSD saved me at least 100 man-hours of work and Alex just now saved me another 8 or 9 at the cost of a 5 minute email. That seems to be a good use of the mailing lists in my view. I'm not above asking other driver writers for information that I do not have complete knowledge of. I learned a lot from Alexander Motin's posting with regards to port multipliers, enough that I am now quite comfortable in my ability to add the feature in my own work. Clearly I am not totally deficient in my knowledege since I actually did port the OpenBSD driver to DragonFly. As far as I can tell, I haven't said anything about anyone doing it wrong, certainly not with the tone your extremely jaded portrayal seems to be applying to my posting. I have my opinion and you have yours, but that's all it is... an opinion. My opinion is that the only portable device I/O command set available in the world today is the SCSI command set. There is no ulterior motive, it's just an opinion. I guess it is in the eye of the beholder. -Matt From brooks at freebsd.org Fri Jun 5 22:36:27 2009 From: brooks at freebsd.org (Brooks Davis) Date: Fri Jun 5 22:36:42 2009 Subject: RFT: Allow large values of NGROUPS_MAX Message-ID: <20090605223636.GA24364@lor.one-eyed-alien.net> Skipped content of type multipart/mixed-------------- 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/20090605/29b1c6be/attachment-0001.pgp From des at des.no Sat Jun 6 01:47:48 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Jun 6 01:47:57 2009 Subject: LOR between NFS and syncer Message-ID: <86skief8q6.fsf@ds4.des.no> Anyone seen this one before? NFS+ZFS server, diskless NFS client. Both run head. On the client: lock order reversal: 1st 0xc301c164 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 2nd 0xc322c058 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c07477c6,c2bbfa18,c05921c5,c058310b,c074a615,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c058310b,c074a615,c2cb0828,c2cb0688,c2bbfa74,...) at kdb_backtrace+0x29 _witness_debugger(c074a615,c322c058,c0759e62,c2cb0688,c0750f5e,...) at _witness_debugger+0x25 witness_checkorder(c322c058,9,c0750f5e,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c322c058,80500,c322c074,0,0,...) at __lockmgr_args+0x797 vop_stdlock(c2bbfb88,c2bbfb70,c0591f6b,c0750f5e,c073ced7,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c079d720,c2bbfb88,c0750f5e,c07b5100,c322c000,...) at VOP_LOCK1_APV+0xf3 _vn_lock(c322c000,80500,c0750f5e,823,df,...) at _vn_lock+0x5e vget(c322c000,80500,c2f1f480,c6e,c2f35c94,...) at vget+0xb9 vfs_msync(c2f35c94,2,c0750f5e,d67,c2f35c94,...) at vfs_msync+0xe7 sync_fsync(c2bbfc7c,c301c10c,80400,c0750f5e,69d,...) at sync_fsync+0x17b VOP_FSYNC_APV(c07975c0,c2bbfc7c,c0750f5e,69d,c2f1f480,...) at VOP_FSYNC_APV+0xda sync_vnode(c093d8f0,c093d8dc,3e8,6cc,4e20,...) at sync_vnode+0x168 sched_sync(0,c2bbfd38,c073fcec,334,c2ceea90,...) at sched_sync+0x273 fork_exit(c05d8570,0,c2bbfd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bbfd70, ebp = 0 --- DES -- Dag-Erling Sm?rgrav - des@des.no From peterjeremy at optushome.com.au Sat Jun 6 01:47:58 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Jun 6 01:48:10 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <4A297187.2090701@samsco.org> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> <4A297187.2090701@samsco.org> Message-ID: <20090606014745.GC9161@server.vk2pj.dyndns.org> On 2009-Jun-05 13:27:03 -0600, Scott Long wrote: >Every one of Matt's emails follow this formula: > >1. I don't know how FOO works, but how you're doing it is wrong >2. Here's how I think FOO should work >3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. > >1 and 2 are ignorant and worthless in a technical conversation, and 3 is >off topic for FreeBSD mailing lists. So yes, I'm calling him out. Well, I have seen little evidence of 1. 2 _can_ be relevant in an architectural discussion. 3 may or may not be relevant - it depends whether FreeBSD can make use of the work or not. I agree with Julian that you are being unnecessarily provocative. IMHO, Matt has made a positive contribution to this thread. Rather than quoting him out of context, how about you take a chill pill and consider what benefits FreeBSD can gain by reusing work done by other free Unices. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/5b20014f/attachment.pgp From yuri.pankov at gmail.com Sat Jun 6 02:45:57 2009 From: yuri.pankov at gmail.com (Yuri Pankov) Date: Sat Jun 6 02:46:03 2009 Subject: loader panics with 2 GPT partitioned drives Message-ID: <20090606021835.GC1077@darklight.homeunix.org> Hi, I'm getting the following "panic" from loader when trying to attach another GPT partitioned drive. loader is built using LOADER_ZFS_SUPPORT. BTX Loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 panic:free: guard1 fail @ 0x7fd4b3f4 from /usr/src/sys/boot/i386/libi386/biosdisk.c:1048 ad4: => 34 488397101 ad4 GPT (233G) 34 128 1 freebsd-boot (64K) 162 16777216 2 freebsd-swap (8.0G) 16777378 471619757 3 freebsd-zfs (225G) ad10: empty disk, `gpart create -s GPT ad10` Yuri From chat95 at mac.com Sat Jun 6 03:02:17 2009 From: chat95 at mac.com (Maho NAKATA) Date: Sat Jun 6 03:02:30 2009 Subject: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] In-Reply-To: <20090527134343.GB1104@bsdcrew.de> References: <20090527134343.GB1104@bsdcrew.de> Message-ID: <20090606.120001.68053946.chat95@mac.com> I did a benchmark with Virtualbox: My environment: * Core 2 Quad, Q6600@3GHz * Windows XP SP3@host SP2@VBOX with GuestAddon * http://crystalmark.info/software/CrystalMark/ CrystalMark 2004R3 * Sapphire X1650 * VBOX is running on FBSD7.2-REL/amd64 using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz * Running with fullscreen mode 1280x1024 32bit Here is the result ----------------------------------------- host(4CPU) host(1CPU) vbox(1CPU) Mark 173047 90925 86496 ALU 50985 13493 13060 FPU 63746 15126 15323 MEM 21822 25582 16516 HDD 9336 9331 30600(*) GDI 15153 15195 5127 D2D 5997 5998 5108 OGL 6200 6200 762 ----------------------------------------- (*)somehow lot faster I don't know how to use two CPUs, even changing setting doesn't change. Usually I cannot usually launch VirtualBox even by root. A workaround is that invoking and killing VirtualBox many times for me. After some tries I can launch... thanks From: Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 Date: Wed, 27 May 2009 15:43:43 +0200 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Howdy, > > First of all sorry for all unanswered mails, I got a stupid flu, > but now i feel better... ok now back to vbox, time for a new call > for testing :-) > > Following was added/fixed: > > - - ACPI Support was added > - - hostDVD support was added > - - Fix startup on HEAD > - - Plist problem under AMD64 was fixed > - - Qt4 Frontend is now Optional > - - Desktop file was added > - - Xorg dependencies was fixed > - - Guest additions was added (thx to Maho NAKATA ) > > Open task: > We have got 2 patches for nls support and the request > to make dbus and pulseaudio optional. These both will > be added with the next run. > > We'd like to say many many thanks for all your feedback. > > http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz > > Happy Testing :-) > > > > - -- > > +-----------------------+-------------------------------+ > | 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) > > iEYEARECAAYFAkodQ48ACgkQdLJIhLHm/OmjfQCfR6Zczz0XcZZpAYie64D2G0Ti > wwQAn2r0W/12iidjOfgvX05QPNQX1oUc > =b8tt > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/94f2f9d7/attachment.pgp From mcdouga9 at egr.msu.edu Sat Jun 6 03:53:15 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sat Jun 6 03:53:22 2009 Subject: Possible to boot using gptzfsboot and a 'raid 10' in ZFS? Message-ID: <4A29E825.3010100@egr.msu.edu> Should it be possible to boot from zpool consisting of a striped set of mirrors using gptzfsboot? Using a FreeBSD 7.2 post-v13 ZFS cd or the 200905 8.0 snapshot, neither let me set the bootfs zpool property to a pool that is a 8 disk mirror. If I manage to get zpool to let me set it, will gptzfsboot work with it anyway? Knowing that gptzfsboot can boot from a single disk, mirror, raidz, and raidz2, it didn't enter my mind that a raid10 might not work until I just tried it tonight. Thanks for input. Also thanks for the existing code! From mcdouga9 at egr.msu.edu Sat Jun 6 05:46:08 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sat Jun 6 05:46:15 2009 Subject: Possible to boot using gptzfsboot and a 'raid 10' in ZFS? In-Reply-To: <4A29E825.3010100@egr.msu.edu> References: <4A29E825.3010100@egr.msu.edu> Message-ID: <4A2A029E.50407@egr.msu.edu> Adam McDougall wrote: > Should it be possible to boot from zpool consisting of a striped set > of mirrors using gptzfsboot? Using a FreeBSD 7.2 post-v13 ZFS cd or > the 200905 8.0 snapshot, neither let me set the bootfs zpool property > to a pool that is a 8 disk mirror. If I manage to get zpool to let me > set it, will gptzfsboot work with it anyway? Knowing that gptzfsboot > can boot from a single disk, mirror, raidz, and raidz2, it didn't > enter my mind that a raid10 might not work until I just tried it > tonight. Thanks for input. Also thanks for the existing code! > _______________________________________________ > 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" > Oops sorry, the answer is probably in this mail below, I didn't realize it was so recent. I'm not in a rush since most of my systems will be a standard mirror which I already know works. Date: 05/27/09 From: Doug Rabson ... This is a limitation which I will remove as soon as I have a little time to work on it. ... I will simply remove this limitation for FreeBSD since we can now boot from any pool configuration. From scottl at samsco.org Sat Jun 6 06:44:34 2009 From: scottl at samsco.org (Scott Long) Date: Sat Jun 6 06:44:41 2009 Subject: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] In-Reply-To: <20090606.120001.68053946.chat95@mac.com> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> Message-ID: <4A2A1048.5090101@samsco.org> Maho NAKATA wrote: > I did a benchmark with Virtualbox: > > My environment: > * Core 2 Quad, Q6600@3GHz > * Windows XP SP3@host SP2@VBOX with GuestAddon > * http://crystalmark.info/software/CrystalMark/ > CrystalMark 2004R3 > * Sapphire X1650 > * VBOX is running on FBSD7.2-REL/amd64 > using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz > * Running with fullscreen mode 1280x1024 32bit > Here is the result > ----------------------------------------- > host(4CPU) host(1CPU) vbox(1CPU) > Mark 173047 90925 86496 > ALU 50985 13493 13060 > FPU 63746 15126 15323 > MEM 21822 25582 16516 > HDD 9336 9331 30600(*) > GDI 15153 15195 5127 > D2D 5997 5998 5108 > OGL 6200 6200 762 > ----------------------------------------- > (*)somehow lot faster > > I don't know how to use two CPUs, even changing setting > doesn't change. > > Usually I cannot usually launch VirtualBox even by root. > A workaround is that invoking and killing VirtualBox > many times for me. After some tries I can launch... > > thanks > I take it that you're running freebsd on the "bare metal" in your 4CPU and 1CPU tests, and running WinXP on the bare metal in the vbox test? If so, are you using ATA disks and the ATA driver for all instances of FreeBSD? If so, then the lack of NCQ in the FreeBSD ATA driver would explain the HDD test result. I see similar results with VMWare. Scott From lists at yamagi.org Sat Jun 6 07:39:09 2009 From: lists at yamagi.org (Yamagi Burmeister) Date: Sat Jun 6 07:39:15 2009 Subject: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] In-Reply-To: <20090606.120001.68053946.chat95@mac.com> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> Message-ID: <20090606072041.GC1581@yamagi.org> Hello, > Usually I cannot usually launch VirtualBox even by root. > A workaround is that invoking and killing VirtualBox > many times for me. After some tries I can launch... maybe this workaround helps (as user, not as root): 1. Launch VirtualBox. 2. If it fails open top(1) 3. In top(1) you should see 2(!) processes "VirtualBox" 4. Kill one of them 5. The other one should start This works for me in 9 out of 10 times and is much more comfortable than killing and restarting the whole programm many times. -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/a3e86114/attachment.pgp From chat95 at mac.com Sat Jun 6 09:14:04 2009 From: chat95 at mac.com (Maho NAKATA) Date: Sat Jun 6 09:14:22 2009 Subject: Two VirtualBox processes and do not launch VirtualBox: kill one of them. In-Reply-To: <20090606072041.GC1581@yamagi.org> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <20090606072041.GC1581@yamagi.org> Message-ID: <20090606.181144.193792508.chat95@mac.com> From: Yamagi Burmeister Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 09:20:42 +0200 > Hello, > >> Usually I cannot usually launch VirtualBox even by root. >> A workaround is that invoking and killing VirtualBox >> many times for me. After some tries I can launch... > > maybe this workaround helps (as user, not as root): > 1. Launch VirtualBox. > 2. If it fails open top(1) > 3. In top(1) you should see 2(!) processes "VirtualBox" > 4. Kill one of them > 5. The other one should start > This works for me in 9 out of 10 times and is much more comfortable > than killing and restarting the whole programm many times. Hi Yamagi-san, This workaround works well for me. Many thanks!! Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/f8ac066b/attachment.pgp From chat95 at mac.com Sat Jun 6 09:15:18 2009 From: chat95 at mac.com (Maho NAKATA) Date: Sat Jun 6 09:15:25 2009 Subject: Benchmark In-Reply-To: <4A2A1048.5090101@samsco.org> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <4A2A1048.5090101@samsco.org> Message-ID: <20090606.181302.112520754.chat95@mac.com> From: Scott Long Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 00:44:24 -0600 > Maho NAKATA wrote: >> I did a benchmark with Virtualbox: >> My environment: >> * Core 2 Quad, Q6600@3GHz >> * Windows XP SP3@host SP2@VBOX with GuestAddon >> * http://crystalmark.info/software/CrystalMark/ >> CrystalMark 2004R3 >> * Sapphire X1650 >> * VBOX is running on FBSD7.2-REL/amd64 >> using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz >> * Running with fullscreen mode 1280x1024 32bit >> Here is the result >> ----------------------------------------- >> host(4CPU) host(1CPU) vbox(1CPU) >> Mark 173047 90925 86496 >> ALU 50985 13493 13060 >> FPU 63746 15126 15323 >> MEM 21822 25582 16516 >> HDD 9336 9331 30600(*) >> GDI 15153 15195 5127 >> D2D 5997 5998 5108 >> OGL 6200 6200 762 >> ----------------------------------------- >> (*)somehow lot faster >> I don't know how to use two CPUs, even changing setting >> doesn't change. >> Usually I cannot usually launch VirtualBox even by root. >> A workaround is that invoking and killing VirtualBox >> many times for me. After some tries I can launch... >> thanks >> > > I take it that you're running freebsd on the "bare metal" in your 4CPU > and 1CPU tests, and running WinXP on the bare metal in the vbox test? yes. > If so, are you using ATA disks and the ATA driver for all instances I use SATA for host machine and ATA as VirtualBox machine. > of FreeBSD? If so, then the lack of NCQ in the FreeBSD ATA driver > would > explain the HDD test result. I see similar results with VMWare. Ok, I see Thanks for your clarification. Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/331f2a74/attachment.pgp From olivier at gid0.org Sat Jun 6 09:36:42 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Sat Jun 6 09:36:50 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: References: Message-ID: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> 2009/5/4 Eygene Ryabinkin : > Good day. > > Recently I had filed a PR, > ?http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 > that should heal the situation when estX isn't attached properly > on the half of processor cores (the odd ones). ?I am seeing this > only on Asus MBs, but this could show up on other hardware as well. > > If anyone sees such symptoms, I encourage them to test the patch. > The patch itself contained in the PR, but for ease I had put it > there, > ?http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > and will sync PR's one and this one in the case of any changes. Hello, Your patch was working great on my Asus P5Q3. But the problem has been solved more permanently on -CURRENT with the import of ACPICA 20090521 (r193529-193531). Thanks ! > -- > Eygene > ?_ ? ? ? ? ? ? ? ?___ ? ? ? _.--. ? # > ?\`.|\..----...-'` ? `-._.-'_.-'` ? # ?Remember that it is hard > ?/ ?' ` ? ? ? ? , ? ? ? __.--' ? ? ?# ?to read the on-line manual > ?)/' _/ ? ? \ ? `-_, ? / ? ? ? ? ? ?# ?while single-stepping the kernel. > ?`-'" `"\_ ?,_.-;_.-\_ ', ?fsc/as ? # > ? ? _.-'_./ ? {_.' ? ; / ? ? ? ? ? # ? ?-- FreeBSD Developers handbook > ? ?{_.-``-' ? ? ? ? {_/ ? ? ? ? ? ?# > _______________________________________________ > 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" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From freebsd at abv.bg Sat Jun 6 09:41:01 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sat Jun 6 09:41:11 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 4 Message-ID: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> Hi, thanks a lot for that fix it worked for me, please find attached the patch file, slightly modified so it can be successfully applied the good news is that when I loaded the module it didn't panic, I was even able to run VirtualBox ...I created a virtual machine for windows xp and started the installation...but the virtual machine crashes after the windows installer loads all drivers and tries to start the actual installation and I can see this at the bottom of the vbox log ========================================================================================================================== 00:00:57.770 !!Assertion Failed!! 00:00:57.770 Expression: u64Now <= pNext->u64Expire 00:00:57.770 Location : /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/VMM/TM.cpp(1899) void tmR3TimerQueueRunVirtualSync(VM*) ========================================================================================================================== and this is what I see in /var/log/messages ========================================================================================================================== Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: pszName=vboxdrv0 ppDev=0xffffff807742f628 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: pszName=vboxdrv0 iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: clone_create -> 1; iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: Created *ppDev=0xffffff003235b400 iUnit=0 si_drv1=0 si_drv2=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDOpen: fOpen=0x3 iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005682 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / -37 ulCmd=20005697 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home last message repeated 4 times Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005697 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home last message repeated 5 times Jun 6 11:39:17 home kernel: HWACCMR0InitVM: ffffff80776bf000 Jun 6 11:40:11 home kernel: pid 18802 (VirtualBox), uid 0: exited on signal 5 (core dumped) Jun 6 11:40:11 home kernel: VBoxDrvFreeBSDClose: fFile=0x3 iUnit=0 pSession=0xffffff000890e010 Jun 6 11:40:11 home kernel: HWACCMR0TermVM: ffffff80776bf000 ========================================================================================================================== Has someone successfully installed windows xp on VirtualBox ? regards, mgp P.S. it would be great if I could install windows so I could finally play StarCraft! :) >> Hi, >> I've tried http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz out... >> ?- it compiles fine (except for the iso I had to download manually) >> ?- it panics when I try to load the kernel module, first I tried to load it with X running and the second time I tried to load it without X running, please find attached the output. >> >> about my machine: >> $ uname -a >> FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #7: Thu May 28 01:24:11 EEST 2009 ? ? mgp@mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE ?amd64 >> >> and also ports updated from 28th of May >> >> regards, >> mgp >> _______________________________________________ >> 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" >> > >The following patch fixes this issue for me. > >--- semevent-r0drv-freebsd.c.old 2009-06-05 12:48:55.841136475 +0200 >+++ semevent-r0drv-freebsd.c 2009-06-05 12:15:08.610705499 +0200 >@@ -181,7 +181,7 @@ > rc = tsleep(pEventInt, /* block id */ > fInterruptible ? PZERO | PCATCH : PZERO, > "iprtev", >- tvtohz(&tv)); >+ cMillies == RT_INDEFINITE_WAIT ? 0 : tvtohz(&tv)); > mtx_lock_spin(&pEventInt->Mtx); > >Regards, >Jacques > -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-src-VBox-Runtime-r0drv-freebsd-semevent-r0drv-freebsd.c Type: application/octet-stream Size: 536 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090606/daf5d55f/patch-src-VBox-Runtime-r0drv-freebsd-semevent-r0drv-freebsd.obj From serenity at exscape.org Sat Jun 6 09:42:47 2009 From: serenity at exscape.org (Thomas Backman) Date: Sat Jun 6 09:42:54 2009 Subject: Benchmark In-Reply-To: <20090606.181302.112520754.chat95@mac.com> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <4A2A1048.5090101@samsco.org> <20090606.181302.112520754.chat95@mac.com> Message-ID: <83893B64-0AA4-4705-99F1-19D8F1D1C0DF@exscape.org> On Jun 6, 2009, at 11:13 AM, Maho NAKATA wrote: > From: Scott Long > Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for > FreeBSD! take 4] > Date: Sat, 06 Jun 2009 00:44:24 -0600 > >> Maho NAKATA wrote: >>> I did a benchmark with Virtualbox: >>> My environment: >>> * Core 2 Quad, Q6600@3GHz >>> * Windows XP SP3@host SP2@VBOX with GuestAddon >>> * http://crystalmark.info/software/CrystalMark/ >>> CrystalMark 2004R3 >>> * Sapphire X1650 >>> * VBOX is running on FBSD7.2-REL/amd64 >>> using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz >>> * Running with fullscreen mode 1280x1024 32bit >>> Here is the result >>> ----------------------------------------- >>> host(4CPU) host(1CPU) vbox(1CPU) >>> [...] >>> HDD 9336 9331 30600(*) >>> ----------------------------------------- >>> (*)somehow lot faster >>> I don't know how to use two CPUs, even changing setting >>> doesn't change. >>> Usually I cannot usually launch VirtualBox even by root. >>> A workaround is that invoking and killing VirtualBox >>> many times for me. After some tries I can launch... >>> thanks >>> I've seen similar crazy results in VMware Fusion. I reckon it has something to do with sparse disks *in my case*, at least. I ran HD Tune in a Windows VM, and got ~600MB/s out of a 5400rpm laptop hard drive. Natively, I get about 35MB/s, go figure. :) Regards, Thomas From kostikbel at gmail.com Sat Jun 6 11:52:01 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Jun 6 11:52:08 2009 Subject: LOR between NFS and syncer In-Reply-To: <86skief8q6.fsf@ds4.des.no> References: <86skief8q6.fsf@ds4.des.no> Message-ID: <20090606115154.GI1927@deviant.kiev.zoral.com.ua> On Sat, Jun 06, 2009 at 03:32:01AM +0200, Dag-Erling Sm??rgrav wrote: > Anyone seen this one before? > > NFS+ZFS server, diskless NFS client. Both run head. On the client: > > lock order reversal: > 1st 0xc301c164 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 > 2nd 0xc322c058 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper(c07477c6,c2bbfa18,c05921c5,c058310b,c074a615,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c058310b,c074a615,c2cb0828,c2cb0688,c2bbfa74,...) at kdb_backtrace+0x29 > _witness_debugger(c074a615,c322c058,c0759e62,c2cb0688,c0750f5e,...) at _witness_debugger+0x25 > witness_checkorder(c322c058,9,c0750f5e,823,0,...) at witness_checkorder+0x839 > __lockmgr_args(c322c058,80500,c322c074,0,0,...) at __lockmgr_args+0x797 > vop_stdlock(c2bbfb88,c2bbfb70,c0591f6b,c0750f5e,c073ced7,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c079d720,c2bbfb88,c0750f5e,c07b5100,c322c000,...) at VOP_LOCK1_APV+0xf3 > _vn_lock(c322c000,80500,c0750f5e,823,df,...) at _vn_lock+0x5e > vget(c322c000,80500,c2f1f480,c6e,c2f35c94,...) at vget+0xb9 > vfs_msync(c2f35c94,2,c0750f5e,d67,c2f35c94,...) at vfs_msync+0xe7 > sync_fsync(c2bbfc7c,c301c10c,80400,c0750f5e,69d,...) at sync_fsync+0x17b > VOP_FSYNC_APV(c07975c0,c2bbfc7c,c0750f5e,69d,c2f1f480,...) at VOP_FSYNC_APV+0xda > sync_vnode(c093d8f0,c093d8dc,3e8,6cc,4e20,...) at sync_vnode+0x168 > sched_sync(0,c2bbfd38,c073fcec,334,c2ceea90,...) at sched_sync+0x273 > fork_exit(c05d8570,0,c2bbfd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc2bbfd70, ebp = 0 --- We lock the covered vnode when doing mount or unmount for the non-root filesystem. Since witness works by recording order by lock name, we get the order of mounted on -> mounted from vnode type. Thus, any interleave in the mount type would give us a LOR. The vnode list for the mount point also includes syncer vnode, that has a special fsync vop. Usual order is syncer vnode lock -> vnode lock for the real vnodes. But, when filesystem is unmounted, we get the order covered vnode -> any filesystem vnode during sync before unmount. This one gives the LOR you reported, assuming you unmounted nfs share mounted on the top of nfs share. I think both issues cannot result in a deadlock. -------------- 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/20090606/18ca6a66/attachment.pgp From villa.alberto at gmail.com Sat Jun 6 12:44:25 2009 From: villa.alberto at gmail.com (Alberto Villa) Date: Sat Jun 6 12:44:57 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 4 In-Reply-To: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> References: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> Message-ID: <200906061444.21080.villa.alberto@gmail.com> On Saturday 06 June 2009 11:40:58 Mario Pavlov wrote: > Has someone successfully installed windows xp on VirtualBox ? i have, on i386 with 7.2-stable, and it's perfect and incredibly fast! -- Alberto Villa From rea-fbsd at codelabs.ru Sat Jun 6 13:05:09 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sat Jun 6 13:05:16 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> References: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> Message-ID: Olivier, good day. Sat, Jun 06, 2009 at 11:36:39AM +0200, Olivier SMEDTS wrote: > 2009/5/4 Eygene Ryabinkin : > > If anyone sees such symptoms, I encourage them to test the patch. > > The patch itself contained in the PR, but for ease I had put it > > there, > > ?http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > > and will sync PR's one and this one in the case of any changes. > > Your patch was working great on my Asus P5Q3. But the problem has been > solved more permanently on -CURRENT with the import of ACPICA 20090521 > (r193529-193531). Yes, I already know it, thanks for mentioning this to the list. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From des at des.no Sat Jun 6 15:11:49 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Jun 6 15:11:57 2009 Subject: LOR between NFS and syncer In-Reply-To: <20090606115154.GI1927@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Sat, 6 Jun 2009 14:51:54 +0300") References: <86skief8q6.fsf@ds4.des.no> <20090606115154.GI1927@deviant.kiev.zoral.com.ua> Message-ID: <86ab4lflb8.fsf@ds4.des.no> Kostik Belousov writes: > The vnode list for the mount point also includes syncer vnode, that > has a special fsync vop. Usual order is syncer vnode lock -> vnode > lock for the real vnodes. But, when filesystem is unmounted, we get > the order covered vnode -> any filesystem vnode during sync before > unmount. This one gives the LOR you reported, assuming you unmounted > nfs share mounted on the top of nfs share. No, the LOR occurred during boot. DES -- Dag-Erling Sm?rgrav - des@des.no From kitchetech at gmail.com Sat Jun 6 15:33:12 2009 From: kitchetech at gmail.com (matt donovan) Date: Sat Jun 6 15:33:19 2009 Subject: what does this mean? In-Reply-To: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> References: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> Message-ID: <28283d910906060801p1e1941b5pcf0bc2ea122a6255@mail.gmail.com> On Sat, Jun 6, 2009 at 10:03 AM, dan hirsch wrote: > 1. > > Running the csup(1)< > http://www.freebsd.org/cgi/man.cgi?query=csup&sektion=1>command > later will download and apply all the recent changes to your Ports > Collection, except actually rebuilding the ports for your own system. > > > > -- > regards, > Dan Hirsch > Linked-In: http://www.linkedin.com/in/danhirsch1 > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > exactly as it states it will update your port tree but will not rebuild and install ports that need updating. From francklarchange at free.fr Sat Jun 6 15:33:16 2009 From: francklarchange at free.fr (Franck Royer) Date: Sat Jun 6 15:33:31 2009 Subject: Attansic L1e Gigabit Ethernet driver support Message-ID: <4A2A878D.30203@free.fr> Hi, I have an Acer Aspire 6930 and I'm using the freebsd 8.0-CURRENT branch (the 2009-05) on amd64. As said in the topic, I have a network card Attansic L1e Gigabit Ethernet which is not recognize by the GENERIC kernel and current age/ale drivers. I'd like to know what is the current solution to make it works because I saw different solutions. I'll probably try this one : http://daemonforums.org/showthread.php?t=2244 (patching the ale driver, but for now I'm waiting for the end of the download of my freebsd dvd cause of course I need the kernel sources to compile it). I can give my dmesg messages but it's not obvious (cause I doing a zfs only installation, it is why I took the current, and my other installed system is a ubuntu without zfs support :/). Cheers, Franck From freebsd at abv.bg Sat Jun 6 16:37:31 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sat Jun 6 16:37:44 2009 Subject: ACPI problem with new acer aspire 6930G Message-ID: <1823042729.128315.1244306247806.JavaMail.apache@mail52.abv.bg> Hi, this is a known issue there is an open PR about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 regards, Mario >Hi. >I have a problem with ale support on 7.2-RELEASE and 8.0-CURRENT. >I get on dmesg: > >ale0: irq 17 at device 0.0 on pci9 >ale0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >ale0: cannot allocate memory resources. >device_attach: ale0 attach returned 6 > >When i boot freebsd in safe mode ale starts correctly (but gets no >link), but i get all the time: >"interrupt storm detected on "irq10:"; throttling interrupt source" errors. > >Can anyone help solve the issue? >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From yuri.pankov at gmail.com Sat Jun 6 17:52:18 2009 From: yuri.pankov at gmail.com (Yuri Pankov) Date: Sat Jun 6 17:52:24 2009 Subject: loader panics with 2 GPT partitioned drives In-Reply-To: <20090606021835.GC1077@darklight.homeunix.org> References: <20090606021835.GC1077@darklight.homeunix.org> Message-ID: <20090606175158.GA1080@darklight.homeunix.org> On Sat, Jun 06, 2009 at 06:18:35AM +0400, Yuri Pankov wrote: > Hi, > > I'm getting the following "panic" from loader when trying to attach > another GPT partitioned drive. loader is built using LOADER_ZFS_SUPPORT. > > BTX Loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > > panic:free: guard1 fail @ 0x7fd4b3f4 from > /usr/src/sys/boot/i386/libi386/biosdisk.c:1048 > > > ad4: > => 34 488397101 ad4 GPT (233G) > 34 128 1 freebsd-boot (64K) > 162 16777216 2 freebsd-swap (8.0G) > 16777378 471619757 3 freebsd-zfs (225G) > > ad10: > empty disk, `gpart create -s GPT ad10` > > > > Yuri Looks like there are no checks in loader with GPT support if there are no partitions defined (very rare case, but still.. :-). Attached patch fixes booting with GPT disk without partitions (for me). Yuri -------------- next part -------------- Index: biosdisk.c =================================================================== --- biosdisk.c (revision 193589) +++ biosdisk.c (working copy) @@ -990,7 +990,8 @@ out: if (error) { - free(od->od_partitions); + if (od->od_nparts > 0) + free(od->od_partitions); od->od_flags &= ~BD_GPTOK; } return (error); @@ -1044,7 +1045,7 @@ delay(3000000); #endif #ifdef LOADER_GPT_SUPPORT - if (od->od_flags & BD_GPTOK) + if (od->od_flags & BD_GPTOK && od->od_nparts > 0) free(od->od_partitions); #endif free(od); From erik at cederstrand.dk Sat Jun 6 19:28:02 2009 From: erik at cederstrand.dk (Erik Cederstrand) Date: Sat Jun 6 19:28:15 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <4A27F105.4040109@freebsd.org> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> <4A27F105.4040109@freebsd.org> Message-ID: <686A733E-2F33-4C40-A516-7D3A8E5E431E@cederstrand.dk> Den 04/06/2009 kl. 18.06 skrev Tim Kientzle: > Erik Cederstrand wrote: >> LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but "it >> doesn't interact correctly with conventional nm/ar/etc" (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html >> ). > > In what way does it not interact correctly? There was not much more help to get from the Clang list, unfortunately. The code lives at http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-ld/ and looks very well-documented and structured. Unfortunately, it is a bit over my head to see what needs to be fixed and actually fix it. Thanks, Erik From mav at mavhome.dp.ua Fri Jun 5 16:54:36 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Sat Jun 6 21:20:31 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> Message-ID: <4A294DC3.5010008@mavhome.dp.ua> Hi. Matthew Dillon wrote: > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). I think ATAPI disk device is theoretically possible, but I believe it does not exist in practice, as industry do not need it. It will become SCSI disk opponent from commands PoV, but with all ATA interface ugly growth problems. And I am not sure that it will have more benefits then contras comparing to SCSI or plain ATA. When I was talking about common CAM layer, I was directly speaking that there will be _no_command_translation_ for ATA disks! There will be separate native ATA disk driver withing CAM infrastructure. > The second biggest issue is that it is really unclear to me how the > hell one probes an ATAPI device for NCQ support. The OpenBSD driver > only uses AHCI-NCQ for DISK attachments, where the NCQ support is > returned in the IDENTIFY command. I'm sure there must be a way to > probe an ATAPI device for NCQ support but I don't know what it is. I have never seen opposite, and I believe that NCQ is just not implemented for ATAPI devices. NCQ requires different ATA commands usage for ATA disk drives and that makes drive to behave very different on FIS level. NCQ uses First Party DMA and special command completion FISes, that IMHO just not implemented for ATA PACKET command. > The OpenBSD driver does not have port multiplier support but adding > it to the DFly driver will be pretty easy... I just need some hardware > to test it with (it's on the way). Unfortunately the AHCI-1.0 > specfication says it cannot be used for high-performance multi-disk > I/O because all parallel commands in operation are only allowed to go > to a single target at a time. i.e. you can't mix parallel commands > to different targets on the same port. That's a serious problem. > > (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything > about that?). Latest AHCI specifications define feature named FIS Based Switching. It allows controller independently track state of every device beyond port multiplier. It should be quite easy to use it, but actually none of my controllers have that capability. > It is unclear to me from reading the specification as to whether > AHCI-NCQ is supported for SATA ATAPI attachments. If anyone has an > answer to that I'm looking for a way to probe the device's > max-commands for ATAPI. for DISKs the IDENTIFY command has the > necessary feature bits and information. I'm sure the host controller > supports it natively but the real question is how to probe > the capability on the attached device and whether the device(s) > support it. ATAPI devices have their own equivalent of ATA IDENTIFY command. > Ultimately the best way to expand-out an AHCI interface is with > SCSI pass-through over ATAPI, assuming NCQ can be supported somehow. > The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0 > spec). It is a bit annoying, actually, I wouldn't have though that > Intel would have made such a basic mistake. All they had to do was > implement 4 bits in the FIS and the problem would have been solved. > Instead they have routing bits in a port register. Sigh. Latest AHCI specifications are definitely better, but now we have a lot of hardware conforming early 1.0 and 1.1 revisions. -- Alexander Motin From mav at mavhome.dp.ua Fri Jun 5 16:58:33 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Sat Jun 6 21:20:40 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <200906051601.n55G10Mi075734@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> Message-ID: <4A294EAF.3080706@mavhome.dp.ua> Matthew Dillon wrote: > It's unclear to me what this means. Can we use NCQ to queue multiple > commands to multiple ports behind a single port multiplier in parallel > or can't we? It's very confusing. As I have said, without controller FIS Based Switching capability it is impossible. FBS defines separate memory areas for controller, to track there state of each drive behind PM. Without it, only one drive can be active at a time, as controller will not be able to track when each drive is able to receive next command.. -- Alexander Motin From brde at optusnet.com.au Sat Jun 6 12:48:16 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Jun 6 21:21:40 2009 Subject: RFT: Allow large values of NGROUPS_MAX In-Reply-To: <20090605223636.GA24364@lor.one-eyed-alien.net> References: <20090605223636.GA24364@lor.one-eyed-alien.net> Message-ID: <20090606184344.N16744@delplex.bde.org> On Fri, 5 Jun 2009, Brooks Davis wrote: > I've been working on fixing the limit of 15 groups per user. This has > primarily consisted of merging a patch from Isilon Systems which breaks > the group array out of struct ucred and stores in in malloc'd storage. > > I've attached a patch which includes that change and increases the value > of NGROUPS_MAX to 32767. It also changes references to cr_groups[0] to > use the cr_gid macro ... I don't like this macro. At least the implementation should keep using the unobfuscated reference. kern_prot.c consistently didn't use the obfuscation except once in a comment. > Before any merge a couple decisions need to be made: > > - How large should NGROUPS_MAX be? Linux uses 65536 and we could > extend things to support that, but it's probably unnecessary. 32767 seems excessive too. Hopefully NGROUPS[_MAX] is used only in broken unconverted applications so a large value rarely wastes space. > - Should we make any attempt to support old binaries when there > are more than 16 groups? There is no way to support broken old binaries. They will have a limit of 16. > The POSIX getgroups/setgroups APIs did not > anticipate this change and thus either will fail outright. No, as you explained in previous mail, POSIX anticipated this perfectly unusably by making NGROUPS_MAX a Runtime Increasable Value despite it being constant. This puts the burden of not failing on applications. Only broken apps that don't do any of dynamic allocation using sysconf(_SC_NGROUPS_MAX), or dynamic allocation using getgroups(0, ...), or dynamic allocation after failing using getgroups(old_NGROUPS_MAX, ...) will fail outright. > We can't > fix setgroups, but we might want to make an optional accommodation for > getgroups to allow for truncated returns to old code. If done unconditionally, this would break the unbroken apps that do dynamic allocation after failing using getgroups(old_NGROUPS_MAX, ...). These apps depend on getgroups() failing with the Standard and documented errno EINVAL when the `gidsetlen' parameter is too small. Maybe some per-app or per-environment branding could be used to configure not generating an error. You would apply it only where security is not very important. getgrouplist(3) guarantees filling of the array when the array is too small. getgroups(2) doesn't guarantee anything, and in fact doesn't fill the array. It wouldn't hurt to fill it. % ... % diff -ru --exclude='.glimpse*' --exclude=.svn --exclude=compile --ignore-matching='$FreeBSD' /usr/src/sys/kern/kern_prot.c ngroups/sys/kern/kern_prot.c % --- /usr/src/sys/kern/kern_prot.c 2009-06-05 15:33:50.000000000 -0500 % +++ ngroups/sys/kern/kern_prot.c 2009-06-05 16:02:28.000000000 -0500 % @@ -243,16 +246,11 @@ % % td->td_retval[0] = td->td_ucred->cr_rgid; % #if defined(COMPAT_43) % - td->td_retval[1] = td->td_ucred->cr_groups[0]; % + td->td_retval[1] = td->td_ucred->cr_gid; % #endif % return (0); % } % % -/* % - * Get effective group ID. The "egid" is groups[0], and could be obtained % - * via getgroups. This syscall exists because it is somewhat painful to do % - * correctly in a library function. % - */ % #ifndef _SYS_SYSPROTO_H_ % struct getegid_args { % int dummy; This comment still seems to apply. I wonder if you noticed and/or fixed the related off-by-1 errors in getgroups() and {NGROUPS_MAX}: POSIX.1-2001-draft7 says: % 16834 IDs of the calling process. It is implementation-defined whether getgroups( ) also returns the % 16835 effective group ID in the grouplist array. FreeBSD does return the egid in the array, always as the first element. Neither of these details is documented in getgroups.2 or setgroups.2. Even the implementation doesn't seem to understand this where it is most important -- the implementation of setgroups() seems to be missing some of the things done by setegid(). getgrouplist(3) has explicit support for the egid being in both the initial and final lists (or missing in the initial list?). % ... % 16841 If the effective group ID of the process is returned with the supplementary group IDs, the value % 16842 returned shall always be greater than or equal to one and less than or equal to the value of % 16843 {NGROUPS_MAX}+1. This and probably other things indicate that _supplementary_ actually means supplementary -- it doesn't count the egid. But in FreeBSD, the egid is counted. This gives 2 off-by-1 errors that partially compensate for each other: - NGROUPS_MAX is 15, not 16, since it is impossible to have 16 _supplementary_ groups in cr_groups[0..15] after using cr_groups[0] for the egid - getgroups() cannot return {NGROUPS_MAX}+1 as is needed for it to return the egid plus {NGROUPS_MAX} supplementary groups - getgroups() does return {NGROUPS_MAX}+1 once {NGROUPS_MAX} is corrected. Some userland code depends on these bugs -- the static array size should be NGROUPS_MAX + 1, but it is typically plain NGROUPS. OTOH, libc/gen/initgroups.c uses NGROUPS + 1 and getgrouplist() followed by setgroups(). I think getgrouplist() can produce the extra 1 and then setgroups() and thus initgroups() will fail. I thought again about making cr_gid separate from the array, so that it can be named cr_gid without obfuscation. This wouldn't be good since it would complicate more than the copyin/out in get/setgroups() -- there are a few temporary gid arrays, and some iterations over the arrays that want to see the egid. Bruce From hirsh.dan at gmail.com Sat Jun 6 14:29:14 2009 From: hirsh.dan at gmail.com (dan hirsch) Date: Sat Jun 6 21:23:06 2009 Subject: what does this mean? Message-ID: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> 1. Running the csup(1)command later will download and apply all the recent changes to your Ports Collection, except actually rebuilding the ports for your own system. -- regards, Dan Hirsch Linked-In: http://www.linkedin.com/in/danhirsch1 From nox at jelal.kn-bremen.de Sat Jun 6 16:43:25 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Jun 6 21:27:58 2009 Subject: flash10 vs f10; em(4) now broken in -current in qemu/vbox Message-ID: <20090606162235.GA49444@triton.kn-bremen.de> Hi! I just made a new vbox/qemu -current guest to look at flash10 vs f10 (I made a raw image using qemu-img and gave that to vbox as per this description, http://www.virtualbox.org/manual/UserManual.html#rawdisk so that I can also mount it from the host using mdconfig and boot it in qemu too), and noticed em(4) in both vbox and qemu now report `Invalid MAC address' and consequently don't attach: vbox: em0: port 0xd010-0xd017 mem 0xf0000 000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf0000000 em0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd010 em0: Invalid MAC address device_attach: em0 attach returned 5 qemu: em0: port 0xc040-0xc07f mem 0xf2020 000-0xf203ffff irq 11 at device 3.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2020000 em0: Reserved 0x40 bytes for rid 0x14 type 4 at 0xc040 em0: Invalid MAC address device_attach: em0 attach returned 5 I had to switch to PCnet-PCI II in vbox and model=pcnet in qemu, both driven by le(4) in the guest. Btw, PCnet-FAST III in vbox also doesn't work (driven by pcn(4)), it fails to dhcp, but that breakage also exists in 7.2 so its much older. head snapshot where em(4) works: 8.0-HEAD-20090403-JPSNAP head snapshot where em(4) is broken: 8.0-HEAD-20090605-JPSNAP Anyway, on to www/linux-f8-flashplugin10 with OVERRIDE_LINUX_BASE_PORT and OVERRIDE_LINUX_NONBASE_PORTS both f10: I got that going after removing libidn from the port's USE_LINUX_APPS (its part of linux_base-f10) and installing two new dependencies of f10's libcurl: libldap-2.4.so.2 in openldap-2.4.12-1.fc10.i386.rpm and libsasl2.so.2 in cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm (so we'll need two new ports for these), and then finally to get libflashsupport working too (i.e., audio) I had to ln -s libssl.so.7 /compat/linux/lib/libssl.so.6 - so we probably need a new linux-f10-flashsupport too if we want to avoid that symlink. Oh and btw I got a weird audio issue in vbox also: most of the times audio plays too fast and sounds ugly (using snd_ich; this stays until guest reboot), but I also had the guest boot a few times with proper audio... Cheers, Juergen From glen.j.barber at gmail.com Sat Jun 6 22:36:46 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Jun 6 22:36:59 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! In-Reply-To: <4A263ECD.2070704@fletchermoorland.co.uk> References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> <20090603061650.GC1122@egr.msu.edu> <4A263ECD.2070704@fletchermoorland.co.uk> Message-ID: <4ad871310906061536y55382376x6a73e7ad88ee3b8f@mail.gmail.com> Good evening everyone. Earlier today, I finished a VBox build on a fresh system. After the build succeeded, I 'kldload /boot/modules/vboxdrv.ko' which caused a panic. The machine runs a GENERIC kernel with KDB and KDB_UNATTENDED added -- no other changes. -- The machine -- FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #1 r193481: Sat Jun 6 10:22:25 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION i386 -- Snippet from 'dmesg' -- FreeBSD 7.2-STABLE #0 r193481: Fri Jun 5 01:55:06 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2217.69-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2128793600 (2030 MB) avail memory = 2073436160 (1977 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 -- The panic -- orion# kgdb kernel.debug /var/crash/vmcore.0 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: !!Assertion Failed!! Expression: cMillies != RT_INDEFINITE_WAIT Location : /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/ src/VBox/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c(212) rtSemEventWait Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xc5e180be stack pointer = 0x28:0xe7a73c08 frame pointer = 0x28:0xe7a73c34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 1838 (TIMER) trap number = 3 panic: breakpoint instruction fault cpuid = 1 Uptime: 6h58m4s Physical memory: 2017 MB Dumping 180 MB: 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kerne l/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/ac pi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e45a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e48b2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae6d83 in trap_fatal (frame=0xe7a73bc8, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae7bdc in trap (frame=0xe7a73bc8) at /usr/src/sys/i386/i386/trap.c:726 #5 0xc0acc05b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #6 0xc5e180be in rtSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295, fInterruptible=false) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:212 #7 0xc5e181b0 in RTSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:240 #8 0xc5e157f1 in rtTimerThread (Thread=0xc5d2b990, pvUser=0xc5d2be90) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/generic/timer-generic.cpp:238 #9 0xc5e1a6c0 in rtThreadMain (pThread=0xc5d2b990, NativeThread=3316025600, pszThreadName=0xc5d2b9d0 "TIMER") at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/common/misc/thread.cpp:635 #10 0xc5e26ee7 in rtThreadNativeMain (pvThreadInt=0xc5d2b990) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/thread2-r0drv-freebsd.c:112 ---Type to continue, or q to quit--- #11 0xc07bdbc9 in fork_exit (callout=0xc5e26ec0 , arg=0xc5d2b990, frame=0xe7a73d38) at /usr/src/sys/kern/kern_fork.c:811 #12 0xc0acc0d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) Any thoughts? If needed, I will test patches. -- Glen Barber From phk at phk.freebsd.dk Sat Jun 6 22:43:28 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat Jun 6 22:43:35 2009 Subject: WIP: ATA to CAM integration In-Reply-To: Your message of "Fri, 05 Jun 2009 19:54:27 +0300." <4A294DC3.5010008@mavhome.dp.ua> Message-ID: <6657.1244328220@critter.freebsd.dk> In message <4A294DC3.5010008@mavhome.dp.ua>, Alexander Motin writes: >I think ATAPI disk device is theoretically possible, but I believe it >does not exist in practice, as industry do not need it. Maxtor ZIP ? -- 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 mav at FreeBSD.org Sat Jun 6 23:15:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Jun 6 23:15:26 2009 Subject: WIP: ATA to CAM integration In-Reply-To: <6657.1244328220@critter.freebsd.dk> References: <6657.1244328220@critter.freebsd.dk> Message-ID: <4A2AF876.1030103@FreeBSD.org> Poul-Henning Kamp wrote: > In message <4A294DC3.5010008@mavhome.dp.ua>, Alexander Motin writes: >> I think ATAPI disk device is theoretically possible, but I believe it >> does not exist in practice, as industry do not need it. > > Maxtor ZIP ? May be, never had an ATA version. But it is more FDD, then HDD. Also it existed in Parallel Port and SCSI versions, so it could be done in ATAPI way just for unification. -- Alexander Motin From dillon at apollo.backplane.com Sat Jun 6 23:33:20 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Sat Jun 6 23:33:32 2009 Subject: WIP: ATA to CAM integration References: <6657.1244328220@critter.freebsd.dk> <4A2AF876.1030103@FreeBSD.org> Message-ID: <200906062333.n56NXH6a090341@apollo.backplane.com> I found the ATAPI_C_ATAPI_IDENTIFY command that was mentioned and it works fine, returning the same sort of information for ATAPI attachments that ATA_C_IDENTIFY returns for DISK attachments. That takes care of the queue length negotiation by the device. However, there is no fis->command that I can find that would allow NCQ to operate in ATAPI mode. In ATAPI mode fis->command is typically set to ATA_C_PACKET. In DISK mode fis->command is set to ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA (the first-person DMA mode used by AHCI's NCQ). So unless the *_FPDMA FIS commands work for an ATAPI attached device, we are S.O.L. Section 5.6.4.1: The ATA/ATAPI-7 queued feature set is not supported by AHCI (including READ QUEUED (EXT), WRITE QUEUED (EXT), and SERVICE commands). Queued operations are supported in AHCI using the READ FPDMA QUEUED and WRITE FPDMA QUEUED commands when the HBA and device support native command queueing. It is unclear whether an ATAPI device would accept a non-packet command, aka ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA, instead of ATA_C_PACKET. ATAPI devices do support the ATAPI_C_ATAPI_IDENTIFY command, which is non-packet command, so maybe its possible. If it is possible it would only work for READ and WRITE commands, since those are the only commands the FPDMA modes can be used for. The AHCI spec doesn't explicitly say that the FPDMA commands would not work for an ATAPI attached device, so there's hope. What we need is a SATA ATAPI device which says it supports NCQ + has a queue length > 1 to test with. -Matt Matthew Dillon From geekounet at poildetroll.net Sun Jun 7 03:29:41 2009 From: geekounet at poildetroll.net (Pierre Guinoiseau) Date: Sun Jun 7 03:29:48 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <4A23919F.8050905@mail.zedat.fu-berlin.de> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> Message-ID: <4A2B3040.7020509@poildetroll.net> Hi, I have a similar problem, for about 3 weeks/1 month now, on a SMP box. If i run something using much cpu for a "long" time and/or causing heavy I/O, like compiling or watching a video, my box slows down a lot, X11 (and any apps, X11 or not) become much less responsive, the CPU stays at 100% load (mainly because of X11), even when the original task is ended. If I stop X11, the system stay still very slow. The only way to get my machine back in a usable state is to reboot it... :( Following this discussion, I've tried to compile a kernel (with a fresh check out from yesterday) with and without adaptive sx, and it didn't change anything at all, so this is not the origin of the problem. I've no idea from where the problem comes from, and I can't say exactly since when it is here. But I can give more informations about my system if needed and test any solution you could advise if any. Thanks! Pierre Guinoiseau O. Hartmann wrote: > Kip Macy wrote: >>> I'm running the r193133 amd64 with a custom kernel and all debugging off >>> on an AMD Athlon64 3400+ single-core, and I haven't noticed any significant >>> slowing, although I haven't been doing any systematic benchmarking. >>> >>> What would be the penalties of running an SMP -CURRENT kernel on >>> single-core hardware with no hyperthreading? Can anyone quantify the >>> typical added overhead? Or, counterintuitively, would an SMP kernel >>> be better in some ways? >>> >>> >> He is trying to diagnose if the problem was introduced by enabling >> adaptive spinning on sx locks. They're only enabled on SMP kernels. >> >> Cheers, >> Kip >> > Well, no SMP on UP AMD CPUs without SMT means no usage of the sx locks. > As far as I know, the sx locks were introduced a couple of days ago, > weren't they? > > To avoid any kind of misunderstanding, there is no permanent 'slowdown', > it occurs especially whenever the system's compiler builds world or a > kernel or heavy I/O activities occur. It seems my boxes, especially the > UP box, is freezing, no reaction on X11. Well, first time I thought it > is related to UP, low memory or especially new drm code used with X11 > for acceleration, but I also realized those 'slowdown-incidents' on > boxes with multicores, 8 or more GB of RAM and no X11 installed and > running. This performance impact in situations whenever building a > world is significant. We did not change the compiler, it is still the > old gcc 4.2, so I do not expect an impact from new high-memory and > cpu-consuming optimization routines. I do not even benchmark my boxes > day for day, but I usually do a set of the same work on those boxes used > for scientific work, so while building world even on SMP boxes and > working after installation with the same software set reveals some > weirdness in some points. > > I thought this is due some use-uninterruptable debugging switches, some > wrote the malloc code is about to change and so on so I was wondering if > there is something temporarely going on at the moment where some hints > could prevent me from building a world within this testing phase. Just > speculation. > > Greetings, > Oliver > _______________________________________________ > 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090607/dbf42dc8/signature.pgp From pyunyh at gmail.com Sun Jun 7 04:46:24 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Jun 7 04:46:32 2009 Subject: Attansic L1e Gigabit Ethernet driver support In-Reply-To: <4A2A878D.30203@free.fr> References: <4A2A878D.30203@free.fr> Message-ID: <20090607044802.GB51551@michelle.cdnetworks.co.kr> On Sat, Jun 06, 2009 at 04:13:17PM +0100, Franck Royer wrote: > Hi, > > I have an Acer Aspire 6930 and I'm using the freebsd 8.0-CURRENT branch > (the 2009-05) on amd64. > > As said in the topic, I have a network card Attansic L1e Gigabit > Ethernet which is not recognize by the GENERIC kernel and current > age/ale drivers. > That's strange. Would you show me the output of "pciconf -lcv"? It's possible that you have third generation ethernet controller, AR8131/AR8132 from Atheros. I'm working on supporting these controllers and you can get the latest driver for AR8131/AR8132 from the following URL. http://people.freebsd.org/~yongari/alc/if_alc.c http://people.freebsd.org/~yongari/alc/if_alcreg.h http://people.freebsd.org/~yongari/alc/if_alcvar.h http://people.freebsd.org/~yongari/alc/Makefile > I'd like to know what is the current solution to make it works because I > saw different solutions. I'll probably try this one : > http://daemonforums.org/showthread.php?t=2244 (patching the ale driver, Ignore the thread. You don't need any patches to make ale(4) run on RELENG_7/CURRENT. > but for now I'm waiting for the end of the download of my freebsd dvd > cause of course I need the kernel sources to compile it). > > I can give my dmesg messages but it's not obvious (cause I doing a zfs > only installation, it is why I took the current, and my other installed > system is a ubuntu without zfs support :/). > > Cheers, > > Franck From kaiwang27 at gmail.com Sun Jun 7 05:57:31 2009 From: kaiwang27 at gmail.com (Kai Wang) Date: Sun Jun 7 05:57:38 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <4A27F105.4040109@freebsd.org> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> <4A27F105.4040109@freebsd.org> Message-ID: <20090607052555.GA2154@viskning> On Thu, Jun 04, 2009 at 09:06:29AM -0700, Tim Kientzle wrote: > Erik Cederstrand wrote: > > > > LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but "it > > doesn't interact correctly with conventional nm/ar/etc" > > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html). > > In what way does it not interact correctly? llvm-ar manual page: http://llvm.org/cmds/llvm-ar.html I think the major difference is that llvm-ar is aimed for bitcode (.bc) files, same as other llvm-xxx tools. (for example, llvm-ld) Other that that, llvm-ar uses a different symbol table, a different compression solution. (llvm-ar compresses each member separately, not the entire archive, this is probably better wrt random access of members?). llvm-ar also has a handy -R option which we should probably add to our ar(1). And from what I read in the wiki, it looks like llvm-ld can be used as long as --emit-llvm is specified when compiling? -Kai From attilio at freebsd.org Sun Jun 7 10:39:51 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Jun 7 10:40:00 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <4A2B3040.7020509@poildetroll.net> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> Message-ID: <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> 2009/6/7 Pierre Guinoiseau : > Hi, > > I have a similar problem, for about 3 weeks/1 month now, on a SMP box. > If i run something using much cpu for a "long" time and/or causing heavy > I/O, like compiling or watching a video, my box slows down a lot, X11 > (and any apps, X11 or not) become much less responsive, the CPU stays at > 100% load (mainly because of X11), even when the original task is ended. > If I stop X11, the system stay still very slow. The only way to get my > machine back in a usable state is to reboot it... :( Would you both be able to get a schedgraph trace of your offending workloads? In order to do that you would need to: - Recompile your kernel by just adding the following lines: options KTR options KTR_COMPILE=(KTR_SCHED) options KTR_ENTRIES=262144 options KTR_MASK=(KTR_SCHED) - Install the py-tkinter package from ports - While the new kernel is running the workload you are profiling do 'sysctl debug.ktr.mask=0' (it will disable, until restored the ability to trace, so in order to get more traces re-enable it) - Then do ktrdump -ct > ktr.out and send the output to lists, possibly specifying the frequency of your cores Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From francklarchange at free.fr Sun Jun 7 11:38:30 2009 From: francklarchange at free.fr (francklarchange@free.fr) Date: Sun Jun 7 11:38:38 2009 Subject: Attansic L1e Gigabit Ethernet driver support In-Reply-To: <20090607044802.GB51551@michelle.cdnetworks.co.kr> References: <4A2A878D.30203@free.fr> <20090607044802.GB51551@michelle.cdnetworks.co.kr> Message-ID: <1244373651.4a2ba2931774f@imp.free.fr> I'm sorry, I actually have the same problem than in thread "ACPI problem with new acer aspire 6930G", I misread the logs and didn't realized that acpi was the problem, here is my dmesg : ale0: irq 17 at device 0.0 on pci9 ale0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). ale0: cannot allocate memory resources. device_attach: ale0 attach returned 6 If it is still useful, here is pciconf -lcv for the network card : ale0@pci0:9:0:0: class=0x020000 card=0x015e1025 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) cap 03[6c] = VPD Here is my full dmesg.boot : http://pastebay.com/20666 and my full pciconf -lcv : http://pastebay.com/20667 Cheers, Franck Selon Pyun YongHyeon : > On Sat, Jun 06, 2009 at 04:13:17PM +0100, Franck Royer wrote: > > Hi, > > > > I have an Acer Aspire 6930 and I'm using the freebsd 8.0-CURRENT branch > > (the 2009-05) on amd64. > > > > As said in the topic, I have a network card Attansic L1e Gigabit > > Ethernet which is not recognize by the GENERIC kernel and current > > age/ale drivers. > > > > That's strange. Would you show me the output of "pciconf -lcv"? > It's possible that you have third generation ethernet controller, > AR8131/AR8132 from Atheros. I'm working on supporting these > controllers and you can get the latest driver for AR8131/AR8132 > from the following URL. > http://people.freebsd.org/~yongari/alc/if_alc.c > http://people.freebsd.org/~yongari/alc/if_alcreg.h > http://people.freebsd.org/~yongari/alc/if_alcvar.h > http://people.freebsd.org/~yongari/alc/Makefile > > > I'd like to know what is the current solution to make it works because I > > saw different solutions. I'll probably try this one : > > http://daemonforums.org/showthread.php?t=2244 (patching the ale driver, > > Ignore the thread. You don't need any patches to make ale(4) run on > RELENG_7/CURRENT. > > > but for now I'm waiting for the end of the download of my freebsd dvd > > cause of course I need the kernel sources to compile it). > > > > I can give my dmesg messages but it's not obvious (cause I doing a zfs > > only installation, it is why I took the current, and my other installed > > system is a ubuntu without zfs support :/). > > > > Cheers, > > > > Franck > _______________________________________________ > 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 doublef-ctm at yandex.ru Sun Jun 7 12:49:04 2009 From: doublef-ctm at yandex.ru (Sergey Zaharchenko) Date: Sun Jun 7 12:49:32 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 4 In-Reply-To: <20090527134343.GB1104@bsdcrew.de> References: <20090527134343.GB1104@bsdcrew.de> Message-ID: <20090607123354.GA2645@shark.localdomain> Hello Martin! Wed, May 27, 2009 at 03:43:43PM +0200 you wrote: > > Howdy, > > First of all sorry for all unanswered mails, I got a stupid flu, > but now i feel better... ok now back to vbox, time for a new call > for testing :-) > > http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz I'm running -CURRENT (yesterday's kernel) on i386, single-processor. I've tried this out, it works OK (including a WinXP install + installation of VS2005 under it), but there's a problem when I try to shut down the VM: the host system reproducibly panics:(. Here's what I've managed to get: Unread portion of the kernel message buffer: panic: vm_page_dirty: page is invalid! (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc086270e in boot (howto=260) at /home/df/checkouts/freebsd/src/sys/kern/kern_shutdown.c:420 #2 0xc08629e2 in panic (fmt=Variable "fmt" is not available. ) at /home/df/checkouts/freebsd/src/sys/kern/kern_shutdown.c:576 #3 0xc0a9fdf2 in vm_page_dirty (m=0x0) at /home/df/checkouts/freebsd/src/sys/vm/vm_page.c:574 #4 0xc0b685ad in pmap_remove_pte (pmap=0xc87bb358, ptq=Variable "ptq" is not available. ) at /home/df/checkouts/freebsd/src/sys/i386/i386/pmap.c:2478 #5 0xc0b68f1a in pmap_remove (pmap=0xc87bb358, sva=2945187840, eva=2945318912) at /home/df/checkouts/freebsd/src/sys/i386/i386/pmap.c:2607 #6 0xc0a967bc in vm_map_delete (map=0xc87bb2ac, start=2945187840, end=2945318912) at /home/df/checkouts/freebsd/src/sys/vm/vm_map.c:2579 #7 0xc0a969c1 in vm_map_remove (map=0xc87bb2ac, start=2945187840, end=2945318912) at /home/df/checkouts/freebsd/src/sys/vm/vm_map.c:2608 #8 0xc19ef55c in rtR0MemObjNativeFree () from /boot/modules/vboxdrv.ko #9 0xc19edbb2 in RTR0MemObjFree () from /boot/modules/vboxdrv.ko #10 0xc19dc4ac in supdrvMemRelease () from /boot/modules/vboxdrv.ko #11 0xc19df52e in supdrvIOCtl () from /boot/modules/vboxdrv.ko #12 0xc19dadca in VBoxDrvFreeBSDIOCtl () from /boot/modules/vboxdrv.ko #13 0xc07e73f8 in devfs_ioctl_f (fp=0xc7c54508, com=3317652896, data=0xc5bf5da0, cred=0xc87c1800, td=0xc8257900) at /home/df/checkouts/freebsd/src/sys/fs/devfs/devfs_vnops.c:660 #14 0xc08a59ad in kern_ioctl (td=0xc8257900, fd=22, com=3223082507, data=0xc5bf5da0 "birddrib\034") at file.h:262 #15 0xc08a5b34 in ioctl (td=0xc8257900, uap=0xe6d33cf8) at /home/df/checkouts/freebsd/src/sys/kern/sys_generic.c:677 #16 0xc0b6c853 in syscall (frame=0xe6d33d38) at /home/df/checkouts/freebsd/src/sys/i386/i386/trap.c:1073 #17 0xc0b4fab0 in Xint0x80_syscall () at /home/df/checkouts/freebsd/src/sys/i386/i386/exception.s:261 #18 0x00000033 in ?? () Still, thanks a lot for your hard work! VirtualBox is such a nice thing... -- DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090607/e2afa0f6/attachment.pgp From attilio at freebsd.org Sun Jun 7 13:23:20 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Jun 7 13:23:26 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <4A2BBDC0.6000801@poildetroll.net> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> Message-ID: <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> 2009/6/7 Pierre Guinoiseau : > Ok, here is a ktr output. This time, the slowdown appeared while > recompiling thunderbird. I have 2 core at 2.2Ghz (and powerd running, I > don't know if it matters). > > BTW, what is the use of py-tkinter ? If it was in order to cause the > bug, it failed, it needed a higher load. :) Ah sorry, I was supposed to let you run schedgraph but I'm going to do that, so you actually didn't need it I will let you know if something cames up. If others can report the same it will be great. Thanks, Attilio From freebsd-current at chrishedley.com Sun Jun 7 15:27:44 2009 From: freebsd-current at chrishedley.com (Chris Hedley) Date: Sun Jun 7 15:27:52 2009 Subject: New builds won't boot (fwd) Message-ID: Hope it's not bad form for me to forward this on to -current for comments; I guess since nobody else has brought this up it's something I'm doing wrong rather than a serious flaw, but I'd be most grateful for a pointer nonetheless. :) And, since I think I forgot to mention it, I'm using -current/amd64 and ZFS v13. ---------- Forwarded message ---------- Date: Fri, 5 Jun 2009 11:00:48 From: Chris Hedley To: freebsd-amd64@freebsd.org Subject: New builds won't boot Hi all, I was wondering if anybody has any suggestions for me. Since around January this year, I've been unable to get new builds to boot on my system: they go through the usual kernel initialisation stage, reach the "ZFS is an experimental feature" message, sometimes followed a few other random notices, and then it hangs indefinitely. I've just regressed to a version from mid January which boots without any problems, though ZFS from that point is unstable enough that I'm unable to update any of the packages on the security alerts list without it locking up, so it's not ideal. I've tried various approaches to see if I can find out what was the problem. I did read that GEOM_MIRROR has displayed similar problems in recent versions, especially if combined with k8temp, oddly, but disabling one or other, or both, or making it part of the kernel, and various other trial-and-error configurations haven't yielded any success. Other attempts have been to try a build both with and without SMP, turning off optimisation in CFLAGS and numerous other fiddles that I can't recall now. A further complication is that USB appears also to be broken in the newer versions, so although I can break out into the debugger, the keyboard doesn't work from that point onwards. Not that it makes a lot of difference as I'm not really sure what to look for. It is also worth noticing that a build of GENERIC also has the above two problems so I'm not entirely convinced it's a configuration issue unless there's something weird in my loader.conf, which is as follows if it looks suspect to anybody: #geom_mirror_load="YES" geom_label_load="YES" geom_eli_load="YES" nvram_load="YES" zfs_load="YES" vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_min="512M" vfs.zfs.arc_max="1024M" vfs.zfs.prefetch_disable=1 # vfs.zfs.zil_disable=1 vfs.root.mountfrom="zfs:tank/root.2009.01" kern.maxfiles="25000" My system setup is a uniprocessor Opteron 248 in a Tyan Thunder dual processor motherboard with 3GB registered/ECC RAM. I use ZFS for my main storage array in a RAIDZ2 configuration spread across eight of its 10 partitioned SATA discs; the system boots off one component of a GEOM_MIRROR enabled partition to avoid any need for zfsboot and related issues. I'm wondering if it might be ZFS that's the problem here. I'm not especially enthusiastic about giving it up, so might I be better off migrating to Solaris, do you think? Any suggestions would be welcome! _______________________________________________ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From onemda at gmail.com Sun Jun 7 18:08:40 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Jun 7 18:08:47 2009 Subject: page fault in shutdown Message-ID: <3a142e750906071108xfe6a3c7hbbc872bd0c90d6ee@mail.gmail.com> I got several times page fault when syncing disk but it is not easy to reproduce. I have coredump. All buffers synced. lock order reversal: 1st 0xc4083bdc ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1197 2nd 0xc40a1488 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xe6497a80 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05fa097 stack pointer = 0x28:0xc399a864 frame pointer = 0x28:0xc399a8fc 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 = 1 (init) Physical memory: 1007 MB Dumping 123 MB: 108 92 76 60 44 28 12 Reading symbols from /boot/KERNEL/sound.ko...Reading symbols from /boot/KERNEL/sound.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/sound.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/random.ko...Reading symbols from /boot/KERNEL/random.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/random.ko Reading symbols from /boot/KERNEL/acpi.ko...Reading symbols from /boot/KERNEL/acpi.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/acpi.ko Reading symbols from /boot/KERNEL/ata.ko...Reading symbols from /boot/KERNEL/ata.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/ata.ko Reading symbols from /boot/KERNEL/atapci.ko...Reading symbols from /boot/KERNEL/atapci.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/atapci.ko Reading symbols from /boot/KERNEL/ataahci.ko...Reading symbols from /boot/KERNEL/ataahci.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/ataahci.ko Reading symbols from /boot/KERNEL/atadisk.ko...Reading symbols from /boot/KERNEL/atadisk.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/atadisk.ko Reading symbols from /boot/KERNEL/ataintel.ko...Reading symbols from /boot/KERNEL/ataintel.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/ataintel.ko Reading symbols from /boot/KERNEL/cpufreq.ko...Reading symbols from /boot/KERNEL/cpufreq.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/cpufreq.ko Reading symbols from /boot/KERNEL/mem.ko...Reading symbols from /boot/KERNEL/mem.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/mem.ko Reading symbols from /boot/KERNEL/io.ko...Reading symbols from /boot/KERNEL/io.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/io.ko Reading symbols from /boot/KERNEL/sysvmsg.ko...Reading symbols from /boot/KERNEL/sysvmsg.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/sysvmsg.ko Reading symbols from /boot/KERNEL/sysvsem.ko...Reading symbols from /boot/KERNEL/sysvsem.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/sysvsem.ko Reading symbols from /boot/KERNEL/sysvshm.ko...Reading symbols from /boot/KERNEL/sysvshm.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/sysvshm.ko Reading symbols from /boot/KERNEL/nullfs.ko...Reading symbols from /boot/KERNEL/nullfs.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/nullfs.ko Reading symbols from /boot/KERNEL/usb.ko...Reading symbols from /boot/KERNEL/usb.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/usb.ko Reading symbols from /boot/KERNEL/uhci.ko...Reading symbols from /boot/KERNEL/uhci.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/uhci.ko Reading symbols from /boot/KERNEL/ehci.ko...Reading symbols from /boot/KERNEL/ehci.ko.symbols...done. done. Loaded symbols for /boot/KERNEL/ehci.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc042f539 in db_fncall (dummy1=1, dummy2=0, dummy3=-1064047392, dummy4=0xc399a5fc "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc042f931 in db_command (last_cmdp=0xc069c2dc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc042fa8a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc043199d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc04e1826 in kdb_trap (type=12, code=0, tf=0xc399a824) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc061586f in trap_fatal (frame=0xc399a824, eva=3863575168) at /usr/src/sys/i386/i386/trap.c:924 #7 0xc0615a90 in trap_pfault (frame=0xc399a824, usermode=0, eva=3863575168) at /usr/src/sys/i386/i386/trap.c:846 #8 0xc06164f3 in trap (frame=0xc399a824) at /usr/src/sys/i386/i386/trap.c:528 #9 0xc05fb36b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc05fa097 in db_backtrace (td=0xc3d11000, tf=0x0, frame=0xc399a95c, pc=3225623030, count=-1) at /usr/src/sys/i386/i386/db_trace.c:413 #11 0xc05fa8c9 in db_trace_self () at /usr/src/sys/i386/i386/db_trace.c:520 #12 0xc04319f6 in db_trace_self_wrapper () at /usr/src/sys/ddb/db_main.c:246 #13 0xc04e1a79 in kdb_backtrace () at /usr/src/sys/kern/subr_kdb.c:300 #14 0xc04f4f75 in _witness_debugger (cond=-431392176, msg=0xc062738a "witness_checkorder") at /usr/src/sys/kern/subr_witness.c:2799 #15 0xc04f6199 in witness_checkorder (lock=0xc40a1488, flags=9, file=0xc06572df "/usr/src/sys/ufs/ffs/ffs_vfsops.c", line=1194, interlock=0xc40a14a4) at /usr/src/sys/kern/subr_witness.c:1321 #16 0xc049a187 in __lockmgr_args (lk=0xc40a1488, flags=525312, ilk=0xc40a14a4, wmesg=0x0, pri=0, timo=0, file=0xc06572df "/usr/src/sys/ufs/ffs/ffs_vfsops.c", line=1194) at /usr/src/sys/kern/kern_lock.c:525 #17 0xc052a3e2 in vop_stdlock (ap=0xc399aae0) at lockmgr.h:93 #18 0xc0623b65 in VOP_LOCK1_APV (vop=0xc0681d40, a=0xc399aae0) at vnode_if.c:1988 #19 0xc0546c6e in _vn_lock (vp=0xc40a1430, flags=525312, file=0xc06572df "/usr/src/sys/ufs/ffs/ffs_vfsops.c", line=1194) at vnode_if.h:859 #20 0xc05a8d87 in ffs_flushfiles (mp=0xc41de284, flags=2, td=0xc3d11000) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 #21 0xc05a9900 in ffs_unmount (mp=0xc41de284, mntflags=524288) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1084 #22 0xc05349bd in dounmount (mp=0xc41de284, flags=524288, td=0xc3d11000) at /usr/src/sys/kern/vfs_mount.c:1287 #23 0xc053ae6e in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3141 #24 0xc04b266d in boot (howto=Variable "howto" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:401 #25 0xc04b2e1b in reboot (td=0xc3d11000, uap=0xc399acf8) at /usr/src/sys/kern/kern_shutdown.c:173 #26 0xc0615db3 in syscall (frame=0xc399ad38) at /usr/src/sys/i386/i386/trap.c:1073 #27 0xc05fb3d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #28 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Paul From info at martenvijn.nl Sun Jun 7 18:22:32 2009 From: info at martenvijn.nl (Marten Vijn) Date: Sun Jun 7 18:22:39 2009 Subject: uplcom write:Device not configured In-Reply-To: <200905261416.13566.hselasky@c2i.net> References: <1243288231.4621.90.camel@mvn-desktop> <200905261047.58476.hselasky@c2i.net> <1243338029.4558.41.camel@mvn-desktop> <200905261416.13566.hselasky@c2i.net> Message-ID: <1244398944.6260.2.camel@mvn-desktop> On Tue, 2009-05-26 at 14:16 +0200, Hans Petter Selasky wrote: > Hi Marten! Hi Hans, I haven't seen this problem, on 7.x install on the same machine, nor on 8.0 from december. I have updated current to r 192766 and the problem is gone. I did not try your patch. thanks, Marten > > I see some CRC errors there, indicating some kind of cable problem: > > TD(0xc4a9c860) td_next=-VF td_status=-CRCTO-STALLED, errcnt=0, actlen=8 > pid=2d,addr=2,endpt=0,D=0,maxlen=8 > TD(0xc4a9c830) at 0x0269c834 = link=0x00000001 status=0x398003ff > token=0xffe80269 buffer=0x00000000 > > Try the following patch: > > http://perforce.freebsd.org/chv.cgi?CH=162771 > > Not sure if it helps. > > Also try to use an external USB HUB. > > --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" -- http://martenvijn.nl Marten Vijn http://martenvijn.nl/trac/wiki/soas Sugar on a Stick http://bsd.wifisoft.org/nek/ The Network Event Kit http://har2009.org 13th-16th August http://opencommunitycamp.org 26th Jul - 2nd August From kientzle at freebsd.org Sun Jun 7 19:17:49 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Jun 7 19:17:55 2009 Subject: New builds won't boot (fwd) In-Reply-To: References: Message-ID: <4A2C124A.1050707@freebsd.org> Chris Hedley wrote: > > I was wondering if anybody has any suggestions for me. Since around > January this year, I've been unable to get new builds to boot on my > system:... > > I've just regressed to a version from mid January which boots without > any problems,... The following information would help a lot: * dmesg output from a successful boot. * Latest checkout date of a kernel that does boot. * Earliest checkout date of a kernel that doesn't boot. * If it's not a GENERIC kernel, the kernel configuration. (Diff against GENERIC is enough.) SVN revisions are even better than dates if you have them available. (Most people don't; that's okay.) With this, someone can look through the changes that were made during that period and possibly come up with a few likely culprits. Obviously, it's better if you can narrow it down to a shorter interval (a week is good, a day is better) by checking out sources from the half-way point and trying that. Tim From glen.j.barber at gmail.com Sun Jun 7 19:26:22 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sun Jun 7 19:26:30 2009 Subject: page fault in shutdown In-Reply-To: <3a142e750906071108xfe6a3c7hbbc872bd0c90d6ee@mail.gmail.com> References: <3a142e750906071108xfe6a3c7hbbc872bd0c90d6ee@mail.gmail.com> Message-ID: <4ad871310906071226m4e31aa0cwda11795100249e03@mail.gmail.com> Paul, On Sun, Jun 7, 2009 at 2:08 PM, Paul B. Mahol wrote: > I got several times page fault when syncing disk but it is > not easy to reproduce. > I saw this yesterday on one of my 7.2-STABLE machines that I was rebooting: FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #1 r193481: Sat Jun 6 10:22:25 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION i386 > I have coredump. > I, unfortunately, am not that lucky. -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From ianjhart at ntlworld.com Sun Jun 7 21:58:47 2009 From: ianjhart at ntlworld.com (ian j hart) Date: Sun Jun 7 21:58:54 2009 Subject: Bug in recent large_alloc changes to the ZFS zio code? In-Reply-To: <3c1674c90905312139p6ad5020dgb82f0740f75fd096@mail.gmail.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> <20090531074907.GA26858@ichotolot.servalan.com> <3c1674c90905312139p6ad5020dgb82f0740f75fd096@mail.gmail.com> Message-ID: <200906072243.41285.ianjhart@ntlworld.com> On Monday 01 June 2009 05:39:26 Kip Macy wrote: > On Sun, May 31, 2009 at 12:49 AM, Richard Todd > > wrote: > > On Sat, May 30, 2009 at 11:54:47PM -0700, Kip Macy wrote: > >> http://svn.freebsd.org/changeset/base/192360 > > > > Ah. ?Hmm. ?So if I'm reading this right, you already backed out that > > change in the master SVN repo, right? ?Well, *something* weird's going > > on, because that change never seems to have made it to the CVS version of > > the repo or to the cvsup sites, because I'm not seeing it there; see for > > yourself at > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/ut > >s/common/fs/zfs/ . ?The commit log for 192360 never showed up in > > CVSROOT-src/commitlogs/sys either. ?So it looks like bits are falling on > > the floor somewhere between the SVN and CVS repos. > > Yup. This is causing problems for other ZFS users on head. It looks > like if you use ZFS on head you need to use svn. > > > I'm not in a position to fix this issue. > > > Cheers, > Kip > _______________________________________________ > 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" Is this (cvs missing updates) still broken? I have an issue with zfs which I'm trying to explore. I'd like to make sure I have an up to date CURRENT. I only have cvs. Thanks -- ian j hart From kmacy at freebsd.org Sun Jun 7 22:17:04 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sun Jun 7 22:17:11 2009 Subject: Bug in recent large_alloc changes to the ZFS zio code? In-Reply-To: <200906072243.41285.ianjhart@ntlworld.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> <20090531074907.GA26858@ichotolot.servalan.com> <3c1674c90905312139p6ad5020dgb82f0740f75fd096@mail.gmail.com> <200906072243.41285.ianjhart@ntlworld.com> Message-ID: <3c1674c90906071516y774d8c0dved9b0f71b28a7c1c@mail.gmail.com> It's been fixed. On Sun, Jun 7, 2009 at 2:43 PM, ian j hart wrote: > On Monday 01 June 2009 05:39:26 Kip Macy wrote: >> On Sun, May 31, 2009 at 12:49 AM, Richard Todd >> >> wrote: >> > On Sat, May 30, 2009 at 11:54:47PM -0700, Kip Macy wrote: >> >> http://svn.freebsd.org/changeset/base/192360 >> > >> > Ah. ?Hmm. ?So if I'm reading this right, you already backed out that >> > change in the master SVN repo, right? ?Well, *something* weird's going >> > on, because that change never seems to have made it to the CVS version of >> > the repo or to the cvsup sites, because I'm not seeing it there; see for >> > yourself at >> > >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/ut >> >s/common/fs/zfs/ . ?The commit log for 192360 never showed up in >> > CVSROOT-src/commitlogs/sys either. ?So it looks like bits are falling on >> > the floor somewhere between the SVN and CVS repos. >> >> Yup. This is causing problems for other ZFS users on head. It looks >> like if you use ZFS on head you need to use svn. >> >> >> I'm not in a position to fix this issue. >> >> >> Cheers, >> Kip >> _______________________________________________ >> 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" > > Is this (cvs missing updates) still broken? > > I have an issue with zfs which I'm trying to explore. I'd like to make sure I > have an up to date CURRENT. I only have cvs. > > Thanks > > -- > ian j hart > _______________________________________________ > 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 tinderbox at freebsd.org Sun Jun 7 22:42:37 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jun 7 22:42:50 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090607224233.C334E7302F@freebsd-current.sentex.ca> TB --- 2009-06-07 20:55:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-07 20:55:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-07 20:55:15 - cleaning the object tree TB --- 2009-06-07 20:55:41 - cvsupping the source tree TB --- 2009-06-07 20:55:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-07 20:55:53 - building world TB --- 2009-06-07 20:55:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 20:55:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 20:55:53 - TARGET=sparc64 TB --- 2009-06-07 20:55:53 - TARGET_ARCH=sparc64 TB --- 2009-06-07 20:55:53 - TZ=UTC TB --- 2009-06-07 20:55:53 - __MAKE_CONF=/dev/null TB --- 2009-06-07 20:55:53 - cd /src TB --- 2009-06-07 20:55:53 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 20:55:55 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jun 7 22:16:54 UTC 2009 TB --- 2009-06-07 22:16:54 - generating LINT kernel config TB --- 2009-06-07 22:16:54 - cd /src/sys/sparc64/conf TB --- 2009-06-07 22:16:54 - /usr/bin/make -B LINT TB --- 2009-06-07 22:16:54 - building LINT kernel TB --- 2009-06-07 22:16:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 22:16:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 22:16:54 - TARGET=sparc64 TB --- 2009-06-07 22:16:54 - TARGET_ARCH=sparc64 TB --- 2009-06-07 22:16:54 - TZ=UTC TB --- 2009-06-07 22:16:54 - __MAKE_CONF=/dev/null TB --- 2009-06-07 22:16:54 - cd /src TB --- 2009-06-07 22:16:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 22:16:54 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -d -warn-common -r -d -o snd_uaudio.kld uaudio.o uaudio_pcm.o :> export_syms awk -f /src/sys/conf/kmod_syms.awk snd_uaudio.kld export_syms | xargs -J% objcopy % snd_uaudio.kld ld -Bshareable -d -warn-common -o snd_uaudio.ko snd_uaudio.kld objcopy --strip-debug snd_uaudio.ko ===> sound/driver/audiocs (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/sound/driver/audiocs/../../../../dev/sound/sbus/cs4231.c /src/sys/modules/sound/driver/audiocs/../../../../dev/sound/sbus/cs4231.c:276: error: 'S16_LE' undeclared here (not in a function) *** Error code 1 Stop in /src/sys/modules/sound/driver/audiocs. *** Error code 1 Stop in /src/sys/modules/sound/driver. *** Error code 1 Stop in /src/sys/modules/sound. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 22:42:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 22:42:33 - ERROR: failed to build lint kernel TB --- 2009-06-07 22:42:33 - 5154.46 user 453.26 system 6438.44 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From imb at protected-networks.net Mon Jun 8 00:53:46 2009 From: imb at protected-networks.net (Michael Butler) Date: Mon Jun 8 00:53:53 2009 Subject: Intermittent crash .. Message-ID: <4A2C6110.9010504@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On today's -current, and over the last week or so, I've been getting crashes like this .. any thoughts? Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: c14a5000 cpuid = 1 Uptime: 8m40s Physical memory: 2025 MB Dumping 173 MB: 158panic: bufwrite: buffer is not busy??? cpuid = 1 142 126 110 94 78 62 46 30 14 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) Reading symbols from /boot/modules/kqemu.ko...done. Loaded symbols for /boot/modules/kqemu.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc06ac340 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc06ac7c8 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc08c6174 in vm_fault (map=0xc1490000, vaddr=3242872832, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:283 #4 0xc093d3a4 in trap_pfault (frame=0xe7bd4bfc, usermode=0, eva=3242876884) at /usr/src/sys/i386/i386/trap.c:835 #5 0xc093dd41 in trap (frame=0xe7bd4bfc) at /usr/src/sys/i386/i386/trap.c:528 #6 0xc092236b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc069a8fe in free (addr=0xc6478150, mtp=0xc0a4e93c) at vm_page.h:255 #8 0xc06e8db5 in ioctl (td=0xc58aa900, uap=0xe7bd4cf8) at /usr/src/sys/kern/sys_generic.c:683 #9 0xc093d5bf in syscall (frame=0xe7bd4d38) at /usr/src/sys/i386/i386/trap.c:1073 #10 0xc09223d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkosYRAACgkQQv9rrgRC1JJyPgCgh1wVhHA4Uvn0nTa/IpVdDWOC U54AoLoHXUlZ4b4oh0kdNPil2oaRcTUN =KvPa -----END PGP SIGNATURE----- From peterjeremy at optushome.com.au Mon Jun 8 01:19:49 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Jun 8 01:19:56 2009 Subject: Suspend/resume on Acer Aspire One Message-ID: <20090608011945.GB9529@server.vk2pj.dyndns.org> I would like to get suspend/resume to work on my AA1. Using a recent -current (from 3rd June), it appears to suspend OK (the power light changes to flashing orange) but won't resume (power light goes green, ethernet link comes up but there's no response to keyboard or network). As far as I can tell, the hard reset needed to recover wipes msgbuf. Does anyone have any suggestions on how to proceed? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090608/29f5e04d/attachment.pgp From kientzle at freebsd.org Mon Jun 8 01:50:52 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Jun 8 01:50:58 2009 Subject: Suspend/resume on Acer Aspire One In-Reply-To: <20090608011945.GB9529@server.vk2pj.dyndns.org> References: <20090608011945.GB9529@server.vk2pj.dyndns.org> Message-ID: <4A2C6E7B.3060200@freebsd.org> Peter Jeremy wrote: > I would like to get suspend/resume to work on my AA1. Using a recent > -current (from 3rd June), it appears to suspend OK (the power light > changes to flashing orange) but won't resume (power light goes green, > ethernet link comes up but there's no response to keyboard or network). > As far as I can tell, the hard reset needed to recover wipes msgbuf. > > Does anyone have any suggestions on how to proceed? I've gotten it to work with a UP kernel, but I think i386 SMP suspend/resume is still quite badly broken. There is an old patch that claims to fix this, but I've not gotten very far with it yet (I've made a few half-hearted attempts to update it to match -CURRENT; what I have compiles but still fails): http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004879.html There's also some commits from a few months ago that got amd64 suspend/resume to work. Tim From dataefx at charter.net Mon Jun 8 01:57:29 2009 From: dataefx at charter.net (john scroggins) Date: Mon Jun 8 01:57:35 2009 Subject: make installworld failed on CURRENT Message-ID: <1244424790.2343.19.camel@microtetonics.charterpipeline.net> after updating via cvsup 2 nights ago, I ran into an issue during make installworld. I get the following error: ===> usr.sbin/acpi (install) ===> usr.sbin/acpi/acpiconf (install) install -s -o root -g wheel -m 555 acpiconf /usr/sbin install -o root -g wheel -m 444 acpiconf.8.gz /usr/share/man/man8 ===> usr.sbin/acpi/acpidb (install) install -o root -g wheel -m 444 acpidb.8.gz /usr/share/man/man8 install -s -o root -g wheel -m 555 acpidb /usr/sbin install: acpidb: No such file or directory *** Error code 71 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error also attempting to make acpi individually results in the following: resrc.o utstate.o uttrack.o utxface.o -lpthread hwxface.o(.text+0x0): In function `AcpiGetSleepTypeData': : multiple definition of `AcpiGetSleepTypeData' hwregs.o(.text+0xb7a): first defined here /usr/bin/ld: Warning: size of symbol `AcpiGetSleepTypeData' changed from 730 in hwregs.o to 756 in hwxface.o hwvalid.o(.text+0x94): In function `AcpiHwValidateIoRequest': : undefined reference to `AcpiDebugPrint' hwvalid.o(.text+0xc0): In function `AcpiHwValidateIoRequest': : undefined reference to `AcpiError' hwvalid.o(.text+0x10b): In function `AcpiHwValidateIoRequest': : undefined reference to `AcpiGbl_OsiData' hwvalid.o(.text+0x1ef): In function `AcpiHwValidateIoRequest': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x126): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiError' hwxface.o(.text+0x168): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiException' hwxface.o(.text+0x21c): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiError' hwxface.o(.text+0x26d): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x2c0): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiError' hwxface.o(.text+0x2e6): In function `AcpiGetSleepTypeData': : undefined reference to `AcpiError' hwxface.o(.text+0x405): In function `AcpiReadBitRegister': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x59b): In function `AcpiWriteBitRegister': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x6b8): In function `AcpiWrite': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x6fc): In function `AcpiWrite': : undefined reference to `AcpiError' hwxface.o(.text+0x8ca): In function `AcpiRead': : undefined reference to `AcpiDebugPrint' hwxface.o(.text+0x90e): In function `AcpiRead': : undefined reference to `AcpiError' dsopcode.o(.text+0x11c4): In function `AcpiDsGetRegionArguments': : undefined reference to `AcpiOsValidateAddress' nspredef.o(.text+0xaf): In function `AcpiNsCheckParameterCount': : undefined reference to `AcpiWarning' nspredef.o(.text+0xe9): In function `AcpiNsCheckParameterCount': : undefined reference to `AcpiWarning' nspredef.o(.text+0x130): In function `AcpiNsCheckParameterCount': : undefined reference to `AcpiWarning' nspredef.o(.text+0x15d): In function `AcpiNsCheckParameterCount': : undefined reference to `AcpiWarning' nspredef.o(.text+0x1c4): In function `AcpiNsCheckObjectType': : undefined reference to `AcpiWarning' nspredef.o(.text+0x267): more undefined references to `AcpiWarning' follow nspredef.o(.text+0x3b6): In function `AcpiNsCheckObjectType': : undefined reference to `AcpiUtGetReferenceName' nspredef.o(.text+0x3e4): In function `AcpiNsCheckObjectType': : undefined reference to `AcpiWarning' nspredef.o(.text+0x599): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiDebugPrint' nspredef.o(.text+0x5e4): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiWarning' nspredef.o(.text+0x670): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiError' nspredef.o(.text+0x937): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiWarning' nspredef.o(.text+0x995): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiWarning' nspredef.o(.text+0x9d2): In function `AcpiNsCheckPredefinedNames': : undefined reference to `AcpiWarning' *** Error code 1 Stop in /usr/src/usr.sbin/acpi/acpidb. *** Error code 1 Stop in /usr/src/usr.sbin/acpi. Could this be due to addition to the latest submissions to the acpi code? machine specs as follows: FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sat Jun 6 14:32:29 PDT 2009 root@microtetonics:/usr/obj/usr/src/sys/microtetonics WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU N280 @ 1.66GHz (1662.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d> AMD Features=0x100000 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2080251904 (1983 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs any help would be appreciated -J From tinderbox at freebsd.org Mon Jun 8 02:57:18 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 02:57:31 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090608025715.499087302F@freebsd-current.sentex.ca> TB --- 2009-06-08 00:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 00:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-08 00:40:00 - cleaning the object tree TB --- 2009-06-08 00:41:23 - cvsupping the source tree TB --- 2009-06-08 00:41:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-08 00:41:35 - building world TB --- 2009-06-08 00:41:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 00:41:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 00:41:35 - TARGET=amd64 TB --- 2009-06-08 00:41:35 - TARGET_ARCH=amd64 TB --- 2009-06-08 00:41:35 - TZ=UTC TB --- 2009-06-08 00:41:35 - __MAKE_CONF=/dev/null TB --- 2009-06-08 00:41:35 - cd /src TB --- 2009-06-08 00:41:35 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 00:41:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jun 8 02:42:52 UTC 2009 TB --- 2009-06-08 02:42:53 - generating LINT kernel config TB --- 2009-06-08 02:42:53 - cd /src/sys/amd64/conf TB --- 2009-06-08 02:42:53 - /usr/bin/make -B LINT TB --- 2009-06-08 02:42:53 - building LINT kernel TB --- 2009-06-08 02:42:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 02:42:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 02:42:53 - TARGET=amd64 TB --- 2009-06-08 02:42:53 - TARGET_ARCH=amd64 TB --- 2009-06-08 02:42:53 - TZ=UTC TB --- 2009-06-08 02:42:53 - __MAKE_CONF=/dev/null TB --- 2009-06-08 02:42:53 - cd /src TB --- 2009-06-08 02:42:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 02:42:53 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_ethersubr.c -I/src/sys/contrib/pf cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_faith.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_fddisubr.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_fwsubr.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gif.c cc1: warnings being treated as errors /src/sys/net/if_gif.c: In function 'gif_ioctl': /src/sys/net/if_gif.c:920: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 02:57:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 02:57:15 - ERROR: failed to build lint kernel TB --- 2009-06-08 02:57:15 - 6316.59 user 647.93 system 8234.85 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Mon Jun 8 05:45:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 05:45:47 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090608054531.7D2B37302F@freebsd-current.sentex.ca> TB --- 2009-06-08 04:20:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 04:20:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-08 04:20:12 - cleaning the object tree TB --- 2009-06-08 04:20:45 - cvsupping the source tree TB --- 2009-06-08 04:20:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-08 04:20:58 - building world TB --- 2009-06-08 04:20:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 04:20:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 04:20:58 - TARGET=ia64 TB --- 2009-06-08 04:20:58 - TARGET_ARCH=ia64 TB --- 2009-06-08 04:20:58 - TZ=UTC TB --- 2009-06-08 04:20:58 - __MAKE_CONF=/dev/null TB --- 2009-06-08 04:20:58 - cd /src TB --- 2009-06-08 04:20:58 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 04:21:02 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/ia64/src/tmp/usr/lib/libc.a /obj/ia64/src/tmp/usr/lib/libgeom.a /obj/ia64/src/tmp/usr/lib/libsbuf.a /obj/ia64/src/tmp/usr/lib/libbsdxml.a /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 05:45:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 05:45:31 - ERROR: failed to build world TB --- 2009-06-08 05:45:31 - 4058.06 user 327.51 system 5118.83 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From hselasky at c2i.net Mon Jun 8 06:58:44 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 8 06:58:53 2009 Subject: Temporary patch to fix USB in kdebase4 Message-ID: <200906080902.43391.hselasky@c2i.net> See attachment. --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: kdebase4.diff Type: text/x-patch Size: 5884 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090608/3558137c/kdebase4.bin From rea-fbsd at codelabs.ru Mon Jun 8 07:01:00 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 07:01:12 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20090608025715.499087302F@freebsd-current.sentex.ca> References: <20090608025715.499087302F@freebsd-current.sentex.ca> Message-ID: <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> Sun, Jun 07, 2009 at 10:57:15PM -0400, FreeBSD Tinderbox wrote: > TB --- 2009-06-08 00:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > >>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gif.c > cc1: warnings being treated as errors > /src/sys/net/if_gif.c: In function 'gif_ioctl': > /src/sys/net/if_gif.c:920: warning: cast to pointer from integer of different size Looks like that ----- ifr->ifr_data = (caddr_t)(size_t)options; ----- will be more correct and will disable this warning -- it will convert u_int to the proper type that will be able to carry addresses for the given platform. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From tinderbox at freebsd.org Mon Jun 8 07:26:00 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 07:26:13 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090608072557.4747A7302F@freebsd-current.sentex.ca> TB --- 2009-06-08 06:18:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 06:18:10 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-08 06:18:10 - cleaning the object tree TB --- 2009-06-08 06:18:30 - cvsupping the source tree TB --- 2009-06-08 06:18:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-08 06:18:40 - building world TB --- 2009-06-08 06:18:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 06:18:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 06:18:40 - TARGET=sparc64 TB --- 2009-06-08 06:18:40 - TARGET_ARCH=sparc64 TB --- 2009-06-08 06:18:40 - TZ=UTC TB --- 2009-06-08 06:18:40 - __MAKE_CONF=/dev/null TB --- 2009-06-08 06:18:40 - cd /src TB --- 2009-06-08 06:18:40 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 06:18:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/sparc64/src/tmp/usr/lib/libc.a /obj/sparc64/src/tmp/usr/lib/libgeom.a /obj/sparc64/src/tmp/usr/lib/libsbuf.a /obj/sparc64/src/tmp/usr/lib/libbsdxml.a /obj/sparc64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 07:25:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 07:25:57 - ERROR: failed to build world TB --- 2009-06-08 07:25:57 - 3067.44 user 313.02 system 4066.86 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Mon Jun 8 07:31:20 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 07:31:54 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090608073117.F10B77302F@freebsd-current.sentex.ca> TB --- 2009-06-08 05:45:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 05:45:31 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-08 05:45:31 - cleaning the object tree TB --- 2009-06-08 05:46:00 - cvsupping the source tree TB --- 2009-06-08 05:46:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-08 05:46:08 - building world TB --- 2009-06-08 05:46:08 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 05:46:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 05:46:08 - TARGET=powerpc TB --- 2009-06-08 05:46:08 - TARGET_ARCH=powerpc TB --- 2009-06-08 05:46:08 - TZ=UTC TB --- 2009-06-08 05:46:08 - __MAKE_CONF=/dev/null TB --- 2009-06-08 05:46:08 - cd /src TB --- 2009-06-08 05:46:08 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 05:46:10 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 8 07:13:40 UTC 2009 TB --- 2009-06-08 07:13:40 - generating LINT kernel config TB --- 2009-06-08 07:13:40 - cd /src/sys/powerpc/conf TB --- 2009-06-08 07:13:40 - /usr/bin/make -B LINT TB --- 2009-06-08 07:13:40 - building LINT kernel TB --- 2009-06-08 07:13:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 07:13:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 07:13:40 - TARGET=powerpc TB --- 2009-06-08 07:13:40 - TARGET_ARCH=powerpc TB --- 2009-06-08 07:13:40 - TZ=UTC TB --- 2009-06-08 07:13:40 - __MAKE_CONF=/dev/null TB --- 2009-06-08 07:13:40 - cd /src TB --- 2009-06-08 07:13:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 07:13:41 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ofw/ofw_standard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/scc/scc_bfe_macio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/macio/aoa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/macio/davbus.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/macio/i2s.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/macio/snapper.c cc1: warnings being treated as errors /src/sys/dev/sound/macio/snapper.c:126: warning: comparison of distinct pointer types lacks a cast *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 07:31:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 07:31:16 - ERROR: failed to build lint kernel TB --- 2009-06-08 07:31:16 - 4915.59 user 440.41 system 6345.34 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From rea-fbsd at codelabs.ru Mon Jun 8 07:31:31 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 07:32:12 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> Message-ID: Mon, Jun 08, 2009 at 11:00:56AM +0400, Eygene Ryabinkin wrote: > Looks like that > ----- > ifr->ifr_data = (caddr_t)(size_t)options; > ----- > will be more correct and will disable this warning -- it will convert > u_int to the proper type that will be able to carry addresses for the > given platform. Hmm, looking a bit into the code of gif_ioctl, I am under impression that 'options' will not be initialized at the GIFSOPTS processing. And the statement ----- if ((error = copyin(&options, &sc->gif_options, sizeof(sc->gif_options)))) { ----- looks strange -- (&options) is in the kernel space (stack space), so why one is passing it as the userland address? Judging by the contents of newly added setgifopts() inside ifgif.c, I would assume that one wants 'ifr->ifr_data' instead of '&options'. Am I missing something? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From hrs at FreeBSD.org Mon Jun 8 07:56:11 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Jun 8 07:56:25 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> Message-ID: <20090608.165325.225640915.hrs@allbsd.org> 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/20090608/5476ad32/attachment.pgp From rea-fbsd at codelabs.ru Mon Jun 8 08:14:46 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 08:15:39 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20090608.165325.225640915.hrs@allbsd.org> References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <20090608.165325.225640915.hrs@allbsd.org> Message-ID: Hiroki, good day. Mon, Jun 08, 2009 at 04:53:25PM +0900, Hiroki Sato wrote: > Gr, certainly this looks strange. I meant the attached patch. > Thanks for pointing out it. No problems. But still: > Index: if_gif.c > =================================================================== > --- if_gif.c (revision 193673) > +++ if_gif.c (working copy) > @@ -914,10 +914,10 @@ > case GIFSOPTS: > if ((error = priv_check(curthread, PRIV_NET_GIF)) != 0) > break; > - if ((error = copyin(&options, &sc->gif_options, > - sizeof(sc->gif_options)))) { > + if ((error = copyin(ifr->ifr_data, &options, > + sizeof(options)))) { > if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) > - ifr->ifr_data = (caddr_t)options; > + sc->gif_options = options; > else > error = EINVAL; > } Do you intend to set sc->gif_options only for the case of failed copyin()? This looks a bit strange to me too, because 1. in this case 'options' will have undeterminate contents; 2. I thought that 'set options' should set options if it is permitted. Though there could be some logics behing this -- don't know, but may be the negation operator was lost before '(error = copyin(...))' -- this is most adequate description of check for GIF_FULLOPTS. By the way, it will be great if new sysctls and their options will be documented somewhere, perhaps in the gif(4) itself. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From tinderbox at freebsd.org Mon Jun 8 08:24:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 08:25:10 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090608082455.A8C517302F@freebsd-current.sentex.ca> TB --- 2009-06-08 07:25:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 07:25:57 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-08 07:25:57 - cleaning the object tree TB --- 2009-06-08 07:26:27 - cvsupping the source tree TB --- 2009-06-08 07:26:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-08 07:26:35 - building world TB --- 2009-06-08 07:26:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 07:26:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 07:26:35 - TARGET=sun4v TB --- 2009-06-08 07:26:35 - TARGET_ARCH=sparc64 TB --- 2009-06-08 07:26:35 - TZ=UTC TB --- 2009-06-08 07:26:35 - __MAKE_CONF=/dev/null TB --- 2009-06-08 07:26:35 - cd /src TB --- 2009-06-08 07:26:35 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 07:26:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/sun4v/src/tmp/usr/lib/libc.a /obj/sun4v/src/tmp/usr/lib/libgeom.a /obj/sun4v/src/tmp/usr/lib/libsbuf.a /obj/sun4v/src/tmp/usr/lib/libbsdxml.a /obj/sun4v/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 08:24:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 08:24:55 - ERROR: failed to build world TB --- 2009-06-08 08:24:55 - 3042.71 user 306.72 system 3538.18 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From peterjeremy at optushome.com.au Mon Jun 8 08:43:27 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Jun 8 08:43:34 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> Message-ID: <20090608084107.GE9529@server.vk2pj.dyndns.org> On 2009-Jun-08 11:00:56 +0400, Eygene Ryabinkin wrote: > ifr->ifr_data = (caddr_t)(size_t)options; >----- >will be more correct and will disable this warning -- it will convert >u_int to the proper type that will be able to carry addresses for the >given platform. Whilst I notice this specific problem has been resolved differently, for future reference, you should use [u]intptr_t rather than [s]size_t for this purpose. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090608/1e3ed7ad/attachment.pgp From rea-fbsd at codelabs.ru Mon Jun 8 08:47:22 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 08:47:33 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <20090608.165325.225640915.hrs@allbsd.org> Message-ID: And one more thing: Mon, Jun 08, 2009 at 12:14:42PM +0400, Eygene Ryabinkin wrote: > > if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) May be GIF_FULLOPTS is better be named GIF_OPTMASK -- it is easier to understand what does this constant mean. A bit bikeshedy, but still... -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From hrs at FreeBSD.org Mon Jun 8 08:47:48 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Jun 8 08:47:54 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: References: <20090608.165325.225640915.hrs@allbsd.org> Message-ID: <20090608.174450.250237255.hrs@allbsd.org> Eygene Ryabinkin wrote in : re> Do you intend to set sc->gif_options only for the case of failed re> copyin()? This looks a bit strange to me too, because re> 1. in this case 'options' will have undeterminate contents; re> 2. I thought that 'set options' should set options if it is re> permitted. re> Though there could be some logics behing this -- don't know, but re> may be the negation operator was lost before '(error = copyin(...))' -- re> this is most adequate description of check for GIF_FULLOPTS. Yea, you are right. '!' was missing at the head of the condition. The options should be updated when copyin() succeeds. Probably I need some sleep :| re> By the way, it will be great if new sysctls and their options will be re> documented somewhere, perhaps in the gif(4) itself. Okay, I think it is reasonable, too. I'll do. Thanks for the suggestion. -- Hiroki -------------- 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/20090608/87cff007/attachment.pgp From rea-fbsd at codelabs.ru Mon Jun 8 08:55:51 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 08:55:58 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20090608084107.GE9529@server.vk2pj.dyndns.org> References: <20090608025715.499087302F@freebsd-current.sentex.ca> <8LPG99US2/4EsGlonyfMSkDb40o@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <20090608084107.GE9529@server.vk2pj.dyndns.org> Message-ID: Mon, Jun 08, 2009 at 06:41:07PM +1000, Peter Jeremy wrote: > On 2009-Jun-08 11:00:56 +0400, Eygene Ryabinkin wrote: > > ifr->ifr_data = (caddr_t)(size_t)options; > >----- > >will be more correct and will disable this warning -- it will convert > >u_int to the proper type that will be able to carry addresses for the > >given platform. > > Whilst I notice this specific problem has been resolved differently, > for future reference, you should use [u]intptr_t rather than [s]size_t > for this purpose. Thanks -- I had trouble with recalling the name of 'intptr_t', so used 'size_t'. Just curious -- are there platforms/compilers on that these two are really different in sizes? Or this is pure semantical difference? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From mav at FreeBSD.org Mon Jun 8 09:15:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Jun 8 09:15:46 2009 Subject: Multiple MSI on SMP, misrouting or misunderstanding? Message-ID: <4A2CD6AC.80407@FreeBSD.org> Hi. While experimenting with using multiple MSIs support on AHCI controller I have got the problem. When system boots as UP - everything is fine, driver allocates all available 16 MSIs and works. But when system booted as SMP, interrupts begin to behave strange: I didn't receive expected AHCI IRQs, but instead receive IRQ1 interrupts of atkbd0, while I have no PS/2 keyboard/mouse attached. As I have found, problem appears due to IRQ rebalancing between CPUs. As I have got, MSI requires that all vectors from the same group to be allocated sequentially, but IRQ rebalancing breaks correct order, that happed during initial allocation. I was quite surprised by this issue. If multiple MSI vectors of the same device have to be allocated sequentially and bound to the same CPU, then they will be unable to give any SMP scalability benefits. Am I right, or there is some special technique expected to be used to somehow distribute grouped MSI vectors between CPUs which we don't have? I have made small patch that denies rebalancing for grouped MSIs, to make them work at least somehow. It works fine for me, but I am not sure that it is the best solution. -- Alexander Motin -------------- next part -------------- --- msi.c.prev 2009-06-08 11:30:13.000000000 +0300 +++ msi.c 2009-06-08 11:30:06.000000000 +0300 @@ -210,6 +210,8 @@ msi_assign_cpu(struct intsrc *isrc, u_in old_id = msi->msi_cpu; if (old_vector && old_id == apic_id) return; + if (old_vector && !msi->msi_msix && msi->msi_first->msi_count > 1) + return; /* Allocate IDT vector on this cpu. */ vector = apic_alloc_vector(apic_id, msi->msi_irq); if (vector == 0) From tinderbox at freebsd.org Mon Jun 8 09:51:43 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 09:51:56 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090608095139.648A17302F@freebsd-current.sentex.ca> TB --- 2009-06-08 08:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 08:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-08 08:40:00 - cleaning the object tree TB --- 2009-06-08 08:41:17 - cvsupping the source tree TB --- 2009-06-08 08:41:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-08 08:41:25 - building world TB --- 2009-06-08 08:41:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 08:41:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 08:41:25 - TARGET=amd64 TB --- 2009-06-08 08:41:25 - TARGET_ARCH=amd64 TB --- 2009-06-08 08:41:25 - TZ=UTC TB --- 2009-06-08 08:41:25 - __MAKE_CONF=/dev/null TB --- 2009-06-08 08:41:25 - cd /src TB --- 2009-06-08 08:41:25 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 08:41:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libgeom.a /obj/amd64/src/tmp/usr/lib/libsbuf.a /obj/amd64/src/tmp/usr/lib/libbsdxml.a /obj/amd64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 09:51:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 09:51:39 - ERROR: failed to build world TB --- 2009-06-08 09:51:39 - 3228.49 user 336.16 system 4298.93 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From gabor at FreeBSD.org Mon Jun 8 12:31:46 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Mon Jun 8 12:31:52 2009 Subject: warnings cause build fail Message-ID: <4A2D04AB.5090907@FreeBSD.org> Hi, building yesterday's -current on 7.2-R fails due to -Werror, I can only build it if I set WERROR="". Is this a known issue or is it supposed to build successfully on -stable? Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From wxs at FreeBSD.org Mon Jun 8 12:43:52 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Mon Jun 8 12:44:00 2009 Subject: Kernel panic when accessing ZFS-Filesystem via NFS In-Reply-To: <20090601182012.GA21543@darkthrone.kvedulv.de> References: <20090601182012.GA21543@darkthrone.kvedulv.de> Message-ID: <20090608124351.GA81796@atarininja.org> On Mon, Jun 01, 2009 at 08:20:12PM +0200, Michael Moll wrote: > Hi, > > I'm getting the following crash on the NFS server with -CURRENT (r193229) > as soon as I try to access a file on a ZFS filesystem via NFS: > > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0x80562773 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:420 > #2 0x8056297e in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0x807b488c in trap_fatal (frame=0xfcc95718, eva=1660) > at /usr/src/sys/i386/i386/trap.c:933 > #4 0x807b4af0 in trap_pfault (frame=0xfcc95718, usermode=0, eva=1660) > at /usr/src/sys/i386/i386/trap.c:846 > #5 0x807b5492 in trap (frame=0xfcc95718) at > /usr/src/sys/i386/i386/trap.c:528 > #6 0x8079ceeb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #7 0x8053d1bd in prison_priv_check (cred=0x85fe7000, priv=334) > at /usr/src/sys/kern/kern_jail.c:3315 > #8 0x8055631e in priv_check_cred (cred=0x85fe7000, priv=334, flags=0) > at /usr/src/sys/kern/kern_priv.c:93 > #9 0x8514412c in secpolicy_fs_owner () from /boot/kernel/zfs.ko > #10 0x85144657 in secpolicy_vnode_access () from /boot/kernel/zfs.ko > #11 0x851bfc5b in zfs_zaccess () from /boot/kernel/zfs.ko > #12 0x851bfeeb in zfs_zaccess_rwx () from /boot/kernel/zfs.ko > #13 0x851d55a4 in zfs_freebsd_access () from /boot/kernel/zfs.ko > #14 0x807bf282 in VOP_ACCESS_APV (vop=0x85238640, a=0xfcc958cc) > at vnode_if.c:571 > #15 0x806e8057 in nfsrv_access (vp=0x80, accmode=-2062450688, > cred=0x85fe7000, rdonly=0, override=0) at vnode_if.h:254 > #16 0x806e87f1 in nfsrv3_access (nfsd=0xfcc95a9c, slp=0x0, > mrq=0xfcc95a94) > at /usr/src/sys/nfsserver/nfs_serv.c:238 > #17 0x806f65a5 in nfssvc_program (rqst=0x86080800, xprt=0x85fe9e00) > at /usr/src/sys/nfsserver/nfs_srvkrpc.c:410 > #18 0x8071658f in svc_run_internal (pool=0x84d9e500, ismaster=1) > at /usr/src/sys/rpc/svc.c:883 > #19 0x807173fd in svc_run (pool=0x84d9e500) at > /usr/src/sys/rpc/svc.c:1223 > #20 0x806f5f6d in nfssvc_nfsd (td=Variable "td" is not available. > ) > at /usr/src/sys/nfsservc.c:199 > #22 0x806f8158 in nfssvc (td=0x8549fb40, uap=0xfcc95cf8) > at /usr/src/sys/nfs/nfs_nfssvc.c:90 > #23 0x807b4e35 in syscall (frame=0xfcc95d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #24 0x8079cf50 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #25 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > Any ideas on this one? A workaround was committed to this while a more suitable fix is being worked on (r193650). -- WXS From mister.olli at googlemail.com Mon Jun 8 12:58:08 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Mon Jun 8 12:58:21 2009 Subject: Assign IP address and hostname via kernel parameter In-Reply-To: <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> References: <1241623255.12407.6.camel@phoenix.blechhirn.net> <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> Message-ID: <1244465872.12252.39.camel@phoenix.blechhirn.net> Hi, thanks for the hint, this brought me to a (IMHO) good way to accomplish this. When using FreeBSD as domU and configuring the kernel in the domU config file (rather than using pygrub) it's possible to append kernel parameters, by defining them in the variable 'extras' within the domU config file. With 'kenv' I can read them from within the bootet domU, so this should be just a simple shell script to setup all parameters. Currently I'm not sure where this script should hook into freebsd's internas. The greatest thing would be having a 'rc.conf' parameter to enable configuration from the kernel parameters. Setting this to 'true' would simply fire up the shell script to do all the stuff. Any suggestions or hints on this??? Regards, --- Mr. Olli On Wed, 2009-05-06 at 17:52 +0100, Bob Bishop wrote: > Hi, > > On 6 May 2009, at 16:20, Mister Olli wrote: > > > is there a way to configure IP address and hostname on freebsd systems > > via kernel command line parameters? [etc] > > When running diskless, the loader sets kernel variables like: > > boot.netif.gateway="192.168.198.1" > boot.netif.hwaddr="00:15:17:47:14:fc" > boot.netif.ip="192.168.198.8" > boot.netif.netmask="255.255.255.0" > > to values obtained from BOOTP or DHCP, and the right things happen. I > guess you could just set these in loader.conf or at the loader prompt. > > -- > Bob Bishop > rb@gid.co.uk > > > > From shuvaev at physik.uni-wuerzburg.de Mon Jun 8 13:16:38 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon Jun 8 13:16:46 2009 Subject: warnings cause build fail In-Reply-To: <4A2D04AB.5090907@FreeBSD.org> References: <4A2D04AB.5090907@FreeBSD.org> Message-ID: <20090608131634.GA91130@wep4035.physik.uni-wuerzburg.de> On Mon, Jun 08, 2009 at 02:31:39PM +0200, Gabor Kovesdan wrote: > Hi, > > building yesterday's -current on 7.2-R fails due to -Werror, I can only > build it if I set WERROR="". Is this a known issue or is it supposed to > build successfully on -stable? > SVN rev 193673 on 2009-06-08 02:13:24Z by marcel Make the size (-s) and start (-b) parameters of the add verb optional. The missing parameter(s) are automatically filled-in. Attached patch (probably) solves the issue. Alexey. -------------- next part -------------- --- geom_part.c.orig 2009-06-08 15:11:02.000000000 +0200 +++ geom_part.c 2009-06-08 15:11:45.000000000 +0200 @@ -342,13 +342,13 @@ return (ENOSPC); if (!has_size) { - asprintf(&val, "%jd", size); + asprintf(&val, "%llu", size); if (val == NULL) return (ENOMEM); gctl_change_param(req, "size", -1, val); } if (!has_start) { - asprintf(&val, "%jd", start); + asprintf(&val, "%llu", start); if (val == NULL) return (ENOMEM); gctl_change_param(req, "start", -1, val); From gabor at FreeBSD.org Mon Jun 8 13:18:58 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Mon Jun 8 13:19:05 2009 Subject: warnings cause build fail In-Reply-To: <20090608131634.GA91130@wep4035.physik.uni-wuerzburg.de> References: <4A2D04AB.5090907@FreeBSD.org> <20090608131634.GA91130@wep4035.physik.uni-wuerzburg.de> Message-ID: <4A2D0FBC.2060404@FreeBSD.org> Alexey Shuvaev escribi?: > On Mon, Jun 08, 2009 at 02:31:39PM +0200, Gabor Kovesdan wrote: > >> Hi, >> >> building yesterday's -current on 7.2-R fails due to -Werror, I can only >> build it if I set WERROR="". Is this a known issue or is it supposed to >> build successfully on -stable? >> >> > > SVN rev 193673 on 2009-06-08 02:13:24Z by marcel > > Make the size (-s) and start (-b) parameters of the add verb optional. > The missing parameter(s) are automatically filled-in. > > Attached patch (probably) solves the issue. > > No, I see various warnings in different parts of the kernel: acpica, usb, xfs, ... -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From tinderbox at freebsd.org Mon Jun 8 13:27:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 13:27:52 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090608132731.D174B7302F@freebsd-current.sentex.ca> TB --- 2009-06-08 12:03:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 12:03:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-08 12:03:56 - cleaning the object tree TB --- 2009-06-08 12:04:24 - cvsupping the source tree TB --- 2009-06-08 12:04:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-08 12:04:34 - building world TB --- 2009-06-08 12:04:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 12:04:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 12:04:34 - TARGET=ia64 TB --- 2009-06-08 12:04:34 - TARGET_ARCH=ia64 TB --- 2009-06-08 12:04:34 - TZ=UTC TB --- 2009-06-08 12:04:34 - __MAKE_CONF=/dev/null TB --- 2009-06-08 12:04:34 - cd /src TB --- 2009-06-08 12:04:34 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 12:04:37 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/ia64/src/tmp/usr/lib/libc.a /obj/ia64/src/tmp/usr/lib/libgeom.a /obj/ia64/src/tmp/usr/lib/libsbuf.a /obj/ia64/src/tmp/usr/lib/libbsdxml.a /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 13:27:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 13:27:31 - ERROR: failed to build world TB --- 2009-06-08 13:27:31 - 4060.65 user 327.68 system 5014.84 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From rea-fbsd at codelabs.ru Mon Jun 8 14:23:03 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jun 8 14:23:18 2009 Subject: warnings cause build fail In-Reply-To: <4A2D0FBC.2060404@FreeBSD.org> References: <4A2D04AB.5090907@FreeBSD.org> <20090608131634.GA91130@wep4035.physik.uni-wuerzburg.de> <4A2D0FBC.2060404@FreeBSD.org> Message-ID: <9suKjvUm8qSfgVnPJ5GW5mwE64U@j4OYE6OL8eALCd4BvSxIfwgoxSc> Gabor, good day. Mon, Jun 08, 2009 at 03:18:52PM +0200, Gabor Kovesdan wrote: > No, I see various warnings in different parts of the kernel: acpica, > usb, xfs, ... Can you show them? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From tinderbox at freebsd.org Mon Jun 8 14:33:15 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 14:33:22 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090608143311.31CFF7302F@freebsd-current.sentex.ca> TB --- 2009-06-08 13:27:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 13:27:31 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-08 13:27:31 - cleaning the object tree TB --- 2009-06-08 13:28:01 - cvsupping the source tree TB --- 2009-06-08 13:28:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-08 13:28:07 - building world TB --- 2009-06-08 13:28:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 13:28:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 13:28:07 - TARGET=sparc64 TB --- 2009-06-08 13:28:07 - TARGET_ARCH=sparc64 TB --- 2009-06-08 13:28:07 - TZ=UTC TB --- 2009-06-08 13:28:07 - __MAKE_CONF=/dev/null TB --- 2009-06-08 13:28:07 - cd /src TB --- 2009-06-08 13:28:07 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 13:28:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/sparc64/src/tmp/usr/lib/libc.a /obj/sparc64/src/tmp/usr/lib/libgeom.a /obj/sparc64/src/tmp/usr/lib/libsbuf.a /obj/sparc64/src/tmp/usr/lib/libbsdxml.a /obj/sparc64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 14:33:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 14:33:10 - ERROR: failed to build world TB --- 2009-06-08 14:33:10 - 3062.78 user 312.94 system 3939.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From jhb at freebsd.org Mon Jun 8 15:33:58 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 8 15:34:42 2009 Subject: loader panics with 2 GPT partitioned drives In-Reply-To: <20090606175158.GA1080@darklight.homeunix.org> References: <20090606021835.GC1077@darklight.homeunix.org> <20090606175158.GA1080@darklight.homeunix.org> Message-ID: <200906081100.06174.jhb@freebsd.org> On Saturday 06 June 2009 1:51:58 pm Yuri Pankov wrote: > On Sat, Jun 06, 2009 at 06:18:35AM +0400, Yuri Pankov wrote: > > Hi, > > > > I'm getting the following "panic" from loader when trying to attach > > another GPT partitioned drive. loader is built using LOADER_ZFS_SUPPORT. > > > > BTX Loader 1.00 BTX version is 1.02 > > Consoles: internal video/keyboard > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > > > panic:free: guard1 fail @ 0x7fd4b3f4 from > > /usr/src/sys/boot/i386/libi386/biosdisk.c:1048 > > > > > > ad4: > > => 34 488397101 ad4 GPT (233G) > > 34 128 1 freebsd-boot (64K) > > 162 16777216 2 freebsd-swap (8.0G) > > 16777378 471619757 3 freebsd-zfs (225G) > > > > ad10: > > empty disk, `gpart create -s GPT ad10` > > > > > > > > Yuri > > Looks like there are no checks in loader with GPT support if there are > no partitions defined (very rare case, but still.. :-). Attached patch > fixes booting with GPT disk without partitions (for me). That is the correct fix. -- John Baldwin From jhb at freebsd.org Mon Jun 8 15:33:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 8 15:34:54 2009 Subject: Multiple MSI on SMP, misrouting or misunderstanding? In-Reply-To: <4A2CD6AC.80407@FreeBSD.org> References: <4A2CD6AC.80407@FreeBSD.org> Message-ID: <200906081116.40462.jhb@freebsd.org> On Monday 08 June 2009 5:15:24 am Alexander Motin wrote: > Hi. > > While experimenting with using multiple MSIs support on AHCI controller > I have got the problem. When system boots as UP - everything is fine, > driver allocates all available 16 MSIs and works. But when system booted > as SMP, interrupts begin to behave strange: I didn't receive expected > AHCI IRQs, but instead receive IRQ1 interrupts of atkbd0, while I have > no PS/2 keyboard/mouse attached. > > As I have found, problem appears due to IRQ rebalancing between CPUs. As > I have got, MSI requires that all vectors from the same group to be > allocated sequentially, but IRQ rebalancing breaks correct order, that > happed during initial allocation. > > I was quite surprised by this issue. If multiple MSI vectors of the same > device have to be allocated sequentially and bound to the same CPU, then > they will be unable to give any SMP scalability benefits. Am I right, or > there is some special technique expected to be used to somehow > distribute grouped MSI vectors between CPUs which we don't have? > > I have made small patch that denies rebalancing for grouped MSIs, to > make them work at least somehow. It works fine for me, but I am not sure > that it is the best solution. It is a limitation of MSI. With MSI, you have a single address register for the entire group of messages (the individual messages are just distinguished by toggling the lower N bits in the message data register). On x86 the address register includes the APIC ID. That means that all of the messages get sent to the same CPU. With MSI-X, there is a table with separate address and data registers for each message. This allows a driver to distribute interrupts across CPUs. I had old patches prior to the per-CPU IDT stuff to handle this quirk of MSI groups. The approach I used there was that I would only allow reassigning of the entire group by assigning to the first interrupt in the group. With per-CPU IDTs that gets trickier though as you need to allocate a whole block of aligned, consecutive IDT vectors in the new CPU. -- John Baldwin From tinderbox at freebsd.org Mon Jun 8 15:38:17 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 15:38:30 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090608153805.ED0FA7302F@freebsd-current.sentex.ca> TB --- 2009-06-08 14:33:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 14:33:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-08 14:33:11 - cleaning the object tree TB --- 2009-06-08 14:33:33 - cvsupping the source tree TB --- 2009-06-08 14:33:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-08 14:33:40 - building world TB --- 2009-06-08 14:33:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 14:33:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 14:33:40 - TARGET=sun4v TB --- 2009-06-08 14:33:40 - TARGET_ARCH=sparc64 TB --- 2009-06-08 14:33:40 - TZ=UTC TB --- 2009-06-08 14:33:40 - __MAKE_CONF=/dev/null TB --- 2009-06-08 14:33:40 - cd /src TB --- 2009-06-08 14:33:40 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 14:33:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/sun4v/src/tmp/usr/lib/libc.a /obj/sun4v/src/tmp/usr/lib/libgeom.a /obj/sun4v/src/tmp/usr/lib/libsbuf.a /obj/sun4v/src/tmp/usr/lib/libbsdxml.a /obj/sun4v/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 15:38:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 15:38:05 - ERROR: failed to build world TB --- 2009-06-08 15:38:05 - 3060.38 user 309.99 system 3894.45 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From hselasky at c2i.net Mon Jun 8 15:57:11 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 8 15:57:19 2009 Subject: KDE4 on FreeBSD (was: KDE4 and input events) Message-ID: <200906081801.17477.hselasky@c2i.net> Hi, During the last couple of weeks I've seen several posts about input devices freezing. I'm not sure if I have a solution for it, but it seems like there is a software bug there. Starting up kde4 as a non-root user leaded to the following strange situation: kded4 (KDE 4.2.4) was constanly waiting on "select" using 30% CPU while one zombie process was present. Solution: killall -kill kded4 After that my system was behaving normal. I was not able to figure out if this is a kernel race or userland race. --HPS From tinderbox at freebsd.org Mon Jun 8 16:50:54 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 16:51:08 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090608165051.53A247302F@freebsd-current.sentex.ca> TB --- 2009-06-08 15:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-08 15:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-08 15:40:01 - cleaning the object tree TB --- 2009-06-08 15:40:42 - cvsupping the source tree TB --- 2009-06-08 15:40:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-08 15:40:50 - building world TB --- 2009-06-08 15:40:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 15:40:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 15:40:50 - TARGET=amd64 TB --- 2009-06-08 15:40:50 - TARGET_ARCH=amd64 TB --- 2009-06-08 15:40:50 - TZ=UTC TB --- 2009-06-08 15:40:50 - __MAKE_CONF=/dev/null TB --- 2009-06-08 15:40:50 - cd /src TB --- 2009-06-08 15:40:50 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 15:40:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo geom: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libgeom.a /obj/amd64/src/tmp/usr/lib/libsbuf.a /obj/amd64/src/tmp/usr/lib/libbsdxml.a /obj/amd64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/core/geom.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/label/geom_label.c cc -O2 -pipe -I/src/sbin/geom -I/src/sbin/geom/core -DSTATIC_GEOM_CLASSES -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/geom/class/part/geom_part.c cc1: warnings being treated as errors /src/sbin/geom/class/part/geom_part.c: In function 'gpart_autofill': /src/sbin/geom/class/part/geom_part.c:345: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' /src/sbin/geom/class/part/geom_part.c:351: warning: format '%jd' expects type 'intmax_t', but argument 3 has type 'long long unsigned int' *** Error code 1 Stop in /src/sbin/geom. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 16:50:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 16:50:50 - ERROR: failed to build world TB --- 2009-06-08 16:50:50 - 3229.04 user 332.88 system 4249.90 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From imp at bsdimp.com Mon Jun 8 18:07:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Jun 8 18:07:20 2009 Subject: Clang: now available from a SVN server near you! In-Reply-To: <20090604093831.GE48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> Message-ID: <20090608.120552.756910862.imp@bsdimp.com> In message: <20090604093831.GE48776@hoeg.nl> Ed Schouten writes: : Good news everyone! ... : So far we've only done testing on amd64 and i386. A lot of ports are : probably still broken. Caveat emptor. Beware of dog. Slippery when wet. "objects in mirror may be larger than they appear" Do you have size or run-time performance comparisons yet? Warner From mcdouga9 at egr.msu.edu Mon Jun 8 18:27:00 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon Jun 8 18:27:06 2009 Subject: CFT: ee 1.5.0 In-Reply-To: <20090526213921.GD48776@hoeg.nl> References: <20090526213921.GD48776@hoeg.nl> Message-ID: <20090608182658.GY12796@egr.msu.edu> On Tue, May 26, 2009 at 11:39:21PM +0200, Ed Schouten wrote: Hi all, Some days ago Bruce Cran and I were talking on IRC about the ancient version of ee(1) we have in the tree. Today I spent some time moving ee(1) to contrib/ee with proper mergeinfo in place, to make it easier to upgrade it. It turns out all local modifications we have to ee(1) right now (line numbers, mktemp, etc) have been implemented upstream as well, in most cases even better. So I've decided to switch to an almost clean copy of ee(1). My patch so far (requires a very recent source tree): http://80386.nl/pub/ee-freebsd-1.5.0.diff Any comments before I commit this patch to SVN? After using the new ee in a -current build, it seems like an old issue has come back where if the containing xterm is resized, ee ungracefully exits without saving. I think it was fixed a while ago but a quick look at the modern ee.c seems to indicate this was lost: Revision 1.25: download - view: text, markup, annotated - select for diffs Sat Jul 28 22:40:10 2001 UTC (7 years, 10 months ago) by mp Branches: MAIN Diff to: previous 1.24: preferred, colored Changes since revision 1.24: +5 -10 lines Properly handle wgetch(3) returning ERR. This prevents an abnormal exit when a windows resize event (SIGWINCH) occurs. Reported by: John Doe and others on -stable. Reviewed by: dd MFC after: 1 week Also something else which I did not check on: Revision 1.26: download - view: text, markup, annotated - select for diffs Fri Aug 31 21:50:06 2001 UTC (7 years, 9 months ago) by mp Branches: MAIN Diff to: previous 1.25: preferred, colored Changes since revision 1.25: +2 -1 lines Exit gracefully when a SIGHUP is received. This prevents ee from going into an infinite spin loop when the terminal window is forcibly blown away. PR: 29553 Reported by: Sung N. Cho MFC after: 1 day Thanks. Let me know if I should do more to help. From sam at freebsd.org Mon Jun 8 18:33:24 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Jun 8 18:33:31 2009 Subject: KDE4 on FreeBSD (was: KDE4 and input events) In-Reply-To: <200906081801.17477.hselasky@c2i.net> References: <200906081801.17477.hselasky@c2i.net> Message-ID: <4A2D596F.9050508@freebsd.org> Hans Petter Selasky wrote: > Hi, > > During the last couple of weeks I've seen several posts about input > devices freezing. I'm not sure if I have a solution for it, but it seems > like there is a software bug there. > > Starting up kde4 as a non-root user leaded to the following strange > situation: > > kded4 (KDE 4.2.4) was constanly waiting on "select" using 30% CPU while > one zombie process was present. > > Solution: killall -kill kded4 > > After that my system was behaving normal. > > I was not able to figure out if this is a kernel race or userland race. > I have hit numerous kde4 issues on head. Ever since upgrading from kde3 the akonadi server will not startup and I've not figured out why (best guess is it's failing to register w/ dbus but could also be mysql-related). apps randomly go into a "hard run" for extended periods of time (especially thunderbird). firefox3 does not work (best guess was a dns problem) but konqueror does (firefox2 works better but the google search box is inoperative--perhaps same dns issue). And lots of other stuff. I'm too busy w/ other stuff to chase issues but would work with someone familiar w/ kde4 to diagnose. FWIW this is a dual-amd64 install that used to work fine w/ kde3. Sam From das at FreeBSD.ORG Mon Jun 8 19:16:54 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Jun 8 19:17:06 2009 Subject: RFT: Allow large values of NGROUPS_MAX In-Reply-To: <20090605223636.GA24364@lor.one-eyed-alien.net> References: <20090605223636.GA24364@lor.one-eyed-alien.net> Message-ID: <20090608185122.GA65737@zim.MIT.EDU> On Fri, Jun 05, 2009, Brooks Davis wrote: > - Should we make any attempt to support old binaries when there > are more than 16 groups? The POSIX getgroups/setgroups APIs did not > anticipate this change and thus either will fail outright. We can't > fix setgroups, but we might want to make an optional accommodation for > getgroups to allow for truncated returns to old code. Awesome. I think the ABI breakage is fine as long as it only affects systems where users are actually in more than 16 groups. It's perfectly reasonable to expect people to recompile in order to take advantage of a new feature. As for the value of NGROUPS_MAX, there are systems with more than 32k groups out there, but I doubt there are interesting cases where a single user is a member of more than 32k groups. The permission checking code would not realistically scale to group lists that long anyway. From jille at quis.cx Mon Jun 8 19:30:48 2009 From: jille at quis.cx (Jille Timmermans) Date: Mon Jun 8 19:30:58 2009 Subject: panic: oof, we didn't get our fd while playing with devfs(8) and jails Message-ID: <4A2D62B6.9080207@quis.cx> I was playing with the new hierarchical jails (yay!) and devfs(8) to tune the devfs mountpoints. At some point I tried to apply another ruleset and the machine panic'd a few seconds later. I haven't been able to reproduce this. (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc063cf3f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc063d222 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0609399 in fdcheckstd (td=0xc46ff000) at /usr/src/sys/kern/kern_descrip.c:1946 #4 0xc0611086 in kern_execve (td=0xc46ff000, args=0xe647fc58, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:679 #5 0xc06118fc in execve (td=0xc46ff000, uap=0xe647fcf8) at /usr/src/sys/kern/kern_exec.c:203 #6 0xc08c25f3 in syscall (frame=0xe647fd38) at /usr/src/sys/i386/i386/trap.c:1073 #7 0xc08a5f60 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #8 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 3 #3 0xc0609399 in fdcheckstd (td=0xc46ff000) at /usr/src/sys/kern/kern_descrip.c:1946 1946 KASSERT(devnull == i, ("oof, we didn't get our fd")); (kgdb) print i $1 = 1 (kgdb) print devnull $2 = 0 (kgdb) print fdp->fd_ofiles[0] $3 = (struct file *) 0xc41b2e00 (kgdb) print fdp->fd_ofiles[1] $4 = (struct file *) 0x0 (kgdb) print fdp->fd_ofiles[2] $5 = (struct file *) 0x0 (kgdb) print *fdp->fd_ofiles[0]->f_ops $6 = {fo_read = 0xc067d880 , fo_write = 0xc067dee0 , fo_truncate = 0xc067c280 , fo_ioctl = 0xc067ca90 , fo_poll = 0xc067c950 , fo_kqfilter = 0xc067c770 , fo_stat = 0xc067c390 , fo_close = 0xc067d560 , fo_flags = 1} (kgdb) print td->td_name $7 = "sendmail\000er\000\000\000\000\000\000\000\000" # I think the "er" is coming from mailwrapper, overwritten by sendmail\0 Full textdump is attached, I'll keep the vmcore so let me know if you want to know other variables. -- Jille -------------- next part -------------- boom-freebsd.quis.cx dumped core - see /var/crash/vmcore.1 Sun Jun 7 20:23:39 UTC 2009 FreeBSD boom-freebsd.quis.cx 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r193116: Sun May 31 03:24:20 UTC 2009 quis@boom-freebsd.quis.cx:/usr/obj/usr/src/sys/EEE i386 panic: oof, we didn't get our fd 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: oof, we didn't get our fd cpuid = 0 KDB: enter: panic Uptime: 35m34s Physical memory: 1007 MB Dumping 124 MB: 109 93 77 61 45 29 13 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 Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /boot/kernel/unionfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/unionfs.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc063cf3f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc063d222 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0609399 in fdcheckstd (td=0xc46ff000) at /usr/src/sys/kern/kern_descrip.c:1946 #4 0xc0611086 in kern_execve (td=0xc46ff000, args=0xe647fc58, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:679 #5 0xc06118fc in execve (td=0xc46ff000, uap=0xe647fcf8) at /usr/src/sys/kern/kern_exec.c:203 #6 0xc08c25f3 in syscall (frame=0xe647fd38) at /usr/src/sys/i386/i386/trap.c:1073 #7 0xc08a5f60 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #8 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - DLs ?? 574325:36.00 [kernel] 0 1 0 0 51 0 2912 0 wait DLs ?? 433844:48.00 [init] 0 2 0 0 -8 0 0 0 - RL ?? 4739556:24.00 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 8305428:36.00 [g_up] 0 4 0 0 -8 0 0 0 - RL ?? 8741096:36.00 [g_down] 0 5 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 6 0 0 -16 0 0 0 waitin DL ?? 3955:36.00 [sctp_itera 0 7 0 0 -64 0 0 0 psleep DL ?? 74129:48.00 [pagedaemon 0 8 0 0 -64 0 0 0 psleep DL ?? 158:48.00 [vmdaemon] 0 9 0 0 76 0 0 0 pgzero DL ?? 1165:00.00 [pagezero] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 171 0 0 0 - RL ?? -8184896:-35.55 [idle] 0 12 0 0 -60 0 0 0 - WL ?? 7683134:36.00 [intr] 0 13 0 0 -16 0 0 0 - DL ?? 3712870:00.00 [yarrow] 0 14 0 0 -16 0 0 0 tzpoll DL ?? 5014709:12.00 [acpi_therm 0 15 0 0 -16 0 0 0 coolin DL ?? 101114:48.00 [acpi_cooli 0 16 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 17 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 18 0 0 -64 0 0 0 wmsg DL ?? 341083:48.00 [usbus0] 0 19 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 20 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 21 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 22 0 0 -64 0 0 0 wmsg DL ?? 360224:00.00 [usbus1] 0 23 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 24 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 25 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 26 0 0 -64 0 0 0 wmsg DL ?? 341889:00.00 [usbus2] 0 27 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 28 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 29 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 30 0 0 -64 0 0 0 wmsg DL ?? 389174:48.00 [usbus3] 0 31 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 32 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 33 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 34 0 0 -64 0 0 0 wmsg DL ?? 600090:36.00 [usbus4] 0 35 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 36 0 0 -64 0 0 0 psleep DL ?? 306277:24.00 [bufdaemon] 0 37 0 0 -64 0 0 0 vlruwt DL ?? 343869:48.00 [vnlru] 0 38 0 0 44 0 0 0 - RL ?? 3600303:48.00 [syncer] 0 39 0 0 -64 0 0 0 sdflus DL ?? 796358:48.00 [softdepflu 0 40 0 0 -64 0 0 0 flowcl DL ?? 34703:12.00 [flowcleane 0 371 1 0 76 0 1888 0 select Ds ?? 72696:00.00 [devd] 0 474 1 0 44 0 3320 0 select Ds ?? 587030:12.00 [syslogd] 0 744 1 0 76 0 3348 0 nanslp Ds ?? 356433:12.00 [cron] 0 794 1 0 44 0 3784 0 wait Ds ?? 1022241:12.00 [login] 0 795 1 0 44 0 3784 0 wait Ds ?? 1009421:48.00 [login] 0 796 1 0 44 0 3784 0 wait Ds ?? 1013099:12.00 [login] 0 797 1 0 76 0 3320 0 ttyin Ds+ ?? 206877:36.00 [getty] 0 798 1 0 76 0 3320 0 ttyin Ds+ ?? 200452:00.00 [getty] 0 799 1 0 76 0 3320 0 ttyin Ds+ ?? 210536:12.00 [getty] 0 800 1 0 76 0 3320 0 ttyin Ds+ ?? 211536:36.00 [getty] 0 801 1 0 76 0 3320 0 ttyin Ds+ ?? 160099:24.00 [getty] 0 802 794 0 44 0 4532 0 wait D ?? 7244470:36.00 [bash] 1000 803 795 0 45 0 4532 0 wait D ?? 566209:00.00 [bash] 1000 805 803 0 -8 0 12740 0 - R+ ?? -24403354:-31.55 [herrie] 0 822 802 0 44 0 3516 0 - T ?? 1313011:36.00 [vi] 0 920 796 0 44 0 4532 0 wait D ?? 5883692:48.00 [bash] 0 921 920 0 44 0 3516 0 - T ?? 815540:36.00 [vi] 0 1507 0 0 76 0 0 0 - RL ?? 123704:12.00 [pfpurge] 0 2469 1 0 44 0 3320 0 select Ds ?? 433086:24.00 [syslogd] 0 2575 1 0 76 0 6648 0 select Ds ?? 94350:24.00 [sshd] 0 2584 1 0 44 0 3348 0 nanslp Ds ?? 341654:36.00 [cron] 0 2618 920 0 44 0 3600 0 ttyin D+ ?? 498359:24.00 [sh] 0 2629 1 0 44 0 6648 0 select Ds ?? 67591:48.00 [sshd] 0 2702 802 0 44 0 3516 0 ttyin D+ ?? 0:00.00 [vi] 0 2716 2584 0 49 0 3348 0 wait D ?? 0:00.00 [cron] 2 2719 2716 0 46 0 1204 0 - Rs ?? 0:00.00 [sendmail] ------------------------------------------------------------------------ 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 866 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() 882 pages cached 0 pages freed 0 pages freed by daemon 372578 pages freed by exiting processes 7064 pages active 3496 pages inactive 9 pages in VM cache 24283 pages wired down 218414 pages free 4096 bytes per page 158836 total name lookups cache hits (57% pos + 11% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM XPT 10 1K - 25 16,32,64,512 sigio 1 1K - 1 32 filedesc 83 33K - 3002 32,256,2048 kenv 76 7K - 79 16,32,64,128,4096 kqueue 0 0K - 22 128,1024 proc-args 27 2K - 88959 16,32,64,128,256 ata_generic 1 1K - 1 1024 ithread 71 6K - 71 16,64,128 prison 2 3K - 10 16,2048 KTRACE 100 13K - 100 128 ad_driver 1 1K - 1 32 linker 115 337K - 219 16,32,256,1024,2048,4096 lockf 14 1K - 190 32,64 ip6ndp 4 1K - 5 64,128 temp 34 233K - 13958 16,32,64,128,256,1024,2048,4096 devbuf 2697 2896K - 2732 16,32,64,128,256,512,1024,2048,4096 module 280 18K - 280 64,128 acpidev 70 3K - 70 32 mtx_pool 1 4K - 1 4096 subproc 188 299K - 2841 256,4096 proc 2 8K - 2 4096 session 17 2K - 49 64 pgrp 25 2K - 385 64 cred 27 7K - 6152 256 uidinfo 4 2K - 24 32,1024 plimit 15 4K - 478 256 sysctltmp 0 0K - 479 16,32,64,128,256 sysctloid 3504 107K - 3617 16,32,64,128 sysctl 0 0K - 1254 16,32,64 callout 1 256K - 1 umtx 161 11K - 161 64 vimage 14 1K - 14 32 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 kbdmux 6 9K - 6 16,128,256,2048,4096 bus-sc 69 127K - 1729 16,32,64,128,256,512,1024,2048,4096 bus 797 35K - 4110 16,32,64,128,512,1024 clist 4 1K - 4 128 devstat 10 21K - 10 16,4096 eventhandler 76 5K - 76 32,64,128 kobj 191 382K - 258 2048 rman 171 11K - 583 16,32,64 sbuf 0 0K - 514 16,32,64,128,256,512,1024,2048,4096 pci_link 16 2K - 16 64,128 ddb_capture 1 48K - 1 stack 0 0K - 2 128 taskqueue 13 1K - 13 16,64 Unitno 10 1K - 96 16,64 iov 0 0K - 314 64,128,256,512 select 33 3K - 33 64 ioctlops 0 0K - 4958 16,32,64,128,256,512,1024 msg 4 25K - 4 1024,4096 sem 4 7K - 4 256,1024,4096 shm 1 12K - 1 tty 17 9K - 19 512,1024 mbuf_tag 0 0K - 45 32,64 shmfd 1 4K - 1 4096 acpi_perf 1 1K - 1 128 pcb 14 79K - 65 16,64,512,1024,2048,4096 soname 5 1K - 306 16,32,128 biobuf 83 166K - 104 2048 vfscache 1 512K - 1 cl_savebuf 0 0K - 3 32 vfs_hash 1 256K - 1 vnodes 2 1K - 2 128 vnodemarker 0 0K - 874 512 mount 136 5K - 1600 16,32,64,128,256,1024 entropy 1024 64K - 1024 64 BPF 3 1K - 4 64 ether_multi 17 1K - 18 16,32,64 ifaddr 43 12K - 54 16,32,64,128,256,512,2048 ifnet 4 4K - 5 128,1024 clone 5 20K - 5 4096 arpcom 1 1K - 1 16 lltable 9 3K - 14 128,256 USBdev 20 6K - 20 32,128,1024 USB 35 6K - 35 16,32,64,1024 routetbl 53 259K - 204 16,32,64,128,256,512 igmp 3 1K - 4 128 DEVFS1 102 26K - 116 256 DEVFS3 237 30K - 716 128 in_multi 3 1K - 3 128 DEVFS2 102 2K - 104 16 sctp_iter 0 0K - 11 128 sctp_ifn 3 1K - 3 128 sctp_ifa 6 1K - 9 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 11 16 hostcache 1 16K - 1 syncache 1 72K - 1 DEVFS_RULE 37 9K - 173 32,256 DEVFS 35 1K - 102 16,64 in6_multi 12 2K - 12 16,256 mld 3 1K - 4 128 NFS FHA 1 1K - 1 1024 rpc 2 5K - 2 128,4096 audit_evclass 170 3K - 209 16 savedino 0 0K - 197 256 dirrem 8 1K - 211 32 mkdir 0 0K - 208 32 diradd 9 1K - 341 64 freefile 0 0K - 156 32 freeblks 0 0K - 86 256 freefrag 0 0K - 24 32 allocdirect 1 1K - 305 128 bmsafemap 3 1K - 101 64 newblk 1 1K - 306 64,256 inodedep 12 258K - 441 128 pagedep 4 33K - 216 64 ufs_dirhash 63 12K - 63 16,32,64,128,512 ufs_mount 12 25K - 12 256,2048,4096 vm_pgdata 2 65K - 2 64 pfs_nodes 20 3K - 20 128 atkbddev 2 1K - 2 32 acpica 2661 133K - 53036 16,32,64,128,256,512,1024 apmdev 1 1K - 1 64 acpitask 0 0K - 4 32 GEOM 140 28K - 915 16,32,64,128,512,1024 CAM dev queue 1 1K - 1 64 isadev 8 1K - 8 64 io_apic 1 1K - 1 1024 agp 1 1K - 1 16 memdesc 1 4K - 1 4096 CAM queue 3 1K - 3 16 msi 2 1K - 2 64 nexusdev 4 1K - 4 16 acpisem 34 3K - 34 64 CAM SIM 1 1K - 1 128 cdev 12 2K - 12 128 CAM periph 2 1K - 9 16,32,64,128 feeder 406 7K - 473 16,64 ratefeed 2 21K - 12 64 mixer 2 8K - 2 4096 hdac 7 16K - 7 64,128,256,512,1024,2048 UNIONFS path 20 1K - 11802 16,32 UNIONFS node 36 3K - 28877 64 UNIONFS hash 22 2K - 17825 64 UNIONFS mount 2 1K - 8 32 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 102, 18, 102, 0 UMA Zones: 888, 0, 102, 2, 102, 0 UMA Slabs: 284, 0, 555, 5, 828, 0 UMA RCntSlabs: 544, 0, 67, 3, 67, 0 UMA Hash: 128, 0, 3, 27, 3, 0 16 Bucket: 76, 0, 52, 48, 75, 0 32 Bucket: 140, 0, 50, 6, 72, 0 64 Bucket: 268, 0, 47, 9, 94, 7 128 Bucket: 524, 0, 62, 1, 853, 118 VM OBJECT: 124, 0, 1736, 186, 43049, 0 MAP: 136, 0, 7, 22, 7, 0 KMAP ENTRY: 68, 56336, 35, 245, 2888, 0 MAP ENTRY: 68, 0, 680, 384, 79284, 0 DP fakepg: 68, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 249, 124, 249, 0 16: 16, 0, 3630, 430, 45402, 0 32: 32, 0, 2355, 470, 35648, 0 64: 64, 0, 4661, 413, 66532, 0 128: 128, 0, 2430, 270, 86950, 0 256: 256, 0, 755, 130, 13027, 0 512: 512, 0, 63, 25, 1366, 0 1024: 1024, 0, 27, 153, 3337, 0 2048: 2048, 0, 313, 79, 563, 0 4096: 4096, 0, 122, 46, 6141, 0 Files: 56, 0, 61, 274, 15058, 0 TURNSTILE: 72, 0, 162, 48, 162, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 676, 0, 66, 54, 2719, 0 THREAD: 568, 0, 141, 20, 141, 0 SLEEPQUEUE: 40, 0, 162, 133, 162, 0 VMSPACE: 228, 0, 26, 76, 2679, 0 cpuset: 40, 0, 3, 273, 18, 0 audit_record: 856, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 0, 134, 1, 0 mbuf: 256, 0, 5, 257, 229, 0 mbuf_cluster: 2048, 25600, 128, 6, 128, 0 mbuf_jumbo_page: 4096, 12800, 0, 0,