I just happen to have an access right now to two Alpha machines,
UP1100 and UP1500, both with Nautilus chipset. Neither of these
can be booted with 2.4.16 or 2.4.17rc1. On an attempt to boot
I can see only messages from a boot loader (aboot):
.....
zero-filling 155872 bytes at 0xffffc0000ad1308
starting kernel vmlinux.......
and that is it. The only thing which works now is a power switch.
The same happens if I try 2.4.17aa1rc1 (Andrea patches).
A kernel with the highest version which I managed to boot so far,
on both machines, is 2.4.13-ac8. Anybody with a handly on what is
going on? I did not check yet if various Alpha specific patches
which were present in "ac" were merged into mainline. But so
far things seem to be quite thorougly broken for Alpha (or at
least Nautilus).
Michal
[email protected]
Try again, this time adding "srmcons" to the boot flags. You're croaking
before we get the console set up under Linux so none of the boot messages are
getting out; srmcons uses the SRM console to print its messages. This won't
fix the bugs, but at least we'll be able to see exactly where you die.
- Pete
Michal Jaegermann wrote:
> I just happen to have an access right now to two Alpha machines,
> UP1100 and UP1500, both with Nautilus chipset. Neither of these
> can be booted with 2.4.16 or 2.4.17rc1. On an attempt to boot
> I can see only messages from a boot loader (aboot):
> .....
> zero-filling 155872 bytes at 0xffffc0000ad1308
> starting kernel vmlinux.......
>
> and that is it. The only thing which works now is a power switch.
> The same happens if I try 2.4.17aa1rc1 (Andrea patches).
>
> A kernel with the highest version which I managed to boot so far,
> on both machines, is 2.4.13-ac8. Anybody with a handly on what is
> going on? I did not check yet if various Alpha specific patches
> which were present in "ac" were merged into mainline. But so
> far things seem to be quite thorougly broken for Alpha (or at
> least Nautilus).
>
> Michal
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, Dec 16, 2001 at 08:20:49PM -0500, Peter Rival wrote:
> Michal Jaegermann wrote:
>
> > I just happen to have an access right now to two Alpha machines,
> > UP1100 and UP1500, both with Nautilus chipset. Neither of these
> > can be booted with 2.4.16 or 2.4.17rc1.
>
> Try again, this time adding "srmcons" to the boot flags. You're croaking
> before we get the console set up under Linux
Thanks. I was not aware of this flag and this is a nice tip.
Unfortunately things lock up immediately before effects of this flag
can be felt. Even with this I am not getting a single line from
a kernel. I tried both on 1500 and 1100. Effects are exactly the same.
Tommorow I will try to graft 'arch/alpha' from 2.4.13-ac8 to 2.4.17rc1
just to see what will happen. Some changes have to be made before this
will even compile. I see that some 'nautilus_init()' function showed up
in 2.4.17rc1 which was not in 2.4.13-ac8. Hm....
I did boot 2.4.13-ac8 on UP1500 but in a short order I collected an
impressive array of "Machine checks" both "Fatal", although machine was
still running to an extent after that, and "Correctable". If somebody
wants to look at them I can oblige. :-) Nothing of that sort showed up
on UP1100 with the same kerel or with older kernels I was able to boot
on 1500.
Michal
On Sun, Dec 16, 2001 at 08:20:49PM -0500, Peter Rival wrote:
> Michal Jaegermann wrote:
>
> > I just happen to have an access right now to two Alpha machines,
> > UP1100 and UP1500, both with Nautilus chipset. Neither of these
> > can be booted with 2.4.16 or 2.4.17rc1. On an attempt to boot
> > I can see only messages from a boot loader (aboot):
> > .....
> > zero-filling 155872 bytes at 0xffffc0000ad1308
> > starting kernel vmlinux.......
> >
> > and that is it. The only thing which works now is a power switch.
> Try again, this time adding "srmcons" to the boot flags. You're croaking
> before we get the console set up under Linux so none of the boot messages are
> getting out; srmcons uses the SRM console to print its messages. This won't
> fix the bugs, but at least we'll be able to see exactly where you die.
>
Perhaps the wording of CONFIG_ALPHA_SRM in Configure.help could be a bit
stronger;
Use SRM as bootloader
CONFIG_ALPHA_SRM
There are two different types of booting firmware on Alphas: SRM,
which is command line driven, and ARC, which uses menus and arrow
keys. Details about the Linux/Alpha booting process are contained in
the Linux/Alpha FAQ, accessible on the WWW from
<http://www.alphalinux.org/>.
The usual way to load Linux on an Alpha machine is to use MILO
(a bootloader that lets you pass command line parameters to the
kernel just like lilo does for the x86 architecture) which can be
loaded either from ARC or can be installed directly as a permanent
firmware replacement from floppy (which requires changing a certain
jumper on the motherboard). If you want to do either of these, say N
here. If MILO doesn't work on your system (true for Jensen
motherboards), you can bypass it altogether and boot Linux directly
from an SRM console; say Y here in order to do that. Note that you
won't be able to boot from an IDE disk using SRM.
If unsure, say N.
Perhaps something like:
If unsure, say N if you boot linux via MILO, or Y if you boot linux via
SRM.
I was fooled by this one also, and with the current text, I read it like
'saying N is safe'.
Jurriaan
--
`That right?' Hawk gave MacReady a long, thoughtful look.
`I'll have to remember that.'
Simon R Green - Hawk & Fisher II Fear and Loathing in Haven
GNU/Linux 2.4.17-rc1 on Debian/Alpha 64-bits 990 bogomips load:1.63 1.20 1.06
On Sun, Dec 16, 2001 at 10:50:13PM -0700, Michal Jaegermann wrote:
>
> Tommorow I will try to graft 'arch/alpha' from 2.4.13-ac8 to 2.4.17rc1
> just to see what will happen.
Not much is left from these changes if one wants to stay within
"reasonable and compilable". :-) Anyway, even after this compiles my
Nautilus boxes still do not boot nor show any inclinations to inform why
they are unhappy.
At the very bottom of arch/alpha/kernel/setup.c one can find the
following:
static int alpha_panic_event(struct notifier_block *this,
unsigned long event,
void *ptr)
{
#if 1
/* FIXME FIXME FIXME */
/* If we are using SRM and serial console, just hard halt here. */
if (alpha_using_srm && srmcons_output)
__halt();
#endif
return NOTIFY_DONE;
}
After I changed "#if 1" to "#if 0" results were that most of the time,
although not always, after aboot loader messages I was sooner or later
quietly back at SRM prompt and yes - "srmcons" was given in boot flags.
On some occasions an attempt to boot would simply lock up. To be sure
this was happening both with CONFIG_ALPHA_LEGACY_START_ADDRESS set
and not set.
Anybody with some ideas where I should really look?
Michal
> A kernel with the highest version which I managed to boot so far,
> on both machines, is 2.4.13-ac8. Anybody with a handly on what is
> going on? I did not check yet if various Alpha specific patches
> which were present in "ac" were merged into mainline. But so
> far things seem to be quite thorougly broken for Alpha (or at
> least Nautilus).
Those and more went into 2.4.16+ so I believe that its probably a new
breakage not a lost diff
On Tue, Dec 18, 2001 at 03:35:13PM +0000, Alan Cox wrote:
Michal Jaegermann wrote:
> > A kernel with the highest version which I managed to boot so far,
> > on both machines, is 2.4.13-ac8.
>
> Those and more went into 2.4.16+ so I believe that its probably a new
> breakage not a lost diff
After a long head scratching and a number of tests it looks to me
now that this was a false alarm. Something seems to be funky with
these new 1500's (caches?). 2.4.17rc2 recompiled with the same
configuration, both generic and a board specific kind, but compiled
on UP1100 does boot UP1100 and it seems to be ok. At least I can
recompile another kernel while using it. :-) Unfortunately I do not
have an access to these 1500's anymore so I cannot check if these
new binaries change anything there. If you wonder about compiler
and binutils versions in all tests they were the same (gcc version 2.96
20000731 (Red Hat Linux 7.1 2.96-87)) with this exception that in
one test i used _also_ a pretty old egcs and 2.4.17rc2 and this
kernel, recompiled on UP1100, behaved too.
To make waters considerable more muddy 2.4.9-12 binaries from Red Hat
updates to 7.1 distribution, which definitely were compiled somewhere
else, not once managed to finish booting UP1500. UP1100 booted that
way, although this was possible, was behaving "strange" throwing
some "machine checks" and weird oopses. This may mean that a hardware
is broken but it may also mean that this particular kernel is stomping
on some memory areas where it should not. It is rather the second
as I did not observe anything of that sort with other kernels I am
using there.
Michal
[email protected]