http://blog.gmane.org/gmane.os.freebsd.devel.hackers hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50769 <pre>Hi All I've been read thousands of pages of FreeBSD and Linux Kernel source code and books on the internals of BSD and Linux over the years in attempt to develop a complete understanding of operating systems (or at least, UNIX like ones). However, I feel that I'm as mystified as to the finer details as when I first started. So I've concluded that the best way to really understand the deep dark details of UNIX is to try and write one from scratch (using the general guidelines of standards like POSIX etc ...), and maybe taking a peek at BSD and Linux from time to time. My questions around this are: a) What kind of hardware (processor) would I use as a development platform, given the requirements of cheap, well documented, easily obtainable, easy to debug etc ... I believe the hardware platform chosen should satisfy the following requirements: - Cheap and relatively commodity (easy to get hold of) - Well documented architecture and API (there's a nice assembly language for it) - </pre> Welcome, Traiano 2013-05-24T10:15:23 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50761 <pre>how to redirect recipient address. i mean - if someone try to send to x&lt; at &gt;y.pl from serwer then it should be redirected to local account, while the rest of mails to domain &lt; at &gt;y.pl should get out normally. alternatively outgoing mail to x&lt; at &gt;y.pl should be rejected. tried access.db - To:x&lt; at &gt;y.pl REJECT doesn't work any idea. thank you _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Wojciech Puchar 2013-05-24T07:33:55 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50758 <pre> Hi all, I am currently doing some performance tests with 10Gb NICs and encounter a strange behavior in case when I do Rx and Tx at the same time: while the Rx rate stays more or less stable (almost the same that I see with only Rx traffic) the Tx rate breaks down drastically. The tests are done with netperf (4 TCP streams for Rx and Tx respectively), the test machine is an Intel i7 (with HT 8 cores at 3,4 GHz) with 16GB RAM running 32 bit FreeBSD 9.0 with default system settings. The results are like the following: TX Only: 2290.32 Mb/s Port=1001 TX 2357.73 Mb/s Port=1002 TX 2340.08 Mb/s Port=1003 TX 2382.87 Mb/s Port=1004 TX TX Total Result: Mb/s 9371 RX Only: 1257.43 Mb/s Port=1001 RX 1901.75 Mb/s Port=1002 RX 2605.19 Mb/s Port=1003 RX 1986.69 Mb/s Port=1004 RX RX Total Result: Mb/s 7751.06 Rx+TX: 251.11 Mb/s Port=1001 TX 3069.74 Mb/s Port=2001 RX 178.35 Mb/s Port=1002 TX 1118.30 Mb/s Port=2002 RX 138.05 Mb/s Port=1003 TX 1661.22 Mb/s Port=2003 RX 129.23 Mb/s Port=1004 TX 1851.75 Mb/s Port=2004 RX R</pre> Lino Sanfilippo 2013-05-23T18:00:16 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50756 <pre>I have a small test program which simply forks and execs its command line arguments, but after the fork and before the exec, it sends a SIGSTOP to the child. The parent then sleeps for 3 seconds before exiting. However, a signal handler for SIGCHLD has been installed and I was expecting the parent to be notified of the SIGSTOP sent to the child, but with the `signal' interface this doesn't appear to work. If I change the code to use `sigaction' and `sigprocmask' (to unblock any blocked SIGCHLD), this program works the way intended, that is, the signal handler is called: 1 #include &lt;stdio.h&gt; 2 #include &lt;signal.h&gt; 3 #include &lt;stdlib.h&gt; 4 #include &lt;fcntl.h&gt; 5 #include &lt;sys/types.h&gt; 6 #include &lt;sys/wait.h&gt; 7 #include &lt;sys/time.h&gt; 8 #include &lt;sys/resource.h&gt; 9 10 #define SIGACTION 11 12 static void waithandler(int i){ 13 int pid, cursig; 14 int tstat; 15 16 #ifdef SIGACTION 17 pid = waitpid(-1, &amp;tstat, WUNTRACED); 18 #else 19 p</pre> Noel Hunt 2013-05-22T22:48:28 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50753 <pre>Hi all, I have an ageing Toshiba Portege R600 laptop (Intel ULV SU9400 1.4GHz Core2 CPU, 3GB RAM) running the latest v3.2 BIOS. I recently stuck a new Samsung 840 Pro 256GB SSD into it and decided to do my usual trick of dual booting Windows 7 and FreeBSD-on-ZFS-root. Windows 7 won't boot from a GPT scheme without a (U)EFI BIOS, so I had to use MBR + BSD labels for FreeBSD which I've never done before with ZFS. I followed the guide at [1] using the FreeBSD head r250260 snapshot from [2]. Rebooting into my newly configured FreeBSD slice from the boot0 F3 option, I'd see zfsloader start running and then the machine would reset. The last line flashed up on screen before the reset was something like "BIOS drive C:". With Andriy's (avg&lt; at &gt;) help, I went digging and traced the problem to zfsloader attempting to probe "disk0:" (floppy drive, though the machine doesn't have one physically). The code call path looks roughly like this with some functions omitted in the middle related to bios disk strategy. zfs_probe_</pre> Lawrence Stewart 2013-05-22T02:49:58 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50748 <pre>OK, maybe I'm missing something obvious, but... find(1) says: -delete Delete found files and/or directories. Always returns true. This executes from the current working directory as find recurses down the tree. It will not attempt to delete a filename with a ``/'' character in its pathname relative to ``.'' for security reasons. Depth-first traversal processing is implied by this option. Following symlinks is incompatible with this option. However, it fails even when the path is absolute: bhyve9# mkdir /tmp/foo bhyve9# find /tmp/foo -empty -delete find: -delete: /tmp/foo: relative path potentially not safe Shouldn't this work? I ran into this during a build of stable/9 with WITHOUT_SHAREDOCS set, which ultimately triggers this bit of /usr/src/Makefile.inc1: .for dist in ${EXTRA_DISTRIBUTIONS} find ${DESTDIR}/${DISTDIR}/${dist} -empty -delete .endfor The actual observed failure is this: ===&gt; etc/sendmail (d</pre> Kurt Lidl 2013-05-20T19:23:16 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50743 <pre>During the BSDCan &amp; DevSummit I got interested in finding out why blogbench is so slow on FreeBSD. After talking to jhb, it looked like one of the reasons might be that opening files with O_RDWR or O_WRONLY (anything opening the file for writing) is serialized. To check this, I've written a small test program, which I've run on CentOS 6.3 and FreeBSD 10-HEAD on the same hardware. Here are the results: https://wiki.freebsd.org/Benchmarking/OpenCloseBenchmark Conclusions: * Linux opens and closes files much faster than FreeBSD * Linux does not serialize write-open operations, while FreeBSD does * Even with O_RDONLY, FreeBSD is much slower in opening (and closing) files. I'd welcome a review of these results and comments. _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Ivan Voras 2013-05-18T04:04:05 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50731 <pre>I have to retrieve some very old backups. They were made on FreeBSD and are on tape... specifically DDS4. I have a DDS4 drive and I ordered cables that hook it up to my sparc64. For fun and giggles I have both the motherboard controller... sym0: &lt;1010-66&gt; port 0x900-0x9ff mem 0x100000-0x1003ff,0x102000-0x103fff at device 2.0 on pci2 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym1: &lt;1010-66&gt; port 0xa00-0xaff mem 0x104000-0x1043ff,0x106000-0x107fff at device 2.1 on pci2 sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking and an adaptec controller ahc0: &lt;Adaptec 3960D Ultra160 SCSI adapter&gt; port 0x300-0x3ff mem 0x100000-0x100fff at device 1.0 on pci3 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: &lt;Adaptec 3960D Ultra160 SCSI adapter&gt; port 0x400-0x4ff mem 0x102000-0x102fff at device 1.1 on pci3 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs in the box. The tape drive is terminated with an external terminator (which seems proper since I found it in my collection with tha</pre> Zaphod Beeblebrox 2013-05-16T20:51:34 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50729 <pre>We need to log all translations from internal IP addresses to external addresses. It's good enough to have IPv4 to Ipv4 translations for TCP streams, just one log for the start of each stream. We're using FreeBSD-9.1-stable and IPFW with userland natd. The -log option of natd just seems to log statistics, not any translation information. I can't see any easy way to do this with ipfw's rule log option either. Any ideas? </pre> Daniel Eischen 2013-05-15T22:48:08 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50722 <pre>Hi folks, Can I ask if there's any way to get ucred/xucred of a process in user space? As I'm trying to port glustertfs and it's a userland filesystem, I need to get secondary groups of a process. AFAIK, Linux gets them in /proc and NetBSD gets them in this way: int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, frame-&gt;root-&gt;pid }; size_t namelen = sizeof name / sizeof name[0]; struct kinfo_proc kp; size_t kplen = sizeof(kp); int i, ngroups; if (sysctl(name, namelen, &amp;kp, &amp;kplen, NULL, 0) != 0) return; ngroups = MIN(kp.kp_eproc.e_ucred.cr_ngroups, GF_REQUEST_MAXGROUPS); I realized none of them would work in FreeBSD. I'm wondering if there's any alternative way to get group information? </pre> Mike Ma 2013-05-14T08:00:21 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50706 <pre>Hello to all, I'm trying to reply to this thread: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.html I also faced this very difficult task of tracking down the user data registered into kq. I end up having some "Tokens" instances which I never deallocate but always re-use them or create new ones if necessary. This tokens are used as user data for kq. They are keeping the actual pointers inside them, and the pointer itself has a reference to the Token. When the pointer dies, I reset the guts of the token. When the time comes to use the token, I have the guarantee is not the corpse of a token (never deallocate them, remember?) and I can see that the actual pointer was gone, everyone is happy. At the application shutdown, I cleanup the mess (the tokens). However, I just want to say that Paul has a valid point when he is wondering why EV_FREEWATCH was not provisioned/implemented. The moment we throw multi-threading into equation, this becomes a extremely hard thing to manage (close </pre> Eugen-Andrei Gavriloaie 2013-05-13T15:19:43 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50705 <pre>Dear Guys; In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: # kldload alq # kldunload alq # init 0 or shutdown -p now it will panic! maybe it's a bug. We have a module which uses alq API's. MODULE_DEPEND(mymodule, alq, 1, 1, 1) when our module starts, loads alq. and when it stops, unloads alq. So after starting and stoping our module and shutdown, we have panic. any opinion in this regard would be appreciated. _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Computer Network Man 2013-05-13T06:37:19 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50703 <pre>FreeBSD Quarterly Status Report, January-March 2013 Introduction This report covers FreeBSD-related projects between January and March 2013. This is the first of four reports planned for 2013. Highlights from this status report include the busy preparations of 8.4-RELEASE, restoration of binary package building, steady progress of several porting efforts, like work on the FreeBSD ports of xorg, GNOME, KDE, and Xfce, bringing FreeBSD to Cubieboard and Hackberry boards, development of ARM and AMD GPU support, improving performance of UFS/FFS and callouts, and introducing a multipath TCP implementation for the network stack. Thanks to all the reporters for the excellent work! This report contains 31 entries and we hope you enjoy reading it. The deadline for submissions covering the period between April and June 2013 is July 7th, 2013. __________________________________________________________________ Projects * FreeNAS * Kernel Information in Process </pre> Gabor Pali 2013-05-12T17:54:05 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50696 <pre>Apologies for the cross post. Were trying out the ofed code and running into some issues, so would love to discuss. -vijay _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Vijay Singh 2013-05-10T22:01:25 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50693 <pre>Hello, I have been taking a look at a few syscalls in /usr/src/sys/kern/ and always find that in their actuall c definition the function names are preprended by a sys_. Take for example the fork system call which is found in /usr/src/sys/kern/kern_fork.c int sys_fork(struct thread *td, struct fork_args *uap) ... Now when I write a program from userland, that makes use of the fork system call, then if call it as: fork(); All the syscall are part of libc, which is usually defined in /usr/src/lib/libc/ Since the system calls are already defined in the kernel sources, they no longer need to be defined in /usr/src/lib/libc/. This is the reason why one can only find the manpages and no c files in /usr/src/lib/libc/sys? At least this is how my thinking goes. Now, when the syscalls in the kernel sources are all defined as sys_xxx but are invoked as xxx and the c headers also show syscall prototypes without any prepended sys. How does the actual user-, kernelland move happen? In other words, why do I in</pre> Karl Dreger 2013-05-10T19:31:24 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50689 <pre>Hi, big picture: I want to get access to my USB DVB device in a jail. First I explain what works (to show what I already know in this regard), then I explain what doesn't work (where I seem to lack some knowledge). What I did so far: I already patched my kernel to give access to /dev/io and /dev/dri in a jail to have X1 up and running in a jail (works since some years): - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel) for the priv_check() for /dev/dri - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c which allow access if a specific allow.xxx flag is set for the jail - added the following lines to devfs.rules in a x11-jail specific section (plus some more devices): ---snip--- add path agpgart unhide add path dri unhide add path 'dri*' unhide add path nvidiactl unhide add path 'nvidia*' unhide add path io unhide add path mem unhide ---snip--- Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff Result so far: - I see the io/mem/nvidia* devices (wh</pre> Alexander Leidinger 2013-05-09T09:07:18 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50676 <pre>Hi fellow -hackers&lt; at &gt;, I've taken a new snapshot of HEAD usr.sbin/bsdconfig and made it available through the ports tree. The last snapshot was almost 12 full months ago, and a lot has changed since then. Most notably, we have the beginnings of the package management module now and we're edging ever-closer to 1.0 release status. I'd like to see if there are any interested folks out there that could give my updated sysutils/bsdconfig port a go and provide some feedback (while I'm still in lighter development phase). Any/all feedback would be greatly appreciated. Just an FYI however… this code is only expected to work on 9.0-R or higher. </pre> Teske, Devin 2013-05-07T19:04:28 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50675 <pre>Hi, I experienced OS freeze when I using Chromium on FreeBSD-CURRENT. - Apr 23 version of FreeBSD-CURRENT/amd64 - Chrome version is 24.0.1312.52(175374) - Flash plugin installed - Not happen with other apps like Firefox - Not depending videocards, it's happen on at least nvidia/intel/matrox video cards - At reast happen on two machines(both are intel core i3/5/7 series) It at least happen on Nvidia / Intel / Matrox video cards, so looks like not depending on video card / driver, and also it doesn't happen until start using Chromium(Firefox is fine). Does anyone have a idea what is the reason? And is there any way to get dmesg &amp; ddb when I using X? Maybe via serial port, but my machines doesn't have a serial port.. _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Takuya ASADA 2013-05-07T13:51:13 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50669 <pre>This patch uses do_cpuid function to fetch CPU Physical and Virtual address sizes and adds 2 new sysctl machine dependant OIDs (machdep.cpu_physical_address_bits and machdep.cpu_virtual_address_bits). In order to retrieve the information, it calls do_cpuid by setting eax register to 0x80000008 value like referenced in chapter 5.2.7 in the CPUID specification [1] Apple, Inc. in xnu kernel do the same thing but they created a specific node called 'machdep.cpu' to store CPU Vendor information, the sysctls are machdep.cpu.address_bits.virtual and machdep.cpu.address_bits.virtual. I really would like to see this patch in our operating system because it's a valuable information nowdays and should be provided like others. Thus, I would like advices to see if before to be imported it needs modification to fit like Apple (i.e using a new sysctl node) or stay like that. Also, I profited of this changes to patch sys/modules/linprocfs in order to display the address sizes values in the output of /usr/compat/linux/p</pre> Sofian Brabez 2013-05-05T23:37:01 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50665 <pre>Hi, I just proceeded a full upgrade from FreeBSD 9.1-RELEASE to the latest 9-STABLE snapshot using tarball sets. I done it this way : tar xpf src.txz -C / tar xf base.txz -C /usr/src mergemaster -p mergemaster -FUi tar cpf etc.tar -C / etc tar xpf base.tar -C / tar xpf etc.tar -C / tar xpf kernel.txz -C / reboot The system work well, I have all my old merged configuration. But, does someone has something to remove old files, like a make delete-old ? Thanks </pre> Florent Peterschmitt 2013-05-04T18:49:08 http://comments.gmane.org/gmane.os.freebsd.devel.hackers/50651 <pre>I am trying to compile this code fragment into my program (taken from lib/libc/amd64/sys/sbrk.S): void my_func() { ... __asm__ __volatile__( "movq .curbrk(%%rip), %%rax;" "lea .curbrk(%%rip), %%rdx;" "movq %%rax, %0;" "movq %%rdx, %1;" : "=r" (my_curbrk), "=r" (my_curbrk_ptr) :: "%rax", "%rdx"); ... } I get a warning: /usr/bin/ld: warning: type and size of dynamic symbol `.curbrk&lt; at &gt;&lt; at &gt;FBSDprivate_1.0' are not defined What is the correct way to declare .curbrk in in-place assembly? Yuri _______________________________________________ freebsd-hackers&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe&lt; at &gt;freebsd.org" </pre> Yuri 2013-05-03T20:10:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.freebsd.devel.hackers