Mailing List Archive

Then you're better off than me. Mine dies hard during init, 2.4.30


I don't know a lot about this. Guessing that the gentoo
specific ross optimizations may be helping me. What setup
or distro are you running. I threw out my email to 3 lists
that cover the gamut. Are you running gentoo? If so, I
can give you my USE and other flags from make.conf to see
what the diff is. Any other of the sparc distros will have a
slightly different setup for gcc, libraries, etc. I wanted
gentoo to get a sun4m optimized ssl setup. Otherwise
gentoo takes an incredibly long time to compile.

Related to that, I did a series of emerges (gentoo speak)
to insure that gcc/libs/kernel were sort-of in sync as I settled
in the environment. You may be fighting some variation of a
kernel/lib problem.

I also have a keyboard attached and that may make a diff.
Again, don't really know.

>from kernel.org, SMP enabled. UP runs OK, though. But we seem to have
>similar hardware:
>
>The only thing I've noticed is that my prom counts the CPUs as 0 and 2:
>
>CPU_#0 HyperSPARC ROSS RT620/RT626 0x00080000 Bytes ECache
>CPU_#2 HyperSPARC ROSS RT620/RT626 0x00080000 Bytes ECache
>
>CPU_#1 ******* NOT installed *******
>CPU_#3 ******* NOT installed *******
>
>Does that hurt?
>
>
No. Usual way it numbers the cpus (believe, not expert).

>I'd like to do some debugging, but I don't know where to start. I have
>no idea where my sparc dies. Cache flushing (these routines are totally
>different for UP and SMP on Hypersparc, as I found out)? Forking and
>context changes? Being a kernel newbie doesn't really help, but I am
>willing to learn,
>

The one kernel that is sort-of guaranteed sparc32 smp
for ross is 2.2 series. May be possible for you to compile
latest 2.2 kernel SMP and try that out. Though I believe
interest is in getting SMP smoothed out and working 2.6.x


--
gentoo-sparc@gentoo.org mailing list

>>Then you're better off than me. Mine dies hard during init, 2.4.30
>>
>>
>>I don't know a lot about this. Guessing that the gentoo
>>specific ross optimizations may be helping me.
>>
>>
>
>I thought you were running stock kernel.org?
>
>
>
I am running stock kernel. But the tool chain is gentoo sparc
and the entire tool chain, libraries, etc. was compiled for my
sparc/ross box. From another email response, guessing the
gentoo optimizations for the libraries/compilers/et al are not
the issue.

>>What setup or distro are you running. I threw out my email to 3 lists
>>that cover the gamut.
>>
>>
>
>Debian woody, sorry, I should have mentioned this.
>
>
>
Debian woody will use a very different (older) tool chain stack then gentoo.
(gcc/libs). Guessing this is likely diff letting me run SMP on roughly
equiv. box.

>>Are you running gentoo? If so, I
>>can give you my USE and other flags from make.conf to see
>>what the diff is. Any other of the sparc distros will have a
>>slightly different setup for gcc, libraries, etc. I wanted
>>gentoo to get a sun4m optimized ssl setup. Otherwise
>>gentoo takes an incredibly long time to compile.
>>
>>
>
>Having only one ISDN line for internet access rules out gentoo or
>Debian testing/unstable or any other download intensive distro for now.
>
>
>
>>Related to that, I did a series of emerges (gentoo speak)
>>to insure that gcc/libs/kernel were sort-of in sync as I settled
>>in the environment. You may be fighting some variation of a
>>kernel/lib problem.
>>
>>
>
>I don't think so, else 2.4.30 would not run UP on my box:
>
>maril:~# uname -a
>Linux maril 2.4.30 #3 Sat Apr 30 20:00:51 CEST 2005 sparc unknown
>maril:~# gcc -v
>Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
>gcc version 2.95.4 20011002 (Debian prerelease)
>
>
>
I'm compiling with gcc 3.3.5 Yours is 2.95.4
My understanding is this is very important re kernel compiles.
Somebody else may want to chime in and note why the gcc
version is (or isn't) important re SMP versus UP.

>[del]
>
>
>>The one kernel that is sort-of guaranteed sparc32 smp
>>for ross is 2.2 series. May be possible for you to compile
>>latest 2.2 kernel SMP and try that out. Though I believe
>>interest is in getting SMP smoothed out and working 2.6.x
>>
>>
>
>I will give 2.2 a spin to gather more info. I bought the system from ebay,
>so there may be a hardware glitch I don't know about, but when it's running
>2.2.x SMP, I think we can rule that out.
>
>
You may want to swap out CPUs, i.e. run with just one, then
just the other, and double check that they're both good.
This is a possibility.
--
gentoo-sparc@gentoo.org mailing list

On Thu, May 05, 2005 at 06:05:31AM -0400, Heitzso wrote:

> I'm compiling current 2.6.x stable (again from kernel.org) now
> just to get a baseline. It seems to have SMP disabled in the
> config in a way that would have to be manually edited to enable.

Um, because it's completely busted?

> I'm not in a position to do in-the-guts debugging by myself
> of SMP sparc32/ross issues. BUT, am quite willing to download
> kernels, patches, etc. and run tests, report on those tests, etc.
> Just let me know.

In the year-plus since you first posted this you could have read, at a
leisurely pace, the entire sparcv8 manual five times and the Linux
smp4m implementation twenty. And if you had, you would be able to fix
the problem instead of testing someone else's nonexistent fixes.
These machines cost, what, ten bucks now? I guarantee you the
limiting factor isn't testing resources.

If you want this port to live, get hacking. If you get stuck, there
are people here who can and often will answer your questions.
Otherwise it's not much use posting periodically to remind people that
you'd like it fixed but aren't willing to do any of the work needed to
make that happen.

--
Keith M Wesolowski

If at first you don't succeed, destroy all evidence that you tried.
--
gentoo-sparc@gentoo.org mailing list

Keith M Wesolowski wrote:

>In the year-plus since you first posted this you could have read, at a
>leisurely pace, the entire sparcv8 manual five times and the Linux
>smp4m implementation twenty. And if you had, you would be able to fix
>the problem instead of testing someone else's nonexistent fixes.
>These machines cost, what, ten bucks now? I guarantee you the
>limiting factor isn't testing resources.
>
>If you want this port to live, get hacking. If you get stuck, there
>are people here who can and often will answer your questions.
>Otherwise it's not much use posting periodically to remind people that
>you'd like it fixed but aren't willing to do any of the work needed to
>make that happen.
>
>
>
If someone could point to a couple of the broken places
that need work for sparc32 smp to function I'll look at them.

Does someone maintain a task list for sparc32 SMP?
I.e. a list of code blocks that need to be cleaned up in order
for sparc32 SMP to work?

Wouldn't this be good for the ultralinux site to manage?
Is that possible?

Thanks
--
gentoo-sparc@gentoo.org mailing list