[ath9k-devel] [PATCH] still same problem

[W. van den Akker <listsrv@wilsoft.nl>]

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.