webdav locking issues
I did try without success to ask some aspect of this on the questions list, but I'm farther along with this anyway. I have an apache22 server setup with webdav for a subversion server. That is working well (I think, anyway), and I'm able access it from a Winblows XP vm I use for various testing and so forth. I'm still trying to resolve some issues with Windows7, but it appears to work in the apache logs. Apache/webdav is setup with ssl and digest auth - no access unless auth'd. Locking appears to be working as well according to logs and cadaver. libreoffice won't build with java, and doesn't appear to like direct webdav access- certificate issues. But that dog won't hunt anyway due to the minimal user friendliness (if that is actually a term). Even with locking disabled the issue remains. wdfs is what is intended to use for general access (I'm open to suggestion though), and I have tried non-threaded operation, locking modes, no locking, and foreground operation. Without locking, the office's complain about io errors. Using the foreground operation of wdfs and the logs, I can see wdfs lock the file and retrieve it and attempt to lock it again. This errors badly obviously, and wdfs tells office's to come back with read only options. Quite frankly I need a little help on where to go from here. I'm trying to figure out what I'm missing exactly. ATM my best guess would be an issue with wdfs, but there isn't much on the google about it. Any thoughts? ___ 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 17:06, Thomas Schmitt wrote: Hi, Da Rockfreebsd-hack...@herveybayaustralia.com.au wrote: 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. If it can say isolinux then the boot process has succeeded as far as the boot sectors of the ISO image are responsible. The system is an Acer AspireOne Netbook D255. I'm using an i386 image because its only an Atom. Can you try whether the Ubuntu image boots from CD or DVD ? Thats the whole point of this exercise - I can't, no cdrom: its a netbook. 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 At that stage you are still in the SYSLINUX/ISOLINUX system. Afaik, there is no 64 bit version of it. So that one can hardly be totally unsuitable for 32 bit systems. I am not familiar with the entrails of the boot loaders. Maybe you can get help at the SYSLINUX mailing list sysli...@zytor.com. http://www.zytor.com/mailman/listinfo/syslinux Google ubuntu atom isolinux finds an older issue: https://bugs.launchpad.net/ubuntu/+bug/774552 points to https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/617779 Just type help on the BOOT prompt, and when you get the help menu, just hit enter. The system will now boot! Does ISOLINUX allow you to enter commands ? Nope. Can't even type 'hello world!'. One thing comes to my mind which you could try. It is quite unlikely to be the culprit though: By a bug in xorriso-1.0.8 the image size is not aligned to a full megabyte, as is prescribed for isohybrid. So you could try to set the end of the USB stick DOS partition 1 to the next higher multiple of 2048 disk blocks minus 1. (Make sure that no block content gets changed after byte 64 * 512.) If this happens to work, then we should inform Ubuntu to upgrade their xorriso to 1.1.0 or later. (Up to now i only know that the correct size silences warnings of Linux fdisk about different physical/logical beginnings.) Dunno. Tried all kinds of tricks, but no go. The client chose FreeBSD anyway, so yay! :) Ubuntu issue not my problem; I'm sure they'll work it out if it comes up again. My disk worked in VBox, so I'm sure it is just a netbook thing. I also use that disk as my install disk, so I'm not sure exactly what partitions been on it now, it has been used for FreeBSD, PC-BSD, Linux distros, etc. Have a nice day :) Thomas Thanks 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: iso2flash img
On 03/23/12 22:08, Thomas Schmitt wrote: Hi, Thats the whole point of this exercise - I can't, no cdrom: its a netbook. I hoped that you had a USB attachable optical drive in reach for development. Haven't you heard? CD's are so yesterday... ;) The reality is I don't have a working CDROM unless its builtin. Haven't needed one for years now, so no point. The servers and desktops have one as well, but most are not working very well anymore due to non use - too much bump and not enough grind. The laptops give me what I need atm. My disk worked in VBox, so I'm sure it is just a netbook thing. I also use that disk as my install disk, so I'm not sure exactly what partitions been on it now, it has been used for FreeBSD, PC-BSD, Linux distros, etc. After copying the ISO image to the base device (/dev/da0 rather than /dev/da0s1), it now carries the isohybrid MBR which marks a single DOS partition and leaves the rest of the disk unclaimed. A partition editor should be able to push the end of the partition to the next 1 MiB boundary, without altering the partition content. But as said, it is unlikely that this misalignement of the partition end is the cause. The observable state of ISOLINUX rather points to a problem between hardware, firmware, and the SYSLINUX programs. My thoughts exactly. Could be Acer, netbook firmware, or the Atom I'd say (or a combination of these). ___ 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 22:38, Thomas Schmitt wrote: Hi, Haven't you heard? CD's are so yesterday... ;) Just wait until the holodiscs come out. :)) http://en.wikipedia.org/wiki/Holographic_Versatile_Disc Now thats what I'm talkin' 'bout! Although I could still probably fill one in a matter of hours... ;) ___ 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: iso2flash img
On 03/23/12 04:46, Thomas Schmitt wrote: Hi, The trick is called isohybrid. Luigi Rizzori...@iet.unipi.it 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
iso2flash img
I'm doing some work for a client and I need to get a copy of ubuntu to demo for them. I can only use a usb disk (no cdrom), and unfortunately the guys at ubuntu are too lazy to create a flash img themselves and expect you to do it yourself. Of course the tools to do this are only available on Winblows and Mac (hdiutils? I think). They have instructions on the site - which of course are useless to me being a FreeBSD freak ;) I googled a bit and found an old post here from Luigi (http://osdir.com/ml/freebsd-hackers/2008-11/msg00245.html) which had a script to do this, but I'm having trouble with it- is anyone familiar with this? I'm on a bit of a deadline... and yes, I did install syslinux port. Output: ../iso2flash ubuntu-11.10-desktop-i386.iso usage: realpath [-q] path [...] type tree /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso image Extract files from /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso into /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso.tree chmod: /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso.tree: No such file or directory total 6 drwxr-xr-x 2 user user 512 Mar 21 18:22 . drwxr-xr-x 6 user user 2560 Mar 21 18:22 .. total 2500 drwxr-xr-x 11 user user 512 Mar 21 18:23 . drwxr-xr-x 6 user user 2560 Mar 21 18:22 .. drwx-- 2 user user 512 Oct 13 01:15 .disk -r 1 user user 225 Oct 13 01:15 README.diskdefines -r 1 user user 143 Oct 13 01:15 autorun.inf drwx-- 3 user user 512 Oct 13 01:15 boot drwx-- 2 user user 512 Oct 13 01:15 casper drwx-- 3 user user 512 Oct 13 01:15 dists drwx-- 2 user user 512 Oct 13 01:15 install drwx-- 2 user user 2560 Oct 13 01:15 isolinux -r 1 user user 4418 Oct 13 01:15 md5sum.txt drwx-- 2 user user 512 Oct 13 01:15 pics drwx-- 4 user user 512 Oct 13 01:15 pool drwx-- 2 user user 512 Oct 13 01:15 preseed -r 1 user user 2491552 Oct 13 01:15 wubi.exe image size is 711676 kb guess type 8+0 records in 8+0 records out 1048576 bytes transferred in 0.005349 secs (196035057 bytes/sec) newfs_msdos: /dev/711676: No such file or directory syslinux: invalid media signature (not a FAT filesystem?) moving boot code mv: rename /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso.tree/isolinux.cfg to /usr/home/user/Downloads/ubuntu-11.10-desktop-i386.iso.tree/syslinux.cfg: No such file or directory moving files... init :: non DOS media Cannot initialize '::' Bad target ::/ init :: non DOS media Cannot initialize '::' I'm going to keep on investigating, I tried this on 8.2 and 9.0 with no luck. I intend to attempt a usb install of FreeBSD at some point (on the todo list for some time now), but at this point its still a bit of a mystery; so I think I may have some trouble understanding this atm. A little instruction would go a long way if someone could provide some pointers. Cheers ___ 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 22:55, Vitaly Magerya wrote: Da Rock wrote: I googled a bit and found an old post here from Luigi (http://osdir.com/ml/freebsd-hackers/2008-11/msg00245.html) which had a script to do this, but I'm having trouble with it- is anyone familiar with this? I'm on a bit of a deadline... Can't help you with that script (I failed to make it work too), but 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. Interesting. I'll have to look further into how that would work. Also, why wouldn't they just tell Mac users to do that? 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 ___ 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: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 ;) ___ 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:11, Da Rock wrote: On 03/21/12 22:55, Vitaly Magerya wrote: Da Rock wrote: I googled a bit and found an old post here from Luigi (http://osdir.com/ml/freebsd-hackers/2008-11/msg00245.html) which had a script to do this, but I'm having trouble with it- is anyone familiar with this? I'm on a bit of a deadline... Can't help you with that script (I failed to make it work too), but 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. Interesting. I'll have to look further into how that would work. Also, why wouldn't they just tell Mac users to do that? 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 Nada. Booted it, and all I got was a blinking cursor, and I couldn't even type hello world! :( Back to square one... I guess I'll try a direct copy. ___ 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 22:55, Vitaly Magerya wrote: Da Rock wrote: I googled a bit and found an old post here from Luigi (http://osdir.com/ml/freebsd-hackers/2008-11/msg00245.html) which had a script to do this, but I'm having trouble with it- is anyone familiar with this? I'm on a bit of a deadline... Can't help you with that script (I failed to make it work too), but 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. 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? Bit of an unnecessary complication though if you ask me... just make an iso _and_ an img. I'm sure canonical are not that strapped for resources... ___ 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: Kernel memory usage
On 03/13/12 05:40, Super Bisquit wrote: CPU architecture and model have a lot to do with performance. You will also get different results if you used qemu in place of VirtualBox. Qemu allows you to choose different emulated architectures, CPUs, and machine bases. What's the downside? You have to use the command line. Install qemu and run a series of virtual machines. Embedded devices also include Power(PC), ARMv?, Coldfire, et al; you're only dealing with i386 and/or the 64 bit extension (AMD64). CISC- which does not contain any hardware modification to be a RISC replacement- runs fewer instructions than RISC due to the limited number of registers. Take this into consideration every time a program runs. Everything else also matters on real and emulated systems: Is it ide, scsi, sdd, flashdevice for the hard drive? What type of RAM? Dedicated or shared disk? I'm a little confused by the response, I was interested if someone knew what determines the size of kernel in memory (or wired); I only considered the embedded list because they have a greater interest in the memory size working with so little. It is academic as I'm trying to understand the kernel internals, as well as understand what works with low memory so I can tune accordingly. I understand the different CPU instruction sets (roughly), although I would be interested as to the size of the kernel in each. What my question was about was the wired memory size and what makes it grow (to put it super simply :) ). I know some growth would be expected, but this seems obese; how would I find out how much memory a process structure takes? Or else what am I missing? That said I'll have a crack at what you suggest as that follows a whole new interesting tangent :) I have used qemu before, but found VBox a bit more responsive (and, I will admit, easier...) On 3/11/12, Da Rock9phack...@herveybayaustralia.com.au wrote: I may be required to move this to embedded, but I am only looking for generalisation. Recently a thread came up on questions regarding memory usage, and a post was made regarding wired memory being nearly all kernel- something I was ready to dispute, but then I thought I'd better make sure. So I tested a few theories first off: 1. Comparing memory usage across machines I checked servers and desktops as well as vm's for memory usage, and I found some interesting results. On a firewall with no apps installed only 35M wired is used, on a desktop up to 700M~ can be used. Even as a dedicated server with a few services used it remains around 35M. Surely this means that the wired memory used is not just kernel? But I held off my assumptions as it was still plausible that the structures used by the kernel could balloon that far, too. 2. Stripped down, lean mean, kernel machine I then (using a vm I was building a kernel for anyway) stripped down a kernel in a VBox VM using le drivers for network to see what could be achieved. This is my kernel conf: include GENERIC ident VPN options IPSEC options IPSEC_DEBUG options IPSEC_NAT_T device crypto device enc # minimise kernel nooptions UFS_GJOURNAL nooptions MD_ROOT nooptions NFSCL nooptions NFSD nooptions NFSLOCKD nooptions NFS_ROOT nooptions MSDOSFS nooptions CD9660 nooptions PROCFS nooptions PSEUDOFS nodevice fdc nodevice mvs nodevice siis nodevice ahc nodevice ahd nodevice esp nodevice hptiop nodevice isp nodevice mpt nodevice mps nodevice sym nodevice trm nodevice adv nodevice adw nodevice aic nodevice bt nodevice ses nodevice amr nodevice arcmsr nodevice ciss nodevice dpt nodevice hptmv nodevice hptrr nodevice irr nodevice ips nodevice mly nodevice twa nodevice aac nodevice aacp nodevice ida nodevice mfi nodevice mlx nodevice twe nodevice tws nodevice splash nodevice cbb nodevice pccard nodevice cardbus nodevice uart nodevice ppc nodevice ppbus nodevice lpt nodevice plip nodevice ppi nodevice puc nodevice bxe nodevice de nodevice em nodevice igb nodevice ixgbe nodevice ti nodevice txp nodevice vx nodevice miibus nodevice ae nodevice age nodevice alc nodevice ale nodevice bce nodevice bfe nodevice bge nodevice dc nodevice et nodevice fxp nodevice jme nodevice lge nodevice msk nodevice nfe nodevice nge nodevice pcn nodevice re nodevice rl nodevice sf nodevice sge nodevice sis nodevice sk nodevice ste nodevice stge nodevice tl nodevice tx nodevice vge nodevice vr nodevice wb nodevice xl nodevice cs nodevice ed nodevice ex nodevice ep nodevice fe nodevice sn nodevice xe nodevice wlan nooptions IEEE80211_DEBUG nooptions IEEE80211_AMPDU_AGE nooptions IEEE80211_SUPPORT_MESH nodevice wlan_wep nodevice wlan_ccmp nodevice wlan_tkip nodevice wlan_amrr nodevice an nodevice ath nodevice ath_pci nodevice ath_hal nooptions AH_SUPPORT_AR5416 nodevice ath_rate_sample nodevice ipw nodevice iwi nodevice iwn nodevice malo nodevice mwl nodevice ral nodevice wi nodevice wpi nodevice md nooption USB_DEBUG nodevice uhci nodevice ohci nodevice ehci nodevice xhci nodevice usb nodevice uhid nodevice
Kernel memory usage
I may be required to move this to embedded, but I am only looking for generalisation. Recently a thread came up on questions regarding memory usage, and a post was made regarding wired memory being nearly all kernel- something I was ready to dispute, but then I thought I'd better make sure. So I tested a few theories first off: 1. Comparing memory usage across machines I checked servers and desktops as well as vm's for memory usage, and I found some interesting results. On a firewall with no apps installed only 35M wired is used, on a desktop up to 700M~ can be used. Even as a dedicated server with a few services used it remains around 35M. Surely this means that the wired memory used is not just kernel? But I held off my assumptions as it was still plausible that the structures used by the kernel could balloon that far, too. 2. Stripped down, lean mean, kernel machine I then (using a vm I was building a kernel for anyway) stripped down a kernel in a VBox VM using le drivers for network to see what could be achieved. This is my kernel conf: include GENERIC ident VPN options IPSEC options IPSEC_DEBUG options IPSEC_NAT_T device crypto device enc # minimise kernel nooptions UFS_GJOURNAL nooptions MD_ROOT nooptions NFSCL nooptions NFSD nooptions NFSLOCKD nooptions NFS_ROOT nooptions MSDOSFS nooptions CD9660 nooptions PROCFS nooptions PSEUDOFS nodevice fdc nodevice mvs nodevice siis nodevice ahc nodevice ahd nodevice esp nodevice hptiop nodevice isp nodevice mpt nodevice mps nodevice sym nodevice trm nodevice adv nodevice adw nodevice aic nodevice bt nodevice ses nodevice amr nodevice arcmsr nodevice ciss nodevice dpt nodevice hptmv nodevice hptrr nodevice irr nodevice ips nodevice mly nodevice twa nodevice aac nodevice aacp nodevice ida nodevice mfi nodevice mlx nodevice twe nodevice tws nodevice splash nodevice cbb nodevice pccard nodevice cardbus nodevice uart nodevice ppc nodevice ppbus nodevice lpt nodevice plip nodevice ppi nodevice puc nodevice bxe nodevice de nodevice em nodevice igb nodevice ixgbe nodevice ti nodevice txp nodevice vx nodevice miibus nodevice ae nodevice age nodevice alc nodevice ale nodevice bce nodevice bfe nodevice bge nodevice dc nodevice et nodevice fxp nodevice jme nodevice lge nodevice msk nodevice nfe nodevice nge nodevice pcn nodevice re nodevice rl nodevice sf nodevice sge nodevice sis nodevice sk nodevice ste nodevice stge nodevice tl nodevice tx nodevice vge nodevice vr nodevice wb nodevice xl nodevice cs nodevice ed nodevice ex nodevice ep nodevice fe nodevice sn nodevice xe nodevice wlan nooptions IEEE80211_DEBUG nooptions IEEE80211_AMPDU_AGE nooptions IEEE80211_SUPPORT_MESH nodevice wlan_wep nodevice wlan_ccmp nodevice wlan_tkip nodevice wlan_amrr nodevice an nodevice ath nodevice ath_pci nodevice ath_hal nooptions AH_SUPPORT_AR5416 nodevice ath_rate_sample nodevice ipw nodevice iwi nodevice iwn nodevice malo nodevice mwl nodevice ral nodevice wi nodevice wpi nodevice md nooption USB_DEBUG nodevice uhci nodevice ohci nodevice ehci nodevice xhci nodevice usb nodevice uhid nodevice ukbd nodevice ulpt nodevice umass nodevice ums nodevice urio nodevice u3g nodevice uark nodevice ubsa nodevice uftdi nodevice uipaq nodevice uplcom nodevice uslcom nodevice uvisor nodevice uvscom nodevice aue nodevice axe nodevice cdce nodevice cue nodevice kue nodevice rue nodevice udav nodevice rum nodevice run nodevice uath nodevice upgt nodevice ural nodevice urtw nodevice zyd #nodevice firewire nodevice fwe nodevice fwip #nodevice dcons #nodevice dcons_rom nodevice sound nodevice snd_es137x nodevice snd_hda nodevice snd_ich nodevice snd_uaudio nodevice snd_via8233 World was also rebuilt as recommended by the handbook. As you can see I was rebuilding for IPSEC (for testing purposes only note). I couldn't remove dcons (not sure why- missing defined references), and that pulled in firewire too. The result was surprising: a 14M kernel became 6.3M, and when running I found it only used 19M used for wired (whoopee!) as opposed to 35M. No services were running per se, only the usual suspects in base: vpn-test# ps ax PID TT STAT TIME COMMAND 0 ?? DLs0:00.11 [kernel] 1 ?? ILs0:00.01 /sbin/init -- 2 ?? DL 0:00.00 [crypto] 3 ?? DL 0:00.00 [crypto returns] 4 ?? DL 0:00.00 [sctp_iterator] 5 ?? DL 0:00.00 [xpt_thrd] 6 ?? DL 0:00.10 [pagedaemon] 7 ?? DL 0:00.00 [vmdaemon] 8 ?? DL 0:00.01 [pagezero] 9 ?? DL 0:00.30 [bufdaemon] 10 ?? DL 0:00.00 [audit] 11 ?? RL 589:34.00 [idle] 12 ?? WL 0:38.64 [intr] 13 ?? DL 0:12.21 [geom] 14 ?? DL 0:03.30 [yarrow] 15 ?? DL 0:04.40 [syncer] 16 ?? DL 0:00.63 [vnlru] 17 ?? DL 0:00.53 [softdepflush] 104 ?? Is 0:00.00 adjkerntz -i 582 ?? Is 0:00.00 /sbin/devd 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c
Re: Graphical Terminal Environment
On 03/07/12 08:04, Dieter BSD wrote: Brandon writes: (If you haven't noticed, I'm going to keep finding excuses to write this as I really am kindof excited to learn/work on it) ideas: Display PostScript rio (from Plan 9) If you're mainly looking for a low-level graphics project, maybe reverse engineer something on the GPU (e.g. UVD) Looks like I may have been a little late to the party, but I'd suggest looking at Plan9 for ideas - this is exactly what it does. It is an OS with windows capabilities builtin (unlike Windows ironically enough, despite its dependencies), Rio itself is a WM like DWM or similar. I'd be surprised if it didn't have a similar api structure as you have outlined previously. For reference to access it like you would ssh on unix you use Drawterm instead, if that gives you any indication of its workings. Essentially no matter which way you look at it you'll be reinventing the wheel; but it does sound like fun! :) ___ 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: OS support for fault tolerance
On 02/15/12 03:25, Brandon Falk wrote: On 2/14/2012 12:05 PM, Jason Hellenthal wrote: On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: On 2/14/12 6:23 AM, Maninya M wrote: For multicore desktop computers, suppose one of the cores fails, the FreeBSD OS crashes. My question is about how I can make the OS tolerate this hardware fault. The strategy is to checkpoint the state of each core at specific intervals of time in main memory. Once a core fails, its previous state is retrieved from the main memory, and the processes that were running on it are rescheduled on the remaining cores. I read that the OS tolerates faults in large servers. I need to make it do this for a Desktop OS. I assume I would have to change the scheduler program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. How do I go about doing this? What exactly do I need to save for the state of the core? What else do I need to know? I have absolutely no experience with kernel programming or with FreeBSD. Any pointers to good sources about modifying the source-code of FreeBSD would be greatly appreciated. This question has always intrigued me, because I'm always amazed that people actually try. From my viewpoint, There's really not much you can do if the core that is currently holding the scheduler lock fails. And what do you mean by 'fails? do you run constant diagnostics? how do you tell when it is failed? It'd be hard to detect that 'multiply' has suddenly started giving bad results now and then. if it just stops then you might be able to have a watchdog that notices, but what do you do when it was half way through rearranging a list of items? First, you have to find out that it held the lock for the module and then you have to find out what it had done and clean up the mess. This requires rewriting many many parts of the kernel to remove 'transient inconsistent states. and even then, what do you do if it was half way through manipulating some hardware.. and when you've figured that all out, how do you cope with the mess it made because it was dying? Say for example it had started calculating bad memory offsets before writing out some stuff and written data out over random memory? but I'm interested in any answers people may have How about core redundancy ? effectively this would reduce the amount of available cores in half in you spread a process to run on two cores at the same time but with an option to adjust this per process etc... I don't see it as unfeasable. The overhead for all of the error checking and redundancy makes this idea pretty impractical. You'd have to have 2 cores to do the exact same thing, then some 'master' core that makes sure they're doing the right stuff, and if you really want to think about it... what if the core monitoring the cores fails... there's a threshold of when redundancy gets pointless. Make no mistake here, I'm not really up with the guts of what this would require (the dog may not hunt at all). Consider me as the little boy throwing rocks at a hornets nest :) That out of the way, how about this scenario: why can't the master be dynamic amongst the cores? 1 core be the master of any 2 cores (not itself). Another thought (probably more scifi then anything else) is about using the cores as individuals which work as a team and fire a weak team member that is failing. I have absolutely no idea how to accomplish this, but I thought it might fire a few neurons in someone who does... :) Perhaps I'm missing out on something, but you can't check the checker (without infinite redundancy). Honestly, if you're worried about a core failing, please take your server cluster out of the 1000 deg C forge. -Brandon ___ 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: Moving on ...
On 02/09/12 16:33, John Kozubik wrote: Hello, On Thu, 26 Jan 2012, Da Rock wrote: I normally hate to dredge up old threads, but this is like getting halfway through a story and not finding out the ending... :) What is the answer? Is there a solution to this? When I wrote the original post, I was expecting at most a benign response, and at worst some real blowback ... but I was really pleasantly surprised to find that my complaints were very well received, and that a lot of folks were experiencing the same issues that I was. It appears to be a classic case of if one customer complains, 99 others are thinking the same thing. I was interested from the perspective of what would make FreeBSD a bigger player on the enterprise level of the market. I know ISP's and large organisations are not as concerned with off the shelf as much as scalability, automation and customisation, and so don't mind running a minor dev team/person to achieve what they want; but smaller organisations would rather have it just work without much input or technical ability. I don't know what it is like where you are, but here even larger organisations are biased in this way- even up to a government level (outsource!). I have a string of questions on this: 1. Incidentally, what exactly does constitute a major release? I was defining major releases to be 4.x, 5.x, 6.x ... and so on. Currently 9.x is the latest major release. To clarify my question (I thought it was a little corny to put it this way, a little too shakespearean :) ), what is in a major release? I suppose it is related to my later question regarding the objectives of a release. 2. Is there a reason to update the numbers so quickly? I didn't think so, which was one of the main points of my post. A lot of other folks have agreed. BUT there were some counter arguments - specifically that fully new features would be delayed for a much longer time AND that there would be large architectural gulfs between major releases. For instance, we might have waited an extra 3-5 years for any ZFS support at all in a -RELEASE, and when it appeared, it would introduce a big upgrade hurdle, as it would be accompanied by major underlying changes in system architecture. But my counter to this was that a lot of these features that we did get introduced to, earlier, were in fact not really usable anyway. For instance, my firm(s) have not even considered production use of ZFS until 8.3-RELEASE. So the question remains, where do we set that dial ? If it were up to me, I think I would stake out a very loud and clear mission statement for FreeBSD that explicitly sacrifices new features for longer lifecycles and deeper investment in particular releases. I've thought seriously about the points that were made in this thread supporting faster releases, and I do appreciate what we would be giving up, but I continue to advocate for a new major release every 5 years. I don't think that's going to happen, but based on this discussion and feedback, it appears that we're going to get more frequent minor releases - possibly 3-4 per year - which makes me very happy. That sounds fair to increase the lifecycle to 5 years, but I think hardware support (at least) needs to be available much sooner; perhaps included in the minor releases. Otherwise users will just go elsewhere (large corps or desktop users- mostly desktop though), it was trying even for me as a stubborn mule. Most haven't the patience that I do. I'm not 100% sure how to do this though... 3. Could a higher bar be set to reach a major release than simply temporal objectives? One of the differentiating factors between linux and FreeBSD is the simple fact that linux distros tend to run so fast through the numbers- and while just a matter of perspective, it could provide some sense of stability to enterprise users. Weighed against, of course, the ability to upgrade easily. I think temporal objectives are decent, provided they are long :) Long timelines give people and organizations incentive to invest time and money into a thing. I know very well of several investments in FreeBSD that my firm(s) did NOT make because we didn't think it was worth it, given that the release, and underlying arch, were going away. Fair enough. I left linux for the same reason (but that was exceedingly extreme). For the same reason drifting [ak]bi between major releases is probably a bad idea - that would be an imitation of what most of us have left in linux. 4. If in the case of the former, could some backporting to the stable and release branches facilitate an easy upgrade to the next major release? 5. Could binaries be the answer to easier upgrades (customised for enterprise users)? I think others have had better comments and insight as far as those two points are concerned. I think you would be well served to read the entire comment thread, and just ignore all of the posts
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/20/12 09:13, John Kozubik wrote: I normally hate to dredge up old threads, but this is like getting halfway through a story and not finding out the ending... :) What is the answer? Is there a solution to this? I have a string of questions on this: 1. Incidentally, what exactly does constitute a major release? 2. Is there a reason to update the numbers so quickly? 3. Could a higher bar be set to reach a major release than simply temporal objectives? One of the differentiating factors between linux and FreeBSD is the simple fact that linux distros tend to run so fast through the numbers- and while just a matter of perspective, it could provide some sense of stability to enterprise users. Weighed against, of course, the ability to upgrade easily. 4. If in the case of the former, could some backporting to the stable and release branches facilitate an easy upgrade to the next major release? 5. Could binaries be the answer to easier upgrades (customised for enterprise users)? I'd really like to know the OP's thoughts on this... Cheers ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/22/12 15:49, Mark Linimon wrote: As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. How do you get that number? I ran a search on pr's and only came up with around ~4k. Is there a trick I'm missing? ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/22/12 22:44, Chris Rees wrote: On 22 Jan 2012 12:05, Da Rock9phack...@herveybayaustralia.com.au wrote: On 01/22/12 15:49, Mark Linimon wrote: As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. How do you get that number? I ran a search on pr's and only came up with around ~4k. Is there a trick I'm missing? Scroll up and count the serious and critical bugs too :) Oh shit! That's embarrassing... I was only looking at the number at the bottom- I didn't realise it broke the numbers into the sections. Sorry for the cruft ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/20/12 09:13, John Kozubik wrote: On Wed, 18 Jan 2012, Dieter BSD wrote: John writes: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 Until a few days ago 8 was the latest, shinest release. So you want to suddenly demote it all the way down to legacy? I thought the goal was to have releases that can be used for a long time? No, that's not quite what I meant. I was speaking at the same time about the problem of having two concurrent production releases. Since 9.0 is already released, you can't stop having two production releases with 8, since 9 is already here. So i was saying *after* you continue the normal 8.x lifecycle (perhaps another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic changes, which I showed in the list above. So 8 would become legacy on the same schedule that it always had. No changes there. The change comes with 9 being the only production release, and 10.0-RELEASE being delayed. I'll weigh in :) I can sympathise with the need for longer support; but then on the other hand that means for things like fixes for drivers you have to wait 2 years or more- I've already done that, and I've been happier when things finally just work rather than having to root around and try to get things to work in any way I can. Case in point: I had a laptop with an iwn driver, there was no support for it, and it was going to wait for 8.0 (7.0 at the time). There was no option to backport as the driver wasn't working in current, so I tried to get involved and help but that quickly stagnated. So I was stuck to a cable (age had to be backported) and finally in 8 it worked, and wpa_supplicant was finally fixed as well. And when everything worked my laptop died and I bought another! :( Now I have ath. ath didn't work in 8. I tried a backport from current, and it worked for a bit and broke in 8.2. I was then forced to work with 9.0-RCx. Waiting longer would not have been an option- I was looking for a release date or some idea on where 9.0-RELEASE was at but the information was outdated and scarce. I was also hoping to get 802.11n support. Now apparently that is not really an option until 10. So what do I do? Some support is backported, but not all can be due to unresolvable API differences, same as what happened back with iwn. So based on this I face a continually moving target: my hardware lifetimes and the ability to keep up with new hardware produced by the dev team. I'd like to get involved, but drivers are still very much an enigma as yet. I also keep getting told to use current to help with testing, but given my userbase I can't do this without screams of agony, and vm's are useless here for hardware testing. I'm also advised to follow stable, but again- same deal. So I'm always asking myself why is it so hard to run release? I've read this entire thread now, but I still can't see a specific answer that resolves the issues presented. IF releases are supported longer, then backports are a must as near as I can see, but if the APIs are too different then how? If hardware or other feature support takes too long then users go elsewhere as well. I can't help being stubborn as mule, working with something no matter how hard it is, but I'm sure most users/sysadmins aren't. If a split was made between server and desktop edition that would be a disaster I believe. The only reason all this works so well is because there is no difference. The features required to make desktop more user friendly need to be added (probably by ports) as required, but that wouldn't kill server support. That only adds more labor to an already stressed environment. I will put my hand up to help with RE, or whatever will help in this situation; maybe even customised releases for rollouts for different organisations interested? I have cpu cycles to burn, and my missus is even egging me on :) I have enough systems to warrant this even for my own needs, and I'm sure I could pull it off with some help. My needs are more desktop than server though, and that should be helpful for the majority as support doesn't just stop at just what will provide for the sysadmins. I'll help in any way I can, if I get some support as well that would be handy. One thing that stands out to me I think is that svn (or similar) is a definite must and the cvs is too archaic for the needs here. The code freeze seems to be a real hindrance to a healthy release. Also, as to bugs, cannot some of the processes be automated (scripted?) somehow? Say if a patch is commited, can't this be detected and tested and a report sent to the stakeholders/interested parties? Depending on skill level required my missus could help on the poking side of things... On another point, Adrian: you mention that one can get involved, but that does seem to be an overwhelming task. I've tried to put up my hand a few times, but got
Re: [SOLVED]Re: 64bit build errors - use gcc46
On 12/08/11 19:58, Tom Evans wrote: On Thu, Dec 8, 2011 at 6:05 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: Just to let the list know, I changed as - ./configure --as=/usr/local/bin/as. I still had the exact same error oddly enough. I then had to install gcc46; and the error changed. I then had to update the configure script to comment out the v4l videodev headers (weird). Bingo! I had success. So, it begs the question did the as option change things? Or does gcc46 imply the use of it anyway? I'll have to try again without the option to see for sure, but for now I have another project that I need to keep the status quo for. Yes, sometimes as is invoked via gcc, and if you are using the stock gcc, it uses the stock as, and you still get the errors. You need both gcc46 and binutils from ports. Sorry, forgot that bit :o Confirmed. Built without --as and only --cc arguments. Great learning experience for me anyway... :) Cheers ___ 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: 64bit build errors
On 12/07/11 20:36, Tom Evans wrote: On Wed, Dec 7, 2011 at 12:40 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. Error: `-1(%edi)' is not a valid 64 bit base/index expression Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? Cheers Yes, you need to use newer binutils from ports. It also helps with ffmpeg/mplayer to use a newer gcc from ports as well (I use gcc46), but the main thing is installing binutils and configuring with --as=/usr/local/bin/as. Cool! Thanks for that. I got a manual to read by the looks of it anyway, but can anyone give me the inside gos on the why it does what it does? (Or something like that.. :) ) Cheers ___ 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: 64bit build errors
On 12/07/11 21:29, Tom Evans wrote: On Wed, Dec 7, 2011 at 10:59 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: Cool! Thanks for that. I got a manual to read by the looks of it anyway, but can anyone give me the inside gos on the why it does what it does? (Or something like that.. :) ) This email explains it: http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-July/083051.html I really hate sounding like an idiot, but if I don't ask I'll never know: The assembler in base is not up-to-date with the latest instruction sets for the cpu, and is causing an error because its telling the cpu to do something it doesn't understand and is going WTF! So the port binutils provides the latest instruction sets for the latest cpus. And ffmpeg and friends use the latest cpu abilities to run as fast as they do? Right or way off? Otherwise I'd have problems building anything, wouldn't I? ___ 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: 64bit build errors
On 12/07/11 22:17, Tom Evans wrote: On Wed, Dec 7, 2011 at 11:47 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: I really hate sounding like an idiot, but if I don't ask I'll never know: The assembler in base is not up-to-date with the latest instruction sets for the cpu, and is causing an error because its telling the cpu to do something it doesn't understand and is going WTF! So the port binutils provides the latest instruction sets for the latest cpus. And ffmpeg and friends use the latest cpu abilities to run as fast as they do? Right or way off? Otherwise I'd have problems building anything, wouldn't I? The way I understand it is that they use compiler/assembler features that did not exist in the version of binutils that is in base. That might be related to CPU features - I know you need binutils from ports to use SSE3 features, for example - but whether that is what happens here, or whether it is due to ffmpeg using newer features would have to be answered by someone who understands what is going on! Ok, that did just answer it. For starters SSE3 is used in ffmpeg/mplayer, but there would be more (3DNOW, etc). So that explains it... interesting study. I'll have a closer look at the docs on binutils to find out more. Cheers ___ 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: 64bit build errors
On 12/08/11 00:45, Garrett Cooper wrote: On Dec 7, 2011, at 6:22 AM, Tom Evanstevans...@googlemail.com wrote: On Wed, Dec 7, 2011 at 1:52 PM, Dimitry Andricd...@freebsd.org wrote: On 2011-12-07 01:40, Da Rock wrote: I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. Error: `-1(%edi)' is not a valid 64 bit base/index expression Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? At first glance, I'd say you are compiling it with a 32-bit compiler or assembler. In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, and it compiles just fine with base gcc. What are the exact commands you are running? I imagine you are running CURRENT or 9.0, which has a newer binutils than 8-STABLE, which is what causes/exposes this issue. The question is: what is the OP running? I don't think that's been identified yet.. For reference 8.1 and 8.2. I'll post once I've had a chance to confirm the solution, but I'm pretty sure it will solve it based on the info I've been given. Cheers ___ 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: 64bit build errors
On 12/08/11 05:47, Mike Meyer wrote: On Wed, 7 Dec 2011 12:17:57 + Tom Evanstevans...@googlemail.com wrote: The way I understand it is that they use compiler/assembler features that did not exist in the version of binutils that is in base. Which begs the question - why isn't the new version of the tools (provided by ports) listed in BUILDDEPENDS in the port, then? I'm not building the port. This is my own build, so the builddepends isn't existent. ___ 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: 64bit build errors
On 12/08/11 08:31, Da Rock wrote: On 12/08/11 05:47, Mike Meyer wrote: On Wed, 7 Dec 2011 12:17:57 + Tom Evanstevans...@googlemail.com wrote: The way I understand it is that they use compiler/assembler features that did not exist in the version of binutils that is in base. Which begs the question - why isn't the new version of the tools (provided by ports) listed in BUILDDEPENDS in the port, then? I'm not building the port. This is my own build, so the builddepends isn't existent. Hence hackers@, else I would have posted ports@ ___ 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
[SOLVED]Re: 64bit build errors - use gcc46
On 12/08/11 08:33, Da Rock wrote: On 12/08/11 08:31, Da Rock wrote: On 12/08/11 05:47, Mike Meyer wrote: On Wed, 7 Dec 2011 12:17:57 + Tom Evanstevans...@googlemail.com wrote: The way I understand it is that they use compiler/assembler features that did not exist in the version of binutils that is in base. Which begs the question - why isn't the new version of the tools (provided by ports) listed in BUILDDEPENDS in the port, then? I'm not building the port. This is my own build, so the builddepends isn't existent. Hence hackers@, else I would have posted ports@ Just to let the list know, I changed as - ./configure --as=/usr/local/bin/as. I still had the exact same error oddly enough. I then had to install gcc46; and the error changed. I then had to update the configure script to comment out the v4l videodev headers (weird). Bingo! I had success. So, it begs the question did the as option change things? Or does gcc46 imply the use of it anyway? I'll have to try again without the option to see for sure, but for now I have another project that I need to keep the status quo for. ___ 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
64bit build errors
I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. Error: `-1(%edi)' is not a valid 64 bit base/index expression Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? Cheers ___ 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: [maybe spam] Re: linux PF_PACKET compatibility
On 02/12/11 19:39, Gary Jennejohn wrote: On Fri, 11 Feb 2011 17:19:17 -0800 Julian Elischerjul...@freebsd.org wrote: On 2/11/11 4:03 PM, Da Rock wrote: Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Ther's a sendarp() routine which uses PF_PACKET to directly access the network driver and bypass the stack. Lazy Linuxers who have no idea or don't care that other operating systems exist. Indeed. Is it possible to leverage another compatible routine? I haven't had a look yet as I just read the message, but can I (after checking return values and arguments) just drop in another arp routine? Or are they simply incompatible across the board? From what I understand they should all be essentially doing the same thing, but I could be wrong on this. Alternatively would I have to basically rewrite the arp.c to be posix compatible (for portability)? Cheers ___ 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: [maybe spam] Re: linux PF_PACKET compatibility
On 02/13/11 06:15, Vlad Galu wrote: On Sat, Feb 12, 2011 at 12:28 PM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/12/11 19:39, Gary Jennejohn wrote: On Fri, 11 Feb 2011 17:19:17 -0800 Julian Elischerjul...@freebsd.org mailto:jul...@freebsd.org wrote: On 2/11/11 4:03 PM, Da Rock wrote: Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Ther's a sendarp() routine which uses PF_PACKET to directly access the network driver and bypass the stack. Lazy Linuxers who have no idea or don't care that other operating systems exist. Indeed. Is it possible to leverage another compatible routine? I haven't had a look yet as I just read the message, but can I (after checking return values and arguments) just drop in another arp routine? Or are they simply incompatible across the board? From what I understand they should all be essentially doing the same thing, but I could be wrong on this. Alternatively would I have to basically rewrite the arp.c to be posix compatible (for portability)? Cheers You only need to rewrite the sendarp() routine, using a BPF device descriptor instead of the PF_PACKET socket descriptor. Take a look at libdnet[1] and rbootd[2]'s source. [1] http://libdnet.sf.net/ [2] http://ftp.fr.openbsd.org/pub/OpenBSD/src/usr.sbin/rbootd/ You will need, however, to fill the source with #ifdefs to compensate the fact that Linux has assigned different names and sizes to the members of struct ether_header and arphdr (and has a _BSD_SOURCE knob to accomodate compiling BSD-based software)./ / Ok, I think I know where I have this thing ass-backwards now: I was looking for similar structs with the same _size_- they don't have to be! Duh! I've figured the out the members like ETH_ALEN and defined the bsd equivalent, I'll have to look into the _BSD_SOURCE. Thx for the recorrect :) ___ 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: linux PF_PACKET compatibility
On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ 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: linux PF_PACKET compatibility
On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ 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: linux PF_PACKET compatibility
On 02/12/11 02:37, Julian Elischer wrote: On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? I'm afraid you have me a little stumped. The PF_PACKET family talks directly with the network driver sending data to and from the app. Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ 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: linux PF_PACKET compatibility
On 02/12/11 02:48, Julian Elischer wrote: On 2/11/11 5:40 AM, Da Rock wrote: On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. why do you think you need only one interface? One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. pppd in base will I think give you multiple interfaces.. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... again, whats' with the single interface? To be honest I don't know. But from what I've read up on it so far (including mpd - use and ng interface) I will have an net interface for every client. Apparently l2tpns doesn't do that, and one of the arguments for its use is that feature. If one has say 100 clients, each of those needs to be managed- 1 sounds better to me :) I am only working on theory here so far though, so please let me know if I'm on the wrong track. Cheers Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ 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: [maybe spam] Re: linux PF_PACKET compatibility
On 02/12/11 11:19, Julian Elischer wrote: On 2/11/11 4:03 PM, Da Rock wrote: On 02/12/11 02:37, Julian Elischer wrote: On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? I'm afraid you have me a little stumped. The PF_PACKET family talks directly with the network driver sending data to and from the app. Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Neither do I. talk to the writer of the web page you indicated.. maybe he can help.. I did. No response so far... It was for 7.3, but I can't see the difference. (I'll merge the 2 threads of this to make it easier and less consuming) again, whats' with the single interface? To be honest I don't know. But from what I've read up on it so far (including mpd - use and ng interface) I will have an net interface for every client. Apparently l2tpns doesn't do that, and one of the arguments for its use is that feature. If one has say 100 clients, each of those needs to be managed- 1 sounds better to me :) I am only working on theory here so far though, so please let me know if I'm on the wrong track. if you have multiple interfaces you can set differnt mtus for them etc. and routing is more straight forward. you can do tcpdump on a particular interface or filter on just one interface. there have been people with 100 interfaces.. who didn't seem to have any problems. there are advantages and disadvantages. I'd say you're right. But if you have all those interfaces (and this what my first thought was when I started this) then it requires more holes in the firewall- right? So for every ng interface I'd need to accept 1701, which gets messy in PF because I'd have to dictate where to rdr every incoming 1701. OTOH, if I have just a tun device for every 1701 to connect to then I only have to rdr all 1701 to the l2tp server. Routing can be done just on that server (mostly to reroute back out again) either through ppp static routing or otherwise. At least this is my impression so far. By all means let me know if I'm idiot with my head on backwards- I'm trying to get beyond theory before I start chatting on the -net list... :) FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use
linux PF_PACKET compatibility
In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ 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
