[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SS20 and SMP using Ross modules



Jurij Smakov wrote:
> 
> On Wed, 2 Nov 2005, Andrew Sharp wrote:
> 
> >> it will boot into SMP, but eventually fails with a "wrong magic" error.
> >
> > eventually fails in what way?  during boot?  after running for two
> > weeks?
> 
> It's probably "cramfs: wrong magic", typical failure message when the
> kernel cannot find the initrd (identified by some 4-byte magic number) in
> the expected place. It might be that there is still some breakage in the
> memory copying routines, which I've hit before.

OK sorry about skimping on the detail there but I was trying to summarise the
situation in case it interested anybody in other timezones.

Freeing initrd memory:2160k freed
cramfs: wrong magic
Press L1-A to return to the boot prom
spin_lock (f0204000) CPU#1 stuck at f0062c94, owner PC(f002b068):CPU(0)
[repeats]

Hope that's right, I've got screen/keyboard attached to the machine rather than
running over a tty.

The system's run overnight except that KStars has bombed (nothing useful in the
backtrace) and a telnet session is telling me:

Message from syslogd@localhost at Wed Nov  2 23:56:18 2005 ...
localhost kernel: Kernel panic: Wheee. Kernel does fpu/atomic unaligned
load/store.

However the desktop and shell still appear to be running which is curious- when
is a panic not a panic?

What I'm planning to do is reboot the system from the same kernel over the LAN
using 2x Sun modules and run it for a few days to check basic stability. I'm the
first to admit that I have limited understanding of this architecture but my
previous experience using Woody suggested adequate reliability, both on
SPARCstations and SPARCservers- whatever some people think of my hack to get the
latter running :-)

> >> Reverting to Ross modules, if I build a standalone kernel I find it's too large
> >> to boot from disc, but I can boot it over the LAN (boot net root=/dev/sda2) and
> >> the system runs SMP reliably. However I notice that while the BogoMIPS rating of
> >> a single CPU is 150 when running SMP it's dropped to 104 per processor- I
> >> thought this was calibrated using a tight loop?
> 
> The old trick to reduce the size of the image on sparc32 to acceptable one
> is to run the following command on the image after the build:
> 
> strip -R .comment -R .note -K sun4u_init -K _end -K _start image
> 
> This strips it of non-essential sections, decreasing its size quite
> dramatically.

Thanks, I think this is probably what I'm looking for and I'll investigate.
Obviously non-essential code has already been modularised. Is that sun4u_init
appropriate for sun4cdm?

> >> I'm assuming that none of the core developers will be looking at this because of
> >> the age of the hardware, and I don't have the hardware information to even start
> >> making sense of this sort of problem. However as a workaround can anybody point
> >> me at the documentation that describes the Debian/SPARC-specific kernel rebuild
> >> procedure- running the standard "make vmlinux" gives me a kernel image of around
> >> 2Mb.
> >>
> >> My position is that I'm keen on promoting Sun kit for in-house use, but having
> >> to boot over the LAN makes it difficult to argue that they are a viable
> >> alternative to PCs, and if I'm not confident making that argument I'm not going
> >> to put my neck on the block and ask for money for newer systems.
> 
> I gave up on sparc32 after multiple attempts to make 2.6.11 and 2.6.12
> work reliably on my Hypersparc system failed. I've recently got myself a
> new SS20 with hypersparc CPUs, so I'm currently trying to figure out how
> 2.6.14 will behave on it. Hopefully, I'll have something definite to say
> about by weekend, so stay tuned :-). I am pretty sure that SMP will not
> work though.

I think a line has to be drawn somewhere. I want to get Sarge working on this
kit since I need to demonstrate FPC/Lazarus running on non-PCs and think it's
prudent to start with a binary port of the compiler. In general I'd suggest that
getting 2.4 working on 32-bit SPARCs is worthwhile, with any work in later
releases limited to making sure that 2.4 can be used as a fallback from 2.6 or
whatever. For some reason I can't successfully build 2.2 under Sarge, but that
and getting one or more SPARCservers running are fairly low on my list of
priorities.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]



Reply to: