Red Hat Bugzilla – Bug 61335
kernel 2.4.9-24 simply does not boot
Last modified: 2007-04-18 12:40:59 EDT
Description of Problem:
vmlinuz-2.4.9-24 as supplied in beta2 does not even start booting
UP1500 (Nautilus). After an initial load by aboot everythig immediately
freezes with not a single line of boot messages showing up and a hardware
reset as the only way out.
With patches which made possible to at least install (see #61326), and
aboot.conf fixed to load initrd (see #61333), this kernel attempts to
start but it dies violently in an init sequence, with a series of
assorted machine checks, when trying to mount disks. Unfortunately
because none of disks gets mountes there are not traces of all this in
log files. Based on various symptoms I have a feel, but no a proof, that
use of initrd is here a killing factor.
Yes, I am running this beta now but a kernel used has not much
with sources and configurations as delivered. Mine is also not perfect
so far but at least I can boot and do few things (like compile this and that).
Attached is a set of patches which I am currently using to get from 2.4.9-31.1
(rawhide) a working kernel on my Alpha. This set includes also patches which
I left on bugzilla on other occasions and they are included here for
After spending recently a considerable time working, in a very close cooperation
with Ivan Kokshaysky, on Nautilus code I am really convinced that what in
Red Hat sources figures as "linux-2.4.3-nautilus.patch" is thoroughly broken.
"linux-2.4-unrh.nautilus.patch" among other things reverses that damage but
not only. Other things are not really Nautilus specific. Kernels also have
to be compiled with CONFIG_BLK_DEV_ALI15X3=y or otherwise a performance
of IDE drivers with built-in Nautilus controllers is unacceptable. Also
built-in sound on these boards requires Trident support.
For a correct operation UP1500 machines have to have SRM updated to at least
5.6-18 version. Alternatives are too painful for a general use.
Created attachment 56105 [details]
Patches to get a working kernel
1) The period for kernel patchs beinging included has expired and I'm prevented
from making changes at this time.
2) I unfortunately don't have access to Nautilus alpha HW so I cannot test.
Consequently this will likely have to be an errata item.
Now I did look at these patchs and some of them are already part of the final kernel
linux-2.4.9-alidma.patch - I'd want to run by Andre Hendrik first
linux-2.4.9-alpha_time.patch - is in but with a small tweak to the
linux-2.4.9-denorm.patch - this is already in
linux-2.4.9-memsetS.patch - not applied
linux-2.4.9-mga_drv.patch - not applied
linux-2.4.9-nrsyscalls.patch - not applied
linux-2.4.9-trident.patch - not applied
linux-2.4.9-vsprintf.patch - looks cosmetic zero impact
linux-2.4-unrh.nautilus.patch - This was partially replaced by another chipset
+linux-2.4.9-alidma.patch - I'd want to run by Andre Hendrik first
This is really a wrong mask for devices and does not go into IDE
+linux-2.4.9-denorm.patch - this is already in
+linux-2.4.9-memsetS.patch - not applied
Not a very big deal as a compiler covers here your ass.
+linux-2.4.9-mga_drv.patch - not applied
Cosmetics in a sense but annoying. Generates around 400 warnings
from a _debugging_ code if not used.
+linux-2.4.9-nrsyscalls.patch - not applied
This is a really serious bug with an obvious fix. Anyway grep for
'quad' in entry.S.
+linux-2.4.9-trident.patch - not applied
You have obvious typos (missing pieces of line) in code which prevents
a compilation of a required module. A part of it was already provided
a long time ago in another bugzilla entry.
+linux-2.4.9-vsprintf.patch - looks cosmetic zero impact
Agreed on cosmetics in a sense. Actually you may be surprised to
learn that impact is very far from negligible :-) but if other things
are correct that should not be visible. The fact that the code
is wrong was very helpful in finding much more serious problem. :-)
+linux-2.4-unrh.nautilus.patch - This was partially replaced by another chipset
What I cold find in the latest available for me your code (rawhide
sources) was plain broken. I cannot comment on what I have not seen.
UP1500 does requires a special treatment, due to differences in
chipsets, or is unusable. Some can test it and listening to what they
have to say could be worthwhile.