Bug 58498

Created attachment 42774 [details]
a patch which makes 2.4.9-14a bootable again

I should add one more thing.  When a few days I had for a moment 4 GB of
a physical memory in UP1500 then I was able to boot this machine with
a similarly patched kernel _provided_ I passed in a boot command 'mem=3872M'.
This was an experimental value with somewhat bigger numbers making
boot impossible.  With smaller amounts of memory no such extra parameters
were required.

Attached archive includes patches for 2.4.9-14a from the first beta
which are needed to support Nautilus chipset machines including
new UP1500 boxes.  This is still work-in-progress and there is no
guarantee that these patches will remain the same but at least without
'linux-2.4.9-rh.ink.patch' UP1500 does NOT boot properly or with
a bigger amount of memory on board, like 4 Gig, does not boot at all.

As you are working on the next beta I would like to avoid situation
when distributed binaries are simply unbootable, like the current
ones, even if there are still not perfect.

Here is a short description:
 -  linux-2.4.9-rh.ink.patch is a sort of minimal patch required to boot;
    with it I can boot and run both UP1500 and UP1100 although with
    2.4.9-14a kernel the later one requires 'ide=nodma' as described
    in #58719.  None of other kernels from 2.4 series which I tried,
    including 2.4.17, displays this problem.

    The patch was principally developed by Ivan Kokshaysky
    <ink.msu.ru> while I was doing testing and supplying
    data.  This work continues.
 
    Basically the same patch works across all current 2.4.x kernels
    with this difference that for "mainline" it does not have to
    undo bogus 'nautilus_init_pci()' stuck into 2.4.9-14a.

  - missing_syms.patch adds symbols required to compile Nautilus
    specific, instead of a generic, kernel.  Present in later 2.4.x
    "mainline".
 
  - trident.patch adds obviously missing piece of a code line

  - core_irongate.cleanup "backports" types patch from later 2.4.x
    kernels

Moreover Trident sound module should be present in configs and binaries
as this is a builtin sound on Nautilus boards which use ALi chipsets.
One issue is that 'trident' configured with 2.4.9-14a prints (???)

Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version
0.14.9c, 13:08:50 Jan 30 2002
trident: architecture does not support 30bit PCI busmaster DMA

while version used in later kernels does:

Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version
0.14.9d, 14:37:46 Jan 28 2002
trident: ALi Audio Accelerator found at IO 0x8400, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881)
ac97_codec: Secondary ac97 codec not present
trident: Running on Alpha system type Nautilus

I cannot tell yet how well it works but at least it does not bitch. :-)

Created attachment 44057 [details]
patches to make 2.4.9-14a bootable

Just a note that I have two different basic approaches to this boot problem
(one obviously broken but it "works" sometimes) and so far there are, disjoint,
configurations when one or another will not boot.  The one from Red Hat is
the most consistent as it does not boot at all, period. :-)  The work continues.

Attached is a patch which I am using currently with various 2.4 kernels.
It does not look like the final word on the topic but it at least boots
various Nautilus machines and works with various memory configurations,
bigger and smaller, on UP1500 boards with 4 and 8 Megabytes caches

Created attachment 46542 [details]
patch to allow various Nautilus machine to boot

Alpha is no longer a supported platform