[Prism54-devel] [patch 0/6] [prism54 svn trunk] various fixes for prism54 svn

[Bob Beers]

On 5/17/05, Jean-Baptiste Note <jean-baptiste.note at wanadoo.fr> wrote:
> 
> Hello,
> 
> > Any way, the end result is: on an embedded platform similar to PCengines
> >  WRAP 1C (geode SC1100 266MHz, 64M SDRAM with miniPCI XG-601)
> >  I now can go ~ 30 minutes before it the entire system locks.  Is there
> >  some other data I can collect?  I'm going to also try again the XG-601
> >  in the PCI adapter with a BOSOR SBC HS-5230 and passive PISA backplane.
> 
> This is bad. Well, time in increased, but the problem is worse...
> 

Well, restart and try again ... (one test is not enough) ...
 I set prism54 as AP, with minimal traffic (one station associated) and then
 generate traffic stream on wired interface (one voip call, ~18k both
directions).
With unpatched driver, wireless interface gets in debug log 
 "timeout waiting for mgmt response" reliably within 15 minutes. Most times
 entire system is useless, but sometimes it is just the wireless messed up.
With patched driver, I was able to run for >12 hours in this scenario.  In
 fact it was still operating great, with no messages in log files, until I
 attempted big e-mail download over wireless link.  Then I got the
 same problem:  "timeout waiting for mgmt response" and "no 
 wireless extensions" reply to iwconfig.  But system is still accessible.  I can
 read the log files, use the wired and serial interfaces, and the voip call
 is even still going.
So, this is a big improvement.  Perhaps i can go right into the heavy traffic on
 the wireless link for debugging now.  Before, any decent amount of traffic
 on the PCI bus seemed to trigger problems.

> 1/ There's a fixme : you should check and BUG_ON() the mgmt rx frame not
> being 32-bits aligned. I know this will cause problem, only hoping it
> won't happen. But it may. patch is to add
> 
> skb_reserve(newskb, (4 - (long) newskb->data) & 0x03);
> at line 133 in islpci_mgt.c, and do the above alloc with MGMT_SIZE + 3
> instead of + 2.
> 

Ok, I can try that.

> 2/ apply patch sent on list about DMA
> 

Ok, i can try this, too.

> 3/ No logs, no error messages ?  How are you collecting the log data ?
> -- you won't get them on disk in case of a hard lockup, you should at
> least use serial / netconsole to gather the data. If that's not
> sufficient, please try to increase the verbosity of the driver to see
> about where it locks up.
> 

Sure, I use minicom to serial port, and ssh to wired ethernet.  Here
is the debug
 log from the latest event, not very exciting.  What's the quick and dirty on
 "increasing the verbosity"?

May 18 13:46:23 rt_hay kernel: wlan0: timeout waiting for mgmt
response 1000, triggering device
May 18 13:46:23 rt_hay kernel: wlan0: timeout waiting for mgmt
response 900, triggering device
May 18 13:46:23 rt_hay kernel: wlan0: timeout waiting for mgmt
response 800, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 700, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 600, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 500, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 400, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 300, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 200, triggering device
May 18 13:46:24 rt_hay kernel: wlan0: timeout waiting for mgmt
response 100, triggering device

-- 
Bob