Re: FreeBSD eats 169.254.x.x addressed packets
Guy Helmer wrote: My previous understanding was that RFC 3927 did not allow transmitting datagrams involving the 169.254.0.0/16 link-local prefix; now that I've looked over the RFC more closely, I'm not sure that is the case. I have cc'ed Bruce Simpson on this message in hopes that he can shed some light on this. I believe he committed the change that disallowed transmitting from 169.254.0.0/16 addresses. RFC 3927 is pretty clear that 169.254.0.0/16 traffic is not to be forwarded beyond the link. I do not understand why the OP is losing traffic, unless he's relying on pre-RFC 3927 behaviour in his network topology. The IN_LINKLOCAL() check happens after ip_input() walks the address hash looking for exact address matches. So if an interface has a link-local address, the packet should get delivered upstack as usual. When I made this change, link-local addressing couldn't be fully implemented in FreeBSD, due to the lack of support for address scopes in the FreeBSD IPv4 code. Hopefully new people can pick up on it as they wish. thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On 04/12/10 05:12, Maho NAKATA wrote: *Abstract* I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd64 using dgemm (a linear algebra routine, matrix-matrix multiplication). I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 and almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed. So, where's the profiling to discover why this is the case? Also I'm not clear on what constitutes 'theoretical peak performance' here or how it is being calculated. So figures like these come across as unscientific. I'm sure this is something which can be resolved if someone sits down, profiles the app, and makes the necessary adjustments (e.g. pthread_setaffinity_np()) to configure CPU affinity, if the lack of it is pessimizing your friend's app. The PMC framework is rapidly maturing, and you can use KCacheGrind with it to visualize context switch overhead. But I think it's expecting a bit much to post informal results to -stable, in an expectation of something other thaninformal suggestions of what may help someone's maths-intensive application. If there are performance issues, then reproducible results are needed, as well as some basic profiling effort of the system elements involved, before people could say anything either way, or offer further help. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Hi all, There's a port archivers/pbzip2, and I am inclined to believe this is a good benchmark for multi-core performance in real-world usage (with an appropriate input data set). BZIP2 is a compression algorithm which is readily applicable to multicore, because of the nature in which its workload may be partioned amongst multiple CPU cores. It block-sorts, and it can compress long runs of input data independently of other CPU threads. When I used PBZIP2 informally back in January, before advising on FreeBSD/Xen, I saw largely the results I'd expect to see from such a workload, and didn't encounter pessimization of benchmark figures. Informal tests were performed on 8-STABLE at that time. The OP may well be looking for Newton-Raphson approximations, to the derivatives involved in his friend's linear algebra system. The point is that PBZIP2 would also exercise context switches in a real-life workload. I'd be concerned, as anyone else would be, about benchmarks which apparently challenge FreeBSD's ability to tackle significant mathematical workloads. But from what little I understand, from speaking to David Schultz and others who have been involved with FreeBSD's floating point performance, on a scientific basis -- without a scientifically reproducible experiment, I don't see a problem. Obviously, I am concerned that Nakata-san observes what he regards to be a problem, and would like to help any way I can. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hardware for home use large storage
On 02/10/10 19:40, Steve Polyack wrote: I haven't had such bad experience as the above, but it is certainly a concern. Using ZFS we simply 'offline' the device, pull, replace with a new one, glabel, and zfs replace. It seems to work fine as long as nothing is accessing the device you are replacing (otherwise you will get a kernel panic a few minutes down the line). m...@freebsd.org has also committed a large patch set to 9-CURRENT which implements proper SATA/AHCI hot-plug support and error-recovery through CAM. I've been running with this patch in 8-STABLE for well over a week now on my desktop w/o issues; I am using main disk for dev, and eSATA disk pack for light multimedia use. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ionice in FreeBSD?
On 02/03/10 11:52, Jordi Espasa Clofent wrote: So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? Some shell-scripts based on dd or rsync, for example. Even a daily antivirus (ClamAV) scanner means an extensive I/O. Even just renicing the processes should help here. The thread(s) will still be scheduled to run when they need running, although it will reduce the rate at which the process(es) involved can saturate the kernel with I/O requests. Currently the FreeBSD kernel doesn't really make a distinction between I/O transactions per process, because of how the unified VM buffer cache works. read() and write() are satisfied from VM; VFS will cause a vm_object to be created for each opened vnode, so read() will be satisfied by the same set of vm_page's as for mmap(). The vnode_pager's getpages() routine will eventually read into physical pages, using BIO requests (although it's usually the filesystem which actually does this). The net effect is that VFS shares its buffers with VM, and this does have some piecemeal benefit as the BIO subsystem will read from the physical medium in large chunks. It isn't impossible to account for I/O per-process. The Xen hypervisor has a similiar problem for per-domain I/O accounting. Currently, Domain 0 is responsible for block I/O, and it can be difficult for its scheduler to tell things apart for similar reasons. There have been previous research forks of FreeBSD to implement I/O scheduling; Eclipse/BSD from Bell Labs was one of them. It might be a good Google Summer of Code project for an interested computer science student. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ionice in FreeBSD?
On 02/02/2010 17:19, Jordi Espasa Clofent wrote: In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. That's not entirely true. A thread's CPU priority is still going to affect its ability to be scheduled on the CPU, and if it's waiting in the read() or write() syscalls, then this will make a difference to how quickly it can complete the next call. However, it doesn't explicitly affect relative I/O prioritization. This is another story entirely. I suspect in a lot of cases adding a weight to per thread I/O, isn't going to make much difference for disk I/Os which are being sorted for the geometry (e.g. AHCI NCQ). So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup
Try GRUB4DOS. I use this so on boxes where I have Windows installed, I can keep GRUB in the NTFS partition. I haven't seen this issue and am tracking -STABLE on an ASUS V-series machine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mounting ext3 for rw
You could try this, but it needs patching for FreeBSD: http://sourceforge.net/projects/ext2fuse/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HP LJ 1020: ulpt0: offline
Graham Menhennitt wrote: Foo2zjs doesn't seem to have changed recently. CUPS has changed but I doubt that's the problem. Maybe something to do with USB drivers? In 8.x, CUPS 1.4.x wants libusb support and the ugen driver, rather than ulpt. Once I changed over to that, all was fine. It's a mite irritating that device permissions can't be tied down easily as they can with ulpt(4), because CUPS needs to see the /dev/usb/* device nodes. On my print server, I just have devfs rules for the new device nodes. P.S. uscanner has also gone away. I use a multi-function device (Epson CX3650). The sane-backends can also use libusb now. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bootless!
Randy Bush wrote: is there a recipe for making a 7.2 usb? Tried the UsbDevice command in NanoBSD? This won't give you a full FreeBSD installer, but you can build a 7.2 system with it just fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-BETA3/i386: make WITHOUT_TOOLCHAIN=yes buildworld broken
Simon L. Nielsen wrote: I'm pretty sure WITHOUT_TOOLCHAIN=yes hasn't worked with buildworld since 7.x, so this is nothing new. You need to specify it with installworld, not buildworld. At least I ran into that with NanoBSD some time ago. Any chance we could get the C++ runtime coaxed away from under this option? Just now, to get libstdc++, I have to ship binutils too in a NanoBSD install... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ataraid's revenge! (Was: Re: A nasty ataraid experience.)
Gavin Atkinson wrote: On Thu, 2009-07-23 at 19:57 +0100, Bruce Simpson wrote: 6 months on, ataraid(4) did it again. Which ataraid(4) controller is this? Seeing a verbose dmesg would help. There are several patches in the PR database for ataraid problems, it would be worth having a look. Not much to report; it is a JMicron PCI-e card. I switched to the JMicron because it actually worked. The on-board controller is VIA and I don't use it; I've had problems managing the VIA based software RAID. Occasionally the mirror degrades, usually on boot, if something panics the machine. This leads to interesting inconsistencies and panics. All I was doing at the time was srm'ing a bunch of sensitive files, and running some CPU (not disk) intensive regression tests for Boost. I found it's difficult to recover from errors. See my post from 6 months ago about how 'atacontrol rebuild' often just plain fails. As per original post, the process(es) just wedged in getblk, and I had to take the system down to get some sense out of it as disk access ground to a halt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: status of flash9/flash10 support in RELENG_7 ?
Luigi Rizzo wrote: Is there a recipe for a working flas9 or flash10 operation ? Allegedly PC-BSD ship a working Flash install, I have not tried it. I have had similar problems and tried similar recipes. The Flash player(s) thus embedded are not very stable, and can crash or hang with multiple opens, or browser tab embedding the player(s) being closed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ataraid's revenge! (Was: Re: A nasty ataraid experience.)
6 months on, ataraid(4) did it again. This time, I was lucky -- I caught in in time, but the damage to the filesystem meant having to use fsdb to NULL out the affected inodes; mounting read-only, tarring, and untarring across the network, after a newfs, let me save the affected partition. All I was doing at the time was srm'ing a few sensitive files; all the processes wedged in WCHAN getblk. It seems ataraid(4) is not robust against temporary drive/controller problems. The SMART logs on the affected array drives all check out just fine, there are no bad block remaps. So, time to either buy a hardware RAID controller, or move to ZFS... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SCSI device not created upon a CF card plug in
Eugene Grosbein wrote: On Thu, Jul 23, 2009 at 10:14:18AM +0800, Sagara Wijetunga wrote If you conversant in this area, could you help us to identify what is/are the exact function/s in which program/s to look into identify the media insertion activity, so that we can generate relevant devd event. No, I'm not. In your position I would study the device specs - does it generate hardware event in case of media change in first place? If yes, I'd read sources of umass driver to see how it generates events for single flash device and add such event for reader's media change. rwatson@ has or has had a patch to do something like this. It is complicated by the fact that GEOM and NEWBUS don't necessarily talk to each other directly. I agree something needs to be done about removable volume management in FreeBSD. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.2 USB stack info needed
Sagara Wijetunga wrote: 1. Could I know which exact program print above line on /dev/devctl ? The kernel... 2. I want to print another line with daN as the device-name, where N is 0 to 9, with minimum vendor and product ids once the allocated device-name is known for USB Mass Storage devices. Your additional ideas/feedback/help is most welcomed. rwatson had a patch for something like this somewhere. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Merging a GCC bug fix to RELENG_7 - how?
Hi all, This GCC bug bites us in the Boost regression tests in a number of places. Uh oh, I've stepped on the one-line fix bomb: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899 http://gcc.gnu.org/viewcvs?view=revrevision=129199 What's funny is that COPYING in the root of that branch is GPLv2, but the affected file's license is GPLv3. So what on earth do we do? thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
USB critically broken under RELENG_7 on amd64
Hi, Since jhb@ committed the fixes for ULi SATA, I updated my kernel+world on my amd64 desktop machine. So far so good. I updated again Tuesday. Unfortunately I am now seeing USB warnings during boot: uhub1: device problem (TIMEOUT), disabling port 1 I get messages like this for any and all attempts to attach USB devices. ...It works just fine in Windows XP, and worked just fine in RELENG_7 before. What's going on? it doesn't appear to be a repeat of the HAL / libpciaccess saga from February as it happens from boot. This is an ALi OHCI + EHCI controller, fwiw. usbdevs -v spews a lot of 'addr 0 should never happen!'. Could this be an interrupt handling bug of some kind? cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: USB critically broken under RELENG_7 on amd64
Bruce Simpson wrote: Hi, Since jhb@ committed the fixes for ULi SATA, I updated my kernel+world on my amd64 desktop machine. So far so good. I updated again Tuesday. If I revert to the kernel I built from RELENG_7 on June 10th, all is fine. I saw no changes in SVN to the stable/7/sys/dev/usb directory in that time which looked as though they could obviously break USB in such a complete way. Has anyone else seen this issue? It seems fairly critical as a number of folk may not be able to upgrade to FreeBSD 8.0 right away. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
Vlad Galu wrote: ... Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. I've just run head first into this lack for a proof-of-concept I'm looking at -- the lack of PTHREAD_PROCESS_SHARED support on FreeBSD. Are there any other references I can start working from? cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: reecommendations for an 'appliance platform ?
Pete French wrote: Any suggestions, or words of wisdom from anyone who has done someething similar themselevs in the past ? The ASUS EeePC 701 is cheap as chips and can easily be mass-flashed with NanoBSD images from a USB dongle. I wrote a reflash script but didn't release it -- it just takes the USB dongle image and dumps it on the internal SSD with the appropriate fixups. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
Vlad Galu wrote: ... Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. I stand corrected. Having read around this, I don't see how process-shared sems could work at all, although I haven't actually tried running process-shared sem code. POSIX semaphores were however horribly broken in kernel prior to 7.2. The fix was essentially one liner. We got a very good test case from a chap in a GNATS PR. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
Jilles Tjoelker wrote: If process-shared semaphores really work, then the above structure is not a pathological case. Effectively, sem_t is carved in stone. So process-private semaphores should continue to have most of their stuff in a separately allocated structure, to preserve flexibility. There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in HEAD and STABLE about 6 weeks before 7.2 was released. I believe process-shared POSIX semaphores now work -- the Python 'multiprocessing' regression test now runs to completion with no errors on both HEAD and STABLE. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
John Baldwin wrote: ... Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it allocates the resources once for each channel it seems in the ata_ali_sata attachment. Looking in ata-chipset.c, all the other chipsets are good about allocating these resources in their chipinit routines rather than the per-channel allocate routine. Well, except ata_pci_allocate() is also busted. *sigh* I can work on a patch for HEAD if you are willing to test. Yes, ata is gnarly in places... If a fix can be dropped straight into a 7.2 tree, then that is even better... I could try testing a NanoBSD image of HEAD on this machine if the change set delta between branches is sufficiently huge to prevent backporting the fix; this is my desktop machine and this is the only critical bug I've run into so far with 7.2. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Hi, Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: ATA channel 2 on atapci1 panic: resource_list_alloc: resource entry is busy This machine uses an ALi SATA controller. I haven't had any problems with this controller's support for most of the 7.x branch, but it was last broken during the 6.x branch. I see there have recently been commits in this area which may have broken ATA driver support in some subtle way. Backtrace is (w/o symbols):- ... resource_list_alloc() pci_alloc_resource() bus_alloc_resource() ata_ali_sata_allocate() ata_pcichannel_attach() device_attach() ... There are no debugging symbols at the moment as this is a production kernel. If any further information is required to resolve the bug, please let me know. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Bruce Simpson wrote: Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: ATA channel 2 on atapci1 panic: resource_list_alloc: resource entry is busy ... I see there have recently been commits in this area which may have broken ATA driver support in some subtle way. Rolling back SVN rev 192033 by hand makes no difference. The controller is an AcerLabs M5287 SATA150 controller. Has anyone else seen a similar boot panic? thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Leo wrote: Hi Burce, At first, I'm sorry replay late. I've test build libpcap without ports and using same tar ball. The error message still output. SLT2# make gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:43: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here *** Error code 1 Hi, I can't think what might be causing this for you... Do you have other pcap libraries installed on the system? Perhaps a define is incorrect. Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that should rule out changes in HEAD. Do you have BPF headers present on the system? Have you checked the output of config.log? Do you have a bpf device in your kernel? -- I think that might be it. The fix might be to specify --with-pcap=bpf in CONFIGURE_ARGS in the port. I just built the port on an i386 system tracking RELENG_7 sources, and couldn't reproduce this problem, although I have bpf in kernel there. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bluetooth troubleshooting
Daniel O'Connor wrote: On Sat, 2 May 2009, Dominic Fandrey wrote: # hccontrol -n ubt0hci inquiry Inquiry complete. Status: No error [00] is pretty lame compared to what should appear according to the handbook: % hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] Depends what's in range. Your command indicates to me that there are no _discoverable_ BT modules in range. (Note the discoverable part :) Not all devices need be INQUIRE-able. Some may not have INQUIRE scan enabled. In that case you need to know the Bluetooth address of the device you're looking for so you can PAGE it. If you're expecting to see a mobile phone or other handheld device you might need to enable discoverability on the device itself. There are also other IAC codes used for INQUIRY, but generally these aren't used. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Leo wrote: I don't have other pcap lib installed on this box. Previously installed a libpcap 0.9 on this box , But I've deleted this version. On my box, not enable BPF. Let me try if enable the feature. That's probably what it is. Can you try the following: * give pcap configure --with-pcap=bpf WITHOUT having bpf in your kernel config. * try enabling bpf in kernel config and building the port as usual. Most likely libpcap's new configure script is detecting the lack of /dev/bpf* and assuming there is no packet capture support in the system. This needs to be fixed for cross compiling to be possible. If you could try at least the first fix then this is the answer. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help ! Regarding libpcap issue.
Hi, I recently updated the port, but didn't see this condition in testing. Are you able to build libpcap *without* using the port from the same tarball? do-patch in the port doesn't touch those files. Leo wrote: Hi All, I want to install libpcap from ports. But when I make install clean, the box output: ... config.status: creating pcap_open_dead.3pcap config.status: creating pcap_open_offline.3pcap config.status: creating config.h === Building for libpcap-1.0.0 cc -O2 -O2 -fno-strict-aliasing -pipe -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:44: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: error: previous declaration of 'pcap_activate' was here gmake: *** [pcap-null.o] Error 1 *** Error code 1 thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel compile fails without AH_SUPPORT_AR5416
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing these
ath(4) changes to RELENG_7.
I can't remember if I tested the kernel compile without the
AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
...
ru had a change to fix this but decided not to; can't say why.
Otherwise there is a better way to fix this which I alluded to in
previous mail--use the config-generated #define that is generated for
the ath_hal device.
thanks,
BMS
Index: UPDATING
===
--- UPDATING(revision 191718)
+++ UPDATING(working copy)
@@ -8,6 +8,11 @@
/usr/ports/UPDATING. Please read that file before running
portupgrade.
+20090505:
+ The kernel compile-time option AH_SUPPORT_AR5416 has been
+ removed; it is now enabled by default as if_ath.c depends on it
+ in order to build.
+
20090504:
FreeBSD 7.2-RELEASE
Index: sys/arm/conf/AVILA
===
--- sys/arm/conf/AVILA (revision 191718)
+++ sys/arm/conf/AVILA (working copy)
@@ -133,7 +133,6 @@
#devicewlan_tkip # 802.11 TKIP support
device ath # Atheros pci/cardbus NIC's
device ath_hal # Atheros HAL (Hardware Access Layer)
-optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx
descriptors
device ath_rate_sample # SampleRate tx rate control for ath
optionsATH_DEBUG
Index: sys/sparc64/conf/GENERIC
===
--- sys/sparc64/conf/GENERIC(revision 191718)
+++ sys/sparc64/conf/GENERIC(working copy)
@@ -191,7 +191,6 @@
device wlan_scan_sta # 802.11 STA mode scanning
device ath # Atheros pci/cardbus NIC's
device ath_hal # Atheros HAL (Hardware Access Layer)
-optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx
descriptors
device ath_rate_sample # SampleRate tx rate control for ath
# Pseudo devices.
Index: sys/conf/options
===
--- sys/conf/options(revision 191718)
+++ sys/conf/options(working copy)
@@ -731,8 +731,6 @@
ATH_TX99_DIAG opt_ath.h
# options for the Atheros hal
-AH_SUPPORT_AR5416 opt_ah.h
-
AH_DEBUG opt_ah.h
AH_ASSERT opt_ah.h
AH_DEBUG_ALQ opt_ah.h
Index: sys/modules/ath/Makefile
===
--- sys/modules/ath/Makefile(revision 191718)
+++ sys/modules/ath/Makefile(working copy)
@@ -76,8 +76,9 @@
#
# AR5416, AR9160 support; these are 11n parts but only really
# supported (right now) operating in legacy mode. Note enabling
-# this support requires defining AH_SUPPORT_AR5416 in opt_ah.h
+# this support requires defining AH_SUPPORT_AR5416
# so the 11n tx/rx descriptor format is handled.
+# This support is now enabled by default.
#
# NB: 9160 depends on 5416 but 5416 does not require 9160
#
@@ -106,7 +107,4 @@
CFLAGS+= -I. -I${.CURDIR}/../../dev/ath -I${.CURDIR}/../../dev/ath/ath_hal
-opt_ah.h:
- echo '#define AH_SUPPORT_AR5416 1' $@
-
.include bsd.kmod.mk
Index: sys/dev/ath/ath_hal/ah_desc.h
===
--- sys/dev/ath/ath_hal/ah_desc.h (revision 191718)
+++ sys/dev/ath/ath_hal/ah_desc.h (working copy)
@@ -20,8 +20,12 @@
#ifndef _DEV_ATH_DESC_H
#define _DEV_ATH_DESC_H
-#include opt_ah.h/* NB: required for AH_SUPPORT_AR5416 */
+#include opt_ah.h
+#ifndef AH_SUPPORT_AR5416
+#define AH_SUPPORT_AR5416 /* always support AR5416 */
+#endif
+
/*
* Transmit descriptor status. This structure is filled
* in only after the tx descriptor process method finds a
Index: sys/dev/ath/if_ath.c
===
--- sys/dev/ath/if_ath.c(revision 191718)
+++ sys/dev/ath/if_ath.c(working copy)
@@ -3399,7 +3399,7 @@
rix = rs-rs_rate;
sc-sc_rx_th.wr_rate = sc-sc_hwmap[rix].ieeerate;
sc-sc_rx_th.wr_flags = sc-sc_hwmap[rix].rxflags;
-#if HAL_ABI_VERSION = 0x07050400
+#if HAL_ABI_VERSION = 0x07050400 defined(AH_SUPPORT_AR5416)
if (sc-sc_curchan.channelFlags CHANNEL_HT) {
/*
* For HT operation we must specify the channel
Index: sys/i386/conf/GENERIC
===
--- sys/i386/conf/GENERIC (revision 191718)
+++ sys/i386/conf/GENERIC (working copy)
@@ -255,7 +255,6 @@
device an # Aironet 4500/4800 802.11 wireless NICs.
device ath # Atheros pci/cardbus NIC's
device ath_hal
Re: kernel compile fails without AH_SUPPORT_AR5416
Sam Leffler wrote: ... the ath_hal device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device name gets pulled into config(5) with the 'device' keyword. Thanks for the reminder... This is a much cleaner fix for the issue than forcing the option to be set on always. It looks like HEAD has this issue too and this can go right in there. Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? The 'out of box' config hasn't been broken by the change and this is identical to to the situation in HEAD as far as I can see. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel compile fails without AH_SUPPORT_AR5416
Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. Dennis Melentyev wrote: 2009/4/16 Maxim Sobolev sobo...@sippysoft.com: Dennis Melentyev wrote: Could be worth an entry in UPDATING and/or explicitly added to GENERIC. My point is that if the option is mandatory for compiling ath(4) driver, then there is no point in having this option in the first place. Well, fair. +1 from me :). So is there a consensus that this seems to break the build for folk who do not need this option? If so I can see about committing the necessary changes to turn this option on by default. I needed the option for what I was trying to do. Of course if someone already has a patch for that, that will help, as I don't have a lot of free time at the moment but can certainly commit a quick fix if someone already has one. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Anyone using func or certserver?
Is anyone out there using Fedora's Unified Network Controller (func) or certserver on FreeBSD? If so, I would really like to hear from you about your experience with it. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
HEADS UP: Atheros HAL merged to RELENG_7
Hello all, This is just a note to let you all know that the open source Atheros HAL has been merged from HEAD to -STABLE. I tested it out OK on an IBM/Lenovo ThinkPad T43 with an AR5212 in HostAP and STA mode, and on an ASUS EeePC 701 with AH5424 (PCI-express) in STA mode. The ath_rate* modules have been removed as kernel modules, however the options remain, as these are now knobs for the HAL as it gets built into if_ath.ko itself. Furthermore, the ath_hal module should no longer be required. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp unusable after make world
Pyun YongHyeon wrote: Your controller looks like i82550. 82550/82551 has nice hardware cryptographic capability for IPSec acceleration but it's not used at all under FreeBSD. Intel's open source developer manual didn't even mention the existence of cryptographic capability. I had a crack at this about 5-6 years ago. Now that the descriptor ring format is fairly well known for fxp, reverse engineering is feasible, as the setup uses the normal NDIS hooks which Microsoft added for offloading cryptographic operations. Those *are* documented. Making it work is another matter entirely... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1-STABLE does not boot after recent superpage support MFC
Igor Sysoev wrote: Is anyone able to boot kernel with recently merged superpage support ? I have csup'd world to *default date=2009.02.26.23.59.59 then rebuild world and kernel does not boot: FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 X kernel trap 12 with interrupts disabled +1. Attempting to set the tunable at boot time doesn't work for me either. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
I can confirm that with 7-STABLE as of this writing, the USB problems with amd64 and Xorg appear to be fixed. The key requirements are a 7-STABLE tree from *now*, a fresh buildworld+buildkernel, and a forced rebuild of libpciaccess to pick up PCIOCGETBAR. I can now run both scanpci and Xorg without seeing the loss of USB functionality from before. Thanks to jhb@ and rnoland@ for backporting the fixes! cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Cleaning unused libraries and rebuilding dependent ones?
Hi all,
I'm sure that these questions have been asked before, however, a quick
search of forums on the Web didn't turn up any obvious answers.
I currently use portupgrade on all my FreeBSD installations, however, I
have noticed over time that a fair amount of detritus can build up in
${PREFIX}/lib/compat/pkg. So my questions are:-
1. Is there a tool like Gentoo's revdep-rebuild to force packages
depending on packaged libraries to be rebuilt?
2. Is there a more complete tool to clean orphaned libraries like
'portsclean -L' used to do?
Whilst I greatly appreciate the hard work and effort which the FreeBSD
ports maintainers put in to ensure shared library versions get bumped
when needed, this isn't always possible, as it requires keeping a sharp
eye out for 3rd party software packages which do the wrong thing, and
don't bump the major(s) when significant semantic changes happen inside
their libraries, or when the ABI changes.
[1] revdep-rebuild has very similar semantics to what I'm looking for,
as it will navigate the dependency graph for all packages installed on
the system, and rebuild packages where dependent libraries have changed.
To do the same with portupgrade alone, I need to know which port(s)
contain shared libraries, and tell it to go off and rebuild these
*specific* packages if things change.
[2] 'portsclean -L' used to do something :-) it does not appear to do
anything now.
I realize I could use libchk to discover which libraries are
unreferenced at load-time, however, a fair number of the libraries which
portupgrade moves into ${PREFIX}/lib/compat/pkg can potentially be
loaded by dlopen() at run-time.
Using libchk's output to remove unreferenced libraries isn't really an
option without significant post-processing of its output.
I would rather not rely on 'portupgrade -f -a -r', as this is going to
cause a *lot* of work on the affected systems.
Thanks for any help!
BMS
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: buildworld broken
Already dealt with, I was merging a change by hand whilst hungover after a good party. ;^) Sorry for the churn. A lot of this stuff gets utterly demolished and rebuilt in the IGMPv3 snap. I don't plan to backport the multicast work ongoing in p4 to 7-STABLE without testers, and air-out in 8-CURRENT first. One of the reasons it's taken so long is because there has been a *lot* of network stack re-engineering in 8-CURRENT (VIMAGE, arpv2, multi-fib, IFF_NEEDSGIANT removal). ASM state changes are believed working, but that is dog simple... Right now my aim is to get SSM working in the p4 branch fully. The IGMPv3 bottom half code is all done with the VIMAGE hooks, it's just a case of making the SSM state change stuff behave right. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Q: eSATA Hot Swap supported?
Hi, Does FreeBSD 7.1 support eSATA hot swappable disks? cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ext2fuse: user-space ext2 implementation
Paul B. Mahol wrote: Project itself doesnt look very active, but I may be wrong. It is in alpha state as reported on SF. IMHO it is better to maintain our own because it is in better shape, but I'm not intersted in ext* as developer. Shelved due to lack of interest, then... others can feel free to pick up. thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ext2fuse: user-space ext2 implementation
Paul B. Mahol wrote: On 12/8/08, Bruce M. Simpson b...@freebsd.org wrote: I have rolled a port for ext2fuse: http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar Ignoring fact that is buggy, slooow and port doesnt have any cache implemented and port leaves files behind in share/doc/ext2fuse when package deleted it looks fine. Can you please relay this feedback to the authors of ext2fuse? As mentioned earlier in the thread, the ext2fuse code could benefit from UBLIO-ization. Are you or any other volunteers happy to help out here? Can you elaborate further on the files being left behind by the port? I didn't see this issue in my own testing. thank you BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1-RC1 Available...
I've been tracking 7.1 on 3 separate machines since around September without any issues (1 server, 1 desktop, 1 laptop). Thank you for all your hard work on this. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression in vr - not receiveing multicast
Goran Lowkrantz wrote: Can you see ALLMULTI flag from the output of ifconfig vr0? No - # ifconfig vr0 vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=284bRXCSUM,TXCSUM,VLAN_MTU,POLLING,WOL_UCAST,WOL_MAGIC ether 00:00:24:c8:e0:9c inet xxx.xxx.xxx.xxx netmask 0xfff8 broadcast xxx.xxx.xxx.yyy media: Ethernet autoselect (100baseTX full-duplex) status: active Only a client of the MROUTING socket-level API (e.g. mrouted, XORP, pimdd, pimsd) is able to cause the kernel to enable ALLMULTI on an interface by itself. You will need to get a multicast routing daemon of some kind running to test this. mrouted is OK for testing very simple configurations, although it has been de-orbitted as far as the 'Net itself is concerned. thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
kern.ipc.maxpipekva exceeded; see tuning(7)
I just got lots and lots of this: kern.ipc.maxpipekva exceeded; see tuning(7) However, tuning(7) on my system has no information about this tunable whatsoever. anglepoise:~ % uname -a FreeBSD anglepoise.lon.incunabulum.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Tue Nov 4 15:40:44 GMT 2008 [EMAIL PROTECTED]:/home/obj/usr/src/sys/ANGLEPOISE7 amd64 anglepoise:~ % sysctl kern.ipc.maxpipekva kern.ipc.maxpipekva: 20971520 I was running a couple of copies of synergys at the time. After killing them, all seems fine, however this was causing most binaries on the system to error out with ENOMEM. Any ideas? BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC Request
Patrick Tracanelli wrote: Is it possible to have traceroute MFC'd for 7.1? I would like to have -a and -A switchs (ASN Path mapping) available. Thank you :) There's an AS lookup capable traceroute in ports: /usr/ports/net/ntraceroute is this insufficient for your needs? thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
