Bug 58498

Summary: 2.4.9-14a does not boot on UP1500
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: kernelAssignee: Beth Uptagrafft <bhu>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-08 00:26:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
a patch which makes 2.4.9-14a bootable again
patches to make 2.4.9-14a bootable
patch to allow various Nautilus machine to boot none

Description Michal Jaegermann 2002-01-18 05:18:26 UTC
Description of Problem:

On UP1500 (Nautilus) new Alpha from Samsung 2.4.9-14aBOOT
used on an installation CD does not boot making an installation
rather difficult.  The same applies to an installed 2.4.9-14a

Tu put a matter in some perspective a kernel used on installation
CDs for 7.1 Alpha distribution, i.e. 2.4.3-12BOOT, does not have
any problems.

I attach below minimal patches which are required to make this
kernel bootable.  They are derived from other patches provided by
Samsung but they are not the same.  Unfortunately I can tell only
that they work for me, and kernels patches that way boot also
another Nautilus, i.e. UP1100, but I can only guess why they may

More precisely - an attempt to boot with an unpatched kernel
generates a number of "Machine checks" during a startup and machine
quickly locks up somewhere in an initialization sequence.


  IRONGATE0->agpva = (IRONGATE0->agpva & ~0x0000000f) | 0x00000007;

statement in core_irongate.c is NOT commented out but the other patch
applied then machine checks disapper but a computer dies while
attempting to turn on swap or access a file system with
"Kernel panic: Aiee. Killing interrupt handler! In interrupt handler
- not syncing."  With all changes in place it is possible to boot
and things seem to be stable.


Comment 1 Michal Jaegermann 2002-01-18 05:19:48 UTC
Created attachment 42774 [details]
a patch which makes 2.4.9-14a bootable again

Comment 2 Michal Jaegermann 2002-01-18 06:20:45 UTC
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.

Comment 3 Michal Jaegermann 2002-01-30 23:43:58 UTC
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@jurassic.park.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
  - trident.patch adds obviously missing piece of a code line

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

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. :-)

Comment 4 Michal Jaegermann 2002-01-30 23:46:09 UTC
Created attachment 44057 [details]
patches to make 2.4.9-14a bootable

Comment 5 Michal Jaegermann 2002-02-08 18:39:55 UTC
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.

Comment 6 Michal Jaegermann 2002-02-24 18:52:48 UTC
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

Comment 7 Michal Jaegermann 2002-02-24 18:54:16 UTC
Created attachment 46542 [details]
patch to allow various Nautilus machine to boot

Comment 8 Alan Cox 2003-06-08 00:26:31 UTC
Alpha is no longer a supported platform