Bug 57529 - Current updates to 7.1 make impossible to boot UP1100
Summary: Current updates to 7.1 make impossible to boot UP1100
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: alpha
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-14 22:14 UTC by Michal Jaegermann
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-07 23:35:40 UTC
Embargoed:


Attachments (Terms of Use)
Output from 'cat /proc/cpuinfo' for the machine in question (468 bytes, text/plain)
2001-12-14 22:15 UTC, Michal Jaegermann
no flags Details
All startup messages - note that a date ended up as Dec 31 2000 (2.65 KB, application/x-gunzip)
2001-12-14 22:18 UTC, Michal Jaegermann
no flags Details
results of ksymoops run on "oops" from the previous attachment (2.73 KB, text/plain)
2001-12-14 22:20 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2001-12-14 22:14:10 UTC
Description of Problem:

Applying all existing updates to 7.1 made impossible to boot
Alpha UP1100 (output from 'cat /proc/cpuinfo' attached).
The whole process hangs in various initialization stages seemingly
in a random manner although hangs on file system checks seem to be
vastly preferred.

Once I managed to get "oops" and save it.  A whole boot message
and decoded oops are attached as well.

Closer investigation revealed that problems are really caused by
these pieces of a startup which attempt to mess with a system clock.

After commenting these lines in /etc/rc.d/rc.sysinit

/sbin/hwclock --adjust
/sbin/hwclock $CLOCKFLAGS

and also this:

runcmd $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAG

in /etc/rc.d/init.d/halt and after adding in /etc/modules.conf

alias char-major-10-135 off

not only my machine boots and runs without any incidents but, on the
top of it, has correct time.  Before fixing this extreme bogosity
after every screwed up boot attempt I was ending up with fantastic
dates scattered all over the place which was making fixup jobs so much
harder.  Alphas usually have rather decent clocks on boards, as
opposed to x86 hardware, and random messing with them on a startup is,
and always was, counterproductive and problems caused by such meddling
were reported in the past.

NOTE: I just got another Alpha with a Nautilus chipset which is a
new UP1500.  This one, so far, does not boot _any_ kernel from Red
Hat.  I have at this moment one which does boot but it is not from
any RH distribution or updates.  I will file more when I will have
at least _some_ hard information.

  Michal
  michal

Comment 1 Michal Jaegermann 2001-12-14 22:15:39 UTC
Created attachment 40690 [details]
Output from 'cat /proc/cpuinfo' for the machine in question

Comment 2 Michal Jaegermann 2001-12-14 22:18:39 UTC
Created attachment 40691 [details]
All startup messages - note that a date ended up as Dec 31 2000

Comment 3 Michal Jaegermann 2001-12-14 22:20:24 UTC
Created attachment 40692 [details]
results of ksymoops run on "oops" from the previous attachment

Comment 4 Alan Cox 2003-06-07 23:35:40 UTC
Alpha is no longer supported



Note You need to log in before you can comment on or make changes to this bug.