cone segmentation fault on 8.0-STABLE amd64
Hi all, I'm running cone on 8.0-STABLE. When I run the program for the first time it works like a charm! Cone then creates a configuration directory and conerc. When I run cone the second time it crashed with a segmentation fault. Then after removing the OPTIONS node from the config file cone starts again. When I go to the setup menu and hit save also crashes with segfault. Any ideas? Cheers, Mark conerc: ?xml version=1.0? CONESERVER NAME=My E-mail URL=maildir:MaildirNAMESPACE PATH=INBOX:INBOX:M/NAMESPACE PATH=INBOX:INBOX:S//SERVERSERVER NAME=Online Tutorial URL=mbox:/usr/local/share/cone/cone.hlpNAMESPACE PATH=cone.hlp://SERVERADDRESSx...@/ADDRESSSMTP URL=/NNTP COMMAND=/DICTIONARY NAME=/OPTIONS DEMORONIZATION=MIN POSTANDMAIL=ASK SUSPEND= EDITOR= CUSTOMHEADERS= AUTOSAVE=60 GPGENCRYPTSIGNOPTIONS= GPGDECRYPTVERIFYOPTIONS= WATCHDAYS=14 WATCHDEPTH=5/COLORS fl_accountName=6 fl_accountType=5 fl_folderName=4 fl_folderDirName=3 fl_messageCount=2 md_headerName=6 md_headerContents=5 md_formatWarning=4 wm_headerName=6 perms_user=6 perms_group=5 perms_owner=4 perms_admins=3 perms_other=2 perms_rights=1 misc_promptColor=6 misc_inputField=5 misc_buttonColor=4 misc_menuTitle=3 misc_menuOption=2 misc_titleBar=1 misc_statusBar=0 misc_hotKey=7 misc_hotKeyDescr=6/TAG NAME=Important/TAG NAME=Work/TAG NAME=Personal/TAG NAME=To Do/TAG NAME=Later/TAG NAME=Custom1/TAG NAME=Custom2/TAG NAME=Custom3/TAG NAME=Custom4//CONE signature.asc Description: OpenPGP digital signature
Re: kernel MCA messages
on 25/08/2010 02:38 Jeremy Chadwick said the following: On Tue, Aug 24, 2010 at 07:13:23PM -0400, Dan Langille wrote: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 FYI, these are occurring every hour, almost to the second. e.g. xx:56:yy, where yy is 09, 10, or 11. Checking logs, I don't see anything that correlates with this point in the hour (i.e 56 minutes past) that doesn't also occur at other times. It seems very odd to occur so regularly. I still think that everything of essence has already been said in this thread. 1) Why haven't you replaced the DIMM in Bank 4 -- or better yet, all Bank 4 here is MCA reporting bank, it has nothing to do with RAM slots. Currently on FreeBSD we don't have a standard tool to map physical address to DRAM module, but I am sure that there could be some ways to do it. the DIMMs just to be sure? Do this and see if the problem goes away. If not, no harm done, and you've narrowed it down. 2) What exact manufacturer and model of motherboard is this? If you can provide a link to a User Manual that would be great. 3) Please go into your system BIOS and find where ECC ChipKill options are available (likely under a Memory, Chipset, or Northbridge section). Please write down and provide here all of the options and what their currently selected values are. 4) Please make sure you're running the latest system BIOS. I've seen on certain Rackable AMD-based systems where Northbridge-related features don't work quite right (at least with Solaris), resulting in atrocious memory performance on the system. A BIOS upgrade solved the problem. There's a ChipKill feature called ECC BG Scrubbing that's vague in definition, given that it's a background memory scrub that happens at intervals which are unknown to me. Maybe 60 minutes? I don't know. This is why I ask question #3. For John and other devs: I assume the decoded MCA messages indicate with absolute certainty that the ECC error is coming from external DRAM and not, say, bad L1 or L2 cache? Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. -- Andriy Gapon ___ 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
zfs sharenfs with multiple hosts/networks and options
Hi list, with traditional /etc/exports i can do /export/linux/root -ro xxx.xxx.xxx.0/24 /export/linux/root -maproot=0 xxx.xxx.xxx.1 How can i do this using zfs's sharenfs option? When i try zfs set sharenfs=-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1 data/linux/root /var/log/messages shows network/host conflict and bad exports list line. The general problem seems to be that with each zfs set sharenfs command, the corresponding in /etc/zfs/exports gets overwritten. Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? Thanks for any help, Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax :-3341 ___ 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: zfs sharenfs with multiple hosts/networks and options
On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: Hi list, with traditional /etc/exports i can do /export/linux/root-ro xxx.xxx.xxx.0/24 /export/linux/root-maproot=0 xxx.xxx.xxx.1 How can i do this using zfs's sharenfs option? When i try zfs set sharenfs=-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1 data/linux/root /var/log/messages shows network/host conflict and bad exports list line. The general problem seems to be that with each zfs set sharenfs command, the corresponding in /etc/zfs/exports gets overwritten. Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? Thanks for any help, In december '09 I started a thread about it in freebsd...@. Subject: zfs sharenfs to multiple subnets - found a dirty looking hack I found a dirty hack to do what you need there. Not sure there is a more elegant way to do it already, would be nice. Marco -- Now watch me snatch defeat from the jaws of victory - Rigoletto during a game on www.dailygammon.com ___ 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
typo error in /etc/defaults/rc.conf
Hello , Refers to rc.conf(5) the alternative way for cloning interfaces is by using create_args_interface variable In rc.conf there is a typo error in variable name --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.0 +0300 +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.0 +0300 @@ -212,7 +212,7 @@ #ifconfig_ed0_ipx=ipx 0x00010010 # Sample IPX address family entry. #ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0. #vlans_fxp0=101 vlan0# vlan(4) interfaces for fxp0 device -#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device +#create_args_vlan0=vlan 102 # vlan tag for vlan0 device #wlans_ath0=wlan0# wlan(4) interfaces for ath0 device #wlandebug_wlan0=scan+auth+assoc # Set debug flags with wlanddebug(8) #ipv4_addrs_fxp0=192.168.0.1/24 192.168.1.1-5/28 # example IPv4 address entry. ___ 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: zfs sharenfs with multiple hosts/networks and options
On 25.08.2010, at 10:03, Marco van Tol wrote: On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: Hi list, with traditional /etc/exports i can do /export/linux/root -ro xxx.xxx.xxx.0/24 /export/linux/root -maproot=0 xxx.xxx.xxx.1 How can i do this using zfs's sharenfs option? When i try zfs set sharenfs=-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1 data/linux/root /var/log/messages shows network/host conflict and bad exports list line. The general problem seems to be that with each zfs set sharenfs command, the corresponding in /etc/zfs/exports gets overwritten. Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? Thanks for any help, In december '09 I started a thread about it in freebsd...@. Subject: zfs sharenfs to multiple subnets - found a dirty looking hack I found a dirty hack to do what you need there. Not sure there is a more elegant way to do it already, would be nice. Marco I already found your hack (after starting this thread) and it does work. However, when i then use zfs to create a descendant filesystem, things go wrong because when inheriting the sharenfs property from the parent, zfs does not adjust the mountpoint that i used in the hack. Similar problems will probably arise if one choses to change the mountpoint of the filesystem afterwards. Thanks anyway for the hint! -Heinrich -- Now watch me snatch defeat from the jaws of victory - Rigoletto during a game on www.dailygammon.com ___ 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 Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax :-3341 ___ 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: typo error in /etc/defaults/rc.conf
Fixed. Thanks for the patch. On Wed, 25 Aug 2010, 11:05+0300, Bojidara Marinchovska wrote: Hello , Refers to rc.conf(5) the alternative way for cloning interfaces is by using create_args_interface variable In rc.conf there is a typo error in variable name --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.0 +0300 +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.0 +0300 @@ -212,7 +212,7 @@ #ifconfig_ed0_ipx=ipx 0x00010010 # Sample IPX address family entry. #ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0. #vlans_fxp0=101 vlan0# vlan(4) interfaces for fxp0 device -#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device +#create_args_vlan0=vlan 102 # vlan tag for vlan0 device #wlans_ath0=wlan0# wlan(4) interfaces for ath0 device #wlandebug_wlan0=scan+auth+assoc # Set debug flags with wlanddebug(8) #ipv4_addrs_fxp0=192.168.0.1/24 192.168.1.1-5/28 # example IPv4 address entry. ___ 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 -- Maxim Konovalov ___ 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 MCA messages
On Tue, Aug 24, 2010 at 4:06 PM, John Baldwin j...@freebsd.org wrote: On Monday, August 23, 2010 5:35:40 pm Matthew D. Fuller wrote: On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: It is not private, it is in //depot/projects/mcelog/... in p4. Which may as well be Siberia for us lowly non-developers. Any chance you could stick a tarball or a patch against upstream mcelog somewhere? It is actually public at perforce.freebsd.org. :) However, it is tedious to download the files. It really should be a port perhaps, though Someone (tm) should try to get the patches integrated upstream. You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also need to download the memstream.c file from there as well and put that in the extracted mcelog tarball. I wrote a small script a while back to extract a tree from perforce using the web interface, might be handy: http://www.clearchain.com/~benjsc/downloads/FreeBSD/P4fetch.rb Cheers Tom ___ 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 MCA messages
On 8/25/2010 3:11 AM, Andriy Gapon wrote: Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. Andriy: What is your interpretation of the decoded message? What is your view on replacing DRAM? What do you conclude from the summary? -- Dan Langille - http://langille.org/ ___ 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 MCA messages
on 25/08/2010 13:41 Dan Langille said the following: On 8/25/2010 3:11 AM, Andriy Gapon wrote: Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. Andriy: What is your interpretation of the decoded message? What is your view on replacing DRAM? What do you conclude from the summary? Most likely you have a small defect in one of your memory modules, perhaps a stuck bit. You will be getting correctable ECC errors for that module. Eventually you might get uncorrectable error. That may happen soon or it may never happen during lifetime of that modules. As that study has demonstrated a significant percentage of systems and modules report at least one correctable ECC error. ECC correctable errors at present correlate with correctable ECC errors in the future. They also correlate with uncorrectable errors in the future. But percentage of systems developing uncorrectable errors is significantly smaller, so chances of false positives are substantial. You should decide whether you want to replace the module (if you can pinpoint it) or all modules depending on your resources (money, etc), importance of service that the server in question provides (allowable downtime and cost of it and fault-tolerance of a larger system, of which the server may be a part (e.g. it may have a standby server for failover). I think that most of what I've just said was kind of obvious from the start. The important bit from that study is that ECC errors are not as random and as rare as was previously thought, and they can be attributed to a number of factors like manufacturing defects, layout of memory lanes on motherboard, etc. -- Andriy Gapon ___ 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
Can't compile ath(4) into kernel
My laptop's kernel config file reads: device wlan# 802.11 support device ath device ath_ar5212 device ath_rate_onoe Config raises no objections and the compilation succeeds, but linking the kernel breaks: ... linking kernel.debug ah.o(.text+0x218): In function `ath_hal_rfprobe': /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' *** Error code 1 What could this be? All modules (including ath_hal) build correctly... Thank you! -mi ___ 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 MCA messages
On Wednesday, August 25, 2010 12:05:09 am Matthew D. Fuller wrote: On Tue, Aug 24, 2010 at 11:06:43AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: It is actually public at perforce.freebsd.org. :) However, it is tedious to download the files. Oh, I'd apparently blocked out of my mind that you could clicky-clicky files one at a time from there. Probably for the best; I'd be real annoyed by the end of that ;) You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also need to download the memstream.c file from there as well and put that in the extracted mcelog tarball. Thanks! For anyone following along at home, I needed to make a few changes to get it compiling here: - I'm on a nice recent -CURRENT, so I had to #if 0 out the getline() definition. Yeah, that needs a __FreeBSD_version wrapper. - Add a FREEBSD definition to the Makefile (or remember it manually). I just do 'gmake FREEBSD=yes'. - Comment out the kread_symbol() of X_SNAPDATE in mcelog.c. I don't see X_SNAPDATE defined anywhere in my /usr/include, and the var doesn't seem to ever actually be read for anything anyway (unless I'm supposed to -DLOCAL_HACK...). Bah, I must have missed that. You certainly don't want LOCAL_HACK. -- John Baldwin ___ 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 MCA messages
On Tuesday, August 24, 2010 7:13:23 pm Dan Langille wrote: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 FYI, these are occurring every hour, almost to the second. e.g. xx:56:yy, where yy is 09, 10, or 11. Checking logs, I don't see anything that correlates with this point in the hour (i.e 56 minutes past) that doesn't also occur at other times. It seems very odd to occur so regularly. That is because machine checks for corrected errors have to be polled and the kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a separate interrupt (CMCI) that can fire for corrected errors. -- John Baldwin ___ 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: Can't compile ath(4) into kernel
On Wednesday, August 25, 2010 12:39:40 am Mikhail T. wrote: My laptop's kernel config file reads: device wlan# 802.11 support device ath device ath_ar5212 device ath_rate_onoe Config raises no objections and the compilation succeeds, but linking the kernel breaks: ... linking kernel.debug ah.o(.text+0x218): In function `ath_hal_rfprobe': /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' *** Error code 1 What could this be? All modules (including ath_hal) build correctly... Thank you! You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors For the 6.x - 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list. -- John Baldwin ___ 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 MCA messages
On Wednesday, August 25, 2010 7:01:19 am Andriy Gapon wrote: on 25/08/2010 13:41 Dan Langille said the following: On 8/25/2010 3:11 AM, Andriy Gapon wrote: Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. Andriy: What is your interpretation of the decoded message? What is your view on replacing DRAM? What do you conclude from the summary? Most likely you have a small defect in one of your memory modules, perhaps a stuck bit. You will be getting correctable ECC errors for that module. Eventually you might get uncorrectable error. That may happen soon or it may never happen during lifetime of that modules. As that study has demonstrated a significant percentage of systems and modules report at least one correctable ECC error. ECC correctable errors at present correlate with correctable ECC errors in the future. They also correlate with uncorrectable errors in the future. But percentage of systems developing uncorrectable errors is significantly smaller, so chances of false positives are substantial. You should decide whether you want to replace the module (if you can pinpoint it) or all modules depending on your resources (money, etc), importance of service that the server in question provides (allowable downtime and cost of it and fault-tolerance of a larger system, of which the server may be a part (e.g. it may have a standby server for failover). I think that most of what I've just said was kind of obvious from the start. The important bit from that study is that ECC errors are not as random and as rare as was previously thought, and they can be attributed to a number of factors like manufacturing defects, layout of memory lanes on motherboard, etc. A while back I found a slide deck from some Intel presentation that claimed that a modern 4GB DIMM should average 18 corrected errors a month. Your rate is a bit higher than that, but corrected ECC errors are not that unexpected. -- John Baldwin ___ 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 MCA messages
on 25/08/2010 15:23 John Baldwin said the following: That is because machine checks for corrected errors have to be polled and the kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a separate interrupt (CMCI) that can fire for corrected errors. I think that on AMD it's possible to configure an interrupt for Bank 4 events as well (perhaps other banks too), but I need to refresh my memory of BKDG. -- Andriy Gapon ___ 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 MCA messages
on 25/08/2010 18:02 Andriy Gapon said the following: on 25/08/2010 15:23 John Baldwin said the following: That is because machine checks for corrected errors have to be polled and the kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a separate interrupt (CMCI) that can fire for corrected errors. I think that on AMD it's possible to configure an interrupt for Bank 4 events as well (perhaps other banks too), but I need to refresh my memory of BKDG. Yeah, for Bank 4 only, configurable via MSR_0413 and MSRC000_04[0A:08] Machine Check Misc 4 (Thresholding) Registers. Also, see section 2.12.1.6 Error Thresholding in Fam10h BKDG. -- Andriy Gapon ___ 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: Can't compile ath(4) into kernel
On 8/25/2010 8:27 AM, John Baldwin wrote: You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors But I don't have the ar5416 chipset... Mine is AR2312... And it is an option, so should not it be optional? Anyway, I tried adding that option and the error is the same (did cleandepend depend, saw ah.c recompiled anew). For the 6.x - 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list Thanks, I did that. After several attempts to fiddle with options/devices, the wireless section now looks like: # Wireless NIC cards device wlan# 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath device ath_rate_sample # SampleRate tx rate control for ath device ath_ar5212 #device ath_rate_onoe #optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that picking out a single driver should work... -mi ___ 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
