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 a completness. 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
Two things. 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 LCA4/EV4 timers 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 update Sorry Phil =--=
+ +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 code itself. +linux-2.4.9-denorm.patch - this is already in Good. +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 + update 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.