Re: Can't compile ath(4) into kernel
Please just create a PR for it. I haven't tried compiling ath without AR5416 support so I have no idea whether it'll work. adrian On 25 August 2010 22:03, Mikhail T. mi+th...@aldan.algebra.com wrote: 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 #options AH_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 ___ 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: igb related(?) panics on 7.3-STABLE
On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, with two igb nics in use. Previously the machine was fine, running earlier versions of 7-STABLE, although the load on the network has increased due to additional machines being added to the network (the machine functions as a fileserver, serving files to compute machines via NFS(v3)). Any advice is much appreciated. System info is below. Followup with more information. The machine just panic'ed again, with a lot of load on the network. Output from the 'systat' that was running at the time: 3 usersLoad 54.47 42.35 24.25 Aug 30 11:17 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 462325504 86814010548 943324 count All 4564847852 1074772k27740 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow 54220 total 1 170 392k8 278 22k 1951zfodsio0 irq4 ozfod fdc0 irq6 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle%ozfod27 twa0 uhci0 ||||||||||| daefr 2001 cpu0: time ===++ prcfr igb0 256 9938 dtbuf 1247 totfr igb0 257 Namei Name-cache Dir-cache10 desvn react igb0 258 Callshits %hits % 34443 numvn1 pdwak igb0 259 24996 frevn 112852 pdpgs igb0 262 intrn igb0 263 Disks da0 da1 pass0 pass1 2570672 wireigb0 264 KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 tps 026 0 014706896 inact 19449 igb1 266 MB/s 0.00 0.31 0.00 0.000 769796 26585 021 0 0 173528 -greg Machine: === FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 r...@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 Kernel was csup'd earlier in the day on 25 August, immediately prior to the build. Panic: == Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x8052f40c stack pointer = 0x10:0xff82056819d0 frame pointer = 0x10:0xff82056819f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x294 trap() at trap+0x106 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8052f40c, rsp = 0xff82056819d0, rbp = 0xff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c uma_zfree_arg() at uma_zfree_arg+0x41 m_freem() at m_freem+0x54 ether_demux() at ether_demux+0x85 ether_input() at ether_input+0x1bb igb_rxeof() at igb_rxeof+0x29d igb_handle_que() at igb_handle_que+0x9a taskqueue_run() at taskqueue_run+0xac taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x122 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8205681d30, rbp = 0 --- Uptime: 11h57m6s Physical memory: 18411 MB Dumping 3770 MB: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80188b5f stack pointer = 0x10:0xff82056811f0 frame pointer = 0x10:0xff82056812f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 12 pciconf: === i...@pci0:10:0:0: class=0x02 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet i...@pci0:10:0:1: class=0x02 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class
Re: Crashes on X7SPE-HF with em
Bcc: Subject: Re: igb related(?) panics on 7.3-STABLE Reply-To: In-Reply-To: 20100830094631.gd12...@core.byshenk.net On Mon, Aug 30, 2010 at 11:46:31AM +0200, Greg Byshenk wrote: On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, with two igb nics in use. Previously the machine was fine, running earlier versions of 7-STABLE, although the load on the network has increased due to additional machines being added to the network (the machine functions as a fileserver, serving files to compute machines via NFS(v3)). Any advice is much appreciated. System info is below. Followup with more information. The machine just panic'ed again, with a lot of load on the network. Output from the 'systat' that was running at the time: 3 usersLoad 54.47 42.35 24.25 Aug 30 11:17 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 462325504 86814010548 943324 count All 4564847852 1074772k27740 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow 54220 total 1 170 392k8 278 22k 1951zfodsio0 irq4 ozfod fdc0 irq6 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle%ozfod27 twa0 uhci0 ||||||||||| daefr 2001 cpu0: time ===++ prcfr igb0 256 9938 dtbuf 1247 totfr igb0 257 Namei Name-cache Dir-cache10 desvn react igb0 258 Callshits %hits % 34443 numvn1 pdwak igb0 259 24996 frevn 112852 pdpgs igb0 262 intrn igb0 263 Disks da0 da1 pass0 pass1 2570672 wireigb0 264 KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 tps 026 0 014706896 inact 19449 igb1 266 MB/s 0.00 0.31 0.00 0.000 769796 26585 021 0 0 173528 -greg Machine: === FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 r...@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 Kernel was csup'd earlier in the day on 25 August, immediately prior to the build. Panic: == Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x8052f40c stack pointer = 0x10:0xff82056819d0 frame pointer = 0x10:0xff82056819f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x294 trap() at trap+0x106 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8052f40c, rsp = 0xff82056819d0, rbp = 0xff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c uma_zfree_arg() at uma_zfree_arg+0x41 m_freem() at m_freem+0x54 ether_demux() at ether_demux+0x85 ether_input() at ether_input+0x1bb igb_rxeof() at igb_rxeof+0x29d igb_handle_que() at igb_handle_que+0x9a taskqueue_run() at taskqueue_run+0xac taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x122 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8205681d30, rbp = 0 --- Uptime: 11h57m6s Physical memory: 18411 MB Dumping 3770 MB: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80188b5f stack pointer = 0x10:0xff82056811f0 frame pointer = 0x10:0xff82056812f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 12 pciconf: ===
Re: Crashes on X7SPE-HF with em
On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote: Bcc: Subject: Re: igb related(?) panics on 7.3-STABLE Reply-To: In-Reply-To: 20100830094631.gd12...@core.byshenk.net On Mon, Aug 30, 2010 at 11:46:31AM +0200, Greg Byshenk wrote: On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, with two igb nics in use. Previously the machine was fine, running earlier versions of 7-STABLE, although the load on the network has increased due to additional machines being added to the network (the machine functions as a fileserver, serving files to compute machines via NFS(v3)). Any advice is much appreciated. System info is below. Followup with more information. The machine just panic'ed again, with a lot of load on the network. Output from the 'systat' that was running at the time: 3 usersLoad 54.47 42.35 24.25 Aug 30 11:17 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 462325504 86814010548 943324 count All 4564847852 1074772k27740 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Fltcow 54220 total 1 170 392k8 278 22k 1951zfod sio0 irq4 ozfod fdc0 irq6 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle%ozfod27 twa0 uhci0 ||||||||||| daefr 2001 cpu0: time ===++ prcfr igb0 256 9938 dtbuf 1247 totfr igb0 257 Namei Name-cache Dir-cache10 desvn react igb0 258 Callshits %hits % 34443 numvn1 pdwak igb0 259 24996 frevn 112852 pdpgs igb0 262 intrn igb0 263 Disks da0 da1 pass0 pass1 2570672 wire igb0 264 KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 tps 026 0 014706896 inact 19449 igb1 266 MB/s 0.00 0.31 0.00 0.000 769796 26585 021 0 0 173528 -greg Machine: === FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 r...@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 Kernel was csup'd earlier in the day on 25 August, immediately prior to the build. Panic: == Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x8052f40c stack pointer = 0x10:0xff82056819d0 frame pointer = 0x10:0xff82056819f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x294 trap() at trap+0x106 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8052f40c, rsp = 0xff82056819d0, rbp = 0xff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c uma_zfree_arg() at uma_zfree_arg+0x41 m_freem() at m_freem+0x54 ether_demux() at ether_demux+0x85 ether_input() at ether_input+0x1bb igb_rxeof() at igb_rxeof+0x29d igb_handle_que() at igb_handle_que+0x9a taskqueue_run() at taskqueue_run+0xac taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x122 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8205681d30, rbp = 0 --- Uptime: 11h57m6s Physical memory: 18411 MB Dumping 3770 MB: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80188b5f stack pointer = 0x10:0xff82056811f0 frame pointer = 0x10:0xff82056812f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long
Re: igb related(?) panics on 7.3-STABLE
On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote:
Bcc:
Subject: Re: igb related(?) panics on 7.3-STABLE
Reply-To:
In-Reply-To: 20100830094631.gd12...@core.byshenk.net
{snip}
My apologies -- somehow my mail client completely broke the Subject line
and pulled it from another thread. I'm not quite sure how mutt managed
to do that, but probably an extraneous newline when editing mail
headers, e.g. PEBKAC.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: Why is NFSv4 so slow?
On Sun, Aug 29, 2010 at 11:44:06AM -0400, Rick Macklem wrote: Hi. I'm still having problems with NFSv4 being very laggy on one client. When the NFSv4 server is at 50% idle CPU and the disks are 1% busy, I am getting horrible throughput on an idle client. Using dd(1) with 1 MB block size, when I try to read a 100 MB file from the client, I'm getting around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s with the same test (on a different file). On the broken client: Since other client(s) are working well, that seems to suggest that it is a network related problem and not a bug in the NFS code. Well I wouldn't say well. Every client I've set up has had this issue, and somehow through tweaking various settings and restarting nfs a bunch of times, I've been able to make it tolerable for most clients. Only one client is behaving well, and that happens to be the only machine I haven't rebooted since I enabled NFSv4. Other clients are seeing 2-3 MiB/s on my dd(1) test. I should point out that caching is an issue. The second time I run a dd on the same input file, I get upwards of 20-35 MiB/s on the bad client. But I can invalidate the cache by unmounting and remounting the file system so it looks like client-side caching. I'm not sure how you can say it's network-related and not NFS. Things worked just fine with NFSv3 (in fact NFSv3 client using the same NFSv4 server doesn't have this problem). Using rsync over ssh I get around 15-20 MiB/s throughput, and dd piped through ssh gets almost 40 MiB/s (neither one is using compression)! First off, the obvious question: How does this client differ from the one that performs much better? Different hardware (CPU, board, memory). I'm also hoping it was some sysctl tweak I did, but I can't seem to determine what it was. Do they both use the same re network interface for the NFS traffic? (If the answer is no, I'd be suspicious that the re hardware or device driver is the culprit.) That's the same thing you and others said about the *other* NFSv4 clients I set up. How is v4 that much different than v3 in terms of network traffic? The other clients are all using re0 and exactly the same ifconfig options and flags, including the client that's behaving fine. Things that I might try in an effort to isolate the problem: - switch the NFS traffic to use the nfe0 net interface. I'll consider it. I'm not convinced it's a NIC problem yet. - put a net interface identical to the one on the client that works well in the machine and use that for the NFS traffic. It's already close enough. Bad client: r...@pci0:1:7:0: class=0x02 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Single Gigabit LOM Ethernet Controller (RTL8110)' class = network subclass = ethernet Good client: r...@pci0:1:0:0: class=0x02 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet Mediocre client: r...@pci0:1:0:0: class=0x02 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet The mediocre and good clients have exactly identical hardware, and often I'll witness the slow client behavior on the mediocre client, and rarely on the good client although in previous emails to you, it was the good client which was behaving the worst of all. Other differences: good client = 8.1 GENERIC r210227M amd64 12GB RAM Athlon II X2 255 med. client = 8.1 GENERIC r209555M i386 4GB RAM Athlon II X2 255 bad client = 8.1 GENERIC r211534M i386 2GB RAM Athlon 64 X2 5200+ - turn off TXCSUM and RXCSUM on re0 Tried that, didn't help although it seemed to slow things down a little. - reduce the read/write data size, using rsize=N,wsize=N on the mount. (It will default to MAXBSIZE and some net interfaces don't handle large bursts of received data well. If you drop it to rsize=8192,wszie=8192 and things improve, then increase N until it screws up.) 8k didn't improve things at all. - check the port configuration on the switch end, to make sure it is also 1000bps-full duplex. It is, and has been. - move the client to a different net port on the switch or even a different switch (and change the cable, while you're at it). I've tried that too. The switches are great and my cables are fine. Like I said, NFSv3 on the same moint point works just fine (dd does around 30-35 MiB/s). - Look at netstat -s and see if there are a lot of retransmits going on in TCP. 2 of 40k TCP packets retransmitted, 7k of 40k duplicate acks received. I don't see anything else in netstat -s with numbers larger than 10. If none of the above seems to help, you
Re: Why is NFSv4 so slow?
Well I wouldn't say well. Every client I've set up has had this issue, and somehow through tweaking various settings and restarting nfs a bunch of times, I've been able to make it tolerable for most clients. Only one client is behaving well, and that happens to be the only machine I haven't rebooted since I enabled NFSv4. Other clients are seeing 2-3 MiB/s on my dd(1) test. All I can tell you is that, for my old hardware (100Mbps networking) I see 10Mbytes/sec (all you can hope for) using the regular NFSv3 client. I see about 10% slower for NFSv3 and NFSv4 using the experimental client (NFSv3 and NFSv4 about identical). The 10% doesn't surprise me, since the experimental client is based on a FreeBSD6 client and, although I plan on carrying all the newer client changes over to it, I haven't gotten around to doing that. If it is still 10% slower after the changes are carried over, I will be looking at why. I don't tune anything with sysctl, I just use what I get from an install from CD onto i386 hardware. (I don't even bother to increase kern.ipc.maxsockbuf although I suggest that in the mount message.) I also do not specify any mount options other than the protocol version. My mount commands look like: # mount -t nfs -o nfsv3 server:/path /mnt # mount -t newnfs -o nfsv3 server:/path /mnt # mount -t nfs -o nfsv4 server:/path /mnt So, I don't see dramatically slower NFSv4 and expect to get the 10% perf. reduction fixed when I bring the exp. client in line with the current one, but can't be sure. So, I have no idea what you are seeing. It might be an issue that will be fixed when I bring the exp. client up to date, but I have no idea if that's the case? (It will be a few months before the client update happens.) The only thing I can suggest is trying: # mount -t newnfs -o nfsv3 server:/path /mnt and seeing if that performs like the regukar NFSv3 or has the perf. issue you see for NFSv4? If this does have the perf. issue, then the exp. client is most likely the cause and may get better in a few months when I bring it up-to-date. rick ___ 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: Why is NFSv4 so slow?
On Sun, Aug 29, 2010 at 11:44:06AM -0400, Rick Macklem wrote: Hi. I'm still having problems with NFSv4 being very laggy on one client. When the NFSv4 server is at 50% idle CPU and the disks are 1% busy, I am getting horrible throughput on an idle client. Using dd(1) with 1 MB block size, when I try to read a 100 MB file from the client, I'm getting around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s with the same test (on a different file). On the broken client: Since other client(s) are working well, that seems to suggest that it is a network related problem and not a bug in the NFS code. Oh, one more thing...Make sure that the user and group name/number space is consistent across all machines and nfsuserd is working on them all. (Look at ls -lg on the clients and see that the correct user/group names are showing up.) If this mapping isn't working correctly, it will do an upcall to the userland nfsuserd for every RPC and that would make NFSv4 run very slowly. It will also use the domain part (after first '.') of each machine's hostname, so make sure that all the hostnames (all clients and server) are the same. ie: server.cis.uoguelph.ca, client1.cis.uoguelph.ca,... are all .cis.uoguelph.ca. If that is the problem # mount -t newnfs -o nfsv3 server:/path /mnt will work fine, since NFSv3 doesn't use the mapping daemon. Is that something easily scriptable with tcpdump? I'd rather not look for such things manually. I've always done this manually and, although tcpdump can be used to do the packet capture, wireshark actually understands NFS packets and, as such, is much better for looking at the packets. rick ___ 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
