Thanks.  I'll watch for that one once I get my network configured.  I'm writing a separate post with patches that *seem* to get rid of the timeout and initialization problems I have.  I put in like 20 retries on the entire sequence AND increased the timeout for each pass.  It never times out the first time anymore.  I've tried halt + reset switch, reboot, power off, etc...

Ethan Soutar-Rau wrote:

I found another thing that happens pretty regularly. If I leave the Ambicom connected to a network for more than 10 minutes or so wifi goes down and I get these errors:

#NETDEV WATCHDOG: wifi0: transmit timed out
wifi0 Tx timed out! Resetting card
hostap_cs: wifi0: resetting card
hostap_cs: first command failed - assuming card does not have primary firmware

Earlier I had assumed that that was related to me messing with configuration, but it happens pretty consistently at idle. 


On Monday, January 09, 2006, at 03:53PM, Michael Taylor <> wrote:

<<Original Attached>>

Ethan, I'm working on a theory. The area where it blows up during initialization is in hostap_download.c when trying to turn on the "aux" port. The "aux" port is basically a way to directly access the memory addresses on the MAC chip. Three magic values are written to specific addresses, acting as a safety device against accidental aux port enabling. Then we write a couple of bits in the control register to enable the "aux" port and loop, waiting for the control register to reflect the enabled bits as on. It is at this point that we get this timeout... or we don't. If we get past this aux port enable, the aux port stays enabled and will not need to be enabled again. IF the driver calls this function to enable the AUX port and it's already enabled, it just returns. I.e. it works until you cut power and then you may or may not succeed on the next restart after power is restored. Now, shutdown may leave the system in a state different than a power on, resulting in consistent failure after a clean shutdown. If the problem is limited to this routine, it should be pretty easy to figure out what the state of the world is during each call to this routine with both cold and warm reboots, etc.. If I can improve the situation, I'll post a patch file. Ethan Soutar-Rau wrote: >Here is my setup. I have a Connex XM 400 using a file system image I built on December 2nd using the main build root on Ubuntu. I disabled openobex because of a mirror problem and turned on kermit, sqlite, and a couple other things that should have no relation to this issue. > >I saw your #2 problem and a couple others. I also noticed that the wifi failed to come up every time if I rebooted the gumstix from the command line, but generally came up if I unplugged the gumstix and plugged it back in. > >I tried to experiment with that a bit. After I had rebooted four times I got a nasty message interspersed with getty about setting the Mac address to 0 on wlan0, and then even unplugging failed on each test. The gumstix began freezing in a variety of places, the usb net startup, and in getty. > >As my gumstix was now unusable I took the CFStix board off and tried just the gumstix and waysmall. That worked fine. I unplugged the gumstix, reattached the CFStix (with Wifi card), and tried again. This time the gumstix booted successfully and wifi came up. > >At this point I was resolved to never use "reboot" or "halt" again, but I still wasn't sure that unplugging made any difference. > >To make sure it wasn't completely a red herring I started unplugging, accessing gumstix.local/cgi-bin/ifconfig from my laptop and noting the results. The first seven plug/unplugs worked without a hitch. The eighth froze after rendezvous startup. The ninth froze at getty. So I disassembled and reassembled again. Attempt ten worked fine. Eleven gave me hostap_cs grief. Then it worked until I ran short on time, say 5 more startups. > >It seems to me that there is something messing up with the way that the card is intialized, but once it gets going it seems to stay relatively organized as long as the system never gets a chance to gracefully shut down. If the system does shutdown then something happens which totally borks the whole thing. It also seems that removing the cfstix and booting the gumstix by itself will clear whatever the problem is, temporarily anyway. > >I would like to be able to test those ideas abit more thoroughly but I am heading off to a convention in San Fran this week so I won't be able to get on it for awhile. I'll keep an eye here though. > >Ethan > > > >On Monday, January 09, 2006, at 11:46AM, Michael Taylor <> wrote: > > > >>The card is detected as Z-Com XI300 11Mb/s WLAN Card. This is >>apparently OK from what I have read. I've seen three modes: >> >>1. Fails with "prism2_enable_ax_port: was not enabled!?" >> >>2. Registered netdevice wifi0 with index 0x01: Vcc 5.0, irq 49, io >>0xc4860000-0xc486003f >>but locking up after >>wifi0: NIC: id=0x801b v1.0.0 >>wifi0: PRI: id=0x15 v1.1.1 >>wifi0: STA: id=0x1f v1.8.0 >> >>and >> >>3. Successful boot with netdevice wifi0 "registered". >> >>The same configuration can produce all three cases, just rebooting. I'm >>thinking race condition or some other problem with the initialization >>sequence. >> >> >>------------------------------------------------------- >>This email is sponsored by: Splunk Inc. Do you grep through log files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> >>_______________________________________________ >>gumstix-users mailing list >> >> >> >> >> >> > > >------------------------------------------------------- >This email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >_______________________________________________ >gumstix-users mailing list > > > > >