Re: iso2flash img
On Wed, Mar 21, 2012 at 11:11:42PM +1000, Da Rock wrote: ... > In the meantime I think I may have stumbled on the solution to the > script: In the midst of all the output it mentions "usage realpath [-q] > path". I wasn't 100% sure exactly what that meant, but I put the full > path to the iso and a full path to an img file and I *think* that > worked. I've yet to test the result; and I have no idea of the '-q' > option REALPATH(1) FreeBSD General Commands ManualREALPATH(1) NAME realpath -- return resolved physical path SYNOPSIS realpath [-q] path [...] DESCRIPTION The realpath utility uses the realpath(3) function to resolve all sym- bolic links, extra `/' characters and references to /./ and /../ in path. If -q is specified, warnings will not be printed when realpath(3) fails. EXIT STATUS The realpath utility exits 0 on success, and >0 if an error occurs. SEE ALSO realpath(3) HISTORY The realpath utility first appeared in FreeBSD 4.3. FreeBSD 8.1November 24, 2000 FreeBSD 8.1 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
still issues with unreadable dmesg output on SMP systems
hi there, a few years ago there were huge issues with SMP and dmesg output, where messages from various drivers were output to /dev/ttyv0 without any timing, which caused a lot of unreadable lines. this was fixed and almost all of the dmesg lines i see now look similar to dmesg on a non-SMP aware kernel. however there still seems to be an issue within the cd(4) driver. maybe somebody could fix the driver output to match the drivers, where the dmesg output looks correct (da(4), ada(4), ...). here's a bit of dmesg output. i'm running HEAD on amd64 btw.: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: w " Rfermeoqvuaebnlcey CD1-4R0O6M2 5S0C0S IH-z0 qdueavliityc e1 000 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 40.000MB/s transfers da0: 953837MB (1953458176 512 byte sectors: 255H 63S/T 121597C) again: apart from cd(4) all the drivers i have enabled in my kernel config produce proper dmesg lines. cheers. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On Wed, Mar 21, 2012 at 10:52:53AM -0500, Mark Felder wrote: > As an alternative I recently purchased a Zalman ZM-VE200 device (there's > also a USB3.0 flavor) that lets you copy ISOs to it and it will emulate a > CDROM/DVDROM/BDROM for you so you never have to deal with this mess again. > It works amazingly well. I was tired of fighting this problem and this is > an amazing solution -- I can keep every ISO I ever need on a single drive. > > http://www.zalman.com/eng/product/Product_Read.asp?idx=431 > http://www.zalman.com/eng/product/Product_Read.asp?idx=459 > http://www.rmprepusb.com/tutorials/ve200 really nice, thanks for the link. Now if they had something that supported a USB key it would be even nicer... cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On 22/03/12 12:15 +0100, Luigi Rizzo wrote: > On Wed, Mar 21, 2012 at 10:52:53AM -0500, Mark Felder wrote: > > As an alternative I recently purchased a Zalman ZM-VE200 device (there's > > also a USB3.0 flavor) that lets you copy ISOs to it and it will emulate a > > CDROM/DVDROM/BDROM for you so you never have to deal with this mess again. > > It works amazingly well. I was tired of fighting this problem and this is > > an amazing solution -- I can keep every ISO I ever need on a single drive. > > > > http://www.zalman.com/eng/product/Product_Read.asp?idx=431 > > http://www.zalman.com/eng/product/Product_Read.asp?idx=459 > > http://www.rmprepusb.com/tutorials/ve200 > > really nice, thanks for the link. Now if they had something > that supported a USB key it would be even nicer... > > cheers > luigi > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" This remembers me a recent kickstarter project called isostick :) - rodrigo http://www.kickstarter.com/projects/elegantinvention/isostick-the-optical-drive-in-a-usb-stick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
I've refined the behaviour I observe, which isn't consistent depending on the size one mallocates. (see interleaved comments) > In my driver, I need to map some malloc-ed memory, obtained from > another module, into userspace. > > The problem: on the smaller mallocs, as well as on some bigeer ones > (8k seems fine, 64k fails): vm_map_lookup() fails finding the > underlying vm object. In the current implementation I'm calling vm_map_lookup() against the kmem_map. As a result it either return the kmem_object, or fails at all (for smaller or larger mallocs.) > Do somebody know how (or better, have a piece of code!) to retrieve > the vm_object associated with malloc-ed memory? (small and big ones) > > As far as I can see in the vm code, there isn't any object associated > with the slabs (the smaller mallocs), it seems that a huge chunk of > virtual space is used "as is", so I presume the virtual addresses > where the SLABs are have some remarkable property, with respect to > physical addresses, that could allow creating an object from scratch? By using kernel_map instead of kmem_map, vm_map_lookup() now always return a vm_object. That's a big progress. As expected, when this object is kmem_object, the user mapping works fine (for smaller or larger mallocs.) Otherwise that object doesn't match kernel_object. It's an anonymous object to me. Using that "anonymous" vm_object for mapping into user map (using vm_map_find()) doesn't directly fail, it does provide a virtual address in the user map. However I read zeros at that address, from within the user process. Any help would be highly appreciated. Thanks! Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improving gcore
On Wed, Mar 21, 2012 at 04:35:13PM -0700, Sushanth Rai wrote: > Sometimes I have trouble capturing the "correct" state of a > multithreaded process using gcore. That is, it looks like target > process might have done some work since the time command was issued > and the core file was generated. > > Looking at the code, gcore calls ptrace(PT_ATTACH...), which > internally issues SIGSTOP, and calls waitpid() to wait until the > process stops. So, it's quite possible that some threads that are not > sleeping interruptibly will continue to run until the process notices > the signal. Signals are only checked when a thread that is tagged to > handle the signal crosses the user boundary (return from syscall, > trap). When the thread finally handles SIGSTOP, it needs to stop all > threads, which is done by lighting a flag-bit it each thread. This > bit is checked as each thread crosses the user boundary. So, there > will always be some state change in the target process from the time > SIGSTOP is posted to the time all threads are actually stopped. Yes, this is how things work. There are two factors causing the asynchronous stopping: first, other CPUs may execute several threads of the process, so the suspension of that other threads require an IPI to be generated. IPI_AST handler just returns, which causes kernel->usermode transition and possible signal delivery and suspend check. second, kernel never allows to suspend thread executing and blocked in kernel. Doing otherwise would cause deadlocks, because executing threads own resources that are shared with other threads. So, the only safe points to suspend the threads is at kernel->user boundary or at some sleep points that are not marked as unsafe with PBDRY flag. On the other hand, since kernel waits for all threads to suspend before reporting the wait(2) event, the usermode state shall be consistent with itself, or rather, it shall be not worse then if the threads reach the stop point executing asynchronously on different CPUs. See the check for p->p_suspcount == p->p_numthreads in the kern_wait() function before it decides that the found process is satisfactory for wait request. > > I was wondering if I could improve this a bit by calling PT_SUSPEND on > all threads, instead of posting SIGSTOP and waiting for all threads > to stop. Once the core is generated, unsuspend all threads. As with > SIGSTOP, individual thread will only notice suspension as they cross > user boundary. But there is no overhead of tagging a thread to handle > the signal and that thread doing the suspension. The idea is to try > and generate the core file which reflects the running state of the > process as closely as possible. PT_SUSPEND can only be called on the process which you alread attached to. So the call to suspend all threads of the just attached threads is mostly nop for your purposes. > > Does this sound reasonable ? I think you need to describe in more details what do you mean by inconsistent state of the threads in gcore-generated core file, before some conclusion could be made. pgpGQtQXErHXQ.pgp Description: PGP signature
Re: Approaching the limit on PV entries
On Wednesday, March 21, 2012 4:20:17 pm Mark Saad wrote: > On Wed, Mar 21, 2012 at 12:39 PM, Sergey Kandaurov wrote: > > On 21 March 2012 19:19, John Baldwin wrote: > >> On Tuesday, March 20, 2012 11:37:57 am Sergey Kandaurov wrote: > >>> On 22 November 2011 19:29, Mark Saad wrote: > >>> > Hello All > >>> > >>> [found this mail in my drafts, not sure if my answer is still useful] > >>> > >>> > I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and > >>> > 7.3-RELEASE I have seen the following warning in dmesg. > >>> > > >>> > Approaching the limit on PV entries, consider increasing either the > >>> > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. > >>> > > >>> > So looking around I see a few posts here and there about how to tune > >>> > the sysctls to address the warning however I am not 100% sure what > >>> > each value does. > >>> > It appears changing vm.pmap.shpgperproc affects the value of > >>> > vm.pmap.pv_entry_max . Can someone explain the relationship of the two > >>> > sysctls. Also > >>> > >>> This is how they are calculated. > >>> > >>> pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; > >>> > >>> and, respectively, > >>> > >>> shpgperproc = (pv_entry_max - cnt.v_page_count) / maxproc; > >>> > >>> So, changing one sysctl will change another and vice versa. > >>> > >>> > what pitfalls of changing them are. > >>> > >>> Not known to me (on amd64 platform). > >>> I have had vm.pmap.shpgperproc=15000 on 8.1 amd64 with 4G RAM > >>> to make some badly written commercial software to work until it > >>> was decommissioned to the scrap. > >> > >> FYI, Alan just removed this warning and the associated sysctls from HEAD > >> yesterday because they were made obsolete several years ago. I think they > >> are > >> obsolete even on 7. Certainly on 8. > > > > Yep, and since switching to direct map (somewhere around 7.x on amd64?) > > made PV entry limit factually obsolete, this is really cool. > > > > -- > > wbr, > > pluknet > > Interesting so this warning is relevant in 7.x ? No, looks like it was obsolete starting with 7.0. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
On Wednesday, March 21, 2012 7:27:58 pm Eric Saint-Etienne wrote: > Hi, > > >From within the freeBSD kernel, not all malloc are made equal: > * malloc() smaller than KMEM_ZMAX (set to one page size) end up in > UMA SLABs, themselves laid out in powers of 2 (from 16 bytes, 32... to > 4096 bytes) > * bigger malloc() are done through uma_large_malloc() which uses the > kmem wired space > > In my driver, I need to map some malloc-ed memory, obtained from > another module, into userspace. > > The problem: on the smaller mallocs, as well as on some bigeer ones > (8k seems fine, 64k fails): vm_map_lookup() fails finding the > underlying vm object. > > Do somebody know how (or better, have a piece of code!) to retrieve > the vm_object associated with malloc-ed memory? (small and big ones) > > As far as I can see in the vm code, there isn't any object associated > with the slabs (the smaller mallocs), it seems that a huge chunk of > virtual space is used "as is", so I presume the virtual addresses > where the SLABs are have some remarkable property, with respect to > physical addresses, that could allow creating an object from scratch? > > The usual answer is: use mmap(). It seems mmap() is the solution to > everything. But what I dislike with mmap() is the following cost *for > each page*: > 1/ a page fault > 2/ a call to a pager function that will do the "on demand" mapping. You can prefault each page in userland after you call mmap() if you want to pay the cost up front vs. later during runtime. However, there is another option you can use (though it might require you to rework your interfaces a bit, esp. depending on how you get the malloc'd memory in the first place). Specifically, I recently added an extension to the 'shm_open()' API in the kernel that lets you map a shared memory object into the kernel (shm_map() and shm_unmap(), the change should be easy to MFC to 8 and 9 (I use it in 8 and will MFC it soonish to those stable branches)). The way the workflow works in this case is that userland creates a shared memory object (usually an anonymous one, so using SHM_ANON), and then passes the fd in as part of an ioctl request to something in the kernel. The kernel code uses fget() to convert the fd to a reference to a 'struct file *'. You can then pass that file to shm_map(). Once the kernel code is done with the mapping it should call shm_unmap() to release it as well as using fdrop() to release the reference to the 'fp' obtained from fget(). shm_map() will wire down pages for the mapped region of the shm (and alloc them if needed). As a bonus then, if you mmap() the shm in userland after the ioctl, you can pass MAP_PREFAULT_READ to mmap() and it should remove all the page faults in userland. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: still issues with unreadable dmesg output on SMP systems
On Thursday, March 22, 2012 6:10:41 am Alexander Best wrote: > hi there, > > a few years ago there were huge issues with SMP and dmesg output, where > messages from various drivers were output to /dev/ttyv0 without any timing, > which caused a lot of unreadable lines. > > this was fixed and almost all of the dmesg lines i see now look similar to > dmesg on a non-SMP aware kernel. however there still seems to be an issue > within the cd(4) driver. maybe somebody could fix the driver output to match > the drivers, where the dmesg output looks correct (da(4), ada(4), ...). s/fixed/mostly worked around/ The problem is that the work around isn't perfect. The root cause is still not fixed. avg@ has some ideas on better ways to handle this, but it is a bit tricky to get this right since we also dont' want printfs to be delayed too much (and to fix this perfectly requires buffering printf output). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On 03/21/12 23:34, Andrzej Tobola wrote: On Wed, Mar 21, 2012 at 11:16:59PM +1000, Da Rock wrote: On 03/21/12 23:06, Matthias Apitz wrote: Hello, I've forwarded your question to a colleague who is an Ubuntu fan and he replied, that the creation of a booting Ubuntu USB key is possile with Ubuntu tools/methods only, i.e. booting the Ubuntu live CD and following the ways to install it onto the key (and not on disk). He wrote some years ago a small Wiki page about, it is in German but maybe you can clue something from the commands there: http://mikiwiki.org/wiki/Ubuntu_8.10_Intrepid_Ibex/Installation_2009.04.07_usbstick I'll have to translate that, but I am trying to get a 'live' usb disk to demo on the clients cdrom less unit. I know the cd is live, I assumed I could get a live usb disk from that based on their instructions. For a supposedly user friendly system, obtaining install media is not.. :/ Maybe a little too much debian in the system ;) You can use VirtualBox - boot live iso, connect usb and use native tool there. The saga continues... That doesn't work either- the live disk doesn't have the tools required! They obviously have no concept of simplicity... this really is insane :/ Back to the drawing board... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: still issues with unreadable dmesg output on SMP systems
Hi, On 22 March 2012 05:13, John Baldwin wrote: > s/fixed/mostly worked around/ > > The problem is that the work around isn't perfect. The root cause is still > not fixed. avg@ has some ideas on better ways to handle this, but it is a bit > tricky to get this right since we also dont' want printfs to be delayed too > much (and to fix this perfectly requires buffering printf output). I'm rapidly liking the brokenness of the IO. Why? Because it becomes _very freaking obvious_ when things are running concurrently. I've found many ath/net80211 bugs because of this. Having it as an option would be nice. :-) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
> By using kernel_map instead of kmem_map, vm_map_lookup() now always > return a vm_object. That's a big progress. > As expected, when this object is kmem_object, the user mapping works > fine (for smaller or larger mallocs.) > > Otherwise that object doesn't match kernel_object. It's an anonymous > object to me. > Using that "anonymous" vm_object for mapping into user map (using > vm_map_find()) doesn't directly fail, > it does provide a virtual address in the user map. However I read > zeros at that address, from within the user process. Actually when using kernel_map, the object returned is NULL! However the the vm_entry_t it returns seems a valid address, its 'object' field is NULL too (that's consistent) That's the reason why I didn't find it in any existing 'puclic' map (such as kernel_map, buffers_map, kmem_map, exec_map or pipe_map) But a NULL object isn't good at anything and I'm not sure what to do with a vm_entry_t only... Any idea how to insert it in the process map? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On Thu, Mar 22, 2012 at 3:15 AM, Luigi Rizzo wrote: > On Wed, Mar 21, 2012 at 10:52:53AM -0500, Mark Felder wrote: >> As an alternative I recently purchased a Zalman ZM-VE200 device (there's >> also a USB3.0 flavor) that lets you copy ISOs to it and it will emulate a >> CDROM/DVDROM/BDROM for you so you never have to deal with this mess again. >> It works amazingly well. I was tired of fighting this problem and this is >> an amazing solution -- I can keep every ISO I ever need on a single drive. >> >> http://www.zalman.com/eng/product/Product_Read.asp?idx=431 >> http://www.zalman.com/eng/product/Product_Read.asp?idx=459 >> http://www.rmprepusb.com/tutorials/ve200 > > really nice, thanks for the link. Now if they had something > that supported a USB key it would be even nicer... I *love* mine - it almost always Just Works. Since all you do is buy the enclosure (around $30), you can put in whatever size 2.5" drive you'd like. I threw in a 750G, so I have ~98G of CD and DVD images. There is a physical rocker switch for navigating the list of ISOs and mounting/unmounting them. You can also toggle ISO-only, drive-only, or hybrid/both mode, so I've got lots of other stuff on there that's handy once you've booted. It also has a physical read-only switch - great feature. The only hangup I've seen so far is if the BIOS doesn't support USB-attached optical drives. There are probably some workarounds for that out there (boot from a USB and then chainload-ish the optical drive), but I have not yet pursued them. There is undocumented support for floppy images as well. I haven't tested it, but there are success stories. *Highly* recommended. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
Hi, Vitaly Magerya : > > you might want to try to dd the iso image directly onto USB instead; there > > where talks that Ubuntu would support this starting at 11.10. Da Rock : > Nada. Tried that and it didn't work. I'm not sure how that would work given > that it uses isolinux to boot- ergo needs a cd to load the kernel. Maybe > some way to determine the install media? The trick is called "isohybrid". It works by a DOS MBR which starts the same executable boot image that is pointed to by the El Torito boot catalog. If the ISO is on a hard disk (or alike), then the BIOS boots via MBR. If it is on an optical medium, then the BIOS boots via El Torito. The question is rather why it does not work for you. I downloaded ubuntu-11.10-desktop-i386.iso from http://www.ubuntu.com/download/ubuntu/download and put it onto an USB stick (by a Linux machine, but that should not matter) dd of=/dev/sdc if=ubuntu-11.10-desktop-i386.iso bs=2048 Note that /dev/sdc is not the first partition but the whole USB stick. This stick boots on amd64 hardware. After some waiting with sparse iconography i get to the question whether i want to try or to install. I choose to try and get a graphical desktop. From the icon list i start Firefox and google a bit via my internet router. All seems well. On FreeBSD, GEOM complains about the DOS partition alignment. Partition 1 starts at block 64. fdisk -p /dev/da0 # /dev/da0 g c243 h255 s63 p 1 0x17 64 1423896 a 1 Nevertheless these two commands work and open access to the image content: mount -t cd9660 /dev/da0 /mnt mount -t cd9660 /dev/da0s1 /mnt (The ISO has two superblocks and two directory trees.) Does your hardware boot from USB stick at all ? Is its firmware (U)EFI rather than BIOS ? Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
LSI mps(4) driver issues with PIKE 2008/IMR (LSI SAS2008)
Hello,
I am trying to get the latest mps(4) driver in FreeBSD 9-STABLE working
with am LSI SAS2008 variant from ASUS, they call it PIKE 2008/IMR. Link
http://www.asus.com/Server_Workstation/Accessories/PIKE_2008IMR/
From what I can see this card should be compatible with the mps(4)
driver MFC'd to 9-STABLE about 6 weeks ago.
# uname -a
FreeBSD xxx 9.0-STABLE FreeBSD 9.0-STABLE #3 r233304M: Thu Mar 22
12:53:17 GMT 2012 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64
Revision: 233304
Initially the card is not seen at all by the driver, however pciconf
shows us why that is.
mps0@pci0:2:0:0:class=0x010700 card=0x843b1043 chip=0x00731000
rev=0x03 hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 9240'
class = mass storage
subclass = SAS
It seems on other models of LSI SAS2008 the chip device ID is 0x0072,
however for some reason this card has 0x0073. So I patched the mps(4)
driver and recompiled.
diff -ruN mps.orig/mpi/mpi2_cnfg.h mps/mpi/mpi2_cnfg.h
--- mps.orig/mpi/mpi2_cnfg.h2012-03-22 14:50:53.0 +
+++ mps/mpi/mpi2_cnfg.h 2012-03-22 14:52:23.0 +
@@ -416,7 +416,8 @@
/* SAS */
#define MPI2_MFGPAGE_DEVID_SAS2004 (0x0070)
-#define MPI2_MFGPAGE_DEVID_SAS2008 (0x0072)
+#define MPI2_MFGPAGE_DEVID_SAS2008_1(0x0072)
+#define MPI2_MFGPAGE_DEVID_SAS2008_2(0x0073)
#define MPI2_MFGPAGE_DEVID_SAS2108_1(0x0074)
#define MPI2_MFGPAGE_DEVID_SAS2108_2(0x0076)
#define MPI2_MFGPAGE_DEVID_SAS2108_3(0x0077)
diff -ruN mps.orig/mps_pci.c mps/mps_pci.c
--- mps.orig/mps_pci.c 2012-03-22 14:48:41.0 +
+++ mps/mps_pci.c 2012-03-22 14:51:59.0 +
@@ -99,7 +99,9 @@
} mps_identifiers[] = {
{ MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2004,
0x, 0x, 0, "LSI SAS2004" },
- { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008,
+ { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_1,
+ 0x, 0x, 0, "LSI SAS2008" },
+ { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_2,
0x, 0x, 0, "LSI SAS2008" },
{ MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2108_1,
0x, 0x, 0, "LSI SAS2108" },
After reboot it now loads the mps(4) module and attempts to init the
card but fails.
# dmesg | grep mps
mps0: port 0xd800-0xd8ff mem
0xfbd7c000-0xfbd7,0xfbdc-0xfbdf irq 16 at device 0.0 on pci2
mps0: Doorbell failed to activate
device_attach: mps0 attach returned 6
From this point I'm stuck on what to try next, google does not provide
any answers for this situation. Does any one have any advice or ideas as
to why this is not working?
I am able to provide ssh access to the server if any one wants to log
on and have a look at it.
Really appreciate any help you can give.
Kind Regards
Jake
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On Thu, Mar 22, 2012 at 05:42:27PM +0100, Thomas Schmitt wrote: > Hi, > > Vitaly Magerya : > > > you might want to try to dd the iso image directly onto USB instead; there > > > where talks that Ubuntu would support this starting at 11.10. > > Da Rock : > > Nada. Tried that and it didn't work. I'm not sure how that would work given > > that it uses isolinux to boot- ergo needs a cd to load the kernel. Maybe > > some way to determine the install media? > > The trick is called "isohybrid". > It works by a DOS MBR which starts the same executable boot image > that is pointed to by the El Torito boot catalog. > If the ISO is on a hard disk (or alike), then the BIOS boots via MBR. > If it is on an optical medium, then the BIOS boots via El Torito. interesting. It does work for me indeed. And it might be a nice trick for our images too, so we don't have to build a memstick and an ISO image... cheers luigi > The question is rather why it does not work for you. > > I downloaded > ubuntu-11.10-desktop-i386.iso > from > http://www.ubuntu.com/download/ubuntu/download > and put it onto an USB stick (by a Linux machine, but that should not matter) > dd of=/dev/sdc if=ubuntu-11.10-desktop-i386.iso bs=2048 > Note that /dev/sdc is not the first partition but the whole USB stick. > > This stick boots on amd64 hardware. > After some waiting with sparse iconography i get to the question > whether i want to try or to install. I choose to try and get a > graphical desktop. From the icon list i start Firefox and google > a bit via my internet router. All seems well. > > > On FreeBSD, GEOM complains about the DOS partition alignment. > Partition 1 starts at block 64. > fdisk -p /dev/da0 > # /dev/da0 > g c243 h255 s63 > p 1 0x17 64 1423896 > a 1 > Nevertheless these two commands work and open access to the image content: > mount -t cd9660 /dev/da0 /mnt > mount -t cd9660 /dev/da0s1 /mnt > (The ISO has two superblocks and two directory trees.) > > > Does your hardware boot from USB stick at all ? > Is its firmware (U)EFI rather than BIOS ? > > > Have a nice day :) > > Thomas > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Approaching the limit on PV entries
On Thu, Mar 22, 2012 at 8:03 AM, John Baldwin wrote: > On Wednesday, March 21, 2012 4:20:17 pm Mark Saad wrote: >> On Wed, Mar 21, 2012 at 12:39 PM, Sergey Kandaurov wrote: >> > On 21 March 2012 19:19, John Baldwin wrote: >> >> On Tuesday, March 20, 2012 11:37:57 am Sergey Kandaurov wrote: >> >>> On 22 November 2011 19:29, Mark Saad wrote: >> >>> > Hello All >> >>> >> >>> [found this mail in my drafts, not sure if my answer is still useful] >> >>> >> >>> > I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and >> >>> > 7.3-RELEASE I have seen the following warning in dmesg. >> >>> > >> >>> > Approaching the limit on PV entries, consider increasing either the >> >>> > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. >> >>> > >> >>> > So looking around I see a few posts here and there about how to tune >> >>> > the sysctls to address the warning however I am not 100% sure what >> >>> > each value does. >> >>> > It appears changing vm.pmap.shpgperproc affects the value of >> >>> > vm.pmap.pv_entry_max . Can someone explain the relationship of the two >> >>> > sysctls. Also >> >>> >> >>> This is how they are calculated. >> >>> >> >>> pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; >> >>> >> >>> and, respectively, >> >>> >> >>> shpgperproc = (pv_entry_max - cnt.v_page_count) / maxproc; >> >>> >> >>> So, changing one sysctl will change another and vice versa. >> >>> >> >>> > what pitfalls of changing them are. >> >>> >> >>> Not known to me (on amd64 platform). >> >>> I have had vm.pmap.shpgperproc=15000 on 8.1 amd64 with 4G RAM >> >>> to make some badly written commercial software to work until it >> >>> was decommissioned to the scrap. >> >> >> >> FYI, Alan just removed this warning and the associated sysctls from HEAD >> >> yesterday because they were made obsolete several years ago. I think >> >> they are >> >> obsolete even on 7. Certainly on 8. >> > >> > Yep, and since switching to direct map (somewhere around 7.x on amd64?) >> > made PV entry limit factually obsolete, this is really cool. >> > >> > -- >> > wbr, >> > pluknet >> >> Interesting so this warning is relevant in 7.x ? > > No, looks like it was obsolete starting with 7.0. > > -- > John Baldwin Any chance it could be mfc'ed to 7-STABLE ? -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
Hi, > > The trick is called "isohybrid". Luigi Rizzo wrote: > interesting. It does work for me indeed. So why not for Da Rock ? > And it might be a nice trick for our images too, so we don't > have to build a memstick and an ISO image... I would be happy to help with that. I am the developer of program xorriso which in the role of mkisofs has composed that Ubuntu image. My knowlege is only about pointing BIOS to the boot loader start programs, not about those boot systems themselves. A while ago i exercised the most simple case of http://wiki.freebsd.org/AvgLiveCD with the mkisofs emulation of xorriso. It booted. An MBR can be inserted easily by mkisofs option -G. isohybrid demands to patch that MBR with the LBA of the boot image and to set up the DOS partition table. GRUB2 demands only to set up the partition table. (Special xorrisofs options get employed.) What would a FreeBSD bootloader MBR need to know about the data in the ISO image to start up and handle it like a read-only hard disk ? Do programs of the first boot stages need to know their own LBA in the image resp. partition ? The El Torito and MBR equipment of GRUB2 can provide the same functionality as ISOLINUX with isohybrid. GRUB2 script grub-mkrescue demonstrates this. I understand Debian GNU/kFreeBSD boots via El Torito and GRUB2. But it makes no use of the opportunity to have an MBR too. I boot my own FreeBSD 8-STABLE from hard disk via MBR, GRUB2 and a chainloaded FreeBSD boot loader. Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
On Thu, Mar 22, 2012 at 10:42 AM, Eric Saint-Etienne wrote: > Actually when using kernel_map, the object returned is NULL! However the > the vm_entry_t it returns seems a valid address, its 'object' field is NULL > too (that's consistent) > That's the reason why I didn't find it in any existing 'puclic' map (such as > kernel_map, buffers_map, kmem_map, exec_map or pipe_map) > > But a NULL object isn't good at anything and I'm not sure what to do with > a vm_entry_t only... Any idea how to insert it in the process map? If your kernel module creates a device in /dev that implements the mmap method, then you don't need to worry about mucking around with vm_maps and objects and whatnot. Your mmap method just needs to be able to convert offsets into the device into physical memory addresses, and the vm infrastructure will do the rest for you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
> If your kernel module creates a device in /dev that implements the > mmap method, then you don't need to worry about mucking around with > vm_maps and objects and whatnot. Your mmap method just needs to be > able to convert offsets into the device into physical memory > addresses, Yes I'm aware of this facility, thank you. > and the vm infrastructure will do the rest for you. Since this mapping is on the main path of the driver, I'm worried that the overhead on each access of a page fault and a function call (the pager associated with a cdev mmap) is too much to bear. So I'd like to do it the "hard" way which I feel is the most optimized. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: malloc pages map to user space
Here is some code which fails with malloc < 1 page
and sometimes succeeds with large mallocs (> 16 pages)
What's wrong?
#include
#include
#include
#include
#include
#include
#include
#include
#include
// Copyright: skeleton took from an older post on the freebsd list
#include
#include
#include
#include
#include
#include
#include
#include
MALLOC_DEFINE(M_FIVEG_SYSC, "fiveg_sysc", "fiveg_sysc test");
struct args {
unsigned char **p;
};
/* String to be located in maped buffer */
#define SIZE PAGE_SIZE // 1 page always fail
static void initialize_array(char *p) {
int i;
for (i = 0; i < 26; i++)
p[i] = i+'a';
p[26] = '!';
p[27] = '\0';
}
static vm_offset_t addr; // allocated/freed at module load/unload
/* Syscall func */
static int syscf(struct thread *td, void *sa) {
vm_offset_t user_addr; /* User space address */
struct args *uap = (struct args*) sa;
struct proc *procp = (struct proc *)td->td_proc;
struct vmspace *vms = procp->p_vmspace;
vm_map_t map;
int result;
vm_object_t object;
vm_ooffset_tobjoffset;
vm_map_entry_t entry;
vm_pindex_t pindex;
vm_prot_t prot;
boolean_t wired;
map = kernel_map; // it always return data within kmeme anyway
uprintf("KERNEL string is '%s' (%p)\n", (char*) addr, (void*) addr);
result = vm_map_lookup(&map, addr, VM_PROT_ALL, &entry, &object,
&pindex, &prot, &wired);
if (result != KERN_SUCCESS) {
uprintf("KERNEL vm_map_lookup failed (%d)\n", result);
return ENOMEM;
}
vm_map_lookup_done(map, entry);
if (object == kernel_object) uprintf("object is kernel_object\n");
else if (object == kmem_object) uprintf("object is kmem_object\n");
else uprintf("object=%p (not kmem, not kernel)\n", object);
uprintf("entry=%p\n", entry);
/* Offset in vm_object */
objoffset = addr - entry->start + entry->offset;
user_addr = 0;
result = vm_map_find(&vms->vm_map, object, objoffset, (vm_offset_t
*) &user_addr, SIZE, VMFS_ANY_SPACE, VM_PROT_RW, VM_PROT_RW, 0);
if (result != KERN_SUCCESS)
uprintf("vm_map_find failed: %d\n", result);
else {
*uap->p = (char*) user_addr;
uprintf("KERNEL ---> Syscall: user_addr for allocating space =
0x%lx\n", user_addr);
}
return result;
}
/* Sysent entity for syscall */
static struct sysent sc_sysent = {
1, /* Number of arguments */
syscf /* Syscall function*/
};
//static struct sysent *old_sysent;
/* Offset in sysent[] */
static int offset = NO_SYSCALL;
/* Loader */
static int
load (struct module *m, int cmd, void *something)
{
int error = 0;
switch(cmd){
case MOD_LOAD:
//MALLOC(addr, vm_offset_t, SIZE, M_FIVEG_SYSC, M_WAITOK | M_ZERO);
addr = (vm_offset_t) malloc(SIZE, M_FIVEG_SYSC, M_WAITOK);
initialize_array((char*) addr);
uprintf("KERNEL Module with sysc loaded. Offset = %d \n", offset);
break;
case MOD_UNLOAD:
free((void*) addr, M_FIVEG_SYSC);
uprintf("KERNEL Module with sysc unloaded. Offset = %d \n", offset);
break;
default:
error = EOPNOTSUPP;
break;
}
return (error);
/* Syscall macro*/
SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL);
/* eof */
-- USERLAND PROGRAM
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int sysc_num, error;
struct module_stat mstat;
/* This Variable will save the addres of remapped buffer */
unsigned char *some_var = NULL;
/* Pointer to pointer to remapped buffer */
unsigned char **p = &some_var;
/* Search module with system call */
mstat.version = sizeof(mstat);
if (!(modstat(modfind("sys/fiveg_sysc"), &mstat))){
/* Our module */
sysc_num = mstat.data.intval;
printf("USER: Module found, Syscall number = %d \n", sysc_num);
/* make system call */
error = syscall(sysc_num, p);
if (error != 0) {
printf("USER: an error occured: %d\n", error);
return -1;
}
/* Read the string from remapped buffer */
printf("USER: p = %p\n", p);
printf("USER: *p = %p\n", *p);
printf("USER: String = %s\n", *p);
} else
printf("USER: Module seems to be not loaded! \n");
return 0;
}
/* eof */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: a sysctl for process binary osreldate
On Sat, Mar 17, 2012 at 9:30 PM, Mikolaj Golub wrote: > Hi, > > Currently we can check and change binary osreldate of another process via > procfs(5). > > Kostik suggested to add a new sysctl for the same purpose and also extend > procstat to show osrel. > > Here are patches I am going to commit if there are no objections or > suggestions. > > http://people.freebsd.org/~trociny/kern_proc_osrel.1.patch > http://people.freebsd.org/~trociny/procstat.osrel.1.patch > > I set the same permissions as for procfs(5) osrel -- so only user can read it, > but may be this is too restrictive and p_cansee on read would be ok? Actually I don't see reasons why this may not be p_cansee, so I updated the patch and going to commit it if there is no objections. -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: a sysctl for process binary osreldate
On Thu, 22 Mar 2012 22:38:15 +0200 Mikolaj Golub wrote: MG> Actually I don't see reasons why this may not be p_cansee, so I MG> updated the patch and going to commit it if there is no objections. The updated patch: http://people.freebsd.org/~trociny/kern_proc_osrel.2.patch -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LSI mps(4) driver issues with PIKE 2008/IMR (LSI SAS2008)
On Thu, Mar 22, 2012 at 16:24:16 +0100, Jake Smith wrote:
> Hello,
>
> I am trying to get the latest mps(4) driver in FreeBSD 9-STABLE working
> with am LSI SAS2008 variant from ASUS, they call it PIKE 2008/IMR. Link
> http://www.asus.com/Server_Workstation/Accessories/PIKE_2008IMR/
>
> From what I can see this card should be compatible with the mps(4)
> driver MFC'd to 9-STABLE about 6 weeks ago.
>
> # uname -a
> FreeBSD xxx 9.0-STABLE FreeBSD 9.0-STABLE #3 r233304M: Thu Mar 22
> 12:53:17 GMT 2012 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64
>
> Revision: 233304
>
> Initially the card is not seen at all by the driver, however pciconf
> shows us why that is.
>
> mps0@pci0:2:0:0:class=0x010700 card=0x843b1043 chip=0x00731000
> rev=0x03 hdr=0x00
> vendor = 'LSI Logic / Symbios Logic'
> device = 'MegaRAID SAS 9240'
> class = mass storage
> subclass = SAS
>
> It seems on other models of LSI SAS2008 the chip device ID is 0x0072,
> however for some reason this card has 0x0073. So I patched the mps(4)
> driver and recompiled.
>
> diff -ruN mps.orig/mpi/mpi2_cnfg.h mps/mpi/mpi2_cnfg.h
> --- mps.orig/mpi/mpi2_cnfg.h 2012-03-22 14:50:53.0 +
> +++ mps/mpi/mpi2_cnfg.h 2012-03-22 14:52:23.0 +
> @@ -416,7 +416,8 @@
>
> /* SAS */
> #define MPI2_MFGPAGE_DEVID_SAS2004 (0x0070)
> -#define MPI2_MFGPAGE_DEVID_SAS2008 (0x0072)
> +#define MPI2_MFGPAGE_DEVID_SAS2008_1(0x0072)
> +#define MPI2_MFGPAGE_DEVID_SAS2008_2(0x0073)
> #define MPI2_MFGPAGE_DEVID_SAS2108_1(0x0074)
> #define MPI2_MFGPAGE_DEVID_SAS2108_2(0x0076)
> #define MPI2_MFGPAGE_DEVID_SAS2108_3(0x0077)
> diff -ruN mps.orig/mps_pci.c mps/mps_pci.c
> --- mps.orig/mps_pci.c2012-03-22 14:48:41.0 +
> +++ mps/mps_pci.c 2012-03-22 14:51:59.0 +
> @@ -99,7 +99,9 @@
> } mps_identifiers[] = {
> { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2004,
> 0x, 0x, 0, "LSI SAS2004" },
> - { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008,
> + { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_1,
> + 0x, 0x, 0, "LSI SAS2008" },
> + { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_2,
> 0x, 0x, 0, "LSI SAS2008" },
> { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2108_1,
> 0x, 0x, 0, "LSI SAS2108" },
>
> After reboot it now loads the mps(4) module and attempts to init the
> card but fails.
>
> # dmesg | grep mps
> mps0: port 0xd800-0xd8ff mem
> 0xfbd7c000-0xfbd7,0xfbdc-0xfbdf irq 16 at device 0.0 on pci2
> mps0: Doorbell failed to activate
> device_attach: mps0 attach returned 6
>
> From this point I'm stuck on what to try next, google does not provide
> any answers for this situation. Does any one have any advice or ideas as
> to why this is not working?
> I am able to provide ssh access to the server if any one wants to log
> on and have a look at it.
In looking at the specs, that card supports RAID-5 and RAID-50. That means
it isn't a SAS card supported by mps(4), but rather a MegaRAID card.
It should be supported by mfi(4). Try adding the PCI ID to that
driver and see if that works. Or you can grab the driver from the
head_mfi branch, it looks like it already supports that card. Here's the
mfi_pci.c file, you can see the PCI ID in there:
http://svnweb.freebsd.org/base/projects/head_mfi/sys/dev/mfi/mfi_pci.c?revision=232888&view=markup
Ken
--
Kenneth Merry
k...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iso2flash img
On 03/23/12 04:46, Thomas Schmitt wrote: Hi, The trick is called "isohybrid". Luigi Rizzo wrote: interesting. It does work for me indeed. So why not for Da Rock ? Starting to feel left out here :) I tried with your flags to dd (as opposed to those on Ubuntu - bs=1m - not that I thought it would make much diff), and it got as far as the last time. It shows isolinux 4.04, blah blah, and a blinking cursor. It goes no further than that, which I why I commented that it seemed an unlikely solution. The system is an Acer AspireOne Netbook D255. I'm using an i386 image because its only an Atom. I did test a amd64 system and it worked though... hmmm. I wonder if they mixed up their images? That'd be a funny cock-up :D And it might be a nice trick for our images too, so we don't have to build a memstick and an ISO image... I would be happy to help with that. I am the developer of program xorriso which in the role of mkisofs has composed that Ubuntu image. My knowlege is only about pointing BIOS to the boot loader start programs, not about those boot systems themselves. A while ago i exercised the most simple case of http://wiki.freebsd.org/AvgLiveCD with the mkisofs emulation of xorriso. It booted. An MBR can be inserted easily by mkisofs option -G. isohybrid demands to patch that MBR with the LBA of the boot image and to set up the DOS partition table. GRUB2 demands only to set up the partition table. (Special xorrisofs options get employed.) What would a FreeBSD bootloader MBR need to know about the data in the ISO image to start up and handle it like a read-only hard disk ? Do programs of the first boot stages need to know their own LBA in the image resp. partition ? The El Torito and MBR equipment of GRUB2 can provide the same functionality as ISOLINUX with isohybrid. GRUB2 script grub-mkrescue demonstrates this. I understand Debian GNU/kFreeBSD boots via El Torito and GRUB2. But it makes no use of the opportunity to have an MBR too. I boot my own FreeBSD 8-STABLE from hard disk via MBR, GRUB2 and a chainloaded FreeBSD boot loader. Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
