Re: panic m_demote: m_nextpkt not NULL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2014 12:24, Gleb Smirnoff wrote: On Fri, Sep 05, 2014 at 08:38:10AM -0700, Mark Atkinson wrote: M r271093 GENERIC amd64. Received this panic in the tcp reassembly code: M Unread portion of the kernel message buffer: M panic: m_demote: m_nextpkt not NULL M cpuid = 0 Sorry for that. Was fixed in r271123. Thank you and Jean-Sébastien for the pointer, I was able rebuild the kernel quickly on Fri with just this change and it's working fine. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQN2jgACgkQrDN5kXnx8yZjlgCfcIyo87hclmT7YPVws/X0DAap PK8AoKA7G9IQGO7Om0s0fXkwvzGtKZaR =HSx2 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic m_demote: m_nextpkt not NULL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 r271093 GENERIC amd64. Received this panic in the tcp reassembly code: Unread portion of the kernel message buffer: panic: m_demote: m_nextpkt not NULL cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011331b410 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011331b4c0 vpanic() at vpanic+0x189/frame 0xfe011331b540 kassert_panic() at kassert_panic+0x139/frame 0xfe011331b5b0 m_demote() at m_demote+0x79/frame 0xfe011331b5e0 sbappendstream_locked() at sbappendstream_locked+0x4b/frame 0xfe011331b600 tcp_reass() at tcp_reass+0x3bd/frame 0xfe011331b660 tcp_do_segment() at tcp_do_segment+0x1b01/frame 0xfe011331b750 tcp_input() at tcp_input+0xf67/frame 0xfe011331b890 ip_input() at ip_input+0xce/frame 0xfe011331b8e0 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfe011331b950 ether_demux() at ether_demux+0x141/frame 0xfe011331b980 ether_nh_input() at ether_nh_input+0x32a/frame 0xfe011331b9b0 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfe011331ba20 ether_input() at ether_input+0x4f/frame 0xfe011331ba50 if_input() at if_input+0xa/frame 0xfe011331ba60 em_rxeof() at em_rxeof+0x2bd/frame 0xfe011331bae0 em_handle_que() at em_handle_que+0x40/frame 0xfe011331bb20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe011331bb80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe011331bbb0 fork_exit() at fork_exit+0x84/frame 0xfe011331bbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe011331bbf0 - --- trap 0, rip = 0, rsp = 0xfe011331bcb0, rbp = 0 --- Uptime: 41m32s Dumping 357 out of 3937 MB:..5%..14%..23%..32%..41%..54%..63%..72%..81%..95% (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x8090d6b7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x8090dc58 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x8090da89 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:634 #4 0x80983b59 in m_demote (m0=0xf80067044c00, all=value optimized out) at /usr/src/sys/kern/uipc_mbuf.c:402 #5 0x8098b0ab in sbappendstream_locked (sb=0xf8009914c090, m=0xf80067044c00) at /usr/src/sys/kern/uipc_sockbuf.c:532 #6 0x80ac15ed in tcp_reass (tp=0xf80099115000, th=value optimized out, tlenp=value optimized out, m=value optimized out) at /usr/src/sys/netinet/tcp_reass.c:264 #7 0x80abbb41 in tcp_do_segment (m=0xf80067044c00, th=0xf80067091022, so=0xf8009914c000, tp=value optimized out, drop_hdrlen=value optimized out, tlen=1448, ti_locked=1) at /usr/src/sys/netinet/tcp_input.c:2917 #8 0x80ab9667 in tcp_input (mp=value optimized out, offp=value optimized out, proto=0) at /usr/src/sys/netinet/tcp_input.c:1383 #9 0x80a4f6fe in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:729 #10 0x809e9046 in netisr_dispatch_src (proto=value optimized out, source=value optimized out, m=0xf80067044c00) at /usr/src/sys/net/netisr.c:968 #11 0x809dfe91 in ether_demux (ifp=value optimized out, m=0xf80067044c00) at /usr/src/sys/net/if_ethersubr.c:775 #12 0x809e0bea in ether_nh_input (m=value optimized out) at /usr/src/sys/net/if_ethersubr.c:582 #13 0x809e9046 in netisr_dispatch_src (proto=value optimized out, source=value optimized out, m=0xf80067044c00) at /usr/src/sys/net/netisr.c:968 #14 0x809e019f in ether_input (ifp=0xf80002c08000, m=0x0) at /usr/src/sys/net/if_ethersubr.c:683 #15 0x809dd1da in if_input (ifp=0x0, sendmp=0x0) at /usr/src/sys/net/if.c:3909 #16 0x804dd51d in em_rxeof (count=99) at /usr/src/sys/dev/e1000/if_em.c:4485 #17 0x804dce00 in em_handle_que (context=0xfed23000, pending=value optimized out) at /usr/src/sys/dev/e1000/if_em.c:1522 #18 0x80956bb0 in taskqueue_run_locked (queue=0xf80002957000) at /usr/src/sys/kern/subr_taskqueue.c:356 #19 0x809576ab in taskqueue_thread_loop (arg=value optimized out) at /usr/src/sys/kern/subr_taskqueue.c:623 #20 0x808db5f4 in fork_exit ( callout=0x80957610 taskqueue_thread_loop, arg=0xfed25738, frame=0xfe011331bc00) at /usr/src/sys/kern/kern_fork.c:977 #21 0x80d0607e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #22 0x in ?? () (kgdb) frame 4 #4 0x80983b59 in m_demote (m0=0xf80067044c00, all=value optimized out) at /usr/src/sys/kern/uipc_mbuf.c:402 402 KASSERT(m-m_nextpkt == NULL, (kgdb) list 397 m_tag_delete_chain(m, NULL); 398 m-m_flags = ~M_PKTHDR; 399
Re: panic on vt / kms rv610
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/15/2014 04:52, Aleksandr Rybalko wrote: On Wed, 14 May 2014 08:29:32 -0700 Mark Atkinson atkin...@gmail.com wrote: I updated -current to r265915 w/ amd64 kernel and I get a panic when I startx instantly (no video output of panic). There is a LOR right before the panic. Hello Mark, looks like it is kms driver load problem. I think updating to r265927 or more fresh will fix your problem. Sorry for inconvenience. I knew I was missing that revision, but looking at the diff It didn't seem like it would prevent loading, but low and behold it works. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN2HrAACgkQrDN5kXnx8ybCAwCgpzZY4INjEbzRy6ppGR+7CxNv TcQAniC5uXTG6AE0QVug6wdiddcoAL7J =ilGJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
New ufs LOR.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mounted a drive with -o sync this morning on r266123 and got a LOR I had not seen before (ufs/soft updates) lock order reversal: 1st 0xf8005904db78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 2nd 0xfe00efe72080 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xf8005921bb78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011a213380 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011a213430 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe011a2134c0 __lockmgr_args() at __lockmgr_args+0x9ca/frame 0xfe011a2135f0 ffs_lock() at ffs_lock+0x84/frame 0xfe011a213640 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe011a213670 _vn_lock() at _vn_lock+0xaa/frame 0xfe011a2136e0 vget() at vget+0x67/frame 0xfe011a213720 vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfe011a213770 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe011a213800 softdep_sync_buf() at softdep_sync_buf+0xafc/frame 0xfe011a2138e0 ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfe011a213960 softdep_fsync() at softdep_fsync+0x59e/frame 0xfe011a213a00 ffs_fsync() at ffs_fsync+0x60/frame 0xfe011a213a30 VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf7/frame 0xfe011a213a60 sys_fsync() at sys_fsync+0x175/frame 0xfe011a213ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe011a213bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe011a213bf0 - --- syscall (95, FreeBSD ELF64, sys_fsync), rip = 0x80308230a, rsp = 0x7fffe688, rbp = 0x7fffe6a0 --- Also I always get this one during installworld for, like the last 2.5 years or more. Any chance on nuking it? lock order reversal: 1st 0xfe00ef0962e0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3081 2nd 0xf8000652e400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011a009410 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011a0094c0 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe011a009550 _sx_xlock() at _sx_xlock+0x75/frame 0xfe011a009590 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe011a0095d0 ufs_direnter() at ufs_direnter+0x6a0/frame 0xfe011a009690 ufs_mkdir() at ufs_mkdir+0x89c/frame 0xfe011a009880 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf7/frame 0xfe011a0098b0 kern_mkdirat() at kern_mkdirat+0x209/frame 0xfe011a009ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe011a009bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe011a009bf0 - --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x80095550a, rsp = 0x7fffea08, rbp = 0x7fffebd0 --- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN2IXkACgkQrDN5kXnx8yas9wCfdrUSzmr647EhHndH7RR5tSMI QPAAnj+yA/XZQ+ZsnEc3l8SiC7q4L2n5 =gqxv -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic on vt / kms rv610
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated -current to r265915 w/ amd64 kernel and I get a panic when I startx instantly (no video output of panic). There is a LOR right before the panic. This is built using the VT kernel definition. loading the old kernel built @ r264316 continues to load fine. here's what normal under the old kernel looks like $ kldstat Id Refs AddressSize Name 1 53 0x8020 19b8a48 kernel 21 0x81c11000 9d81 linprocfs.ko 31 0x81c1b000 44ba6linux.ko 41 0x81c6 2349 ums.ko 51 0x81c63000 6809 uftdi.ko 61 0x81c6a000 3b95 ucom.ko 71 0x81c6e000 16fd uhid.ko 81 0x81c7 115db3 radeonkms.ko 91 0x81d86000 48761drm2.ko 104 0x81dcf000 2004 iicbus.ko 111 0x81dd2000 1a3f iic.ko 121 0x81dd4000 1e35 iicbb.ko 131 0x81dd6000 1066 radeonkmsfw_RV610_pfp.ko 141 0x81dd8000 5b63 radeonkmsfw_RV610_me.ko 151 0x81dde000 1361 radeonkmsfw_R600_rlc.ko relevant boot messages on problematic r265915: May 12 23:41:00 kern.crit moby kernel: VT: running with driver vga. [...] May 12 23:41:00 kern.crit moby kernel: vgapci0: VGA-compatible display port 0xdc00-0xdcff mem 0xd000-0xdfff,0xfe9f-0xfe9f irq 16 at device 0.0 on pci1 May 12 23:41:00 kern.crit moby kernel: vgapci0: Boot video device Point of failure (also available at http://pastebin.com/scubtJE6 so the line wrap doesn't make you go crazy): May 12 23:42:05 kern.crit moby kernel: info: [drm] Initialized drm 1.1.0 20060810 May 12 23:42:05 kern.crit moby kernel: drmn0: Radeon HD 2400 XT on vgapci0 May 12 23:42:05 kern.crit moby kernel: info: [drm] RADEON_IS_PCIE May 12 23:42:05 kern.crit moby kernel: info: [drm] initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02). May 12 23:42:05 kern.crit moby kernel: info: [drm] register mmio base: 0xFE9F May 12 23:42:05 kern.crit moby kernel: info: [drm] register mmio size: 65536 May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_atrm_get_bios: === Try ATRM... May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=94c1 May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_atrm_get_bios: Get ACPI device handle May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_acpi_vfct_bios: === Try VFCT... May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_acpi_vfct_bios: Get VFCT ACPI table May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_acpi_vfct_bios: Failed to get VFCT table: AE_NOT_FOUND May 12 23:42:05 kern.crit moby kernel: info: [drm] igp_read_bios_from_vram: === Try IGP's VRAM... May 12 23:42:05 kern.crit moby kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd000 May 12 23:42:05 kern.crit moby kernel: info: [drm] igp_read_bios_from_vram: Map address: 0xf800d000 (262144 bytes) May 12 23:42:05 kern.crit moby kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_read_bios: === Try PCI Expansion ROM... May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_read_bios: Map address: 0xf80c (131072 bytes) May 12 23:42:05 kern.crit moby kernel: info: [drm] ATOM BIOS: 113 May 12 23:42:05 kern.crit moby kernel: drmn0: info: VRAM: 256M 0x - 0x0FFF (256M used) May 12 23:42:05 kern.crit moby kernel: drmn0: info: GTT: 512M 0x1000 - 0x2FFF May 12 23:42:05 kern.crit moby kernel: info: [drm] Detected VRAM RAM=256M, BAR=256M May 12 23:42:05 kern.crit moby kernel: info: [drm] RAM width 64bits DDR May 12 23:42:05 kern.crit moby kernel: [TTM] Zone kernel: Available graphics memory: 2016864 kiB May 12 23:42:05 kern.crit moby kernel: [TTM] Initializing pool allocator May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: 256M of VRAM memory ready May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: 512M of GTT memory ready. May 12 23:42:05 kern.crit moby kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). May 12 23:42:05 kern.crit moby kernel: info: [drm] Driver supports precise vblank timestamp query. May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: irq initialized. May 12 23:42:05 kern.crit moby kernel: info: [drm] GART: num cpu pages 131072, num gpu pages 131072 May 12 23:42:05 kern.crit moby kernel: info: [drm] probing gen 2 caps for device 8086:29b1 = 1/0 May 12 23:42:05 kern.crit moby kernel: info: [drm] Loading RV610 Microcode May 12 23:42:05 kern.crit moby kernel: firmware: 'radeonkmsfw_RV610_pfp' version 0: 2304 bytes loaded at 0x81fd60d0 May 12 23:42:05 kern.crit moby kernel: firmware: 'radeonkmsfw_RV610_me' version 0: 21504 bytes loaded at 0x81fd80d0 May 12 23:42:05 kern.crit moby kernel:
Re: clang 3.2 RC2 miscompiles libgcc?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/2013 12:23, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov
wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder
wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc #include stdexcept
void f2(void) { std::string s; throw
std::runtime_error(foo); }
void f1(void) { f2(); }
int main(void) { try { std::string s1, s2; f1(); return 0; }
catch (const std::exception ) { return 1; } } $ g++ -O2
-finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error
(core dumped) ./a.out
What is the backtrace ? Compile the system libraries (ld-elf,
libc, libgcc etc) with the debugging information and obtain the
backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
__a=@0x7fffd628) at atomicity.h:69 69 _Atomic_word
__result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose
(this=0x7fffd62fe8, __a=@0x7fffd628) at atomicity.h:69 #1
0x00080089d168 in ~basic_string (this=0x7fffd62fe8) at
basic_string.h:482 #2 0x00401038 in main () at
throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old
libgcc_s.so.1 instead makes the program run correctly.
It seems the std::string destructor is called with an invalid
this pointer for s2:
(gdb) r Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12 12 int main(void)
{ (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4
(gdb) c Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1 (gdb) f 2 #2 0x00400f51 in f2 ()
at throw-crash.cc:5 5 throw std::runtime_error(foo);
(gdb) p s $1 = (string *) 0x7fffd600 (gdb) up #3
0x00400fe2 in main () at throw-crash.cc:15 15
f1(); (gdb) p s1 $2 = (string *) 0x7fffd650 (gdb) p s2 $3 =
(string *) 0x7fffd640 (gdb) b 'std::basic_stringchar,
std::char_traitschar, std::allocatorchar ::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at
basic_string.h:279 279 _M_data() const (gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at
basic_string.h:279 279 _M_data() const (gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at
basic_string.h:279 279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called
with 0x7fffd60f which is also very unaligned. I think this is
the reason for the crash.
Thank you for digging more.
In fact, it is more likely that there is some bug or
incompatibility in c++ unwinder than in the libgcc itself, but as
you noted, a compiler bug is also possible.
Anyway, I was mostly looking could the backtrace starts in rtld.
Rtld bug also cannot be excluded at this stage, but it not much
likely.
Since this is similar to the pain I was seeing rebuilding everything
with clang so I have been following this thread with much interest.
Just to add more data, I get different results. This is all i386.
gcc v464 built using an earlier clang from -current world/kernel
r243027. boost was also built using this revision.
$ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x2806e000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x280c2000)
libm.so.5 = /lib/libm.so.5 (0x281a1000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c2000)
libc.so.7 = /lib/libc.so.7 (0x281cd000)
libthr.so.3 = /lib/libthr.so.3 (0x28317000)
[atkinson@moby ~/dev]$ ./unwinder
Abort trap (core dumped)
clang 32 built from -current world/kernel r244958 works just fine.
$ c++ -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ./unwinder
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x2806d000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x280c1000)
libm.so.5 = /lib/libm.so.5 (0x281a)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c1000)
libc.so.7 = /lib/libc.so.7 (0x281cc000)
libthr.so.3 = /lib/libthr.so.3 (0x28316000)
It might be useful to expand -O2 into all it's -f components and
elminate them one by one until the crash is not reproducable.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using
Re: loopback interface broken on current
On 1/1/2013 2:22 AM, Gleb Smirnoff wrote: Manfred, On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote: M For the past few days the loopback interface 127.0.0.1 is broken on current. M The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012 M Here are some of the errors from current today: Can you please track this down to the specific revision that made the regression? The timeframe is samll, so binary search probably won't take long time. nc -l 127.0.0.1 port works for me on r244911 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with threads/destructors in -current with llvm/clang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2012 09:29, Dimitry Andric wrote: On 2012-12-07 17:43, Mark Atkinson wrote: On 12/7/2012 6:08 AM, Dimitry Andric wrote: ... With this patch (placed in /usr/ports/devel/dbus-qt4/files), qdbus starts up and exits normally for me. I did not do any other rigorous testing, though. :) Thanks for the awesome analysis. I will endeavor to figure out the bug in automoc4 that keeps it segfaulting randomly during compilation. Weirdly it segfaults reliably under portmaster, but may work just fine under just make. Try running it under valgrind. If it does undefined things, it may work or not work randomly, and valgrind usually catches this. OK, so this one's a bit of a headscratcher, but maybe someone has some ideas. automoc4 always dies in libthr. #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP 101795/automoc4.bin)] (gdb) bt #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 #1 0x2864a046 in pthread_getspecific () from /lib/libthr.so.3 #2 0x28649e9a in pthread_getspecific () from /lib/libthr.so.3 #3 0x2864dbfb in pthread_kill () from /lib/libthr.so.3 #4 0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #5 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #6 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #7 0x28075e00 in ?? () #8 0x286b4d30 in pipe () from /lib/libc.so.7 #9 0x280712ac in ?? () from /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? () from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in ?? () #15 0x0001 in ?? () #16 0x in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0 0x2876c3a7 in select () from /lib/libc.so.7 (gdb) bt #0 0x2876c3a7 in select () from /lib/libc.so.7 #1 0x286481ab in select () from /lib/libthr.so.3 #2 0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #3 0x282c23b2 in select_msecs (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, timeout=-1) at io/qprocess_unix.cpp:998 #4 0x282c33f3 in QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at io/qprocess_unix.cpp:1219 #5 0x28240b50 in QProcess::waitForFinished (this=0xbfbfa1e8, msecs=-1) at io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor (this=0xbfbfab00, msg=@0xbfbfa2e0) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00, sourceFile=@0x29011658, mocFileName=@0x2901165c) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #8 0x0804f13b in AutoMoc::run (this=0xbfbfab00) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #9 0x0804aaef in main (argc=6, argv=0xbfbfab98) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 I noticed that qt_safe_select() used a register bound variable for the return value, but removing that didn't alleviate the error. The pthread_getspecific() manpage mentions that if the key is deleted then the behavior is undefined -- so maybe this? It's definitely seems like a race condition of some kind. Valgrind will kill any run of automoc4 and doesn't like some instruction after the qt_safe_select() call: vex x86-IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 ==33074== valgrind: Unrecognised instruction at address 0x380434e9. ==33074==at 0x380434E9: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd) ==33074==by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) (qcore_unix.cpp:83) ==33074==by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) (qprocess_unix.cpp:998) ==33074==by 0x28021D: QProcessPrivate::waitForStarted(int) (qprocess_unix.cpp:1031) ==33074==by 0x1FFA02: QProcess::waitForStarted(int) (qprocess.cpp:1687) ==33074==by 0x1FEAEA: QProcess::waitForFinished(int) (qprocess.cpp:1752) ==33074==by 0x805487A: AutoMoc::echoColor(QString const) (kde4automoc.cpp:74) ==33074==by 0x805264F: AutoMoc::generateMoc(QString const, QString const) (kde4automoc.cpp:569) ==33074==by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) ==33074==by 0x804AAEE: main (kde4automoc.cpp:114) Full valgrind output is at http://pastebin.com/KQTKYGX5 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDGHWEACgkQrDN5kXnx8yZEUwCfXhKBqCJKJcfomG6mHo6ataaw x60An36saeyL2b09CR2Z/zL84KzjPjsQ =EzG3 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with threads/destructors in -current with llvm/clang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2012 10:25, Konstantin Belousov wrote: On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: On 12/07/2012 09:29, Dimitry Andric wrote: On 2012-12-07 17:43, Mark Atkinson wrote: On 12/7/2012 6:08 AM, Dimitry Andric wrote: ... With this patch (placed in /usr/ports/devel/dbus-qt4/files), qdbus starts up and exits normally for me. I did not do any other rigorous testing, though. :) Thanks for the awesome analysis. I will endeavor to figure out the bug in automoc4 that keeps it segfaulting randomly during compilation. Weirdly it segfaults reliably under portmaster, but may work just fine under just make. Try running it under valgrind. If it does undefined things, it may work or not work randomly, and valgrind usually catches this. OK, so this one's a bit of a headscratcher, but maybe someone has some ideas. automoc4 always dies in libthr. Build rtld, libc and libthr with the debug symbols to get useful backtrace. #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP 101795/automoc4.bin)] (gdb) bt #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 #1 0x2864a046 in pthread_getspecific () from /lib/libthr.so.3 #2 0x28649e9a in pthread_getspecific () from /lib/libthr.so.3 #3 0x2864dbfb in pthread_kill () from /lib/libthr.so.3 #4 0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #5 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #6 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #7 0x28075e00 in ?? () #8 0x286b4d30 in pipe () from /lib/libc.so.7 #9 0x280712ac in ?? () from /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? () from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in ?? () #15 0x0001 in ?? () #16 0x in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0 0x2876c3a7 in select () from /lib/libc.so.7 (gdb) bt #0 0x2876c3a7 in select () from /lib/libc.so.7 #1 0x286481ab in select () from /lib/libthr.so.3 #2 0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #3 0x282c23b2 in select_msecs (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, timeout=-1) at io/qprocess_unix.cpp:998 #4 0x282c33f3 in QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at io/qprocess_unix.cpp:1219 #5 0x28240b50 in QProcess::waitForFinished (this=0xbfbfa1e8, msecs=-1) at io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor (this=0xbfbfab00, msg=@0xbfbfa2e0) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00, sourceFile=@0x29011658, mocFileName=@0x2901165c) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #8 0x0804f13b in AutoMoc::run (this=0xbfbfab00) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #9 0x0804aaef in main (argc=6, argv=0xbfbfab98) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 I noticed that qt_safe_select() used a register bound variable for the return value, but removing that didn't alleviate the error. The pthread_getspecific() manpage mentions that if the key is deleted then the behavior is undefined -- so maybe this? It's definitely seems like a race condition of some kind. Valgrind will kill any run of automoc4 and doesn't like some instruction after the qt_safe_select() call: vex x86-IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 This is ud2, an instruction which generates a fault on purpose. So rebuild the system libraries with the debug symbols and show the backtrace. Hmm. Since I took out -O2 and added -g in rebuilding libthr/libc/rtld, I figured I needed to reproduce a new segfault, but the rtld side of things seems broken: #0 0xbf9fd01a in ?? () [New Thread 29003800 (LWP 100652/automoc4.bin)] [New Thread 29003080 (LWP 101395/automoc4.bin)] (gdb) bt #0 0xbf9fd01a in ?? () #1 0xbf9fcd20 in ?? () #2 0x in ?? () (gdb) info thread 2 Thread 29003080 (LWP 101395/automoc4.bin) select () at select.S:3 * 1 Thread 29003800 (LWP 100652/automoc4.bin) 0xbf9fd01a in ?? () Current language: auto; currently asm (gdb) thread 2 [Switching to thread 2 (Thread 29003080 (LWP 101395/automoc4.bin))]#0 select () at select.S:3 3 RSYSCALL(select) (gdb) bt #0 select () at select.S:3 #1 0x28659028 in __select (numfds=17, readfds=0xbfbfc1f0, writefds=0xbfbfc170, exceptfds=0x0, timeout=0x0) at /usr/src/lib/libthr/thread/thr_syscalls.c:539 #2 0x28372c49 in qt_safe_select (nfds=17, fdread=0xbfbfc1f0, fdwrite=0xbfbfc170, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #3 0x282cf3b2 in select_msecs (nfds=17, fdread
Re: problems with threads/destructors in -current with llvm/clang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2012 12:33, Konstantin Belousov wrote: Hmm. Since I took out -O2 and added -g in rebuilding libthr/libc/rtld, I figured I needed to reproduce a new segfault, but the rtld side of things seems broken: Use e.g. cd src/libexec/rtld-elf make DEBUG_FLAGS=-g clean all install This is really FAQ. It _is_ strange, because I did almost exactly that (dumped a temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf) The one I had problems with was libc since It needs a make depend in there. $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges contains: Length: 28 Version: 2 Offset into .debug_info: 0 Pointer Size: 4 Segment Size: 0 AddressLength 0x0e80 0x49 $ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlDGSeMACgkQrDN5kXnx8yYb6QCfQFO6o/At+srdpuRfI8jGCnqu ZJMAlir1UvA4mgE0k2ewP43ayPiepCM= =YVai -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with threads/destructors in -current with llvm/clang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/10/2012 12:45, Mark Atkinson wrote:
On 12/10/2012 12:33, Konstantin Belousov wrote:
Hmm. Since I took out -O2 and added -g in rebuilding
libthr/libc/rtld, I figured I needed to reproduce a new
segfault, but the rtld side of things seems broken:
Use e.g. cd src/libexec/rtld-elf make DEBUG_FLAGS=-g clean
all install This is really FAQ.
It _is_ strange, because I did almost exactly that (dumped a
temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf)
The one I had problems with was libc since It needs a make depend
in there.
$ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges
contains:
Length: 28 Version: 2 Offset
into .debug_info: 0 Pointer Size: 4 Segment Size:
0
AddressLength 0x0e80 0x49 $
So ignoring this weirdness, running under valgrind always segfaults
and the core seems useful.
#0 0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
#1 0x0061b71c in thr_sighandler (sig=20, info=0xbf9fd7b0, _ucp=0x0)
at /usr/src/lib/libthr/thread/thr_sig.c:182
#2 0x380434dc in ?? ()
#3 0x0014 in ?? ()
#4 0xbf9fd7b0 in ?? ()
#5 0x in ?? ()
(gdb) frame 0
#0 0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
(gdb) list
193 int cancel_enable;
194 int in_sigsuspend;
195 int err;
196
197 /* add previous level mask */
198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
199
200 /* add this signal's mask */
201 if (!(actp-sa_flags SA_NODEFER))
202 SIGADDSET(actp-sa_mask, sig);
(gdb) p actp
$1 = (struct sigaction *) 0xbf9fd490
(gdb) p *actp
$2 = {__sigaction_u = {__sa_handler = 0x288310
qt_sa_sigchld_handler(int), __sa_sigaction = 0x288310
qt_sa_sigchld_handler(int)}, sa_flags = 8, sa_mask = {__bits = {0,
0, 0, 0}}}
(gdb) p *ucp
Cannot access memory at address 0x0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z
X7UAn1ea4LbW8PHXL07BwraiVXakh1bU
=GktK
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with threads/destructors in -current with llvm/clang
On 12/7/2012 6:08 AM, Dimitry Andric wrote: On 2012-12-07 13:59, Dimitry Andric wrote: On 2012-12-06 18:12, Mark Atkinson wrote: Short backstory, I had recently upgraded my workstation to the latest current which included clang as default cc now. ... qdbus under kde segfaults in malloc with a huge recursion stack: ... This is a bug in qdbus; it uses a global static QDBusConnection object, and the order in which global destructors are called is undefined: ... The global static QDBusConnection object should be replaced by a singleton, as suggested here: Here is an alternative solution, where the QDBusConnection object is just a local variable in main(), and passed around as a const reference. To make the destructors work properly, I also replaced the exit() calls in main() with return statements. With this patch (placed in /usr/ports/devel/dbus-qt4/files), qdbus starts up and exits normally for me. I did not do any other rigorous testing, though. :) Thanks for the awesome analysis. I will endeavor to figure out the bug in automoc4 that keeps it segfaulting randomly during compilation. Weirdly it segfaults reliably under portmaster, but may work just fine under just make. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
problems with threads/destructors in -current with llvm/clang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Short backstory, I had recently upgraded my workstation to the latest current which included clang as default cc now. Compiling chromium failed for want of SSE2, which led me to recompile world with CPUTYPE?=core2. The original flag for world/ports was CPUTYPE?=i686. After recompilation chromium would sigbus on loading any extensions. I made a concerted effort to recompile the whole ports tree and base on clang to make sure the link stages were CPUTYPE clean, but I experienced the same behavior. Probably the best illustration of the type of problems I'm seeing is qdbus from /usr/ports/devel/dbus-qt4. Compiled with clang at r243950: qdbus under kde segfaults in malloc with a huge recursion stack: [...] #44740 0x282f7bd4 in QObject::QObject () from /usr/local/lib/qt4/libQtCore.so.4 #44741 0x281cb649 in QAdoptedThread::QAdoptedThread () from /usr/local/lib/qt4/libQtCore.so.4 #44742 0x281ce146 in QThreadData::current () from /usr/local/lib/qt4/libQtCore.so.4 #44743 0x282f7bd4 in QObject::QObject () from /usr/local/lib/qt4/libQtCore.so.4 #44744 0x281cb649 in QAdoptedThread::QAdoptedThread () from /usr/local/lib/qt4/libQtCore.so.4 #44745 0x281ce146 in QThreadData::current () from /usr/local/lib/qt4/libQtCore.so.4 #44746 0x282f7bd4 in QObject::QObject () from /usr/local/lib/qt4/libQtCore.so.4 #44747 0x281cb649 in QAdoptedThread::QAdoptedThread () from /usr/local/lib/qt4/libQtCore.so.4 #44748 0x281ce146 in QThreadData::current () from /usr/local/lib/qt4/libQtCore.so.4 #44749 0x281cbc05 in QThread::currentThread () from /usr/local/lib/qt4/libQtCore.so.4 #44750 0x28095d21 in QDBusConnectionPrivate::deleteYourself () from /usr/local/lib/qt4/libQtDBus.so.4 #44751 0x28089634 in QDBusConnection::~QDBusConnection () from /usr/local/lib/qt4/libQtDBus.so.4 #44752 0x0804b800 in __dtor__ZL10connection () #44753 0x28660417 in __cxa_finalize () from /lib/libc.so.7 #44754 0x2860747a in exit () from /lib/libc.so.7 #44755 0x0804c125 in main () (gdb) Compiled with gcc46, no segfault, and seems to follow a normal chain to exiting. [Switching to Thread 29003080 (LWP 100603/qdbus)] Breakpoint 2, 0x285f8462 in exit () from /lib/libc.so.7 (gdb) n Single stepping until exit from function exit, which has no line number information. 0x28677fc0 in f_prealloc () from /lib/libc.so.7 (gdb) n Single stepping until exit from function f_prealloc, which has no line number information. 0x2861bd30 in register_printf_render_std () from /lib/libc.so.7 (gdb) n Single stepping until exit from function register_printf_render_std, which has no line number information. 0x28678190 in fflush () from /lib/libc.so.7 (gdb) n Single stepping until exit from function fflush, which has no line number information. 0x2861bd7e in register_printf_render_std () from /lib/libc.so.7 (gdb) n Single stepping until exit from function register_printf_render_std, which has no line number information. 0x28678190 in fflush () from /lib/libc.so.7 (gdb) n Single stepping until exit from function fflush, which has no line number information. 0x2861bd7e in register_printf_render_std () from /lib/libc.so.7 (gdb) n Single stepping until exit from function register_printf_render_std, which has no line number information. 0x28678190 in fflush () from /lib/libc.so.7 (gdb) n Single stepping until exit from function fflush, which has no line number information. 0x2861bd7e in register_printf_render_std () from /lib/libc.so.7 (gdb) n Single stepping until exit from function register_printf_render_std, which has no line number information. 0x28677fdf in f_prealloc () from /lib/libc.so.7 (gdb) n Single stepping until exit from function f_prealloc, which has no line number information. 0x285f848b in exit () from /lib/libc.so.7 (gdb) n Single stepping until exit from function exit, which has no line number information. Program exited normally. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDA0hcACgkQrDN5kXnx8yb/UACfbpACSvjZGIl7d7H30mb6dptX C2MAn2Jxfr/9MVKG4HzC1KOBl+N8EiLe =9pw6 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Setting up IPv6 in /etc/rc.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2010 11:04, Mark Murray wrote: Hi IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the following (which works): $ ifconfig gif0 create $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 $ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 128 $ route -n add -inet6 default 2001:::::1 $ ifconfig gif0 up ... when my non-working setup in /etc/rc.conf contains gif_interfaces=gif0 gifconfig_gif0=192.168.0.2 11.22.33.44 gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 128 ipv6_defaultrouter=-inet6 default 2001:::::1 ... which used to work. The bit that fails is the bit where gif0 gets its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6=... and ifconfig_gif0_ipv6= The IPv6 endmpoints never make it onto gif0. This used to work, but setting up IPv6 in CURRENT is a moving target, and I can't find a working example any more. I've looked in /etc/defaults/rc.conf, but the gifN examples there are all devoid of any IPv6 examples. I found that my ipv6 tunnel setup needed to be dead last in startup. I could not get it to configure properly via rc.conf and come up. So I just setup the following script to run after the system comes up (using your ip examples): /etc/rc.d/rtadvd stop ifconfig gif0 inet6 2002001:::::2 2001:::::1 prefixlen 128 ifconfig gif0 inet6 -ifdisabled route add -inet6 default 2001:::::1 ifconfig internal inet6 2001:::::/64 eui64 ifconfig internal inet6 -ifdisabled /etc/rc.d/rtadvd start -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky4nTMACgkQrDN5kXnx8yYbSwCgl34QIrmZwCVF+em+ZoeJPOi0 S/cAnAzmCVxrsoiubNWEW8QWcR1dRlBN =rM+v -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: timer selection w/ one shot timer prevents HP DL385G5 from booting (was usb 3.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2010 08:04, Mark Atkinson wrote: On 10/05/2010 11:39, Mark Atkinson wrote: kern.eventtimer.periodic: 0 *sigh* Although I misspelled eventtimer as 'eventtimers' in loader.conf it still fails to boot without manually selecting the timer. It's also annoying since '~ ^b' fails to break when it hangs, but '~ ^r' will work if I give it twice with ALT_BREAK_TO_DEBUGGER. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyslRAACgkQrDN5kXnx8ybMzQCfbLwSk+W7RDmkBnzT4pgsc3oT I3oAnRMsbPJ1suKgeQ4zJ9M3nw3vM/Jp =GR7T -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
strange svnsync mirror problem.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I had problems building world this morning, and noticed the following error had occurred that caused svn update to exit: $ svn update svn: No such revision 207561 I keep a local svn mirror to update all my clients to, but I couldn't grab this revision from the repo: $ svnsync copy-revprops file:///usr/svnmirror/base 207561 svnsync: No such revision 207561 I can't seem to work around this error, other than diving into the repo and doing updates on directories that avoid revision 207561 (head/lib/libpam/modules/pam_krb5/pam_krb5.8) Trying to do that found other inconsistencies: svn: No such revision 207554 any suggestions appreciated. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvi6acACgkQrDN5kXnx8yaz3wCgipcByAgTnL+dBytiKEmaroCk tjEAoILtV3ySPfEw5O7Y4El2mRVHzeri =N0Zq -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: strange svnsync mirror problem.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/06/10 09:09, Mark Atkinson wrote: I had problems building world this morning, and noticed the following error had occurred that caused svn update to exit: $ svn update svn: No such revision 207561 I keep a local svn mirror to update all my clients to, but I couldn't grab this revision from the repo: $ svnsync copy-revprops file:///usr/svnmirror/base 207561 svnsync: No such revision 207561 I can't seem to work around this error, other than diving into the repo and doing updates on directories that avoid revision 207561 (head/lib/libpam/modules/pam_krb5/pam_krb5.8) Trying to do that found other inconsistencies: svn: No such revision 207554 any suggestions appreciated. Turns out to be corruption of my mirror. Restored my backup from a few months ago and resynced. Not sure how it got there, but I'll be making more frequent backups of it now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvjHLIACgkQrDN5kXnx8yZ8igCgg7Do0bJzQ8YNEzhXl37SbDDD iz0An0jCXv+vE7FoXLB7yYeEtQgAlaBv =C0Gd -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @ /usr/src/sys/dev/msk/if_msk.c:3589
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I updated to current yesterday and got the following 'witness_warn'
panic upon executing 'reboot':
suspending ithread with the following locks held:
exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @
/usr/src/sys/dev/msk/if_msk.c:3589
panic: witness_warn
cpuid = 0
KDB: enter: panic
Physical memory: 495 MB
Dumping 80 MB: 65 49 33 17 1
3579 static void
3580 msk_intr(void *xsc)
3581 {
3582 struct msk_softc *sc;
3583 struct msk_if_softc *sc_if0, *sc_if1;
3584 struct ifnet *ifp0, *ifp1;
3585 uint32_t status;
3586 int domore;
3587
3588 sc = xsc;
3589 MSK_LOCK(sc);
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkve11QACgkQrDN5kXnx8yZQ3wCeJHhG18+7uP0dr3rTsioaCQ4X
sw4AoICW3RKrMdO8q20GIhcT/GglUnWZ
=Az4t
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Unable to establish HE gif0 tunnel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated a border gateway yesterday from a Feb 23 kernel to a May 2 version kernel/world, and lost my connectivity to my gif0 HE tunnel. I've been using the following in /etc/rc.conf successfully for some time to establish the tunnel: # Hurricane Electric v6 tunnel ipv6_enable=YES gif_interfaces=gif0 gifconfig_gif0=[MY V4 ADDRESS] [HE V4 ADDRESS] ifconfig_gif0=inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128 ipv6_defaultrouter=[HE V6 ENDPOINT] # v6 gateway ipv6_gateway_enable=YES ipv6_network_interfaces=internal ipv6_prefix_internal=[MY V6 /64 prefix] rtadvd_interfaces=internal Two problems: * That seems to configure the tunnel, but it appears as 'tentative'. * the v6 EUI64 address on interface internal is not assigned as before gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 tunnel inet [MY V4 ADDRESS -- [HE V4 ADDRESS] inet6 fe80::211:2fff:fe46:6347%gif0 prefixlen 64 tentative scopeid 0x8 inet6 [MY V6 ENDPOINT] -- [HE V6 ENDPOINT] prefixlen 128 tentative nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL options=1ACCEPT_REV_ETHIP_VER connectivity to HE's v4 endpoint is fine, but I get nada for my own addresses: $ ping6 2001:470:a:bd::2 PING6(56=40+8+8 bytes) fe80::202:b3ff:fe97:59f%internal -- 2001:470:a:bd::2 ^C - --- 2001:470:a:bd::2 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss [r...@hellfire src]$ ping6 2001:470:a:bd::1 ping6: UDP connect: Can't assign requested address Destroying and recreating gif0 manually has no effect -- same results. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkve2qAACgkQrDN5kXnx8yYfEQCfcbdK/RHygYkPswnUqJ6tS8/Y v28Ani+9YC2LTLQKkJvXEmC4dOEQBHQp =zAHG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/10 12:38, Fabien Thomas wrote: Hi Jeff, I'm with r207548 now and since some days i've system deadlock. It seems related to SUJ with process waiting on suspfs or ppwait. I've also seen it stalled in suspfs, but this information is way better than what I was able to garner. I was only able to tell via ctrl-t on a stalled 'ls' process in a terminal before hard booting. Right now it occurs everytime I attempt to do the portmaster -a upgrade of X/KDE on this system. The backtrace is the following: (kgdb) bt #0 sched_switch (td=0xc52d84c0, newtd=0xc4d88980, flags=260) at /usr/home/fabient/fabient-sandbox/sys/kern/sched_ule.c:1853 #1 0xc0a2838e in mi_switch (flags=260, newtd=0x0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:449 #2 0xc0a62a25 in sleepq_switch (wchan=0xc5389cf0, pri=159) at /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:530 #3 0xc0a62c6c in sleepq_wait (wchan=0xc5389cf0, pri=159) at /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:609 #4 0xc0a27aec in _sleep (ident=0xc5389cf0, lock=0xc5389ca8, priority=159, wmesg=0xc0f5c302 suspfs, timo=0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:234 #5 0xc0ae2e62 in vn_start_write (vp=0xc66bdcc0, mpp=0xce79bb6c, flags=1) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:998 #6 0xc0ae1476 in vn_close (vp=0xc66bdcc0, flags=1, file_cred=0xc577f400, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:299 #7 0xc0ae2cc6 in vn_closefile (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:941 #8 0xc09d7e5e in fo_close (fp=0xc7bcd460, td=0xc52d84c0) at file.h:270 #9 0xc09d7ddc in _fdrop (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2348 #10 0xc09d775b in closef (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2117 #11 0xc09d526a in kern_close (td=0xc52d84c0, fd=3) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1162 #12 0xc09d50ea in close (td=0xc52d84c0, uap=0xce79bcf0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1114 #13 0xc0e5816b in syscall (frame=0xce79bd38) at /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 #14 0xc0e302e0 in Xint0x80_syscall () at /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 If you need more information tell me. Fabien___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfKk0ACgkQrDN5kXnx8yYpZgCeKRqenQbflLhoa3hVaXP7wICE 9KAAn2HEWuNwgI9EUxA5BYMR6DD0NBgi =bhDN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @ /usr/src/sys/dev/msk/if_msk.c:3589
On 5/3/2010 12:55 PM, Pyun YongHyeon wrote: On Mon, May 03, 2010 at 07:01:56AM -0700, Mark Atkinson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated to current yesterday and got the following 'witness_warn' panic upon executing 'reboot': suspending ithread with the following locks held: exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @ /usr/src/sys/dev/msk/if_msk.c:3589 panic: witness_warn It seems msk(4) didn't honor IFF_DRV_RUNNING in status block update check so it continued to process received packets. Would you try attached patch? Now it now longer panics, but the system does hang indefinitely. The hang occurs at the same time the panic does, which is after disks are synced right after the 'rebooting' message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to establish HE gif0 tunnel
On 5/3/2010 1:33 PM, Chris Ruiz wrote: On Mon, May 3, 2010 at 9:16 AM, Mark Atkinson atkin...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated a border gateway yesterday from a Feb 23 kernel to a May 2 version kernel/world, and lost my connectivity to my gif0 HE tunnel. I've been using the following in /etc/rc.conf successfully for some time to establish the tunnel: ifconfig_gif0=inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128 There's your problem, bad syntax. Change it to this: ifconfig_gif0_ipv6=inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128 OK I finally got this to work, however, I cannot boot to single user, and then 'exit' to mutli-user and have it work. I'm not sure what's broken there. Also, I'm still having a problem with 'tentative'. For example I assigned the internal interface with my prefix manually: ifconfig internal inet6 [prefix]/64 eui64 'tentative' is supposed to disappear after DAD, but instead 'hangs on' indefinitely. There appears to be a bug there. There is no collision unless it's seeing it's own broadcast somehow. Even if it did, there's no log/complaining. If I set dad count to 0 and remove and re-add the address, still stuck. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to establish HE gif0 tunnel
On 5/3/2010 6:23 PM, Mark Atkinson wrote: On 5/3/2010 1:33 PM, Chris Ruiz wrote: On Mon, May 3, 2010 at 9:16 AM, Mark Atkinson atkin...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated a border gateway yesterday from a Feb 23 kernel to a May 2 version kernel/world, and lost my connectivity to my gif0 HE tunnel. I've been using the following in /etc/rc.conf successfully for some time to establish the tunnel: ifconfig_gif0=inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128 There's your problem, bad syntax. Change it to this: ifconfig_gif0_ipv6=inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128 OK I finally got this to work, however, I cannot boot to single user, and then 'exit' to mutli-user and have it work. I'm not sure what's broken there. Also, I'm still having a problem with 'tentative'. For example I assigned the internal interface with my prefix manually: ifconfig internal inet6 [prefix]/64 eui64 'tentative' is supposed to disappear after DAD, but instead 'hangs on' indefinitely. There appears to be a bug there. There is no collision unless it's seeing it's own broadcast somehow. Even if it did, there's no log/complaining. If I set dad count to 0 and remove and re-add the address, still stuck. OK, I apparently I have to enable nd6 with -ifenabled. Somehow I missed that this became the default along the way. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: malloc problems in -current malloc_usable_size()
On 03/02/10 09:21, Mark Atkinson wrote: On 03/02/10 09:03, John Baldwin wrote: On Tuesday 02 March 2010 11:38:57 am Mark Atkinson wrote: Hi, I updated my kernel/world yesterday and thunderbird 3.0.2 started core dumping after I completed the upgrade. It continued to do so on previously good operations after a full re-compile. I noticed that some jemalloc changes went in and was wondering if anyone else was noticing SEGV problems in other apps with malloc_usable_size() or ARENA problems in threaded apps? This may be a bug in gssapi rather than malloc(). Someone else was reporting segfaults from gss_release_buffer() because it was free()ing a bad pointer when using gssapi_krb5. Thanks for that tip, I didn't associated that with the LDAP thread until now. LD_PRELOAD ing a dummy gss_release_buffer() stops the segfaulting. Curious it only showed up after I updated. I had an Jan 11th kernel/world earlier. Just a quick note, I found that using sasl 2 will also avoid the problem cyrus-sasl-2.1.23 RFC SASL (Simple Authentication and Security Layer) LD_PRELOAD=/usr/local/lib/sasl2/libgssapiv2.so.2 thunderbird ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
malloc problems in -current malloc_usable_size()
Hi, I updated my kernel/world yesterday and thunderbird 3.0.2 started core dumping after I completed the upgrade. It continued to do so on previously good operations after a full re-compile. I noticed that some jemalloc changes went in and was wondering if anyone else was noticing SEGV problems in other apps with malloc_usable_size() or ARENA problems in threaded apps? 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7 #1 0x28eadbaa in free () from /lib/libc.so.7 #2 0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10 #3 0x2ed9a5ea in gss_release_name () from /usr/lib/libgssapi.so.10 #4 0x2ed96ec9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 #5 0x2ec0aab4 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libauth.so #6 0x2ec0b5c1 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libauth.so #7 0x291853ea in nsMsgProtocol::AsyncOpen () from /usr/local/lib/thunderbird-3.0.2/components/libmail.so #8 0x29255b30 in nsStopwatch::QueryInterface () from /usr/local/lib/thunderbird-3.0.2/components/libmail.so #9 0x29255dc5 in nsStopwatch::QueryInterface () from /usr/local/lib/thunderbird-3.0.2/components/libmail.so #10 0x291832ee in nsMsgProtocol::OnDataAvailable () from /usr/local/lib/thunderbird-3.0.2/components/libmail.so #11 0x2986ff02 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libnecko.so #12 0x298700b6 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libnecko.so #13 0x281f8844 in NS_AsyncCopy () from /usr/local/lib/thunderbird-3.0.2/libxpcom_core.so #14 0x28212846 in NS_SetGlobalThreadObserver () from /usr/local/lib/thunderbird-3.0.2/libxpcom_core.so #15 0x281d3b7f in NS_ProcessNextEvent_P () from /usr/local/lib/thunderbird-3.0.2/libxpcom_core.so #16 0x29a54281 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libwidget_gtk2.so #17 0x29ba1687 in NSGetModule () from /usr/local/lib/thunderbird-3.0.2/components/libtoolkitcomps.so #18 0x2819967d in XRE_main () from /usr/local/lib/thunderbird-3.0.2/libxul.so ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: malloc problems in -current malloc_usable_size()
On 03/02/10 09:03, John Baldwin wrote: On Tuesday 02 March 2010 11:38:57 am Mark Atkinson wrote: Hi, I updated my kernel/world yesterday and thunderbird 3.0.2 started core dumping after I completed the upgrade. It continued to do so on previously good operations after a full re-compile. I noticed that some jemalloc changes went in and was wondering if anyone else was noticing SEGV problems in other apps with malloc_usable_size() or ARENA problems in threaded apps? This may be a bug in gssapi rather than malloc(). Someone else was reporting segfaults from gss_release_buffer() because it was free()ing a bad pointer when using gssapi_krb5. Thanks for that tip, I didn't associated that with the LDAP thread until now. LD_PRELOAD ing a dummy gss_release_buffer() stops the segfaulting. Curious it only showed up after I updated. I had an Jan 11th kernel/world earlier. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wchar.h?
On Tue, 9 Mar 1999, Archie Cobbs wrote: The jikes Java compiler relies on an include file whcar.h being on the system. However, even if it's not, it includes routines to do what it needs... only about 40 lines or so for these functions: I was bitten by this one recently too, and there are quite a few messages in the mailing-list archives on the subject. If I remember right (without looking right now) the reason it hasn't been included was some sort of issue of 16bit vs 32bit. The short answer is you need write your own functions and header file that you need, or use the Xwchar library that came in the original X11R5/contrib distributions (with slight modifications to the header file to use FreeBSD's wchar_t type and specific includes). It looks like jikes does the 'right thing' just because there's not that much consistancy across platforms. Just FYI HP, linux, and solaris all include a wchar.h, but different systems are missing different wcs* type functions. --- Mark Atkinson Checkpoint Technologies' Metaip Group ma...@metaip.checkpoint.com !(wired)?(coffee++):(wired) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
