search for: ithread_loop

...() at sf_buf_mext+0x3c mb_free_ext() at mb_free_ext+0x99 sbdrop_internal() at sbdrop_internal+0x1e8 tcp_do_segment() at tcp_do_segment+0x1512 tcp_input() at tcp_input+0x7f7 ip_input() at ip_input+0xa8 ether_demux() at ether_demux+0x1b4 ether_input() at ether_input+0x1bb bge_intr() at bge_intr+0x3ca ithread_loop() at ithread_loop+0x180 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffea28fd30, rbp = 0 --- Uptime: 36m47s Physical memory: 4087 MB Dumping 708 MB: 693 677 661 645 629 613 597 581 565 549 533 517 501 485 469 453 437 421 405 389 373 357...

...r/src/sys/netinet/tcp_input.c:1201 #6 0xc0740147 in ip_input (m=0xc1c09100) at /usr/src/sys/netinet/ip_input.c:778 #7 0xc07171ff in netisr_processqueue (ni=0xc09ca4f8) at /usr/src/sys/net/netisr.c:236 #8 0xc07174be in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #9 0xc06740e5 in ithread_loop (arg=0xc19c3280) at /usr/src/sys/kern/kern_intr.c:547 #10 0xc0673110 in fork_exit (callout=0xc067402c <ithread_loop>, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 #11 0xc0894a1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 Now the output of bt full:...

...0xc05623aa, esp = 0xdd4f6c34, ebp = 0xdd4f6c40 --- callout_reset(c3a8552c,13,c0561940,c3a852b8,c3612690,...) at 0xc05623aa = callout_reset+0x14a realitexpire(c3a852b8,2d6100,c3612690,1,dd4f6cbc,...) at 0xc0561ab6 = realitexpire+0x176 softclock(0,0,c0747617,4a1,0,...) at 0xc0562c25 = softclock+0x235 ithread_loop(c35e5a20,dd4f6d38,0,0,0,...) at 0xc053268b = ithread_loop+0x1cb fork_exit(c05324c0,c35e5a20,dd4f6d38) at 0xc052eda1 = fork_exit+0xa1 fork_trampoline() at 0xc06f46b0 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdd4f6d70, ebp = 0 --- Some debugging: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0...

Hello, Since FreeBSD 9.1 I have strange problems with the distribution. Some servers are rebooting without any kernel panic, instanly. First i thought it's a problem with my KVM system, but one of my FreeBSD under a Dell R210 have the same problem. The servers concerned are now: - Monitoring server - LDAP test server - Some other servers, randomly (not in production). First i thought it's

...a ed driver bug (based on reports of similar panics with different NICs, notably nge) and one is a filesystem corruption problem. Here's the process that I go through to reliably reproduce both problems. 1) Boot machine in multi-user mode 2) After ifconfig ed0, machine panics with a trap 12 in ithread_loop. 3) In debugger, reset (or panic to get vmcore) 4) Reboot in multi-user mode, but set "hint.ed.0.disabled=1" in the boot loader (to avoid ifconifg panic) 5) Root filesystem is fsckd; all other filesystems are scheduled for background fsck 6) Encounter panic "ffs_valloc: dup alloc&quo...

...le_wait+0x20f _mtx_lock_sleep() at _mtx_lock_sleep+0x89 sf_buf_mext() at sf_buf_mext+0xa3 mb_free_ext() at mb_free_ext+0x64 sbdrop_locked() at sbdrop_locked+0xb8 tcp_input() at tcp_input+0x255e ip_input() at ip_input+0x100 netisr_processqueue() at netisr_processqueue+0x78 swi_net() at swi_net+0x14d ithread_loop() at ithread_loop+0x162 fork_exit() at fork_exit+0x86 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb18ecd00, rbp = 0 --- db> Online 00:33show reg cs 0x8 ss 0x10 rax 0x28 rcx 0xfffffffe rdx 0xcd r...

...5af3 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:299 No locals. #11 0xc052fbcb in ithread_execute_handlers (p=0xc6bef860, ie=0xc6c44e80) at /usr/src/sys/kern/kern_intr.c:682 ih = (struct intr_handler *) 0xc6cc5080 ihn = (struct intr_handler *) 0x0 #12 0xc052fd27 in ithread_loop (arg=0xc6c62550) at /usr/src/sys/kern/kern_intr.c:766 intr_event = (struct intr_thread *) 0xc6c62550 ie = (struct intr_event *) 0xc6c44e80 td = (struct thread *) 0xc6bf0300 p = (struct proc *) 0xc6bef860 #13 0xc052e4b0 in fork_exit (callout=0xc052fcc0 <ithread_loop>, arg=0x1, frame=0...

...0xc051b195 in ata_end_transaction (request=0xc7bedd80) at /usr/src/sys/dev/ata/ata-lowlevel.c:386 #9 0xc05053f2 in ata_interrupt (data=0xc6a37c00) at /usr/src/sys/dev/ata/ata-all.c:343 #10 0xc0506225 in ata_generic_intr (data=0xc69b9b00) at /usr/src/sys/dev/ata/ata-chipset.c:230 #11 0xc07bd1db in ithread_loop (arg=0xc69f7a70) at /usr/src/sys/kern/kern_intr.c:1088 #12 0xc07b9d29 in fork_exit (callout=0xc07bd020 <ithread_loop>, arg=0xc69f7a70, frame=0xc6779d38) at /usr/src/sys/kern/kern_fork.c:810 #13 0xc0ac5f60 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 Regards Raphael --...

...),%eax db> tr Tracing pid 22 tid 100024 td 0xc1619600 xpt_freeze_devq(c16c8300,1) at xpt_freeze_devq+0x18 ahc_handle_seqint(c1583800,71) at ahc_handle_seqint+0x224 ahc_platform_intr(c1583800) at ahc_platform_intr+0x20a ithread_execute_handlers(c1618624,c1589780) at ithread_execute_handlers+0x125 ithread_loop(c16156a0,c6aadd38) at ithread_loop+0x56 fork_exit(c0524560,c16156a0,c6aadd38) at fork_exit+0x6f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc6aadd6c, ebp = 0 --- db> show registers cs 0x20 ds 0x28 es 0x28 fs...

Rarely, a geli partition I have freezes a process in bufwait state. It occurs after an ATA timeout message: Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 The geli partition resides on an Intel MatrixRAID RAID1 mirror using the ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process does not work. Rebooting is the only solution, yet the

...c() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x86 ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 ixgbe_rxeof() at ixgbe_rxeof+0x1b9 ixgbe_msix_que() at ixgbe_msix_que+0x8d intr_event_execute_handlers() at intr_event_execute_handlers+0x6a ithread_loop() at ithread_loop+0xb4 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe [5] FreeBSD XY.hostpoint.net 9.1-RC3 FreeBSD 9.1-RC3 #4 r242695: Wed Nov 7 11:33:17 UTC 2012 root at XY.hostpoint.ch:/usr/obj/usr/src/sys/HOSTPOINT amd64 kernconf: ---- include GENERIC ident HOST...