All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Nathan Lynch <ntl@pobox.com>,
	mcarlson@broadcom.com, Michael Chan <mchan@broadcom.com>,
	netdev <netdev@vger.kernel.org>
Subject: Re: Strange tg3 regression with UMP fw. link reporting
Date: Fri, 08 Aug 2008 19:18:31 +1000	[thread overview]
Message-ID: <1218187111.24157.336.camel@pasglop> (raw)
In-Reply-To: <31233EB5-037E-4615-95C9-7C816E510752@kernel.crashing.org>

On Fri, 2008-08-08 at 10:58 +0200, Segher Boessenkool wrote:
> > I don't know yet for sure what happens, but a quick look at the commit
> > seems to show that the driver synchronously spin-waits for up to 2.5ms
> 
> That's what the comment says, but the code says 2.5 _seconds_:
> 
> +       /* Wait for up to 2.5 milliseconds */
> +       for (i = 0; i < 250000; i++) {
> +               if (!(tr32(GRC_RX_CPU_EVENT) & GRC_RX_CPU_DRIVER_EVENT))
> +                       break;
> +               udelay(10);
> +       }
> 
> (not that milliseconds wouldn't be bad already...)

Right, indeed. I think we have a good candidate for the problem :-) I'll
verify that on monday. Now, that leads to two questions:

 - What such a synchronous and potentially horribly slow code is
going in a locked section or a timer interrupts ? Ie, the link
watch should probably move to a workqueue if that is to remain,
or the code turned into a state machine that periodically check for
events, or whatever is more sane than the above.

 - The code should at least display some error and do something sane in
case of timeout such as disabling the new UMP feature instead of
repeatedly looping ...

 - If this is indeed our problem (timing out in the code above), why is
our firmware not emitting the requested event -> maybe the PowerStations
need a tg3 firmware update.

Matt, what's your take on this ?

Cheers,
Ben.

  reply	other threads:[~2008-08-08  9:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  7:35 Strange tg3 regression with UMP fw. link reporting Benjamin Herrenschmidt
2008-08-08  7:35 ` Benjamin Herrenschmidt
2008-08-08  8:58 ` Segher Boessenkool
2008-08-08  8:58   ` Segher Boessenkool
2008-08-08  9:18   ` Benjamin Herrenschmidt [this message]
2008-08-08 18:43     ` Matt Carlson
2008-08-08 18:43       ` Matt Carlson
2008-08-08 15:20       ` Michael Chan
2008-08-08 15:20         ` Michael Chan
2008-08-08 22:05       ` Benjamin Herrenschmidt
2008-08-08 20:20         ` Michael Chan
2008-08-08 20:20           ` Michael Chan
2008-08-08 21:25     ` Nathan Lynch
2008-08-08 21:25       ` Nathan Lynch
2008-08-08  9:21   ` Arnd Bergmann
2008-08-08  9:21     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1218187111.24157.336.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mcarlson@broadcom.com \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=ntl@pobox.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.