dual G4 time issues..

dual G4 time issues..

[Troy Benjegerdes]

On Sat, 12 Aug 2000, Gabriel Paubert wrote:

>
> On Sat, 12 Aug 2000, Paul Mackerras wrote:
>
> > Gabriel Paubert writes:
> >
> > > > Certainly on my 7600 with a 2-cpu powersurge board, with the code that
> > > > is currently in the devel kernel to use the tb register, you don't get
> > > > the same time on both cpus.
> > >
> > > Yes, we need a way to check that the timebase are in sync and to sync
> > > them if they are not. That's basically the same problem in any case.
> > > The problem is to do it in a way that works on all machines...
> >
> > Until we get SMP working on the 2-cpu G4 machines (hopefully I will be
> > getting one soon), the old powersurge board is the only supported SMP
> > powermac.  I found with mine that when you start the second CPU, it
> > stops the decrementers (and I expect timebases as well) on both CPUs
> > until you send an interrupt from the primary to the secondary cpu.

Benh and I are pushing Mac G4 SMP patches into the recently
created linuxppc_2_5 tree. It currently seems to work reasonably well,
except there is some work needing to be done on syncing the timebases on
CPU's. I seem to have about a 14 second difference between the 2 CPU's on
the machine I'm testing on now.

(from ping -f)

43505 packets transmitted, 43504 packets received, 0% packet loss
round-trip min/avg/max = -144657.0/0.1/144657.3 ms


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

dual G4 time issues..

[Henry Worth]

From: Troy Benjegerdes <hozer@drgw.net>

>Benh and I are pushing Mac G4 SMP patches into the recently
>created linuxppc_2_5 tree. It currently seems to work reasonably well,
>except there is some work needing to be done on syncing the timebases on
>CPU's. I seem to have about a 14 second difference between the 2 CPU's on
>the machine I'm testing on now.
>
>(from ping -f)
>
>43505 packets transmitted, 43504 packets received, 0% packet loss
>round-trip min/avg/max = -144657.0/0.1/144657.3 ms

Troy,

Has your SMP G4 work in Ben's 2.2.18 source tree been folded
into any of the 2.4 source trees?

So far the main problem I'm seeing with the SMP G4 and smp
2.2.18pre4-ben1 is the system hangs up occasionally in xpmac
rev 10, usually when closing an app or logging out. But I've seen
nearly as many xpmac hangs in 2.2.17pre20-ben1 on a Pismo, but
there I can switch VT's and recover. Whereas, on the SMP G4, VT
switches won't work (USB -vs- ADB/PMU?). But, I can't telnet in
either, so maybe it is a hard hang (though enough is alive that it
pings -- not that that means much). Of course, if I have already
telnet'ed in, it never hangs... Will hopefully have time
to build and give XF86 4.0.x a try in a few days.

Other than that, the other problems are the general non-SMP
Rage128 nits of the 2.2.18 fb backport (character rendering
artifacts and occasional raster flickers that probably
indicate non-optimal mclk/sclk settings).

Currently, I've got the CPU load up in the 1.4-1.6 range with
no impact on GUI responsiveness and XMMS playing a CD digitally
without dropping a beat.

Thanks,
Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual G4 time issues..

[Benjamin Herrenschmidt]

>
>So far the main problem I'm seeing with the SMP G4 and smp
>2.2.18pre4-ben1 is the system hangs up occasionally in xpmac
>rev 10, usually when closing an app or logging out. But I've seen
>nearly as many xpmac hangs in 2.2.17pre20-ben1 on a Pismo, but
>there I can switch VT's and recover. Whereas, on the SMP G4, VT
>switches won't work (USB -vs- ADB/PMU?). But, I can't telnet in
>either, so maybe it is a hard hang (though enough is alive that it
>pings -- not that that means much). Of course, if I have already
>telnet'ed in, it never hangs... Will hopefully have time
>to build and give XF86 4.0.x a try in a few days.
>
>Other than that, the other problems are the general non-SMP
>Rage128 nits of the 2.2.18 fb backport (character rendering
>artifacts and occasional raster flickers that probably
>indicate non-optimal mclk/sclk settings).
>
>Currently, I've got the CPU load up in the 1.4-1.6 range with
>no impact on GUI responsiveness and XMMS playing a CD digitally
>without dropping a beat.

I had reports of pthread-intensive applications having the threads
randomly "hang" when running on the SMP 2.2.x kernel. This happens on PPC
only (works fine with the same kernel on x86) and it's fine on UP.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual G4 time issues..

[Henry Worth]

Benjamin Herrenschmidt wrote:
>
>
> I had reports of pthread-intensive applications having the threads
> randomly "hang" when running on the SMP 2.2.x kernel. This happens on PPC
> only (works fine with the same kernel on x86) and it's fine on UP.
>

I'll look into getting a serial port on this machine so I can
try some debugging. Any recommendations what sort of PCI I/O
card would work best, or would one of those gadgets that
replaces the modem be a better bet? I'll guess I should
also look into the modem cross-over cable trick.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual G4 time issues..

[Michel Lanners]

On  19 Sep, this message from Henry Worth echoed through cyberspace:
> I'll look into getting a serial port on this machine so I can
> try some debugging. Any recommendations what sort of PCI I/O
> card would work best, or would one of those gadgets that
> replaces the modem be a better bet?

Go for the modem-replacement-thing, if you don't need the modem. That
will give aou a standard Mac-style serial port, supported
out-of-the-box.

On the other hand, PCI serial boards are supported as of very recently,
and I'm not sure whether/if that suport has found it's way into current
PPC kernels.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/