Re: iwi driver: ioctl[SIOCS80211, op 21, len 42]: Invalid argument
[ Charset ISO-8859-1 unsupported, converting... ] > Vladimir Grebenschikov wrote: > > Hi > > > > i am triing to connect Intel(R) PRO/Wireless 2200BG - iwi0 to WPA-EAP > > wireless network with PEAP: > > > > # wpa_supplicant -i iwi0 -c /usr/local/etc/wpa_supplicant.conf > > Trying to associate with SSID 'OFFICE-PEAP' > > ioctl[SIOCS80211, op 21, len 42]: Invalid argument > > Association request to the driver failed > > ... > > "op 21" is the request to associate. The error most likely indicates > the kernel had no information about the ap at the point where the ioctl > was issued. Adding -d to the command line would provide useful info. ... Initializing interface (2) 'iwi0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:0e:35:03:82:74 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 10 usec Added interface iwi0 State: DISCONNECTED -> SCANNING Trying to associate with SSID 'OFFICE-PEAP' Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: clearing own WPA/RSN IE No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'OFFICE-PEAP' wpa ie len 0 pairwise 4 group 4 key mgmt 3 wpa_driver_bsd_associate: set PRIVACY 1 Association request to the driver failed Setting authentication timeout: 5 sec 0 usec EAPOL: External notification - portControl=Auto CTRL-EVENT-TERMINATING - signal 2 received Removing interface iwi0 State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=1 Cancelling scan request ... > > > > # kldstat | egrep wlan\|iwi > > 281 0xc0892000 2d08 wlan_wep.ko > > 295 0xc0895000 1ed74wlan.ko > > 521 0xc4ff9000 7000 wlan_ccmp.ko > > 531 0xc500 4000 wlan_tkip.ko > > 541 0xc3828000 2000 wlan_xauth.ko > > 571 0xc4f36000 d000 if_iwi.ko > > # Kernel and userland in sync, just rebuild everithing for sure. I've tried with and without wlan_ccmp.ko wlan_tkip.ko - no any difference (they should not be used in may case) > > changing ap_scan=2 >> ap_scan=1 > > improves situation a bit, but still does not work: > > ap_scan has no effect on freebsd if I recall; it's really intended for > linux and other os's where a variety of drivers hook up to > wpa_supplicant. On freebsd all drivers (except for ndis) go through > net80211 and scanning is handled uniformly. > > > > > ... > > State: DISCONNECTED -> SCANNING > > Starting AP scan (broadcast SSID) > > Received 0 bytes of scan results (3 BSSes) > > Scan results: 3 > > Selecting BSS from priority group 0 > > 0: 00:14:a5:0e:eb:60 ssid='COME' wpa_ie_len=0 rsn_ie_len=0 caps=0x31 > >skip - no WPA/RSN IE > > 1: 00:18:b9:2a:c4:50 ssid='OFFICE' wpa_ie_len=0 rsn_ie_len=0 caps=0x31 > >skip - no WPA/RSN IE > > 2: 00:13:46:fe:c2:ff ssid='pmp' wpa_ie_len=0 rsn_ie_len=0 caps=0x31 > >skip - no WPA/RSN IE > > No suitable AP found. > > Setting scan request: 5 sec 0 usec > > Starting AP scan (broadcast SSID) > > Received 0 bytes of scan results (1 BSSes) > > Scan results: 1 > > Selecting BSS from priority group 0 > > 0: 00:18:b9:2a:c4:50 ssid='OFFICE' wpa_ie_len=0 rsn_ie_len=0 caps=0x31 > >skip - no WPA/RSN IE > > No suitable AP found. > > Setting scan request: 5 sec 0 usec > > ... > > > > any hints will be really appreciated. > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with uipc_mbuf.c
Andre Oppermann wrote:
Maxim Konovalov wrote:
On Tue, 29 Aug 2006, 17:15+0200, Andre Oppermann wrote:
John-Mark Gurney wrote:
Randall Stewart wrote this message on Mon, Aug 28, 2006 at 17:04 -0400:
atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 0) {
^
This should be 1 not 0.. as apparently fetchadd_int returns the
old value (at least that's what atomic(9) says), which means that
if we ever race on this comparision, we won't free though we
should of...
if we look at refcount.h, it does:
return (atomic_fetchadd_int(count, -1) == 1);
which release a reference and apparently returns true if it needs to
be free'd...
Though the wierd part is that andre, "fixed" it to be 0 in 1.157:
Fix a logic error introduced with mandatory mbuf cluster
refcounting and freeing of mbufs+clusters back to the packet zone.
Honestly I'm a bit confused myself now and have to dig up things from
when I did the change. However I'm certain there was a problem and the
commit fixed it in some way (not necessarily the correct way). Before
the 'fix' there were some larger leaks going on.
So what's the conclusion? Perhaps it's worth to add an XXX comment in
meantime.
Please give me until Thursday to resolve this issue.
Andre:
It is long past Thursday any status on this? I have not
seen a commit from you on this... When I commit the SCTP code
(some day soon) then we will have an mbuf leak unless we change
the 0 to a 1
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 815-342-5222 (cell)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ÏÎ ÏÎÂÎÄÓ ÃÀÑÒÐÎË ÅÉ
ПРЕДЛАГАЕМ ОРГАНИЗАЦИЮ ГАСТРОЛЕЙ: Группа "Револьверс" - от 1 000$ Натали - от 1 500$ Наталья Штурм - от 1 500$ "Фабрика звезд" - от 1 500$ Прохор Шаляпин - от 3 000$ Юлиан - от 3 000$ Валентина Толкунова - от 3 000$ Надежда Шаврина - от 3 000$ Группа "Лицей" - от 4 000$ Татьяна Буланова - от 5 000$ Группа "Hi - Fi" - от 5 000$ Группа "Сливки" - от 6 000$ Группа "Не пара" -от 6 000$ Анастасия Стоцкая - от 7 000$ Надежда Бабкина - от 8 000$ Филипп Киркоров - от 40 000$ РАБОТАЕМ НА РЫНКЕ 8 ЛЕТ! Тел.:(495)792 77 31 (Без выходных!) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Russsian congenial Slut here doing top-quality .
graceful Eighteens suckking oldman cock! http://ugadnascertbe.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new group About Searched
Create new group About Searched all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer your on can try Answers for expert help with search. Get the latest messages Sign in Web Images VideoNew News Maps more raquo Advanced Search Members: users: Join Alerts Create new group About Searched all groups Help Sign in Web Images VideoNew News Maps more raquo Advanced Search Members: users: Join Alerts Create new group About Searched all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer your on Images VideoNew News Maps more raquo Advanced Search Members: users: Join Alerts Create new group About Searched all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer your on can try Answers for expert help with search. Get the latest messages emailed to Alerts. Terms of Service Privacy oogle Groups Home Help Sign in Web Images VideoNew News Maps more raquo Advanced Search Members: users: Join Alerts Create new group About Searched all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer your on can try Answers for expert help with search. Get the latest messages emailed to Alerts. Terms of Service Privacy Policy Images VideoNew News Maps more raquo Advanced Search Members: users: Join Alerts Create new group About all groups Your search did not match any Make sure words are spelled Try different keywords. general fewer your on can try Answers for expert help with search.___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network Card problems in FreeBSD 4.9
Hi, Nobody has answered to this so far, so I give it a try. First of all, FreeBSD 4.9 is pretty old. It's possible that it doesn't support your NICs (network interface cards) properly. At the very least, you should update to 4-stable (RELENG_4). But the official support for the FreeBSD 4 series ends at the end of January 2007, which means that you won't get security patches anymore. Therefore I recommend that you update to FreeBSD 6. The latest release is 6.1, but 6.2 is currently in the works and is scheduled to be released in about 6 weeks. Steph wrote: > I've recompiled my kernel since I needed to add a new Driver for some > bandwidth management software I'm running and for some reason when I > reboot the box with the new kernel it doesn't show my Network Interfaces > when doing an ifconfig -a. > > The one device is a Dual Intel Pro/1000 Adaptor and the other is a Dual > Broadcom I think. I've compiled the drivers for these devices directly > into the kernel without any errors. They do show up when doing a pciconf > -lv. I'm new to FreeBSD so the chances that I've screwed something up > somewhere is quite good :-) Is there anything else I should be looking > out for? If everything else fails, you can simply try loading the various NIC drivers (kernel modules), one after another, and watch dmesg (console output) for any messages. If one of the drivers attaches, then you know which driver you need. :-) On FreeBSD 4.x, the kernel modules are located in /modules, and on FreeBSD 5.x/6.x they're in /boot/kernel. The NIC drivers alls start with "if_", so the following command will list all of them: # ls /modules/if_* # FreeBSD 4.x # ls /boot/kernel/if_* # FreeBSD 5.x/6.x To load a module, use this command (as root, of course): # kldload if_bge That will load the "bge" driver (for Broadcom gigabit NICs). You can remove unneeded modules with kldunload, and list all currently loaded modules with kldstat. Please refer to their manual pages for details. Note that every NIC driver has a manual page, which lists all chips that are supported. For example, look at the bge manual page. Another possibility is to compile a new kernel which has all of the NIC drivers statically included. Then reboot and check which of the drivers attached to your NICs. Then remove all the others from their kernel (or just keep them, unless you're concerned about wasting some RAM). > [EMAIL PROTECTED]:1:0: class=0x02 card=0x00291374 chip=0x00291374 > [EMAIL PROTECTED]:1:1: class=0x02 card=0x00291374 chip=0x00291374 That doesn't look like an intel adaptor. You can lookup the chip ID here: http://pci-ids.ucw.cz/iii/?i=1374 It lists the device as "Silicom Dual port Copper Giga Ethernet 546GB Bypass Server Adapter". To be honest, I have never heard of such a thing before, and I think it is not supported by FreeBSD. (Someone please correct me if I'm wrong.) > [EMAIL PROTECTED]:0:0: class=0x02 card=0x02c615d9 chip=0x165914e4 > [EMAIL PROTECTED]:0:0: class=0x02 card=0x02c615d9 chip=0x165914e4 That's the "NetXtreme BCM5721 Gigabit Ethernet PCI Express". The last four characters of the "chip" ID are the vendor code (in this case, 14e4 is Broadcom) and the preceding four characters are the model code (here: 1659). See this page: http://pci-ids.ucw.cz/iii/?i=14e4 In FreeBSD 6, the bge(4) manual page says that the BCM5721 is supported by this driver. However, I'm not sure that 4.9 supports it, because it's very old. You probably must update to a more recent version of FreeBSD. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Spam on this mailing list
Folks, I think it's time to reconfigure this mailing list so that only subscribers can post to it. (Frankly, I was suprised that this isn't already done; most mailing lists these day so this.) Ross. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Updated SCTP patch/tar
Hello all: Well, life goes on.. I have once again put up on the sctp.org web site an updated patch for 7.0 and a new tarball for 6.0/6.1 for SCTP. You can find these at: http://www.sctp.org/download.html (or go to www.sctp.org and pick the download tab)... For those on 7.0 please pick the 9/20 patch. For those on 6.0 or 6.1 use the tarball-5 dated 9/20... Note this is getting pretty close to the code we will commit to FreeBSD soon (probably October).. the patch also holds the update for uipc_mbuf.c that fixes the contention memory leak bug.. This will be committed shortly to HEAD.. but for those wanting the patch... this will save you the trouble :-D Happy SCTPing R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Spam on this mailing list
On Wed, Sep 20, 2006 at 11:30:11AM -0700, Ross Finlayson wrote: > Folks, I think it's time to reconfigure this mailing list so that > only subscribers can post to it. (Frankly, I was suprised that this > isn't already done; most mailing lists these day so this.) The spam filter was temporarily broken and has been fixed. -- Brooks pgpHH01RLxHgJ.pgp Description: PGP signature
Much improved sendfile(2) kernel implementation
The recent addition of TSO (TCP Segmentation Offload) has highlighted some shortcommings in our sendfile(2) kernel implementation. The current code simply loops over the file, turns each 4K page into an mbuf and sends it off. This has the effect that TSO can only generate 2 packets per send instead of up to 44 at its maximum of 64K. I have rewritten kern_sendfile() to work in two loops, the inner which turns as many pages into mbufs as it can up to the free send socket buffer space. The outer loop then drops the whole mbuf chain into the send socket buffer, calls tcp_output() on it and then waits until 50% of the socket buffer are free again to repeat the cycle. This way tcp_output() gets the full amount of data to work with and can issue up to 64K sends for TSO to chop up in the network adapter without using any CPU cycles. Thus it gets very efficient especially with the readahead the VM and I/O system do. Looking at the benchmarks we see some very nice improvements (95% confidence): 45% less cpu (or 1.81 times better) with new sendfile vs. old sendfile (non-TSO) 83% less cpu (or 5.7 times better) with new sendfile vs. old sendfile (TSO) The sender is an AMD Opteron 852 (2.6GHz) with em(4) PCI-X-133 interface and the receiver is a DELL Poweredge SC1425 P-IV Xeon 3.2GHz with em(4) LOM connected back to back at 1000Base-TX full duplex. The patch is available here: http://people.freebsd.org/~andre/sendfile-20060920.diff Any testing and heavy (code) beating and reviews welcome. -- Andre Here are the raw numbers (netperf at 95% confidence, +-2.5% error margin, the cpu load reported by netperf is different from the one reported by time(1), all performance references are made based on time(1) output, netperf 2.4.2 used): a) is old sendfile(2) kernel implementation b) is new sendfile(2) kernel implementation 1) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [non-TSO] 2) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [TSO] 3) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [non-TSO] 4) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [TSO] 5) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [non-TSO] 6) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [TSO] 7) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [non-TSO] 8) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [TSO] 9) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m1M [non-TSO] 10) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m1M [TSO] 11) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m2M [non-TSO] 12) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m2M [TSO] 13) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m5M [non-TSO] 14) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K -m5M [TSO] 15) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [non-TSO] 16) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [TSO] 17) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [non-TSO] 18) time ./netperf -H192.168.2.2,4 -tTCP_SENDFILE -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [TSO] Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv SendRecv Size Size Size Time Throughput localremote local remote bytes bytes bytessecs.10^6bits/s % C % C us/KB us/KB 1) 32768 32768 3276810.00 921.16 28.2731.882.514 2.835 0.000u 1.703s 0:10.00 17.0% 94+5091k 0+0io 0pf+0w 2) 32768 32768 3276810.00 897.91 23.8338.652.175 3.526 0.000u 1.310s 0:10.02 13.0% 91+4925k 0+0io 0pf+0w 3) 32768 32768 3276810.00 767.31 20.9829.922.240 3.195 0.013u 0.969s 0:10.00 9.7% 109+5855k 0+0io 1pf+0w 4a) 32768 32768 3276810.00 911.66 15.7133.611.412 3.020 0.000u 0.651s 0:10.00 6.5% 93+4993k 0+0io 0pf+0w 4b) 32768 32768 3276810.00 759.08 11.1330.701.201 3.313 0.007u 0.266s 0:10.00 2.6% 108+5796k 0+0io 0pf+0w 5) 65536 65536 6553610.00 941.59 29.17
