From mboxrd@z Thu Jan 1 00:00:00 1970 From: W. van den Akker Date: Wed, 21 Jan 2009 22:05:59 +0100 Subject: [ath9k-devel] [PATCH] still same problem In-Reply-To: References: <49601028.9030201@gmail.com> <1232541342.6354.9.camel@jm-desktop> Message-ID: <200901212206.00079.listsrv@wilsoft.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Wednesday 21 January 2009, Chris Kennedy wrote: > On Jan 21, 2009, at 6:35 AM, Jouni Malinen wrote: > > On Wed, 2009-01-21 at 02:11 -0800, W. van den Akker wrote: > >> I have tested with 1 CPU disabled. Running now for about 2 hours > >> without > >> hangups (I have several connection drops, but it will reconnect). > >> > >> I have also tested with 2 CPU's and HT-disabled (noht parameter) > >> but that > >> had no effect. > >> > >> So SMP looks like the cause of the problem here. > > > > Thanks for testing this! I'm running most of my tests with a dual core > > system, so SMP is being used, but with two cores, not two separate > > chips. I don't think there should be much difference there, but > > certainly our hardware configuration is different. > > > > Could you please describe your hardware with more details so that > > we can > > see whether we could find a similar system to try to reproduce > > this? Is > > this the IBM 206 eserver with WMP300N you mentioned in an earlier > > message in the thread? That seems to be (by default) a uni-processor > > setup, so I would like to make sure we understand what is the exact > > hardware used here since I do not think we have been able to reproduce > > this type of issue so far in any dual core systems. > > > > - Jouni > > This is a patch (against yesterdays current wireless-testing kernel) > that shows basically what we did in the IVTV driver, > essentially holding a spin_lock() in the interrupt handler. So it > isn't even used, since compiled out, if a system isn't SMP. When the > system is SMP it prevents multiple instances of the interrupt handler > from happening. This seemed to be the magic fix there, I'm not sure if > this is totally correct for this driver, but it's a patch to test > (hopefully the > spinlock I used makes some sense, seems this also is good since > wouldn't want to reset the card and have interrupts happen while > that's going on?). It's at least an example showing what I suspect > could > fix it, and would be interesting if you had the ability to test it on > your SMP > system to see if it is just the interrupt handler where it's happening. > Thanks Chris, I applied the patch.... but no luck. Systems still hangs. gr, Willem -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.