Hi Peter, I think you are seeing a side effect of the IPV6 keepalives not being generated correctly for the dynamic rule created for the outgoing IPV6 connection. This causes the dynamic rule to get deleted prematurely. The bug was found originally in the RELENG_6 tree and documented in the following PR http://www.freebsd.org/cgi/query-pr.cgi?pr=117234 I believe Max Laier will soon be submitting a fix for this that makes things better. Cheers John -----Original Message----- From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-current_at_freebsd.org] Sent: Tuesday, October 23, 2007 10:01 PM To: freebsd-current_at_freebsd.org Subject: freebsd-current Digest, Vol 217, Issue 3 Send freebsd-current mailing list submissions to freebsd-current_at_freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-request_at_freebsd.org You can reach the person managing the list at freebsd-current-owner_at_freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. Re: cant start X with today's kernel (Harry Matthiesen Jensen) 2. Re: cant start X with today's kernel (Gary Jennejohn) 3. Re: [Bulk] Re: [Bulk] Re: New if_zyd driver (John Merryweather Cooper) 4. zfs kernel messages (Olli Hauer) 5. Re: libpcap build error _at_ RELENG_7 (Alexandr Kovalenko) 6. Re: libpcap build error _at_ RELENG_7 (Alexandr Kovalenko) 7. Re: Supermicro H8DA8 hangs on reboot (Mark Powell) 8. Re: Repeatable kernel panic on -CURRENT using ZFS over SATA (Dag-Erling Sm?rgrav) 9. Re: Repeatable kernel panic on -CURRENT using ZFS over SATA (Mark Powell) 10. Re: kthreads->kproc and back to kthread.. next patch (Ivan Voras) 11. more klingdom in dmesg (JoaoBR) 12. Best way for a gmirrored gjournal? (Patrick Hurrelmann) 13. Re: Supermicro H8DA8 hangs on reboot (JoaoBR) 14. Re: zfs kernel messages (Pawel Jakub Dawidek) 15. Re: question for both ports and current (Erwin Lansing) 16. bsdtar can't handle files >8GB (Bruce Cran) 17. Re: which version to install for next 2-3 years? (Oliver Fromme) 18. ipfw2 keep-state + IPv6 on RELENG_7 (Peter Kieser) 19. Re: kthreads->kproc and back to kthread.. next patch (Scott Long) 20. Re: kthreads->kproc and back to kthread.. next patch (Julian Elischer) 21. Re: kthreads->kproc and back to kthread.. next patch (Julian Elischer) 22. Re: kthreads->kproc and back to kthread.. next patch (Julian Elischer) 23. Re: kthreads->kproc and back to kthread.. next patch (Ivan Voras) 24. 7.0-BETA1 Available, 6.3-BETA1 coming soon... (Ken Smith) 25. Re: bsdtar can't handle files >8GB (Josh Carroll) 26. Re: an interesting observation on network performence (Aryeh M. Friedman) 27. an interesting observation on network performence (Aryeh M. Friedman) 28. [ANN] 8-CURRENT, RELENG_7 and RELENG_6 have gotten latest unionfs improvements (Daichi GOTO) 29. NAT_T patch update for FreeBSD 7 / HEAD (VANHULLEBUS Yvan) ---------------------------------------------------------------------- Message: 1 Date: Mon, 22 Oct 2007 09:27:08 +0200 From: Harry Matthiesen Jensen <freebsd_at_elgert.dk> Subject: Re: cant start X with today's kernel To: freebsd-current_at_freebsd.org Message-ID: <20071022072708.GA46467_at_mugin.localhost> Content-Type: text/plain; charset=us-ascii On Sun, Oct 21, 2007 at 06:14:23PM +0200, Gary Jennejohn wrote: > I can't start X with a kernel made today. The server complains that the video card > is on ISA (it's really on AGP) and that it can't find any screens. Here the last > of xorg-7.3 today and X still won't start. Trying to force X to use PCI with BusID > in xorg.conf also doesn't help. I have had same issue: Have you checked out "/usr/src/UPDATING" about pci? There may be a hint for your problem. I re-compiled all that tends to have with xorg to do. -- Mvh/Brgds Harry FreeBSD mugin.localhost 8.0-CURRENT #11: i386 ------------------------------ Message: 2 Date: Mon, 22 Oct 2007 10:16:00 +0200 From: Gary Jennejohn <gary.jennejohn_at_freenet.de> Subject: Re: cant start X with today's kernel To: freebsd-current_at_freebsd.org Message-ID: <20071022101600.12698637_at_peedub.jennejohn.org> Content-Type: text/plain; charset=US-ASCII On Sun, 21 Oct 2007 18:14:23 +0200 Gary Jennejohn <gary.jennejohn_at_freenet.de> wrote: > I can't start X with a kernel made today. The server complains that the video card > is on ISA (it's really on AGP) and that it can't find any screens. Here the last > few lines from /var/log/Xorg.0.log: > > (II) ATI: ATI driver wrapper (version 6.7.195) for chipsets: mach64, rage128, radeon > (II) Primary Device is: ISA > (EE) No devices detected. > > I know there's an entry in /usr/src/UPDATING (20070930), and I did a fresh install > of xorg-7.3 today and X still won't start. Trying to force X to use PCI with BusID > in xorg.conf also doesn't help. > > Has anyone else seen this? At the moment I'm using an old kernel from Sept 27. > Never mind. I got hit with a clue-bat and realized that I hadn't installed world (because of the DLT_* problem) so the X server couldn't pick up the new sys/pciio.h. -- Gary Jennejohn ------------------------------ Message: 3 Date: Sun, 21 Oct 2007 21:35:24 -0700 From: John Merryweather Cooper <john_m_cooper_at_yahoo.com> Subject: Re: [Bulk] Re: [Bulk] Re: New if_zyd driver To: Weongyo Jeong <weongyo.jeong_at_gmail.com> Cc: Ted Lindgreen <ted_at_tednet.nl>, freebsd-current_at_freebsd.org, Warner Losh <imp_at_bsdimp.com> Message-ID: <471C288C.6060106_at_yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Weongyo Jeong wrote: > On Sun, Oct 21, 2007 at 12:05:42AM -0700, John Merryweather Cooper wrote: > >> Weongyo Jeong wrote: >> >>> On Thu, Aug 30, 2007 at 04:14:22PM +0200, Ted Lindgreen wrote: >>> [... snipped ...] >>> >>> >>>> However, the stick needs to be inserted after booting up. Then I can >>>> also remove the stick without ill effects (for logmessages see below). >>>> >>>> When the stick is present during boot, the log shows: >>>> Aug 30 15:25:17 lapje kernel: zyd0: <ZyDAS USB2.0 WLAN, class 255/255, rev 2.00/48.10, addr 2> on uhub4 >>>> Aug 30 15:25:17 lapje kernel: zyd0: setting config no failed >>>> >>>> >>> [... snipped ...] >>> >>> Hello Ted, >>> >>> I send you a patch which is attached with this email to fix a reset >>> problem of the zyd driver when we reboot. >>> >>> In my environment, this patch was worked. Would you please test this >>> patch and send me results? I hope it works. :-) >>> >>> Regards, >>> Weongyo Jeong >>> >> Well, the patch applies cleanly and builds on an amd64: >> >> Copyright (c) 1992-2007 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.0-BETA1 #16: Sat Oct 20 14:58:28 PDT 2007 >> root_at_borgdemon3.temp.wsu.edu:/usr/obj/usr/src/sys/TURION >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2210.07-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 >> >> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> Features2=0x2001<SSE3,CX16> >> AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!> >> AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch> >> Cores per package: 2 >> >> . . . . >> >> zyd0: <Belkin USB2.0 WLAN, class 255/255, rev 2.00/48.10, addr 3> on uhub1 >> zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:17:3f:b0:d4:97 >> zyd0: Ethernet address: 00:17:3f:b0:d4:97 >> zyd0: if_start running deferred for Giant >> >> I realize that the patch wasn't designed to fix my problem (locking up >> when zyd0 is on a moderate load--like cvsup'ing). Nevertheless, here's >> what kgdb has to say: >> >> jcooper_at_borgdemon3$ sudo kgdb kernel.debug /var/crash/vmcore.9 >> [GDB will not be able to debug user-mode threads: >> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd". >> >> Unread portion of the kernel message buffer: >> zyd0: could not transmit buffer: SHORT_XFER >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x2734 >> fault code = supervisor write data, page not present >> instruction pointer = 0x8:0xffffffff808a94fa >> stack pointer = 0x10:0xffffffffab8dfaf0 >> frame pointer = 0x10:0xffffffffab8dfb30 >> 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 = 23 (irq22: ohci0 ehci0) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> Uptime: 8m38s >> Physical memory: 1973 MB >> Dumping 233 MB: 218 202 186 170 154 138 122 106 90 74 58 42 26 10 >> >> #0 doadump () at pcpu.h:194 >> 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); >> (kgdb) >> >> ------- >> >> jmc >> > > Yes. This patch isn't related with your problem. Your problem is > on my TODO list but I think that it would be hard and takes some times > to fix because of the lack of environments that I don't have amd64, > Belkin devices and the zyd driver on my environment works well without > problems. > > Can you show me the backtrace log of `$ kgdb kernel.debug > /var/crash/vmcore.9'? > > Regards, > Weongyo Jeong > > Sure. The backtrace is: #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff802db510 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff802db92d in panic (fmt=0x104 <Address 0x104 out of bounds>) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80512c74 in trap_fatal (frame=Variable "frame" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:695 #5 0xffffffff80513045 in trap_pfault (frame=0xffffffffab8dfa40, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:588 #6 0xffffffff805139eb in trap (frame=0xffffffffab8dfa40) at /usr/src/sys/amd64/amd64/trap.c:393 #7 0xffffffff804f986e in alltraps_pushregs_no_rdi () at /usr/src/sys/amd64/amd64/exception.S:155 #8 0xffffff0001254000 in ?? () #9 0xffffffff80a4b878 in ?? () #10 0x0000000000000000 in ?? () #11 0xffffffffab907c00 in ?? () #12 0xffffff00011d4000 in ?? () #13 0x00000000000005cb in ?? () #14 0xffffffff808a94a0 in ?? () #15 0x0000000000000000 in ?? () #16 0xffffffffab8dfb30 in ?? () #17 0xffffff0001254000 in ?? () #18 0xffffffff806e5240 in ehci_device_ctrl_methods () #19 0xffffffff80a4b878 in ?? () #20 0x0000000000000000 in ?? () #21 0xffffff0001279800 in ?? () #22 0xffffffff80a4a000 in ?? () #23 0x000000000000000c in ?? () #24 0x0000000000002734 in ?? () #25 0xffffffff80250af7 in ehci_device_bulk_start (xfer=0xffffffff80a4b878) at /usr/src/sys/dev/usb/ehci.c:3078 #26 0xffffffff80272ad4 in usb_transfer_complete (xfer=0xffffff0001254000) at /usr/src/sys/dev/usb/usbdi.c:977 #27 0xffffffff8024eace in ehci_softintr (v=Variable "v" is not available. ) at /usr/src/sys/dev/usb/ehci.c:884 #28 0xffffffff80250583 in ehci_intr1 (sc=0xffffff00011d4000) at /usr/src/sys/dev/usb/ehci.c:603 #29 0xffffffff802bf1b0 in ithread_loop (arg=0xffffff000125a300) at /usr/src/sys/kern/kern_intr.c:1036 #30 0xffffffff802bc152 in fork_exit ( callout=0xffffffff802bf040 <ithread_loop>, arg=0xffffff000125a300, frame=0xffffffffab8dfc80) at /usr/src/sys/kern/kern_fork.c:796 #31 0xffffffff804f9bde in nmi_restoreregs () at /usr/src/sys/amd64/amd64/exception.S:386 #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000001 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x00000000009ab000 in ?? () #57 0xffffffff8075ce00 in tdq_cpu () #58 0xffffffff80768a00 in tdq_groups () #59 0xffffffff80768980 in tdq_cpu () #60 0xffffff000125c9f0 in ?? () #61 0x0000000000000000 in ?? () #62 0xffffffffab8df6b8 in ?? () #63 0xffffff000125c9f0 in ?? () #64 0xffffffff802f9404 in sched_switch (td=0xffffffff802bf040, newtd=0x0, flags=0) at /usr/src/sys/kern/sched_ule.c:1902 #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () #120 0x0000000000000000 in ?? () #121 0x0000000000000000 in ?? () #122 0x0000000000000000 in ?? () #123 0x0000000000000000 in ?? () #124 0x0000000000000000 in ?? () #125 0x0000000000000000 in ?? () #126 0x0000000000000000 in ?? () #127 0x0000000000000000 in ?? () #128 0x0000000000000000 in ?? () #129 0x0000000000000000 in ?? () #130 0x0000000000000000 in ?? () #131 0x0000000000000000 in ?? () #132 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffffab8e0000 jmc ------------------------------ Message: 4 Date: Mon, 22 Oct 2007 00:15:50 +0200 From: Olli Hauer <ohauer_at_gmx.de> Subject: zfs kernel messages To: freebsd-current_at_freebsd.org Message-ID: <471BCF96.7000207_at_gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed while playing a little with zfs i get the following kernel messages at ttyv0 (no panic/freeze happend) (captured vi ssh from other system) # vidcontrol -P < /dev/ttyv0 uma_zalloc_arg: zone "256" with the following non-sleepable locks held: exclusive sleep mutex struct mount mtx r = 0 (0xc64e7d3c) locked _at_ /usr/src/sys/modules/zfs/../../compat/opensolaris/kern/opensolaris_vfs.c:206 KDB: stack backtrace: db_trace_self_wrapper(c0a9c175,e72bb6e4,c078428d,c0a9c538,e72bb6f8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0a9c538,e72bb6f8,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0aba40d,c0ac3e77,1,...) at witness_warn+0x1cd uma_zalloc_arg(c146d1e0,0,102,2,c64e7d0c,...) at uma_zalloc_arg+0x34 malloc(94,c0b4c4e0,102,c64e7d0c,e72bb790,...) at malloc+0xd2 crget(c6985300,c0b4c4e0,c64e7d0c,e72bb7d4,c431b9dc,...) at crget+0x23 crdup(c3f07600,0,c439444c,ce,c2,...) at crdup+0xc domount(c450a420,c6ee4330,c43995db,cc152900,e72bb810,...) at domount+0x20c zfsctl_snapdir_lookup(e72bbaa0,e72bbaa0,c450a420,2,c456e660,...) at zfsctl_snapdir_lookup+0x362 VOP_LOOKUP_APV(c439d5c0,e72bbaa0,c450a420,c0aa409d,19b,...) at VOP_LOOKUP_APV+0xa5 lookup(e72bbb48,c0aa409d,c6,bf,c730102c,...) at lookup+0x58e namei(e72bbb48,e72bbb94,60,0,c450a420,...) at namei+0x34b kern_lstat(c450a420,28220318,0,e72bbc18,2d4738cb,...) at kern_lstat+0x4f lstat(c450a420,e72bbcfc,8,c0a9ed42,c0b469d0,...) at lstat+0x2f syscall(e72bbd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2815548b, esp = 0xbfbfe93c, ebp = 0xbfbfe9c8 --- System: 7.0-CURRENT-200710, GENERIC i386, 1GB RAM entries in loader.conf vfs.zfs.prefetch_disable="1" # (loader.conf) vfs.zfs.arc_max="104857600" # (loader.conf) vm.kmem_size_max="402653184" # (loader.conf) entries in sysctl.conf kern.maxvnodes="50000" # (sysctl) It is not easy to reproduce but i get the message this way: - enable shell command line completion - zfs snapshot zvol/test_at_snapX - ls -l /zvol/test/.zfs/snap -> tab Once i get the message i have to create a new snapshot to reproduce this olli ------------------------------ Message: 5 Date: Mon, 22 Oct 2007 07:19:17 +0300 From: Alexandr Kovalenko <never_at_uafug.org.ua> Subject: Re: libpcap build error _at_ RELENG_7 To: Max Laier <max_at_love2party.net> Cc: freebsd-current_at_freebsd.org, Dmitry Morozovsky <marck_at_rinet.ru>, current_at_freebsd.org Message-ID: <20071022041917.GA55333_at_uafug.org.ua> Content-Type: text/plain; charset=us-ascii Hello, Max Laier! On Sun, Oct 21, 2007 at 03:07:17PM +0200, you wrote: > On Sunday 21 October 2007, Dmitry Morozovsky wrote: > > Hi there colleagues, > > > > during buildworld (erased /usr/obj, etc) > > > > ===> lib/libpcap (all) > > cc -O2 -fno-strict-aliasing -pipe -march=prescott -DHAVE_CONFIG_H > > -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. > > -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF > > -DHAVE_NET_PFVAR_H > > -I/usr/src/lib/libpcap/../../contrib/libpcap -c grammar.c > > cc -O2 -fno-strict-aliasing -pipe -march=prescott -DHAVE_CONFIG_H > > -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. > > -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF > > -DHAVE_NET_PFVAR_H > > -I/usr/src/lib/libpcap/../../contrib/libpcap -c > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:382: error: 'DLT_MFR' > > undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:383: error: > > 'DLT_JUNIPER_VP' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:385: error: > > 'DLT_A429' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:386: error: > > 'DLT_A653_ICM' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:387: error: 'DLT_USB' > > undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:388: error: > > 'DLT_BLUETOOTH_HCI_H4' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:389: error: > > 'DLT_CAN20B' undeclared here (not in a function) > > *** Error code 1 > > > > Stop in /usr/src/lib/libpcap. > > *** Error code 1 > > I fat-fingered that one. Fix attached, but I'll do a buildworld this time > to make sure. Sorry! Latest cvsup of RELENG_7 now builds fine, thanks :) -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ------------------------------ Message: 6 Date: Mon, 22 Oct 2007 07:19:17 +0300 From: Alexandr Kovalenko <never_at_uafug.org.ua> Subject: Re: libpcap build error _at_ RELENG_7 To: Max Laier <max_at_love2party.net> Cc: freebsd-current_at_freebsd.org, Dmitry Morozovsky <marck_at_rinet.ru>, current_at_freebsd.org Message-ID: <20071022041917.GA55333_at_uafug.org.ua> Content-Type: text/plain; charset=us-ascii Hello, Max Laier! On Sun, Oct 21, 2007 at 03:07:17PM +0200, you wrote: > On Sunday 21 October 2007, Dmitry Morozovsky wrote: > > Hi there colleagues, > > > > during buildworld (erased /usr/obj, etc) > > > > ===> lib/libpcap (all) > > cc -O2 -fno-strict-aliasing -pipe -march=prescott -DHAVE_CONFIG_H > > -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. > > -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF > > -DHAVE_NET_PFVAR_H > > -I/usr/src/lib/libpcap/../../contrib/libpcap -c grammar.c > > cc -O2 -fno-strict-aliasing -pipe -march=prescott -DHAVE_CONFIG_H > > -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. > > -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF > > -DHAVE_NET_PFVAR_H > > -I/usr/src/lib/libpcap/../../contrib/libpcap -c > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:382: error: 'DLT_MFR' > > undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:383: error: > > 'DLT_JUNIPER_VP' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:385: error: > > 'DLT_A429' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:386: error: > > 'DLT_A653_ICM' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:387: error: 'DLT_USB' > > undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:388: error: > > 'DLT_BLUETOOTH_HCI_H4' undeclared here (not in a function) > > /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:389: error: > > 'DLT_CAN20B' undeclared here (not in a function) > > *** Error code 1 > > > > Stop in /usr/src/lib/libpcap. > > *** Error code 1 > > I fat-fingered that one. Fix attached, but I'll do a buildworld this time > to make sure. Sorry! Latest cvsup of RELENG_7 now builds fine, thanks :) -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ------------------------------ Message: 7 Date: Mon, 22 Oct 2007 13:13:55 +0100 (BST) From: "Mark Powell" <M.S.Powell_at_salford.ac.uk> Subject: Re: Supermicro H8DA8 hangs on reboot To: JoaoBR <joao_at_matik.com.br> Cc: current_at_FreeBSD.org Message-ID: <20071022130929.W45807_at_rust.salford.ac.uk> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 21 Oct 2007, JoaoBR wrote: > has somebody else the problem that this MB does not reboot (stays at uptime at > the end)? I've always had the same problem with 7-CURRENT/PRERELEASE/BETA1 on 2 motherboards Gigabyte GA-P-35-DS4 and Intel D975XBX2 i.e. hangs at uptime. On both machines I use a small ufs mirror to boot and have everything else on zfs. It seems that if the restart is attempted soon after the machine has just come up then it can reboot properly, but if the machine has been up a reasonable time, then it will always hang at uptime. Sorry, can't be more specific than 'a reasonable amount of uptime', i.e. a few hours, as the cause at the mo. Not noticed a specific action which causes it. > both sysctl do not have any effect: > > hw.acpi.disable_on_reboot > hw.acpi.handle_reboot Not tried those. > releng_6 works ok Yep. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key ------------------------------ Message: 8 Date: Mon, 22 Oct 2007 15:16:36 +0200 From: Dag-Erling Sm?rgrav <des_at_des.no> Subject: Re: Repeatable kernel panic on -CURRENT using ZFS over SATA To: "Mark Powell" <M.S.Powell_at_salford.ac.uk> Cc: Bill Hacker <askbill_at_conducive.net>, freebsd-current_at_freebsd.org Message-ID: <86abqbe1cb.fsf_at_ds4.des.no> Content-Type: text/plain; charset=utf-8 "Mark Powell" <M.S.Powell_at_salford.ac.uk> writes: > On Thu, 4 Oct 2007, Dag-Erling Smørgrav wrote: > > Bill Hacker <askbill_at_conducive.net> writes: > > > Short answer - you are overstressing your very marginal hardware. > > You're completely off the mark. Steven is experiencing a well-known bug > > in the ata driver. > When you say well know, is there a PR for this problem? Not that I know of; search the -current archives. DES -- Dag-Erling Smørgrav - des_at_des.no ------------------------------ Message: 9 Date: Mon, 22 Oct 2007 14:08:39 +0100 (BST) From: "Mark Powell" <M.S.Powell_at_salford.ac.uk> Subject: Re: Repeatable kernel panic on -CURRENT using ZFS over SATA To: Dag-Erling Sm?rgrav <des_at_des.no> Cc: Bill Hacker <askbill_at_conducive.net>, freebsd-current_at_freebsd.org Message-ID: <20071022134606.H45807_at_rust.salford.ac.uk> Content-Type: text/plain; charset="iso-8859-1" On Thu, 4 Oct 2007, Dag-Erling Smørgrav wrote: > Bill Hacker <askbill_at_conducive.net> writes: >> Short answer - you are overstressing your very marginal hardware. > > You're completely off the mark. Steven is experiencing a well-known bug > in the ata driver. When you say well know, is there a PR for this problem? I've just been hit by this yesterday. This was several hours after I had updated to BETA1. I had never seen this problem before. It's amd64 on SATA, with a small ufs mirror for boot and everything else on zfs. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key ------------------------------ Message: 10 Date: Mon, 22 Oct 2007 18:42:36 +0200 From: Ivan Voras <ivoras_at_freebsd.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: freebsd-current_at_freebsd.org Message-ID: <ffijts$tqt$1_at_ger.gmane.org> Content-Type: text/plain; charset=UTF-8; format=flowed Julian Elischer wrote: > Here is the link to the next patch. > > this introduces (back) the kthread_create (etc) calls but now they > make threads.. > it may also be worth adding some help for people to make a new kproc, > and populate it with a number of kthreads. For example, why would we do that? :) A practical example: GEOM modules often spawn separate execution contexts to handle non-trivial IO requests. These threads are usually created at most once per GEOM device and live until that device goes away. GEOM framework itself has several execution contexts (g_up, g_down, g_event) which call "methods" from GEOM classes. Should we spawn one "dummy" kproc per GEOM class and then kthreads in it for devices? If "raw" kthreads can be spawned, to which kproc will they belong (if any)? Is the difference between kthread and kproc here purely aesthetic? In other words: when should one create a kproc and when a kthread? ------------------------------ Message: 11 Date: Mon, 22 Oct 2007 15:15:15 -0200 From: JoaoBR <joao_at_matik.com.br> Subject: more klingdom in dmesg To: current_at_freebsd.org Message-ID: <200710221515.15604.joao_at_matik.com.br> Content-Type: text/plain; charset="iso-8859-1" for sure related to the former msg I sent but here it comes kernel: (da0:umasGs-EsOiMm_0L:A0B:E0L::0 )L:a bleolst dmesvdiocsefs kernel: /N8(0d are0m:ouvmeads.s- kernel: sim0:0:0:0): removing device entry kernel: umass0: detached but this time I discovered the meaning myself ;) seems it has to do with the device type because another does not get hacked: kernel: (da0:umass-sim0:0:0:0): lost device kernel: (da0:umass-sim0:0:0:0): removing device entry kernel: umass0: detached I can remove the latter as much as I want no problem, the former each time gets me the mix -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ------------------------------ Message: 12 Date: Mon, 22 Oct 2007 19:08:35 +0200 From: Patrick Hurrelmann <outi_at_bytephobia.de> Subject: Best way for a gmirrored gjournal? To: freebsd-current_at_freebsd.org Message-ID: <20071022190835.1f999a23_at_duality> Content-Type: text/plain; charset=US-ASCII Hi all, Currently I'm trying to install a new server and need some hints on how to best configure filesystems using gmirror and gjournal. The server in question is a amd64 with 512mb of ram and 2x 80gb sata hdds. So I was thinking of a mount-point layout like the following: ad0s1 / (1gb) swap (1gb) /var (8gb) /tmp (1gb) /home (4gb) /usr (13gb) /jails (39gb) ad0s2 10gb for journaling Which would leave a space of 10gb for journaling. I digged through the mailinglist-archives and man-pages of gmirror and gjournal but all I ended up with are questions and doubts :) Now I wanted to create 2 mirrors (gm0s1 and gm0s2). Gmirror gm0s1 containing the slices ad0s1 and ad2s1, while gm0s2 should contain ad0s2 and ad2s2. I created 2 slices, as with the above shown partitioning I was running out of mount-points for this slice. Is such a layout reasonable? Or is it stupid to use a dedicated slice just for journaling and better skip e.g /tmp partition to leave space for a dedicated journaling partition on this slice? Btw. are 10gb enough for journaling of 6 partitions? Or do I need one dedicated partition for journaling each? If I skip using a separate partition for journaling data, gjournal keeps telling me that e.g. the root partion of 1gb is too small for jorunaling. Would it be save to decrease journal size altough man-page discourages? What do you people out there suggest? How do you handle systems with gmirror and gjournal combined? Or even use ZFS although ram is limited (as the machine will serve up several jails with e.g. postgres)? I'm really looking forward to suggestions from you. I intentionally directed this mail to current_at_ as I think that here are the most people around with experience on gjournal. But if I better should direct this mail to questions_at_ I'm happy to do so, too. Best regards, Patrick -- ==================================================================== Patrick Hurrelmann | "Programming today is a race between software Mannheim, Germany | engineers striving to build bigger and better | idiot-proof programs, and the Universe trying outi_at_bytephobia.de | to produce bigger and better idiots. So far, www.bytephobia.de | the Universe is winning." - Rich Cook /"\ \ / ASCII Ribbon Campaign X against HTML email & vCards / \ ------------------------------ Message: 13 Date: Mon, 22 Oct 2007 15:41:38 -0200 From: JoaoBR <joao_at_matik.com.br> Subject: Re: Supermicro H8DA8 hangs on reboot To: freebsd-current_at_freebsd.org Cc: Mark Powell <M.S.Powell_at_salford.ac.uk> Message-ID: <200710221541.38931.joao_at_matik.com.br> Content-Type: text/plain; charset="iso-8859-1" On Monday 22 October 2007 10:13:55 Mark Powell wrote: > On Sun, 21 Oct 2007, JoaoBR wrote: > > has somebody else the problem that this MB does not reboot (stays at > > uptime at the end)? > > I've always had the same problem with 7-CURRENT/PRERELEASE/BETA1 on 2 > motherboards Gigabyte GA-P-35-DS4 and Intel D975XBX2 i.e. hangs at uptime. > On both machines I use a small ufs mirror to boot and have everything > else on zfs. > It seems that if the restart is attempted soon after the machine has > just come up then it can reboot properly, but if the machine has been up a > reasonable time, then it will always hang at uptime. Sorry, can't be more > specific than 'a reasonable amount of uptime', i.e. a few hours, as the > cause at the mo. Not noticed a specific action which causes it. > that indeed sounds strange to me do you have acpi 2.0 selected in your BIOS ? > > both sysctl do not have any effect: > > > > hw.acpi.disable_on_reboot > > hw.acpi.handle_reboot you might try either one, it could help -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ------------------------------ Message: 14 Date: Mon, 22 Oct 2007 20:40:33 +0200 From: Pawel Jakub Dawidek <pjd_at_FreeBSD.org> Subject: Re: zfs kernel messages To: Olli Hauer <ohauer_at_gmx.de> Cc: freebsd-current_at_freebsd.org Message-ID: <20071022184033.GC1118_at_garage.freebsd.pl> Content-Type: text/plain; charset="us-ascii" On Mon, Oct 22, 2007 at 12:15:50AM +0200, Olli Hauer wrote: > while playing a little with zfs i get the following > kernel messages at ttyv0 (no panic/freeze happend) > > (captured vi ssh from other system) > # vidcontrol -P < /dev/ttyv0 > > uma_zalloc_arg: zone "256" with the following non-sleepable locks held: > exclusive sleep mutex struct mount mtx r = 0 (0xc64e7d3c) locked _at_ > /usr/src/sys/modules/zfs/../../compat/opensolaris/kern/opensolaris_vfs.c:206 > KDB: stack backtrace: > db_trace_self_wrapper(c0a9c175,e72bb6e4,c078428d,c0a9c538,e72bb6f8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c0a9c538,e72bb6f8,4,1,0,...) at kdb_backtrace+0x29 > witness_warn(5,0,c0aba40d,c0ac3e77,1,...) at witness_warn+0x1cd > uma_zalloc_arg(c146d1e0,0,102,2,c64e7d0c,...) at uma_zalloc_arg+0x34 > malloc(94,c0b4c4e0,102,c64e7d0c,e72bb790,...) at malloc+0xd2 > crget(c6985300,c0b4c4e0,c64e7d0c,e72bb7d4,c431b9dc,...) at crget+0x23 > crdup(c3f07600,0,c439444c,ce,c2,...) at crdup+0xc > domount(c450a420,c6ee4330,c43995db,cc152900,e72bb810,...) at domount+0x20c > zfsctl_snapdir_lookup(e72bbaa0,e72bbaa0,c450a420,2,c456e660,...) at > zfsctl_snapdir_lookup+0x362 > VOP_LOOKUP_APV(c439d5c0,e72bbaa0,c450a420,c0aa409d,19b,...) at > VOP_LOOKUP_APV+0xa5 > lookup(e72bbb48,c0aa409d,c6,bf,c730102c,...) at lookup+0x58e > namei(e72bbb48,e72bbb94,60,0,c450a420,...) at namei+0x34b > kern_lstat(c450a420,28220318,0,e72bbc18,2d4738cb,...) at kern_lstat+0x4f > lstat(c450a420,e72bbcfc,8,c0a9ed42,c0b469d0,...) at lstat+0x2f > syscall(e72bbd38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2815548b, esp = > 0xbfbfe93c, ebp = 0xbfbfe9c8 --- That's easy to fix. Try this patch: http://people.freebsd.org/~pjd/patches/opensolaris_vfs.c.patch Thanks for the report. -- Pawel Jakub Dawidek http://www.wheel.pl pjd_at_FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071022/00a27cbd/attachment-0001.pgp ------------------------------ Message: 15 Date: Mon, 22 Oct 2007 20:53:08 +0200 From: Erwin Lansing <erwin_at_FreeBSD.org> Subject: Re: question for both ports and current To: Julian Elischer <julian_at_ironport.com> Cc: ports_at_freebsd.org, FreeBSD Current <current_at_freebsd.org> Message-ID: <20071022185307.GT44185_at_droso.net> Content-Type: text/plain; charset="iso-8859-1" Hi Julian, On Sun, Oct 21, 2007 at 12:54:03AM -0700, Julian Elischer wrote: > In a move to support real krenel threads doing work in the kernel, > the code that creates kerel processes has been renamed kthread_xxx to > kproc_xxx > > teh following ports seem to reference the renamed functions in kld modules > they create. > > I'm not a ports export so I'm not sure how to get a port to > change it's behaviour in 8.0 as opposed to 7.0.... > > these are the ports (in fact the lines in the ports) that > will fail at this time.. > > # find . -name "*.[ch]" |xargs grep kthread [snip] > > I'm not sure how I go about patching these two ports to handle the > kthread->kproc > for 8.0 > > rename. Any help appreciated. > The ports infrastructure has an easy mechanism to add patches to the source of a port before it is build, which can be made dependend on OSVERSION. If you can create pachtes against the source of those ports, I'd be happy to get them incorporated in the ports themselves, and do buildtime testing. It would be as simple as a block of: .include <bsd.port.pre.mk> .if ${OSVERSION} > 800001 PATCHFILES= somefile.patch PATCHSITES= ${MASTER_SITE_LOCAL} MASTER_SITE_LOCAL= julian .endif and put the patches on freefall in ~/public_distfiles/ But like I said, I'd be happy to fix this, if you can create the patches. Cheers, -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin_at_FreeBSD.org And it makes you cry. <____) (____> erwin_at_aauug.dk -------------- 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/20071022/90e10934/attachment-0001.pgp ------------------------------ Message: 16 Date: Mon, 22 Oct 2007 20:03:15 +0100 From: Bruce Cran <bruce_at_cran.org.uk> Subject: bsdtar can't handle files >8GB To: current_at_freebsd.org Message-ID: <471CF3F3.6070803_at_cran.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed While taking a look at bin/9123 I found that although pax seems to have gained the ability to extract files over 8GB, bsdtar doesn't seem to be able to any more. I'm running 7.0-PRERELEASE from 14th Oct. I created a 12GB file and tarred it up using "tar cvf tmpfile.tar tmpfile". Attempting to extract it using tar gave the following error: > tar xvf tmpfile.tar x tmpfile tar: Unrecognized archive format: Inappropriate file type or format tar: Error exit delayed from previous errors. I've not verified that the checksums match, but pax extracted the tar file without any errors, and produced a file of the same size as the original. -- Bruce Cran ------------------------------ Message: 17 Date: Mon, 22 Oct 2007 20:57:43 +0200 (CEST) From: Oliver Fromme <olli_at_lurza.secnetix.de> Subject: Re: which version to install for next 2-3 years? To: freebsd-current_at_FreeBSD.ORG, syleishere_at_hotmail.com Message-ID: <200710221857.l9MIvhrW090076_at_lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1 syle ishere <> wrote: > I have a coloed box, OS on their now is ancient redhat 9.0, was thinking > about new SMP support and mysql speed advancements in 7.0. I'd just hate to > install 6.2 on it right now and thats way it stays for next 2-3 years if 7.0 > is stable enough to use right now. FWIW, I updated a coloed box from 6-stable to 7-stable last week (remotely with the usual buildworld dance). No problems so far. More of such machines will follow. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth ------------------------------ Message: 18 Date: Mon, 22 Oct 2007 12:43:15 -0700 From: Peter Kieser <peter_at_wingless.org> Subject: ipfw2 keep-state + IPv6 on RELENG_7 To: freebsd-current_at_freebsd.org Message-ID: <471CFD53.7080608_at_wingless.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, I'm having problems with ipfw2 + IPv6 keep-state rules, if I use a keep-state rule on IPv6 it will only work intermittently (eg. I can connect to an FTP site with IPv6 and start to grab a file, but it will stall after a few seconds). I am using deny all by default on ipfw, my ruleset is as follows (em0 is my external interface): add check-state add allow all from any to any via lo0 add allow all from any to any out via em0 keep-state The keep-state works fine for IPv4 traffic, but IPv6 traffic connectivity will only work intermittently with the above ruleset. I am running a RELENG_7 cvsuped/built on Tue Oct 16: FreeBSD akuma.pfak.org 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Tue Oct 16 18:30:20 PDT 2007 peter_at_akuma.pfak.org:/usr/obj/usr/src/sys/AKUMA i386 Any hints? Is IPv6 + keep-state broken on RELENG_7 or have I missed something obvious? Thank you, -Peter ------------------------------ Message: 19 Date: Mon, 22 Oct 2007 15:08:22 -0600 From: Scott Long <scottl_at_samsco.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: Julian Elischer <julian_at_elischer.org> Cc: current_at_freebsd.org Message-ID: <471D1146.2050502_at_samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Julian Elischer wrote: > Here is the link to the next patch. > > this introduces (back) the kthread_create (etc) calls but now they > make threads.. > It's still in the testing stage.. > I'd certainly appreciate feedback. > Especially as some of the locking and stuff has changed since I first > wrote this and tested it over 2 years ago. > > One possibility.. changing kthread_create() to kthread_new() > so that any people who are using the old kthread_create() don't get the new > one by mistake.... > > > after this is committed, I will start changing over some of the callers > of kproc_create, > one at a time.... > > > http://people.freebsd.org/~julian/kthread.diff > > > it may also be worth adding some help for people to make a new kproc, > and populate it with a number of kthreads. > > for instance it would be aesthetically pleasing to have a single idle > process, > and have all the idle threads be part of that single process. > > Similarly, might things like the syncer or other processes ever benefit > from having multiple threads? > Anyhow that's another discussion. Why is there a need for separate kprocs with their own private kthreads in the kernel? The kernel is a single unified address space; I thought that the only real benefit to "true" kthreads was just elimination of duplication of vmspaces for all off the kthreads that are currently running around. Do I gain some sort of security or management benefit from having my own private kproc for my kthreads, or am I really just burning another vmspace object and nothing more? What about the existing fast context switching between kthreads (i.e. not flushing CR3 on the switch), will that remain, or does it now get more complicated? Are there scheduling implications and benefits? In fact for that matter, how is scheduling going to be done for this? Is it all going to be 1:1 style scheduling, or will there be a multi-tier scheduler for kprocs and kthreads and associated niceness/fairness? What about high priority kthreads like ithreads, taskqueues, and SWI's? If I've missed the discussion on scheduling, I apologize. If not, have these questions been thought through yet? Scott ------------------------------ Message: 20 Date: Mon, 22 Oct 2007 16:40:08 -0700 From: Julian Elischer <julian_at_elischer.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: Ivan Voras <ivoras_at_freebsd.org> Cc: freebsd-current_at_freebsd.org Message-ID: <471D34D8.8020009_at_elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Ivan Voras wrote: > Julian Elischer wrote: >> Here is the link to the next patch. >> >> this introduces (back) the kthread_create (etc) calls but now they >> make threads.. > >> it may also be worth adding some help for people to make a new kproc, >> and populate it with a number of kthreads. > > For example, why would we do that? :) > > A practical example: GEOM modules often spawn separate execution > contexts to handle non-trivial IO requests. These threads are usually > created at most once per GEOM device and live until that device goes > away. GEOM framework itself has several execution contexts (g_up, > g_down, g_event) which call "methods" from GEOM classes. Should we spawn > one "dummy" kproc per GEOM class and then kthreads in it for devices? If > "raw" kthreads can be spawned, to which kproc will they belong (if any)? > Is the difference between kthread and kproc here purely aesthetic? > > In other words: when should one create a kproc and when a kthread? If you wanted to limit CPU usage for a particular group of threads it may be worth grouping them into a process and then you could have some control over them with 'nice'. Another case, The AIO threads need to be processes because each of them needs a different address space that can be hacked to cover the address space of the process they are working for. The Idle threads couldbe in their own process so you can easily see how much cpu idle.. here's what that looks like in top -SH last pid: 34941; load averages: 1.02, 1.01, 1.00 up 0+18:26:04 16:30:40 80 processes: 5 running, 57 sleeping, 18 waiting CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 27M Active, 462M Inact, 160M Wired, 404K Cache, 112M Buf, 2358M Free Swap: 6144M Total, 6144M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2 root 171 i-64 0K 32K CPU3 3 742:14 99.02% idle: cpu3 2 root 171 i-64 0K 32K RUN 2 742:14 99.02% idle: cpu2 2 root 171 i-64 0K 32K RUN 0 742:14 98.73% idle: cpu1 2 root 171 i-64 0K 32K RUN 1 742:14 98.44% idle: cpi0 40 root 20 - 0K 8K syncer 1 1:07 0.49% syncer 10 root -32 - 0K 8K WAIT 0 3:10 0.20% swi4: clock sio 0 root 96 0 0K 32K WAIT 2 742:14 0.00% swapper or top -S PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root 4 171 i-64 0K 32K CPU0 0 743:43 395.80% idle 40 root 1 20 - 0K 8K syncer 1 1:07 0.10% syncer 10 root 1 -32 - 0K 8K WAIT 0 3:10 0.00% swi4: clock sio 0 root 1 171 i-64 0K 32K CPU0 0 743:43 395.80% swapper There are many other reasons you may want to group kernel threads. for example a single process with all teh interrupt threads in it might be useful for accounting for interupts in some ways. > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" ------------------------------ Message: 21 Date: Mon, 22 Oct 2007 17:59:04 -0700 From: Julian Elischer <julian_at_elischer.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: Ivan Voras <ivoras_at_freebsd.org> Cc: freebsd-current_at_freebsd.org Message-ID: <471D4758.2040209_at_elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Ivan Voras wrote: > On 23/10/2007, Julian Elischer <julian_at_elischer.org> wrote: > >> If you wanted to limit CPU usage for a particular group of threads it >> may be worth grouping them into a process and then you could have >> some control over them with 'nice'. > > Kernel processes can be niced? Nice :) So, for example, in theory I > could renice a geli thread that I don't want to eat much of my CPU > from the userland? maybe bu from memory NICE doesn't actually affect real-time threads :-) so it'd require the process to voluntarily take itself out of that class. It was just a random example type thought.. no-one actually has a use for that yet. > >> The AIO threads need to be processes because each of them needs >> a different address space that can be hacked to cover the address space of the >> process they are working for. > > Ok, this is why we used kprocs for them... > >> The Idle threads couldbe in their own process so you can easily see how much cpu idle.. > >> There are many other reasons you may want to group kernel threads. >> for example a single process with all teh interrupt threads in it might >> be useful for accounting for interupts in some ways. > > So, mostly cosmetics :) emphasis on MOSTLY in my original patch 2 years ago I changes nearly all the users of kthread_create to use the new one and only a few things went on using kproc_create(). AIO was one, and there were a couple of others that I didn't trust, so I left them. > > (don't get me wrong, I have nothing against kthreads<->kprocs :) ) Alan Cox is here next to me and we are discussing whether all the threads that are in the kernel should be put under PID 0 and have it called "kernel" instead of "swapper". It's swapper thread would be called "swapper" however. ------------------------------ Message: 22 Date: Mon, 22 Oct 2007 18:09:40 -0700 From: Julian Elischer <julian_at_elischer.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: Scott Long <scottl_at_samsco.org> Cc: current_at_freebsd.org Message-ID: <471D49D4.5010607_at_elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Scott Long wrote: a lot of questions: I'll separate them. > > Why is there a need for separate kprocs with their own private kthreads > in the kernel? Generally there is not. Hence this change. > The kernel is a single unified address space; I thought > that the only real benefit to "true" kthreads was just elimination of > duplication of vmspaces for all off the kthreads that are currently > running around. yes, and the overhead that goes with it. i.e. double the number of processes on an average system -> extra contention on process related locks etc. > Do I gain some sort of security or management benefit > from having my own private kproc for my kthreads, or am I really just > burning another vmspace object and nothing more? Except for the case of AIO, you are currently burning an extra proc structure for no reason. That's why I'm switching.. Realize that up until now all kernel threads have been full processes. What I'm doing is: 1/ changing the name of the exisitng function that makes processes to a name that actually says that. 2/ introducing a new function that makes an actual kernel THREAD. 3/ switching as many possible of the users to use the THREAD version. > What about the > existing fast context switching between kthreads (i.e. not flushing CR3 > on the switch), will that remain, or does it now get more complicated? It stays the same > Are there scheduling implications and benefits not really > > In fact for that > matter, how is scheduling going to be done for this? Is it all going to > be 1:1 style scheduling, or will there be a multi-tier scheduler for > kprocs and kthreads and associated niceness/fairness? What about high > priority kthreads like ithreads, taskqueues, and SWI's? no change. All threads are individually scheduled as they are now. > > If I've missed the discussion on scheduling, I apologize. If not, have > these questions been thought through yet? yes > > Scott ------------------------------ Message: 23 Date: Tue, 23 Oct 2007 02:47:06 +0200 From: "Ivan Voras" <ivoras_at_freebsd.org> Subject: Re: kthreads->kproc and back to kthread.. next patch To: "Julian Elischer" <julian_at_elischer.org> Cc: freebsd-current_at_freebsd.org Message-ID: <9bbcef730710221747w4d338e78mb9dbf5e2eb37908_at_mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 23/10/2007, Julian Elischer <julian_at_elischer.org> wrote: > If you wanted to limit CPU usage for a particular group of threads it > may be worth grouping them into a process and then you could have > some control over them with 'nice'. Kernel processes can be niced? Nice :) So, for example, in theory I could renice a geli thread that I don't want to eat much of my CPU from the userland? > The AIO threads need to be processes because each of them needs > a different address space that can be hacked to cover the address space of the > process they are working for. Ok, this is why we used kprocs for them... > The Idle threads couldbe in their own process so you can easily see how much cpu idle.. > There are many other reasons you may want to group kernel threads. > for example a single process with all teh interrupt threads in it might > be useful for accounting for interupts in some ways. So, mostly cosmetics :) (don't get me wrong, I have nothing against kthreads<->kprocs :) ) ------------------------------ Message: 24 Date: Mon, 22 Oct 2007 22:21:00 -0400 From: Ken Smith <kensmith_at_cse.Buffalo.EDU> Subject: 7.0-BETA1 Available, 6.3-BETA1 coming soon... To: freebsd-stable_at_freebsd.org, freebsd-current_at_freebsd.org Message-ID: <1193106060.82079.19.camel_at_neo.cse.buffalo.edu> Content-Type: text/plain; charset="us-ascii" We have entered the final phases of the FreeBSD-7.0 Release cycle which also means the beginning of the FreeBSD-6.3 Release cycle. Because the people who support the ports for FreeBSD also need to go through a freeze cycle as part of releases we had decided to combine the two releases to try and minimize the impact on the ports maintainers. The current plan is to interleave the BETAs/RCs of the 7.0 and 6.3 releases, trying to follow this for the dates when the builds will get started (with them becoming available on the FTP mirrors a day or two after the builds start): 7.0 6.3 BETA1 10/17 10/24 BETA2 10/31 11/7 RC1 11/14 11/21 RC2 11/28 12/5 REL 12/12 12/19 Tomorrow (10/23) the RELENG_6 branch will be marked "6.3-PRERELEASE" to note that we have entered the 6.3 release cycle. The schedule dates are, as usual, tentative. At this point RELENG_6 is pretty mature so that schedule should be fairly accurate. Being a new branch it is at least somewhat likely the dates for 7.0 will wind up slipping. The 7.0-BETA1 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA1 will be provided via the freebsd-stable list when available. The MD5/SHA256 sums for the ISO files are: MD5 (7.0-BETA1-amd64-bootonly.iso) = 8c6c02401bbd2e68d11ec554e4e1c4a2 MD5 (7.0-BETA1-amd64-disc1.iso) = 91280b705c7330225f6245c6316f6c41 MD5 (7.0-BETA1-amd64-disc2.iso) = 81dab65b611ec4ebea40f311969ad27a MD5 (7.0-BETA1-amd64-docs.iso) = cc002beb3a69ab6245a8a70f52b3528c MD5 (7.0-BETA1-amd64-livefs.iso) = 526554b4b5cc98b2544dd817dbf42b0c MD5 (7.0-BETA1-i386-bootonly.iso) = a1caa2daa032294a5ab101ba7507325a MD5 (7.0-BETA1-i386-disc1.iso) = 47929d67f5673ddd856f54811e744ac2 MD5 (7.0-BETA1-i386-disc2.iso) = 432c54565287f49a7449cb452267852e MD5 (7.0-BETA1-i386-docs.iso) = 57e032ba93b1395a2f2bc859a8816f6a MD5 (7.0-BETA1-ia64-bootonly.iso) = b868f5accee282cc386c419ffcf8642e MD5 (7.0-BETA1-ia64-disc1.iso) = 59c63c6dd5a6986e30fe5cdd218b1d18 MD5 (7.0-BETA1-ia64-disc2.iso) = 9a011dafcd964a1c3e7dff689ebc5cf9 MD5 (7.0-BETA1-ia64-docs.iso) = 3bbf0db507b317a8fa3afe48b800f557 MD5 (7.0-BETA1-ia64-livefs.iso) = 93c3de935c3002a39b291b10f4c45be8 MD5 (7.0-BETA1-pc98-bootonly.iso) = b38f9676dd15308464e81172f9fbaa37 MD5 (7.0-BETA1-pc98-disc1.iso) = d00d2d92ab7b5ff248e431ff22229d11 MD5 (7.0-BETA1-sparc64-bootonly.iso) = 1a64706fe2c42d338af2f136ef57a903 MD5 (7.0-BETA1-sparc64-disc1.iso) = f72780b77fae0b841f08c2126d8e6007 MD5 (7.0-BETA1-sparc64-disc2.iso) = 0477d9547d03b97033c07efac1c1a212 SHA256 (7.0-BETA1-amd64-bootonly.iso) = 343b2b3c63daa8e99dd3cf80f2eb65a63810fc1caef7dbe74ebf54b57d4c8923 SHA256 (7.0-BETA1-amd64-disc1.iso) = 658d9ef30d07576038b8d40724851b46de1311d9ef742806c24c8b284ec72d11 SHA256 (7.0-BETA1-amd64-disc2.iso) = c596d4f7904cb2ffca06fd9f3958dd8068cacb92fa22d57e3b53b03029eee8f6 SHA256 (7.0-BETA1-amd64-docs.iso) = a3399826d857488b18a89f915e1397e07966d979209ed9f2f909b546764ce07a SHA256 (7.0-BETA1-amd64-livefs.iso) = c32eaba36056e6a5fdcfec3cb9af582c5c77d8a7594e9e552ffc974c624206e3 SHA256 (7.0-BETA1-i386-bootonly.iso) = fb3dfc57b0fe53ac44471049cfd7ed043409387bb108d4dfaaa3b2285a2d67ae SHA256 (7.0-BETA1-i386-disc1.iso) = 3d3eefe8c200deddafb9ed1315295ff52aa18b59429b480ae57a73bc8f4edd59 SHA256 (7.0-BETA1-i386-disc2.iso) = 05c84ab7d419e4971493eaeda953a8fbfdb2dee811528d2275e175cdc8fa2271 SHA256 (7.0-BETA1-i386-docs.iso) = b26d5d7f2448c1e0e4f72339c25d065b83529861698a9cf3c60f165e1fa8a6a9 SHA256 (7.0-BETA1-ia64-bootonly.iso) = 3925348937423230d18ba072ef117e5343dfd02414c3a75cfa56d84cc325a1c8 SHA256 (7.0-BETA1-ia64-disc1.iso) = 8b39ce0b83e4fd04343d2a8e595bfbd7ded3abec8d4ff64dcf27ecaadc823f02 SHA256 (7.0-BETA1-ia64-disc2.iso) = 83e9e025064922449e6521ce92fcb32496fea04e271b5fe0157ca4f59c0cc5b0 SHA256 (7.0-BETA1-ia64-docs.iso) = 149e7525b6eb7157ce41139e9c7ad53625c4e287a4dbba5e257edc0dbe347dfa SHA256 (7.0-BETA1-ia64-livefs.iso) = 54d716313a51d80b5583e2439ecac99c5e5ca67121fccc21f53b1483fa1d9178 SHA256 (7.0-BETA1-pc98-bootonly.iso) = e79a8003786e1b031860f251c8b0dcaac8ce27c52f363fa4df7e3d19b15f3ce7 SHA256 (7.0-BETA1-pc98-disc1.iso) = c7e11c012b3e0c4a45c965a46cbda0209d873dd8d7a56cf59af4ea3acb4776bc SHA256 (7.0-BETA1-sparc64-bootonly.iso) = c9d9c2baab182848af6ed6f3a3711b03ad734073a64b0c25607062bf152d2283 SHA256 (7.0-BETA1-sparc64-disc1.iso) = 8a1800bc03a6498f71fe739ac5a618b5fc1ef27d10a891cf5a9a81ff4c45bbd7 SHA256 (7.0-BETA1-sparc64-disc2.iso) = 2a2f63cf1d84b13018d77414c3f89d4da7acbb0a22653e59fda54759efbf03d7 -- Ken Smith - From there to here, from here to | kensmith_at_cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071023/42a97ee5/attachment-0001.pgp ------------------------------ Message: 25 Date: Mon, 22 Oct 2007 23:17:48 -0400 From: "Josh Carroll" <josh.carroll_at_gmail.com> Subject: Re: bsdtar can't handle files >8GB To: "Bruce Cran" <bruce_at_cran.org.uk> Cc: current_at_freebsd.org Message-ID: <8cb6106e0710222017p133ddccyc973c6ebcd23e270_at_mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > tar: Unrecognized archive format: Inappropriate file type or format > tar: Error exit delayed from previous errors. Confirmed in RELENG_7 as well. Interestingly enough, if the file inside the tarball is nothing but zeros (dd if=/dev/zero ...), I don't get this error. However, it doesn't work either. The resulting file is 0 bytes, rather than 10 GB of \0. Note that 10 1GB files worked just fine. Josh ------------------------------ Message: 26 Date: Tue, 23 Oct 2007 02:42:58 -0400 From: "Aryeh M. Friedman" <aryeh.friedman_at_gmail.com> Subject: Re: an interesting observation on network performence To: "Aryeh M. Friedman" <aryeh.friedman_at_gmail.com> Cc: freebsd-current_at_freebsd.org Message-ID: <471D97F2.7030900_at_flosoft-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Aryeh M. Friedman wrote: > I get better network performance on XP running under qemu on 8-current. > (sorry don't have hard numbers but it roughly times better on p2p > apps). Here is the config: > oops two times better ------------------------------ Message: 27 Date: Tue, 23 Oct 2007 02:36:08 -0400 From: "Aryeh M. Friedman" <aryeh.friedman_at_gmail.com> Subject: an interesting observation on network performence To: freebsd-current_at_freebsd.org Message-ID: <471D9658.4060005_at_gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I get better network performance on XP running under qemu on 8-current. (sorry don't have hard numbers but it roughly times better on p2p apps). Here is the config: Host OS: 8-current amd64 4gb ram bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 62:4e:c7:60:d0:a0 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:bd:43:f2:02:00 inet6 fe80::2bd:43ff:fef2:200%tap0 prefixlen 64 scopeid 0x5 Opened by PID 14839 sudo qemu -net nic -net tap -hda test -localtime -m 1024 -soundhw all Host p2p program: deluge (latest) Guest OS: XP Pro SP2 (all updates as of 1/1/2007) Guest p2p program: uTorrent 1.7 ------------------------------ Message: 28 Date: Tue, 23 Oct 2007 13:51:44 +0900 From: Daichi GOTO <daichi_at_freebsd.org> Subject: [ANN] 8-CURRENT, RELENG_7 and RELENG_6 have gotten latest unionfs improvements To: FreeBSD Current <freebsd-current_at_freebsd.org>, freebsd-stable_at_freebsd.org, freebsd-fs_at_freebsd.org Cc: Masanori OZAWA <ozawa_at_ongs.co.jp>, Daichi GOTO <daichi_at_freebsd.org>, Ed Schouten <ed_at_fxq.nl>, Stanislav Sedov <stas_at_FreeBSD.org>, Jeff Roberson <jroberson_at_chesapeake.net>, Ken Smith <kensmith_at_cse.Buffalo.EDU> Message-ID: <471D7DE0.2070103_at_freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Hi unionfs folks It is my pleasure and honor to announce the commitment of latest unionfs improvements for 8-current, RELENG_7 and RELENG_6. Now you can get more stable operation using unionfs on latest 8/7/6. This latest improvements give finstall and FreeSBIE works more well as well as other unionfs works good. If you have interesting in it, would you try it please. However, follow two issues we still have: - It gets a hang-up in a certain case using with NFS. - We cannot see devfs on unionfs. I am going to try those issue fix in near future. Thanks all folks who have helped us! The documents of those unionfs: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) -- Daichi GOTO, http://people.freebsd.org/~daichi ------------------------------ Message: 29 Date: Tue, 23 Oct 2007 09:54:39 +0200 From: VANHULLEBUS Yvan <vanhu_bsd_at_zeninc.net> Subject: NAT_T patch update for FreeBSD 7 / HEAD To: freebsd-current_at_freebsd.org, freebsd-net_at_freebsd.org Message-ID: <20071023075439.GA9645_at_zen.inc> Content-Type: text/plain; charset=us-ascii Hi all. It took me more time than what I expected to provide an updated NAT_T patch for FreeBSD7 / HEAD, mainly because of hardware issues with my FreeBSD7 workstation, but here are updated patches, which applies/compiles and which seems to work correctly (not so much tested for now, I still don't have any FreeBSD7 in production :-) on RELENG7 branch and on recent HEAD (recent means "after KAME's IPSec stack removal"). http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2007-10-22.diff MD5 (patch-natt-freebsd-HEAD-2007-10-22.diff) = 71ecd192d6df4c499011965bc0c76032 http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2007-10-22.diff MD5 (patch-natt-freebsd7-2007-10-22.diff) = bcb4a85a78d9249f8ff493051952d26b Any feedback, bug report, open issue, question to help reporting the patch faster to the official CVS, etc.... are welcome ! Yvan. -- NETASQ http://www.netasq.com ------------------------------ _______________________________________________ freebsd-current_at_freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" End of freebsd-current Digest, Vol 217, Issue 3 ***********************************************Received on Tue Oct 23 2007 - 20:37:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:20 UTC