Re: command not found: problem with dash in filenames
On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: NOTICE: when I run purepw it is located and runned, but when I run pure-pw (NOTICE: dash in name) I get: Command not found Did you by any chance just install this binary? Have you tried running 'rehash' and trying again? Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpIZPuvaqK8t.pgp Description: PGP signature
Re: bsnmp header files question
On Thu, Aug 07, 2008 at 03:22:21AM -0700, Unga wrote: 1) /usr/include/bsnmp/snmpmod.h /usr/src/usr.sbin/bsnmpd/modules/Makefile 2) /usr/include/bsnmp/snmp_mibII.h /usr/src/usr.sbin/bsnmpd/modules/snmp_mibII/Makefile 3) /usr/include/bsnmp/snmp_atm.h /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/Makefile Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp5n0iMda9zb.pgp Description: PGP signature
Re: overheating Thinkpad X60s with 7.0-RC1
On Sun, Jan 06, 2008 at 02:55:32PM -0800, Jeremy Chadwick wrote: I won't even bother mentioning what happens when I run something that's CPU or GPU intensive. I haven't had any crashes, but in some cases, I've seen the GPU temperatures reach over 80C -- completely unacceptable, and bordering on insane. It's gotten to the point where to use my T60p *quietly*, I'm forced to prop the rear corners up on little blocks or whatever, and then place a desk fan nearby, blowing cold air more or less underneathe the laptop. This keeps the fan in low speed mode, which is semi-tolerable. Makes me wonder why you didn't return these laptops for repair... I would urge those here to consider booting XP somehow (if possible) and running tp4xfancontrol to check actual temperatures, since FreeBSD's h/w monitoring capability is spotty at best (I think Linux wins out here, but at least there's room for growth...) ... or just use FreeBSD's own acpi_ibm(4) for reading those temperatures: $ sysctl dev.acpi_ibm.0.thermal dev.acpi_ibm.0.thermal: 49 52 -1 47 32 -1 32 -1 Now, who are you calling spotty? http://www.thinkwiki.org/wiki/Thermal_Sensors has some hints about possible sensor locations, although no one has yet submitted information on sensor locations for the X60s. Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp6If0LYk599.pgp Description: PGP signature
Re: overheating Thinkpad X60s with 7.0-RC1
On Sun, Jan 06, 2008 at 10:26:48PM +0100, Johannes Dieterich wrote: X and T series of the thinkpads are rather different, even the cores are completely different (I have a dualcore low-voltage version, I assume yours is running on a dual Pentium m, or?). FWIW, I haven't seen any temperature related issues on my ThinkPad X60s, which has been tracking -CURRENT for the last year or so. It too has had the IPW3945 replaced by an Atheros wireless card, but it is still using the original HDD. Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpl8Yk0ql6Lg.pgp Description: PGP signature
Re: 7 on Soekris net4801?
On Thu, Nov 08, 2007 at 12:17:59PM +0100, Søren Schmidt wrote: I'd figure that the problem is that the geode chip doesn't support 128 sector writes just up to 126, that is not honered from the dump rutine IIRC. Not only the dump routine fails, so does savecore(8): Physical memory: 251 MB Dumping 74 MB:ata0: FAILURE - oversized DMA transfer attempt 65536 64512 ad0: setting up DMA failed ... Checking for core dump on /dev/ad0s1b... ata0: FAILURE - non aligned DMA transfer attempted ad0: setting up DMA failed savecore: error reading last dump header at offset 536870400 in /dev/ad0s1b: Input/output error savecore: no dumps found Nov 16 19:13:07 tirith savecore: error reading last dump header at offset 536870400 in /dev/ad0s1b: Input/output error Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpkIOIOY17Yg.pgp Description: PGP signature
Re: 7.0-BETA1 2 occasionally freezing, how to diagnose?
On Mon, Nov 05, 2007 at 07:47:29PM -0600, Doug Poland wrote: I've done serial console redirection before but this laptop has no serial port. Can I get console redirection via firewire? Can you point me at some docs? Check out http://wiki.freebsd.org/DebugWithDcons Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpyECaGoBq3C.pgp Description: PGP signature
Re: 7 on Soekris net4801?
On Mon, Nov 05, 2007 at 01:09:14AM +1100, Ian Smith wrote: On Sun, 4 Nov 2007 09:02:42 +0100, Marten Vijn wrote: only issues with tinybsd (ssh and polulating /var /tmp) I 'll post that later on small@ That'll be great, there's been nothing in -small for months. That's because -small@ was obsoleted by -embedded@ -- see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpBQnaTIsCn4.pgp Description: PGP signature
Re: 7 on Soekris net4801?
On Sun, Nov 04, 2007 at 02:59:36AM +1100, Ian Smith wrote: any particular/new issues with RELENG_7 on the Soekris net4801? Thought I should check before upgrading my T23 as a build platform .. I haven't done this before, and will be relying on the howtos for 6.X I recently upgraded two of my net4801s to RELENG_7 - the only problem I have seen so far, is that savecore(8) attempts to do non-aligned DMA transfers and fails. I haven't had time to dig further into this issue yet, though. Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpc2pQUd7CFv.pgp Description: PGP signature
Re: libpcap/tcpdump update
Hi Max, On Fri, Oct 19, 2007 at 10:48:52AM +0200, Max Laier wrote: Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and RELENG_7. Thank you for updating these two components! Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp2pFfzwjHEk.pgp Description: PGP signature
Re: clock too slow - big time offset with ntpdate
On Wed, May 02, 2007 at 10:23:09AM -0700, Doug Barton wrote: [snip /etc/ntp.conf configuration file instructions] Then make sure you have the following in /etc/rc.conf: ntpdate_enable=yes ntpdate_flags=-sb 1.2.3.4 ntpd_enable=yes Just a side note - according to the ntpdate(8) man page, ntpdate is deprecated and will eventually be removed from the distribution since the same functionality is available in ntpd(8). Thus, all you need to put in /etc/rc.conf is this: ntpd_enable=YES ntpd_sync_on_start=YES You still need a properly configured /etc/ntp.conf file. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp7Ra9uPmzdZ.pgp Description: PGP signature
Re: Lenovo X60 em workaround
Hi Jack, On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: saying its known to be a problem doesnt mean its cause is known :) They discovered that setting this eliminated the problem, but we immediately pointed out that this is, as you pointed out, a Bad Thing on other hardware, so the investigation continues, there is always a communication lag on these kind of things, so I dont know if it has been resolved yet or not. I can confirm this patch solves the latency problem with em(4) on my IBM/Lenovo ThinkPad X60s. Any news about a proper solution to this issue? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpycVejfgBuZ.pgp Description: PGP signature
Re: Lenovo X60 em workaround
Hi,
On Mon, Jan 22, 2007 at 10:30:48AM -0800, Jack Vogel wrote:
Acknowledge... I can do better than that, I have a fix for this problem, and
its not temporary. Here is the code change (not a patch, I'm very busy),
its in hardware_init, should be obvious how to patch:
/* Make sure we have a good EEPROM before we read from it */
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
/*
** Some PCI-E parts fail the first check due to
** the link being in sleep state, call it again,
** if it fails a second time its a real issue.
*/
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
device_printf(dev,
The EEPROM Checksum Is Not Valid\n);
return (EIO);
}
}
This is already checked into my code base at Intel, I've just been too
busy to do anything with it, be my guest if you wish to check it in after
testing...
I can confirm that the above patch fixes the frequent initialization
problems with em(4) on my IBM/Lenovo ThinkPad X60s. Without the patch,
I often see the following on boot when there is no link on the em(4)
interface:
Apr 17 22:05:12 lothlorien kernel: em0: The EEPROM Checksum Is Not Valid
Apr 17 22:05:12 lothlorien kernel: em0: Unable to initialize the hardware
With the patch, I can not reproduce the invalid checksum errors - the
second call to e1000_validate_nvm_checksum() succeeds.
Any chance of this patch hitting CURRENT anytime soon? :)
Regards,
Brix
--
Henrik Brix Andersen [EMAIL PROTECTED]
pgp4LeHzR3WOj.pgp
Description: PGP signature
Re: updated to Releng_6, psm0 disappeared, acpi_ibm not working
On Sat, Apr 14, 2007 at 09:42:27AM +0200, [LoN]Kamikaze wrote: I just updated my Thinkpad R40 to Releng_6. The psm0 device is discovered no longer (hence no touchpad or joystick). Dmesg shows no trace of it. I can not reproduce your problem with RELENG_6 of today on my X31. However, you neglected to post your kernel configuration and dmesg (and the output of 'sysctl dev.acpi_ibm') which makes debugging quite a bit more difficult :) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpNuxxJ8cJWq.pgp Description: PGP signature
Re: possible bug in pxeboot with TFTP support
On Mon, Mar 26, 2007 at 03:16:15PM -0400, Ryan J. Taylor wrote: I compiled pxeboot with TFTP support by doing: cd /usr/src/sys/boot make -DLOADER_TFTP_SUPPORT I have clients booting via PXE and grabbing their root filesystem from a memory disk. However, there was a long delay in the boot sequence. tcpdump revealed that after downloading pxeboot, the client was sending RPC traffic, presumably looking for NFS. This caused the boot to stall for 30 seconds or so until the loader spit out NFS MOUNT RPC error: 60 and then continued booting via tftp. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=91720 Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpUeDGfq1ywv.pgp Description: PGP signature
Re: getting garbage faster using FreeBSD?
On Tue, Feb 20, 2007 at 02:06:32PM +0100, Philipp Ost wrote: You could use DBAN [0] to wipe the data, at least on the disks ;) That also takes some time (depends on the method you choose) but it's worth it... I normally use gshred(1) from the sysutils/coreutils port for wiping data. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpopP307oJlA.pgp Description: PGP signature
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Hi Sam, Sorry about the long delay in replying, been busy moving to a new apartment :) On Sun, Jan 28, 2007 at 10:45:06AM -0800, Sam Leffler wrote: I take it you tried ifconfig'ing the interface down and up? Yes, that didn't solve it. The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). Thanks, I'll check that next time the problem occurs. The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. I see. Can you recommend a replacement 802.11a/b/g card model which is supported by ath(4)? Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpKxE48W5yJS.pgp Description: PGP signature
Re: ath0: ath_reset: unable to reset hardware; hal status 3
On Thu, Feb 15, 2007 at 02:16:42PM +0100, Henrik Brix Andersen wrote: On Sun, Jan 28, 2007 at 10:45:06AM -0800, Sam Leffler wrote: The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). Thanks, I'll check that next time the problem occurs. Output of athstats on the AP looks like this with ping(8) running on both AP and STA while things are wedged: input output altrate shortlong xretry crcerr crypt phyerr rssi rate 01 0 0 0 0 0 0 12 39 24M The above output repeats itself with small variations in the phyerr column. The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. I see. Can you recommend a replacement 802.11a/b/g card model which is supported by ath(4)? I have been searching for a replacement for my current 5212-based atheros miniPCI card and came across these two products: http://www.netgate.com/product_info.php?cPath=26_34products_id=279 http://www.netgate.com/product_info.php?cPath=26_34products_id=393 Both are based on the Atheros AR5006xs 6th generation chipset (AR5414) but only one of them supports Super AG. Does anybody know if these cards will work the the ath(4)/ath_hal(4) found in FreeBSD? According to the ath_hal(4) man page, the only supported cards are those based on the Atheros AR5210, AR5211 and AR5212 chipsets? Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp8zXxAjR9iZ.pgp Description: PGP signature
ath0: ath_reset: unable to reset hardware; hal status 3
Hi all, I have noticed a problem when using ath(4) as an 802.11g access point with hostapd(8) and WPA2-PSK CCMP. The following problem seems to only occur when a Microsoft Windows XP STA connects to the AP in 802.11g mode, my FreeeBSD STAs doesn't seem to trigger this: Jan 28 11:21:07 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:07 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:25 osgiliath kernel: ath0: device timeout Jan 28 11:21:25 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:25 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:37 osgiliath kernel: ath0: device timeout Jan 28 11:21:38 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:38 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:46 osgiliath kernel: ath0: device timeout This is FreeBSD RELENG_6 (nanoBSD) as of yesterday with the new ath_hal(4) running on a Soekris net4801-50: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: Atheros 5212 mem 0xa001-0xa001 irq 11 at device 14.0 on pci0 ath0: Ethernet address: 00:05:4e:42:e8:7c ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 The same problem occured with version 0.9.17.2 of ath_hal(4). I have increased the RX/TX buffers in ath(4) as shown in this snippet from my kernel configuration: device ath device ath_hal device ath_rate_sample options ATH_RXBUF=80 options ATH_TXBUF=200 The only way I can get the AP running again after the above messages to syslog is to reboot it. The problem doesn't seem to occur in 802.11b mode nor in 802.11g mode with only FreeBSD STAs. Any help in debugging this will be appreciated. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpaSfvVEpUzW.pgp Description: PGP signature
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
On Tue, Jan 23, 2007 at 09:57:06PM +0100, Dimitry Andric wrote: Yes. The specific line in my rc.conf is: ipv6_ifconfig_gif0=2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128 With that setup you should be able to just do: ipv6_defaultrouter=2001:7b8:2ff:146::1 ipv6_ifconfig_gif0=2001:7b8:2ff:146::2 prefixlen 127 I know it doesn't solve the bug, but if you just need it working... :) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp5E6HMkfHzA.pgp Description: PGP signature
Re: gif problems in -STABLE
On Sat, Dec 30, 2006 at 02:56:35AM +0100, Dimitry Andric wrote: For some reason, the ifconfig command now fails to create the proper routing table entries. With the 2006-11-03 kernel, if I configure my gif0 tunnel as follows: ifconfig gif0 create ifconfig gif0 213.154.244.69 193.109.122.244 ifconfig gif0 inet6 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128 route add -inet6 default 2001:7b8:2ff:146::1 Apart from the two IPv4 endpoint addresses you also assign two IPv6 addresses with prefixlen 128 to the gif0 interface? Looks weird to me... Try this configuration in /etc/rc.conf instead: ipv6_defaultrouter=2001:7b8:2ff:146::1 gif_interfaces=gif0 gifconfig_gif0=213.154.244.69 193.109.122.244 ipv6_ifconfig_gif0=2001:7b8:2ff:146::2 prefixlen 127 This syntax works for my setup (and matches reality - gif0 is a tunnel with two IPv4 endpoints). I have just tested it with RELENG_6 as of today. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgplDzlfW5rfe.pgp Description: PGP signature
Re: apache and php5
On Mon, Dec 11, 2006 at 02:05:03AM -0700, RYAN M. vAN GINNEKEN wrote: I tried what you suggested did not see anything about apache in the dialog and my php still does not seem to work. DO i need to still need to add anything to my apache httpd.conf used to be something like this # php5 #AddModule mod_php5.c #LoadModule php5_modulelibexec/apache/libphp5.so #AddType application/x-httpd-php .php #AddType application/x-httpd-php-source .phps Yes. Remember to substitute the path to libphp5.so with the correct path for your version of apache (apache/ vs. apache22/). Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpuKYdy7TKqv.pgp Description: PGP signature
Re: flash7/firefox plugin no longer registers
On Mon, Oct 16, 2006 at 08:46:06PM +0900, Lee Chung-Yeol wrote: It seems that the plugin directory was changed to /usr/local/lib/browser_plugins (was under /usr/X11R6). After linking the original plugin files to that dir, it works again. This seems to affect other browser plug-ins as well: $ ls -l /usr/X11R6/lib/browser_plugins total 32 lrwxr-xr-x 1 root wheel 67 Oct 16 14:00 libjavaplugin_oji.so - /usr/local/diablo-jdk1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so -rwxr-xr-x 1 root wheel 31368 Jul 18 18:34 mozplugger.so At least the above plug-ins (java/diablo-jdk15 and www/mozplugger) installs under X11BASE although the new www/firefox revision expects them to be under LOCALBASE. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpNflDdRdSuC.pgp Description: PGP signature
Re: flash7/firefox plugin no longer registers
On Mon, Oct 16, 2006 at 02:14:47PM +0200, Henrik Brix Andersen wrote: At least the above plug-ins (java/diablo-jdk15 and www/mozplugger) installs under X11BASE although the new www/firefox revision expects them to be under LOCALBASE. FYI, I have just submitted patches for the above under ports/104474 and ports/104476. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpz1wnG2cOEZ.pgp Description: PGP signature
Re: Recommendations for a serial port card you can actually BUY?
On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I don't remember any brands or models off hand, I bought what was cheap as I needed them and they all worked. Cheap means under $20 delivered (for one port). Speaking of USB-to-serial converters... anybody know which chipset Moxa's UPort 1610-16 [1] and similar products are based on? Anybody know if they work with FreeBSD? Regards, Brix [1]: http://www.moxa.com/product/USB_to_Serial_Hubs.htm -- Henrik Brix Andersen [EMAIL PROTECTED] pgp5TdxOoWKVG.pgp Description: PGP signature
Re: [Q] multisync irmc/irmc_bluetooth plugins
On Sun, Sep 17, 2006 at 10:55:24PM +0200, Pav Lucistnik wrote: Plus, Multisync is dead in water, project abandoned... Not completely true. Multisync in its current form is abandoned, but a new version based on the OpenSync framework (http://www.opensync.org/) is in the works. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpGhBtodBxqQ.pgp Description: PGP signature
Re: ACPI resume problems in STABLE
On Wed, Sep 13, 2006 at 11:40:27AM +1000, Norberto Meijome wrote: $ uname -a FreeBSD ayiin.xxx.com 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6 #23: Tue Sep 12 14:52:32 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN i386 The only thing I've noticed that in how my lappy works now is that if_iwi0 is loaded on startup, but iw_bss and firmware.ko are not. I can load them by hand, but haven't been able to test to see if it actually works (i have a feeling it doesnt). I have installed iwi-firmware-kmod-3.0_1 Intel PRO/Wireless 2200 Firmware Kernel Module You will need net/iwi-firmware (not net/iwi-firmware-kmod) for 6.1-RELEASE. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpcr0wTTdeIj.pgp Description: PGP signature
Re: missed hostapd / ath MFC warning?
On Mon, Sep 04, 2006 at 09:03:57PM +0200, Volker wrote: I just get a 'no carrier' and so no client system is able to see the AP. There's no configuration change just a recently csup'ed and rebuild system. Is there something I've overseen? What does your ath0 entries in /etc/rc.conf look like? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpW2l49qNmjP.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: 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. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpv5kuFIG9T8.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. I know. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind scan stuck, but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpSfwF9fbvoh.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: Sure, it was for others. Ah :) Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpoFWY6qokxS.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Fri, Jul 21, 2006 at 09:00:06AM +1000, 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. Yeah, I know - I have the new iwi-firmware-kmod installed. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp7buIBqnpP2.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote:
You will not be able to reproduce the problem because the code in 6.1R
ignored beacon misses (and a lot of other things).
I see.
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).
Well, losing the connection for 30 seconds every 3 minutes is rather
annoying - if not fatal.
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.
The problem should be solvable in software - the Linux ipw2200 driver
doesn't have these problems when using the same AP.
Regards,
Brix
--
Henrik Brix Andersen [EMAIL PROTECTED]
pgpAKmEJ6LBCu.pgp
Description: PGP signature
scan stuck with if_iwi(4)
of channel 2447 complete (8) Jul 21 00:20:33 fangorn kernel: Scan of channel 2452 complete (9) Jul 21 00:20:33 fangorn kernel: Scan of channel 2457 complete (10) Jul 21 00:20:33 fangorn kernel: Scan of channel 2462 complete (11) Jul 21 00:20:33 fangorn kernel: Scan of channel 2467 complete (12) Jul 21 00:20:33 fangorn kernel: Scan of channel 2472 complete (13) Jul 21 00:20:33 fangorn kernel: Scan of channel 2484 complete (14) Jul 21 00:20:33 fangorn kernel: Scan completed (27, 1) Jul 21 00:20:38 fangorn kernel: iwi_newstate: INIT - SCAN flags 0x1 Jul 21 00:20:38 fangorn kernel: iwi_newstate: SCAN - SCAN flags 0x3 Jul 21 00:20:38 fangorn kernel: Start scanning Jul 21 00:20:38 fangorn kernel: sending command idx=14 type=26 len=96 Jul 21 00:20:39 fangorn kernel: Scan of channel 5180 complete (36) Jul 21 00:20:39 fangorn kernel: Scan of channel 5200 complete (40) Jul 21 00:20:39 fangorn kernel: Scan of channel 5220 complete (44) Jul 21 00:20:39 fangorn kernel: Scan of channel 5240 complete (48) Jul 21 00:20:39 fangorn kernel: Scan of channel 5260 complete (52) Jul 21 00:20:39 fangorn kernel: Scan of channel 5280 complete (56) Jul 21 00:20:39 fangorn kernel: Scan of channel 5300 complete (60) Jul 21 00:20:39 fangorn kernel: Scan of channel 5320 complete (64) Jul 21 00:20:39 fangorn kernel: Scan of channel 5745 complete (149) Jul 21 00:20:40 fangorn kernel: Scan of channel 5765 complete (153) Jul 21 00:20:40 fangorn kernel: Scan of channel 5785 complete (157) Jul 21 00:20:40 fangorn kernel: Scan of channel 5805 complete (161) Jul 21 00:20:40 fangorn kernel: Scan of channel 5825 complete (165) Jul 21 00:20:40 fangorn kernel: Scan of channel 2412 complete (1) Jul 21 00:20:40 fangorn kernel: Scan of channel 2417 complete (2) Jul 21 00:20:40 fangorn kernel: Scan of channel 2422 complete (3) Jul 21 00:20:40 fangorn kernel: Scan of channel 2427 complete (4) Jul 21 00:20:40 fangorn kernel: Scan of channel 2432 complete (5) Jul 21 00:20:40 fangorn kernel: Scan of channel 2437 complete (6) Jul 21 00:20:41 fangorn kernel: Scan of channel 2442 complete (7) Jul 21 00:20:41 fangorn kernel: Scan of channel 2447 complete (8) Jul 21 00:20:41 fangorn kernel: Scan of channel 2452 complete (9) Jul 21 00:20:41 fangorn kernel: Scan of channel 2457 complete (10) Jul 21 00:20:41 fangorn kernel: Scan of channel 2462 complete (11) Jul 21 00:20:41 fangorn kernel: Scan of channel 2467 complete (12) Jul 21 00:20:41 fangorn kernel: Scan of channel 2472 complete (13) Jul 21 00:20:41 fangorn kernel: Scan of channel 2484 complete (14) Jul 21 00:20:41 fangorn kernel: Scan completed (27, 1) Jul 21 00:20:41 fangorn kernel: iwi_newstate: SCAN - AUTH flags 0x1 Jul 21 00:20:41 fangorn kernel: Configuring adapter Jul 21 00:20:41 fangorn kernel: sending command idx=15 type=6 len=20 Jul 21 00:20:41 fangorn kernel: Setting ESSID to brix Jul 21 00:20:41 fangorn kernel: sending command idx=0 type=8 len=4 Jul 21 00:20:41 fangorn kernel: Setting negotiated rates (4) Jul 21 00:20:41 fangorn kernel: sending command idx=1 type=22 len=16 Jul 21 00:20:41 fangorn kernel: Setting optional IE (len=24) Jul 21 00:20:41 fangorn kernel: sending command idx=2 type=31 len=24 Jul 21 00:20:41 fangorn kernel: Setting sensitivity to 39 Jul 21 00:20:41 fangorn kernel: sending command idx=3 type=42 len=4 Jul 21 00:20:41 fangorn kernel: Join bssid 00:02:6f:37:fc:68 dst 00:02:6f:37:fc:68 channel 1 policy 0x2 auth 0 capinfo 0x31 li ntval 100 bintval 100 Jul 21 00:20:41 fangorn kernel: sending command idx=4 type=21 len=40 Jul 21 00:20:41 fangorn kernel: Authentication succeeeded Jul 21 00:20:41 fangorn kernel: iwi_newstate: AUTH - ASSOC flags 0x1 Jul 21 00:20:41 fangorn kernel: Association succeeded Jul 21 00:20:41 fangorn kernel: iwi_newstate: ASSOC - RUN flags 0x11 Jul 21 00:20:41 fangorn kernel: iwi0: link state changed to UP Jul 21 00:20:49 fangorn dhclient: New IP Address (iwi0): 10.0.0.56 Jul 21 00:20:49 fangorn dhclient: New Subnet Mask (iwi0): 255.255.255.0 Jul 21 00:20:49 fangorn dhclient: New Broadcast Address (iwi0): 10.0.0.255 Jul 21 00:20:49 fangorn dhclient: New Routers (iwi0): 10.0.0.1 Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpT6tTsgYmUG.pgp Description: PGP signature
