Hi Matt !
The IBM PowerStation is a machine similar in design to our JS21 blades,
which uses an HT2000 bridge with it's dual 5780 TG3's.
I started investigating recently a problem where with recent kernels,
the machine will appear to freeze every second or two for a second
or two. The freeze
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 25; i++) {
+
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
On Friday 08 August 2008, 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
On Fri, Aug 08, 2008 at 07:18:31PM +1000, Benjamin Herrenschmidt wrote:
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
On Fri, 2008-08-08 at 11:43 -0700, Matthew Carlson wrote:
Segher is right. The code should be 2.5 milliseconds but is actually
much longer. This fix is actually already in my patch queue and needs
to be sent upstream.
Matt, I think we can optimize this a little more. The heart beat event
Benjamin Herrenschmidt wrote:
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
On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote:
Segher is right. The code should be 2.5 milliseconds but is actually
much longer. This fix is actually already in my patch queue and needs
to be sent upstream.
We really shouldn't be displaying any error messages in the event of a
On Fri, 2008-08-08 at 15:05 -0700, Benjamin Herrenschmidt wrote:
On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote:
We really shouldn't be displaying any error messages in the event of a
timeout though. Earlier versions of the UMP firmware did not support
the link update interface.
