Re: ath driver transmits frames only after a low watermark is filled
How is data transmission related to power management? They are pretty intimately related over a wireless link. If the power management at one end decided it can use less transmit power and gets it wrong then your data stops getting through. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. Note that increasing kern.polling.burst_max and kern.polling.each_burst will also increase the number of soft interrupts. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. I thought setting kern.polling.idle_poll would allow the CPU to utilise all idle time. The downside is that the system always shows as 100% utilised so it's very difficult to know how busy the system actually is. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). -- Peter Jeremy pgpMPGKdXFs4w.pgp Description: PGP signature
NVIDIA 6600GT Freeze
I have a problem with my system freezing when using an NVIDIA video card using the nvidia-driver port. All seems to work fine for a while but then the system freezes and won't even reply to a ping. This can happen regardless of whether I use openGL or not. Everything works fine using the nv driver, so it doesn't seem to be a hardware problem. My setup is as follows: uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 11:19:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER i386 AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. The NVIDIA driver is installed as per the instructions, with agp and dri removed from the kernel in order to use the NVIDIA agp interface, even though the sysctl settings suggest otherwise. If anyone has any ideas about this problem I'd be very grateful. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
Peter Jeremy wrote: On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. Note that increasing kern.polling.burst_max and kern.polling.each_burst will also increase the number of soft interrupts. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. I thought setting kern.polling.idle_poll would allow the CPU to utilise all idle time. The downside is that the system always shows as 100% utilised so it's very difficult to know how busy the system actually is. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). This might not apply to bge, but the adaptive polling + fast interrupt changes that I made to if_em earlier in the year were a huge win over the standard polling code in terms of CPU utilization and packets per second. I think it also survived a load that caused normal polling to essentially livelock the machine. And, it had the advantage of automatically adapting to bursty loads. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath driver transmits frames only after a low watermark is filled
Pete French wrote: How is data transmission related to power management? They are pretty intimately related over a wireless link. If the power management at one end decided it can use less transmit power and gets it wrong then your data stops getting through. Your posting truncated the note but what the person was suggesting was the station was operating in power save mode and so deferring transmits to the ap. Unfortunately that's not possible as HEAD has no support for sta-side power save.mode for ath. The original posting didn't provide any basic info so there's little anyone can provide except wild guesses. There are debugging mechanisms for tracing what's going on at the net80211 layer and in the driver that have been referenced countless times in this forum. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panic with PF
Hello,
I am deploying FreeBSD based application proxies' based firewall
(www.kernun.com, but not much English there) and am having frequent
panics of RELENG_6_1 under load. The server has IP forwarding disabled.
I've got two machines in a carp cluster and the transparent proxies use
PF to get the data.
I don't know much about kernel internals and PF but from the following
backtrace I understand that the crash happens because rpool-cur on line
2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It
probably shouldn't happen yet it does.
The machines are SMP and were running SMP kernel. The only places where
pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there
are some lock operations though so it is probably believed that the
coder is properly locked.
I have been running with kern.smp.disabled=1 for a moment before I put
the old firewall in place and haven't seen the panic but the time was
deffinitely too short to make me believe it fixes the issue. Can setting
debug.mpsafenet to 0 possibly also help?
I could probably bandaid this particular failure mode by returning
failure instead of panicing but the bug is probably elsewhere.
I've lost the debug kernel from which this backtrace is and can't
therefore continue much :-(. Unfortunately so far I can only reproduce
the problem in production and for obvious reasons I can't put it there.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0x801ab528
stack pointer = 0x10:0xb1ade650
frame pointer = 0x10:0xff004cc7cc30
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 = 15 (swi1: net)
trap number = 12
panic: page fault
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x803d5137 in boot (howto=260)
at ../../../kern/kern_shutdown.c:402
#3 0x803d58a1 in panic (fmt=0xff007ba32000 @\223A3{)
at ../../../kern/kern_shutdown.c:558
#4 0x80543b3f in trap_fatal (frame=0xff007ba32000,
eva=18446742976272241472) at ../../../amd64/amd64/trap.c:660
#5 0x80543e5f in trap_pfault (frame=0xb1ade5a0,
usermode=0)
at ../../../amd64/amd64/trap.c:573
#6 0x80544113 in trap (frame=
{tf_rdi = 2, tf_rsi = -1098223465792, tf_rdx = -1098439497700,
tf_rcx = -1
314002464, tf_r8 = 0, tf_r9 = -1314002776, tf_rax = 0, tf_rbx = 0,
tf_rbp = -109
8223465424, tf_r10 = 1, tf_r11 = 257, tf_r12 = -1098439497700, tf_r13 =
-1314002
776, tf_r14 = 2, tf_r15 = -1314002464, tf_trapno = 12, tf_addr = 40,
tf_flags =
216171684640539392, tf_err = 0, tf_rip = -214576, tf_cs = 8,
tf_rflags = 661
18, tf_rsp = -1314003360, tf_ss = 16})
at ../../../amd64/amd64/trap.c:352
#7 0x8052feab in calltrap ()
at ../../../amd64/amd64/exception.S:168
#8 0x801ab528 in pf_map_addr (af=2 '\002',
r=0xff004cc7cac0,
saddr=0xff003fe7681c, naddr=0xb1ade9e0, init_addr=0x0,
sn=0xb1ade8a8) at ../../../contrib/pf/net/pf.c:2163
#9 0x801acab6 in pf_get_translation (pd=0xb1ade9c0,
m=0xff0042ede900, off=20, direction=1, kif=0xff007b038a00,
sn=0xb1ade8a8, saddr=0xff003fe7681c, sport=0,
daddr=0xff003fe76820, dport=50881, naddr=0xb1ade9e0,
nport=0xb1ade8b6) at ../../../contrib/pf/net/pf.c:2618
#10 0x801b315b in pf_test_tcp (rm=0xb1ade960,
sm=0xb1ade950, direction=1, kif=0xff007b038a00,
m=0xff0042ede900, off=20, h=0xff003fe76810,
pd=0xb1ade9c0, am=0xb1ade968,
rsm=0xb1ade970,
ifq=0x2, inp=0x0) at ../../../contrib/pf/net/pf.c:3013
#11 0x801b5694 in pf_test (dir=1, ifp=0xffbee800,
m0=0xb1adeaa0, eh=0xb1ade97e, inp=0x0)
at ../../../contrib/pf/net/pf.c:6449
#12 0x801bafb2 in pf_check_in (arg=0x2, m=0xb1adeaa0,
ifp=0xff004cc7cac0, dir=-1314002464, inp=0xb1ade9e0)
at ../../../contrib/pf/net/pf_ioctl.c:3358
#13 0x80461c2e in pfil_run_hooks (ph=0x807e0920,
mp=0xb1adeb28, ifp=0xffbee800, dir=1, inp=0x0)
at ../../../net/pfil.c:139
#14 0x8048d225 in ip_input (m=0xff0042ede900)
at ../../../netinet/ip_input.c:465
#15 0x8046180c in netisr_processqueue (ni=0x807df690)
at ../../../net/netisr.c:236
#16 0x80461abd in swi_net (dummy=0x2)
at ../../../net/netisr.c:349
#17 0x803bbd99 in ithread_loop (arg=0xff0506a0)
at ../../../kern/kern_intr.c:684
#18 0x803ba527 in fork_exit (
callout=0x803bbc50 ithread_loop, arg=0xff0506a0,
frame=0xb1adec50) at ../../../kern/kern_fork.c:805
Re: Kernel panic with PF
Michal Mertl wrote: Hello, I am deploying FreeBSD based application proxies' based firewall (www.kernun.com, but not much English there) and am having frequent panics of RELENG_6_1 under load. The server has IP forwarding disabled. I've got two machines in a carp cluster and the transparent proxies use PF to get the data. I don't know much about kernel internals and PF but from the following backtrace I understand that the crash happens because rpool-cur on line 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It probably shouldn't happen yet it does. The machines are SMP and were running SMP kernel. The only places where pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there are some lock operations though so it is probably believed that the coder is properly locked. I have been running with kern.smp.disabled=1 for a moment before I put the old firewall in place and haven't seen the panic but the time was deffinitely too short to make me believe it fixes the issue. Can setting debug.mpsafenet to 0 possibly also help? ... Are you using user and/or group rules in your PF ruleset? If so, then you will want to set debug.mpsafenet to 0 as its a known issue with pf(4) currently. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath driver transmits frames only after a low watermark is filled
The original posting didn't provide any basic info so there's little anyone can provide except wild guesses. There are debugging mechanisms for tracing what's going on at the net80211 layer and in the driver that have been referenced countless times in this forum. Sorry, didn't know it could be hardware-related. What info do you need? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA 6600GT Freeze
On Thursday 20 July 2006 06:51, Nealie wrote: I have a problem with my system freezing when using an NVIDIA video card using the nvidia-driver port. All seems to work fine for a while but then the system freezes and won't even reply to a ping. This can happen regardless of whether I use openGL or not. Everything works fine using the nv driver, so it doesn't seem to be a hardware problem. My setup is as follows: uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 11:19:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER i386 AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. The NVIDIA driver is installed as per the instructions, with agp and dri removed from the kernel in order to use the NVIDIA agp interface, even though the sysctl settings suggest otherwise. If anyone has any ideas about this problem I'd be very grateful. This probably isn't very helpful but I have nearly the exact same setup and it works fine. The only differences I see is that I'm running 6.1-RELEASE and my motherboard is an asus based on the K8T800 chipset. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Major problem with make buildworld 6.1-STABLE
I didn't like how my partitions were set up so I decided to reinstall 6.1from scratch, but now I cannot finish a buildworld no matter what I do. In order, I've: 1. Installed 6.1-RELEASE from ftp on fresh partitions 1a. installed cvsup and perl-5.8.8 from /usr/ports 2. edit cvsup11 into /usr/share/examples/cvsup/stable-supfile 3. cvsup /usr/share/examples/cvsup/stable-supfile 4. rm -rf /usr/obj/* 5. cd /usr/src/; 6. make clean make clean 7. make buildworld and I get: cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-omit-frame-pointer -fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:65: /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h: In function `const dwarf_cie* get_cie(const dwarf_fde*)': /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:159: error: pointer of type `void *' used in arithmetic /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:159: error: invalid conversion from `void*' to `const dwarf_cie*' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c: In function `void __do_global_dtors_aux()': /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:258: error: `_Bool' does not name a type /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:261: error: `completed' undeclared (first use this function) /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:261: error: (Each undeclared identifier is reported only once for each function it appears in.) *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This is the first time I ran just make buildworld:. I've tried this several times with make -j4 buildworld, but the build always dies while making libgcc instead of crtstuff. I've reinstalled from ftp again (and again) and always the same. Is there a bug in the stable sources? Am I missing something? Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic with PF
Michael Proto wrote: Michal Mertl wrote: Hello, I am deploying FreeBSD based application proxies' based firewall (www.kernun.com, but not much English there) and am having frequent panics of RELENG_6_1 under load. The server has IP forwarding disabled. I've got two machines in a carp cluster and the transparent proxies use PF to get the data. I don't know much about kernel internals and PF but from the following backtrace I understand that the crash happens because rpool-cur on line 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It probably shouldn't happen yet it does. The machines are SMP and were running SMP kernel. The only places where pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there are some lock operations though so it is probably believed that the coder is properly locked. I have been running with kern.smp.disabled=1 for a moment before I put the old firewall in place and haven't seen the panic but the time was deffinitely too short to make me believe it fixes the issue. Can setting debug.mpsafenet to 0 possibly also help? ... Are you using user and/or group rules in your PF ruleset? If so, then you will want to set debug.mpsafenet to 0 as its a known issue with pf(4) currently. Thank you. No, I am not using it and I am quite sure the proxies aren't doing it behind my back either. In fact there isn't a single entry in the rules tables - there are only rdr rules generated on the fly by the proxies. I will try to set this (in addition to running UP) to see whether it helps anyway. Thanks Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
scan stuck with if_iwi(4)
Hi, I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE after which the if_iwi(4) driver started dropping the connection at regular intervals when connected to my hostapd-based AP using WPA2 PSK CCMP. The dmesg output with debug.iwi=4 is listed below - it fails regularly (every 3 mins or so) with the message scan stuck after which the adapter is reinitialized and the connection lost for some seconds. The connection drop seems to be caused by the adapter suddently entering the SCAN state. I have been unable to reproduce this problem with 6.1-RELEASE. $ uname -a FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 18 11:16:02 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Jul 20 23:38:04 fangorn kernel: iwi0: Intel(R) PRO/Wireless 2915ABG mem 0xc020-0xc0200fff irq 11 at device 2.0 on pci2 Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94 ... Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 = 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 = 7 Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN - SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x13 Jul 21 00:20:24 fangorn kernel: Start scanning Jul 21 00:20:24 fangorn kernel: sending command idx=5 type=26 len=96 Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 = 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 = 7 Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN - INIT flags 0x0 Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94 Jul 21 00:20:31 fangorn kernel: sending command idx=0 type=11 len=6 Jul 21 00:20:31 fangorn kernel: Configuring adapter Jul 21 00:20:31 fangorn kernel: sending command idx=1 type=6 len=20 Jul 21 00:20:31 fangorn kernel: Setting power mode to 0 Jul 21 00:20:31 fangorn kernel: sending command idx=2 type=17 len=4 Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=3 type=15 len=4 Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=4 type=16 len=4 Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12) Jul 21 00:20:31 fangorn kernel: sending command idx=5 type=22 len=16 Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8) Jul 21 00:20:31 fangorn kernel: sending command idx=6 type=22 len=16 Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139 Jul 21 00:20:31 fangorn kernel: sending command idx=7 type=34 len=4 Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=8 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=9 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=10 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=11 type=18 len=20 Jul 21 00:20:31 fangorn kernel: Enabling adapter Jul 21 00:20:31 fangorn kernel: sending command idx=12 type=2 len=0 Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x5 Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x3 Jul 21 00:20:31 fangorn kernel: Start scanning Jul 21 00:20:31 fangorn kernel: sending command idx=13 type=26 len=96 Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36) Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40) Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44) Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48) Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52) Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56) Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60) Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64) Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149) Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153) Jul 21 00:20:32 fangorn kernel: Scan of channel 5785 complete (157) Jul 21 00:20:32 fangorn kernel: Scan of channel 5805 complete (161) Jul 21 00:20:32 fangorn kernel: Scan of channel 5825 complete (165) Jul 21 00:20:32 fangorn kernel: Scan of channel 2412 complete (1) Jul 21 00:20:32 fangorn kernel: Scan of channel 2417 complete (2) Jul 21 00:20:32 fangorn kernel: Scan of channel 2422 complete (3) Jul 21 00:20:32 fangorn kernel: Scan of channel 2427 complete (4) Jul 21 00:20:33 fangorn kernel: Scan of channel 2432 complete (5) Jul 21 00:20:33 fangorn kernel: Scan of channel 2437 complete (6) Jul 21 00:20:33 fangorn kernel: Scan of channel 2442 complete (7) Jul 21 00:20:33 fangorn kernel: Scan
Re: scan stuck with if_iwi(4)
The iwi code was recently MFC and it required a port change iwi-firmware - iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Mark B.T.W. the new code is more stable for me. No more complete machine lockups. The WiFi led now binks though if you turn the radio off it stays lit / off depending apon the state it was in at the time. This is still better than not lighting at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote:
Hi,
I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE
after which the if_iwi(4) driver started dropping the connection at
regular intervals when connected to my hostapd-based AP using WPA2 PSK
CCMP.
The dmesg output with debug.iwi=4 is listed below - it fails regularly
(every 3 mins or so) with the message scan stuck after which the
adapter is reinitialized and the connection lost for some seconds.
The connection drop seems to be caused by the adapter suddently
entering the SCAN state.
I have been unable to reproduce this problem with 6.1-RELEASE.
You will not be able to reproduce the problem because the code in 6.1R
ignored beacon misses (and a lot of other things).
The stuck scan is not fatal; the driver just resets the card. It's
caused by a firwmare problem that I never got around to dealing with
('cuz it wouldn't change the overall operation of the driver).
The basic problem is your card is losing sync w/ the ap. I don't know
what the local conditions are but I've seen this a lot w/ iwi; there's
nothing we can do in the driver if you want to be able to roam.
Sam
$ uname -a
FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 18
11:16:02 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
Jul 20 23:38:04 fangorn kernel: iwi0: Intel(R) PRO/Wireless 2915ABG mem
0xc020-0xc0200fff irq 11 at device 2.0 on pci2
Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94
...
Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 = 7
Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 = 7
Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN - SCAN flags 0x11
Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN
Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x11
Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x13
Jul 21 00:20:24 fangorn kernel: Start scanning
Jul 21 00:20:24 fangorn kernel: sending command idx=5 type=26 len=96
Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 = 7
Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 = 7
Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck
Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN - INIT flags 0x0
Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94
Jul 21 00:20:31 fangorn kernel: sending command idx=0 type=11 len=6
Jul 21 00:20:31 fangorn kernel: Configuring adapter
Jul 21 00:20:31 fangorn kernel: sending command idx=1 type=6 len=20
Jul 21 00:20:31 fangorn kernel: Setting power mode to 0
Jul 21 00:20:31 fangorn kernel: sending command idx=2 type=17 len=4
Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346
Jul 21 00:20:31 fangorn kernel: sending command idx=3 type=15 len=4
Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346
Jul 21 00:20:31 fangorn kernel: sending command idx=4 type=16 len=4
Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12)
Jul 21 00:20:31 fangorn kernel: sending command idx=5 type=22 len=16
Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8)
Jul 21 00:20:31 fangorn kernel: sending command idx=6 type=22 len=16
Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139
Jul 21 00:20:31 fangorn kernel: sending command idx=7 type=34 len=4
Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=8 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=9 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=10 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0
Jul 21 00:20:31 fangorn kernel: sending command idx=11 type=18 len=20
Jul 21 00:20:31 fangorn kernel: Enabling adapter
Jul 21 00:20:31 fangorn kernel: sending command idx=12 type=2 len=0
Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x5
Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x3
Jul 21 00:20:31 fangorn kernel: Start scanning
Jul 21 00:20:31 fangorn kernel: sending command idx=13 type=26 len=96
Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60)
Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153)
Jul 21 00:20:32 fangorn kernel: Scan of channel 5785
Re: Kernel panic with PF
[CC'ing -pf]
On Thursday 20 July 2006 17:53, Michal Mertl wrote:
Hello,
I am deploying FreeBSD based application proxies' based firewall
(www.kernun.com, but not much English there) and am having frequent
panics of RELENG_6_1 under load. The server has IP forwarding disabled.
I've got two machines in a carp cluster and the transparent proxies use
PF to get the data.
Which proxies are you using? The pool_ticket: 1429 != 1430 messages you
quote below indicate a synchronization problem within the app talking to pf
via ioctl's. Tickets are used to ensure atomic commits for operations that
require more than one ioctl. If your proxy app runs in parallel it might
screw up the internal state and thus leave it undefined afterwards. I give
you that this shouldn't cause a kernel problem, but if we could fix the app
we can probably find the right sanity check more easily.
I don't know much about kernel internals and PF but from the following
backtrace I understand that the crash happens because rpool-cur on line
2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It
probably shouldn't happen yet it does.
The machines are SMP and were running SMP kernel. The only places where
pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there
are some lock operations though so it is probably believed that the
coder is properly locked.
I have been running with kern.smp.disabled=1 for a moment before I put
the old firewall in place and haven't seen the panic but the time was
deffinitely too short to make me believe it fixes the issue. Can setting
debug.mpsafenet to 0 possibly also help?
I could probably bandaid this particular failure mode by returning
failure instead of panicing but the bug is probably elsewhere.
I've lost the debug kernel from which this backtrace is and can't
therefore continue much :-(. Unfortunately so far I can only reproduce
the problem in production and for obvious reasons I can't put it there.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0x801ab528
stack pointer = 0x10:0xb1ade650
frame pointer = 0x10:0xff004cc7cc30
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 = 15 (swi1: net)
trap number = 12
panic: page fault
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x803d5137 in boot (howto=260)
at ../../../kern/kern_shutdown.c:402
#3 0x803d58a1 in panic (fmt=0xff007ba32000 @\223A3{)
at ../../../kern/kern_shutdown.c:558
#4 0x80543b3f in trap_fatal (frame=0xff007ba32000,
eva=18446742976272241472) at ../../../amd64/amd64/trap.c:660
#5 0x80543e5f in trap_pfault (frame=0xb1ade5a0,
usermode=0)
at ../../../amd64/amd64/trap.c:573
#6 0x80544113 in trap (frame=
{tf_rdi = 2, tf_rsi = -1098223465792, tf_rdx = -1098439497700,
tf_rcx = -1
314002464, tf_r8 = 0, tf_r9 = -1314002776, tf_rax = 0, tf_rbx = 0,
tf_rbp = -109
8223465424, tf_r10 = 1, tf_r11 = 257, tf_r12 = -1098439497700, tf_r13 =
-1314002
776, tf_r14 = 2, tf_r15 = -1314002464, tf_trapno = 12, tf_addr = 40,
tf_flags =
216171684640539392, tf_err = 0, tf_rip = -214576, tf_cs = 8,
tf_rflags = 661
18, tf_rsp = -1314003360, tf_ss = 16})
at ../../../amd64/amd64/trap.c:352
#7 0x8052feab in calltrap ()
at ../../../amd64/amd64/exception.S:168
#8 0x801ab528 in pf_map_addr (af=2 '\002',
r=0xff004cc7cac0,
saddr=0xff003fe7681c, naddr=0xb1ade9e0, init_addr=0x0,
sn=0xb1ade8a8) at ../../../contrib/pf/net/pf.c:2163
#9 0x801acab6 in pf_get_translation (pd=0xb1ade9c0,
m=0xff0042ede900, off=20, direction=1, kif=0xff007b038a00,
sn=0xb1ade8a8, saddr=0xff003fe7681c, sport=0,
daddr=0xff003fe76820, dport=50881, naddr=0xb1ade9e0,
nport=0xb1ade8b6) at ../../../contrib/pf/net/pf.c:2618
#10 0x801b315b in pf_test_tcp (rm=0xb1ade960,
sm=0xb1ade950, direction=1, kif=0xff007b038a00,
m=0xff0042ede900, off=20, h=0xff003fe76810,
pd=0xb1ade9c0, am=0xb1ade968,
rsm=0xb1ade970,
ifq=0x2, inp=0x0) at ../../../contrib/pf/net/pf.c:3013
#11 0x801b5694 in pf_test (dir=1, ifp=0xffbee800,
m0=0xb1adeaa0, eh=0xb1ade97e, inp=0x0)
at ../../../contrib/pf/net/pf.c:6449
#12 0x801bafb2 in pf_check_in (arg=0x2, m=0xb1adeaa0,
ifp=0xff004cc7cac0, dir=-1314002464, inp=0xb1ade9e0)
at ../../../contrib/pf/net/pf_ioctl.c:3358
#13 0x80461c2e in pfil_run_hooks
Re: Kernel panic with PF
On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote: Which proxies are you using? The pool_ticket: 1429 != 1430 messages you quote below indicate a synchronization problem within the app talking to pf via ioctl's. Tickets are used to ensure atomic commits for operations that require more than one ioctl. If your proxy app runs in parallel it might screw up the internal state and thus leave it undefined afterwards. I give you that this shouldn't cause a kernel problem, but if we could fix the app we can probably find the right sanity check more easily. This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE if (newrule-action == PF_NAT) || (newrule-action == PF_RDR) || (newrule-action == PF_BINAT) || (newrule-rt PF_FASTROUTE)) - !pcr-anchor[0])) + !newrule-anchor)) (TAILQ_FIRST(newrule-rpool.list) == NULL)) error = EINVAL; i.e. the pool must not be empty for routing and translation rules, except for translation rules that are actually anchor _calls_. The confusion is between translation rules within anchors (pcr-anchor[0] != '\0') and calls to anchors' translation rules (rule-anchor != NULL). If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't using it at all), AND is trying to add/update a rule that requires at least one replacement address but contains an empty list, then this would cause the panic seen when that rule later matches a packet. This needs fixing in OpenBSD as well. Michal, can you please confirm that the patch above fixes the panic? The proxy will still misbehave and cause the log messages (one more EINVAL in this case ;), but the kernel shouldn't crash anymore. Thanks for the excellent bug report! Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Frozen Processes
Hello, Since upgrading some of our 5.4 servers to the latest 6.1-STABLE we've had some processes stuck in the *inp state as listed in 'top'. Those processes can't be killed and any resources they use up in terms of bound IP addresses or ports can't be freed. Does anyone know what this *inp state means or how to fix this problem? Holt G. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Mark Andrews wrote: The iwi code was recently MFC and it required a port change iwi-firmware - iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Mark B.T.W. the new code is more stable for me. No more complete machine lockups. The WiFi led now binks though if you turn the radio off it stays lit / off depending apon the state it was in at the time. This is still better than not lighting at all. There are some sysctl you can tweak to play w/ the led's. I only had a dell d610 to test with. The more important issue w/ the radio on/off switch is that it doesn't hookup properly to wpa_supplicant. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ndisgen generated module load causes page fault, missing functions
Hi, I have FreeBSD-6.1-STABLE dell D620 laptop with Dell Wireless 1490 802.11a/g Dual-band Mini Card (which seems like bcm4310). # uname -an FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #2: Fri Jul 21 13:50:53 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 [EMAIL PROTECTED]:0:0:class=0x028000 card=0x00071028 chip=0x431214e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART' class= network When I try to load bcmwl5_sys.ko module (generated by ndisgen) system faults: no match for strrchr no match for MmFreeContiguousMemorySpecifyCache no match for MmAllocateContiguousMemorySpecifyCache no match for MmGetPhysicalAddress ndis0: Dell Wireless 1490 Dual Band WLAN Mini-Card mem 0xdfdfc000-0xdfdf irq 17 at device 0.0 on pci12 ndis0: NDIS API version: 5.1 ntoskrnl dummy called... Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1a fault code = supervisor read, page not present instruction pointer = 0x20:0xc530108f stack pointer = 0x28:0xe7209938 frame pointer = 0x28:0xe720994c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 559 (kldload) [thread pid 559 tid 100103 ] Stopped at 0xc530108f: cmpb0(%edi),%al db bt Tracing pid 559 tid 100103 td 0xc4e06a80 bcmwl5_sys_drv_data_start(c534e8f6,c52f9ddc,0,0,e7209980) at 0xc530108f bcmwl5_sys_drv_data_start(c4e2a000,c53d1000,c539d600,c53e2000,c4e2a000) at 0xc53070d3 bcmwl5_sys_drv_data_start(e7209ac8,c4e2a000,0,c53d1000,c539d600) at bcmwl5_sys_drv_data_start+0xe5d6 x86_stdcall_wrap_end(c521d000,0,c,0,0) at x86_stdcall_wrap_end+0x1e ndis_attach(c4bb9300,c4c305a0,5,13,4312) at ndis_attach+0x17c ndis_attach_pci(c4bb9300) at ndis_attach_pci+0x374 device_attach(c4bb9300,c4bb9300,c4bb9300,0,c4ba8700) at device_attach+0x58 device_probe_and_attach(c4bb9300,c4bb9300,c4ba8700) at device_probe_and_attach+0xc4 pci_driver_added(c4bba100,c5356244) at pci_driver_added+0xd1 devclass_add_driver(c4b08440,c5356244,c52df600,c535630c,c4c25070) at devclass_add_driver+0xb7 driver_module_handler(c52df600,0,c5356318,c0872440,0) at driver_module_handler+0x59 module_register_init(c535630c) at module_register_init+0x4b linker_file_sysinit(c51ece00,c51ece00,1,c51ece00,c4c25070) at linker_file_sysinit+0x7d linker_load_file(c4c25070,e7209ca0,400,0,c4bd9800) at linker_load_file+0xce linker_load_module(c4bd9800,0,0,0,e7209ccc) at linker_load_module+0xa3 kldload(c4e06a80,e7209d04,1,0,292) at kldload+0xeb syscall(3b,3b,3b,1,bfbfec88) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280bab77, esp = 0xbfbfebfc, ebp = 0xbfbfec38 --- db Did somebody successfully use ndisgen generated driver for Dell Wireless 1490 802.11a/g Dual-band Mini Card? thanks in advance, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
