On Wednesday 25 October 2006 02:37, John W. Linville wrote:
> Michael,
>
> It looks like you have a patch that I don't have, one that moves the
> netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
> BADNESS_LIMIT)" conditional.
>
> Could you pass that one along as well, or corre
Michael,
It looks like you have a patch that I don't have, one that moves the
netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
BADNESS_LIMIT)" conditional.
Could you pass that one along as well, or correct this patch to match
what is in Linus' tree?
Thanks,
John
On Tue, Oct
Michael,
It looks like you have a patch that I don't have, one that moves the
netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
BADNESS_LIMIT)" conditional.
Could you pass that one along as well, or correct this patch to match
what is in Linus' tree?
Thanks,
John
On Tue, Oct
Oh, damn crap. Please remove the words "fwd" and "hopefully"
from the subject.
Sorry for the inconvenience.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
This fixes a netdev watchdog timeout problem.
The problem is caused by a needed netif_tx_disable
in the hardware calibration code and can be shown by the
following timegraph.
|---5secs - ~10 jiffies time---|---|OOPS
^ ^
last real TX periodic work stop
On Sun, 2006-10-22 at 22:20 +0200, Michael Buesch wrote:
> No success or failure reports on this one??
> Remember, without a response, this issue will never be fixed.
>
This appears to have fixed my watchdog timeouts. I have an (admittedly)
small sample of one night without the patch and one nig
On Sun, Oct 22, 2006 at 10:20:13PM +0200, Michael Buesch wrote:
> No success or failure reports on this one??
Sorry, got distracted by work, haven't had time to test it.
> Remember, without a response, this issue will never be fixed.
Well actually, I've never had watchdog timeouts. Only various
Michael Buesch <[EMAIL PROTECTED]> writes:
> I hopefully found out why we get a watchdog timeout now
> and then.
...
> I think the correct solution for this is to fake a TX start
> on every periodic work execution. This fake is harmless and
> prevents the watchdog from triggering. At least here in
No success or failure reports on this one??
Remember, without a response, this issue will never be fixed.
On Thursday 19 October 2006 21:38, Michael Buesch wrote:
> Hi,
>
> I hopefully found out why we get a watchdog timeout now
> and then.
> I spent some time thinking, testing, thinking and thi
On 10/20/06, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 20 October 2006 12:02, Bin Zhang wrote:
> > Hi,
> >
> > I had to use bcm43xx: Microcode rev 0x122, pl 0x9a (2005-08-15
> > 18:44:03) as a workaround for 2.6.18.1.
> >
> > Now I have tested your patch with bcm43xx: Microcode rev 0x12
On Friday 20 October 2006 12:02, Bin Zhang wrote:
> Hi,
>
> I had to use bcm43xx: Microcode rev 0x122, pl 0x9a (2005-08-15
> 18:44:03) as a workaround for 2.6.18.1.
>
> Now I have tested your patch with bcm43xx: Microcode rev 0x127, pl 0xe
> (2005-04-18 02:36:27), it works fine for three hours.
Hi,
I had to use bcm43xx: Microcode rev 0x122, pl 0x9a (2005-08-15
18:44:03) as a workaround for 2.6.18.1.
Now I have tested your patch with bcm43xx: Microcode rev 0x127, pl 0xe
(2005-04-18 02:36:27), it works fine for three hours.
( I lost my connection when my wife started using another wifi
c
Hi,
I hopefully found out why we get a watchdog timeout now
and then.
I spent some time thinking, testing, thinking and thinking
and I found out that this bug triggers when there is no network
traffic only (at least for me). That is kind of strange and
I think a possible reason for this is the fol
13 matches
Mail list logo
