2.6.x SMP RED_state in prom_startcpu()

2.6.x SMP RED_state in prom_startcpu()

[William Lee Irwin III]

Well, the bootlogs are rather uninteresting, but I've got a 2x u2 that
seems to drop into RED_state after calling prom_startcpu() on 2.6 (I
narrowed it down with prom_printf()'s). UP seems comes up fine. I sort
of flopped in an attempt to write a RED_state trap handler to get a
backtrace or determine the cause, so I'm punting for the moment.


-- wli

Re: 2.6.x SMP RED_state in prom_startcpu()

[Ben Collins]

On Fri, Jan 30, 2004 at 06:59:09PM -0800, William Lee Irwin III wrote:
> Well, the bootlogs are rather uninteresting, but I've got a 2x u2 that
> seems to drop into RED_state after calling prom_startcpu() on 2.6 (I
> narrowed it down with prom_printf()'s). UP seems comes up fine. I sort
> of flopped in an attempt to write a RED_state trap handler to get a
> backtrace or determine the cause, so I'm punting for the moment.

Which 2.6? I have latest 2.6 from bk booting on my 2xU2 just fine.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: 2.6.x SMP RED_state in prom_startcpu()

[William Lee Irwin III]

On Fri, Jan 30, 2004 at 06:59:09PM -0800, William Lee Irwin III wrote:
>> Well, the bootlogs are rather uninteresting, but I've got a 2x u2 that
>> seems to drop into RED_state after calling prom_startcpu() on 2.6 (I
>> narrowed it down with prom_printf()'s). UP seems comes up fine. I sort
>> of flopped in an attempt to write a RED_state trap handler to get a
>> backtrace or determine the cause, so I'm punting for the moment.

On Fri, Jan 30, 2004 at 10:07:59PM -0500, Ben Collins wrote:
> Which 2.6? I have latest 2.6 from bk booting on my 2xU2 just fine.

bk from a couple of days ago. Sorry, I needed to put the compiler in.
I tried with gcc-3.3.2 and gcc-3.2.3 releases as i386-linux-gnu to
sparc64-unknown-elf cross-compilers.


-- wli

Re: 2.6.x SMP RED_state in prom_startcpu()

[Ben Collins]

On Fri, Jan 30, 2004 at 07:17:21PM -0800, William Lee Irwin III wrote:
> On Fri, Jan 30, 2004 at 06:59:09PM -0800, William Lee Irwin III wrote:
> >> Well, the bootlogs are rather uninteresting, but I've got a 2x u2 that
> >> seems to drop into RED_state after calling prom_startcpu() on 2.6 (I
> >> narrowed it down with prom_printf()'s). UP seems comes up fine. I sort
> >> of flopped in an attempt to write a RED_state trap handler to get a
> >> backtrace or determine the cause, so I'm punting for the moment.
> 
> On Fri, Jan 30, 2004 at 10:07:59PM -0500, Ben Collins wrote:
> > Which 2.6? I have latest 2.6 from bk booting on my 2xU2 just fine.
> 
> bk from a couple of days ago. Sorry, I needed to put the compiler in.
> I tried with gcc-3.3.2 and gcc-3.2.3 releases as i386-linux-gnu to
> sparc64-unknown-elf cross-compilers.

The cross-compilation may be the issue. Want to try a native build to
make sure?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: 2.6.x SMP RED_state in prom_startcpu()

[William Lee Irwin III]

On Fri, Jan 30, 2004 at 10:07:59PM -0500, Ben Collins wrote:
>>> Which 2.6? I have latest 2.6 from bk booting on my 2xU2 just fine.

On Fri, Jan 30, 2004 at 07:17:21PM -0800, William Lee Irwin III wrote:
>> bk from a couple of days ago. Sorry, I needed to put the compiler in.
>> I tried with gcc-3.3.2 and gcc-3.2.3 releases as i386-linux-gnu to
>> sparc64-unknown-elf cross-compilers.

On Fri, Jan 30, 2004 at 10:52:12PM -0500, Ben Collins wrote:
> The cross-compilation may be the issue. Want to try a native build to
> make sure?

Trying to get luserspace bootstrapped enough to do this now. I'll start
pinging gcc hackers if that works and hence shows cross builds bust.


-- wli

Re: 2.6.x SMP RED_state in prom_startcpu()

[William Lee Irwin III]

On Fri, Jan 30, 2004 at 10:52:12PM -0500, Ben Collins wrote:
>> The cross-compilation may be the issue. Want to try a native build to
>> make sure?

On Fri, Jan 30, 2004 at 08:24:26PM -0800, William Lee Irwin III wrote:
> Trying to get luserspace bootstrapped enough to do this now. I'll start
> pinging gcc hackers if that works and hence shows cross builds bust.

I got a native toolchain going. 2.4.24 flies with the 2nd cpu online.
2.6.x fails in prom_startcpu(). Cross-builds fail for both.


-- wli

Re: 2.6.x SMP RED_state in prom_startcpu()

[William Lee Irwin III]

On Fri, Jan 30, 2004 at 10:52:12PM -0500, Ben Collins wrote:
>>> The cross-compilation may be the issue. Want to try a native build to
>>> make sure?

On Fri, Jan 30, 2004 at 08:24:26PM -0800, William Lee Irwin III wrote:
>> Trying to get luserspace bootstrapped enough to do this now. I'll start
>> pinging gcc hackers if that works and hence shows cross builds bust.

On Sat, Feb 07, 2004 at 09:06:10PM -0800, William Lee Irwin III wrote:
> I got a native toolchain going. 2.4.24 flies with the 2nd cpu online.
> 2.6.x fails in prom_startcpu(). Cross-builds fail for both.

I've "reseated" the cpus and the RAM, as best I can anyway (I couldn't
fully dislodge them for reinsertion, so I had to settle for pressing
down on them a bit without actually removing them). Going over things
again shows that the current conclusions are:

(a) cross-builds of both 2.4 and 2.6 are bust in SMP regardless of
	compiler version, but both 2.4 and 2.6 work UP regardless of
	compiler version
(b) 2.6 SMP is also bust built natively, regardless of compiler version
(c) The only working Linux SMP datapoints are native builds of 2.4.24,
	regardless of compiler version.
(d) Solaris still boots and works SMP.

This is weird, because u2's supposedly fly in 2.6 for others.

I'm going to have to ignore the cross-build issue and move on to why
2.6 is exploding. I've narrowed the window where the exception happens
down to the call to prom_startcpu() via prom_printf(). I like to think
that I usually have more clue but I'm a bit new to UltraSPARC, so a
general direction like "go dump $FOO via prom_printf()" or "try to
install a RED_state handler" (which I've actually tried and failed at
once) might be handy here.

Thanks.


-- wli