Re: kernel v2.4.11 seems to work now for my Alpha machine
I got a response back from Jay Estabrook of Compaq explaining (at least
to my my level of understanding and beyond) why it started working. In
essence, the Redhat-axp-list newsgroup also showed similar problems. I
suppose because he read that group more than the Debian-alpha, it got
some attention and was fixed. However, the debian-alpha newsgroup was
never notified.
Both of my Alphas have been running 2.4.12 ever since it was released
(actually since 2.4.11 which was short-lived). I hope to try out
reiserfs soon.
I attach his comments.
On Monday 22 October 2001 11:09 am, you wrote:
> On Wednesday 10 October 2001 05:05 pm, James D. Freels wrote:
> > Recall several instances in the past to this mailing list with
> > regard to previous versions of the 2.4.x Linux kernel causing one
> > of my Alphas to lock up (hard). There have been several
> > explanations offered including the de4x5 driver (for DE-500-aa
> > card), tulip driver, scsi driver (ncr-53c810), compiler version
> > (gcc vs egcs), etc. Well, it doesn't matter now because it is
> > working. I did nothing particular revolutionary in the
> > configuration (it is a straight oldconfig from the 2.2.19
> > configuration), but for some reason, it is now working as it
> > should. This has been going on since 2.4.0 release.
>
> I've also been successful getting 2.4.12 and 2.4.13-pre5 running on
> my Alpha of (nearly) the same configuration that none of the previous
> 2.4.x kernels would run on. It has been up and running with jobs,
> network, and NFS for the weekend without trouble. We'll see how it is
> now that users have started showing up.
>
> I suppose it might be worthwhile to have a look through the kernel
> and changelogs to see why 2.4.11 and beyond work now.
>
> Marty Sanborn
Re: kernel v2.4.11 seems to work now for my Alpha machine
From: Jay Estabrook <Jay.Estabrook@compaq.com>
To: "James D. Freels" <freelsjd@ornl.gov>
On Wed, Oct 10, 2001 at 06:05:21PM -0400, James D. Freels wrote:
>
> Recall several instances in the past to this mailing list with regard
> to previous versions of the 2.4.x Linux kernel causing one of my
Alphas
> to lock up (hard). There have been several explanations offered
> including the de4x5 driver (for DE-500-aa card), tulip driver, scsi
> driver (ncr-53c810), compiler version (gcc vs egcs), etc. Well, it
> doesn't matter now because it is working. I did nothing particular
> revolutionary in the configuration (it is a straight oldconfig from
the
> 2.2.19 configuration), but for some reason, it is now working as it
> should. This has been going on since 2.4.0 release.
Ah, now I remember, you were one of the folks with a PC164 that was
having problems with the latest kernels.
Thanks for the feedback about things now working.
Sorry I didn't get back to you, and some other folks on the Debian list
with the same problem, when I submitted some patches that I was hopeful
had solved the problem.
In case you're interested in what the problem was, and how I tried to
fix it, I've attached my posting on the subject to the axp-list.
Let me know if you have any more problems of the same kind.
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook Alpha Engineering - LINUX
Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752 Jay.Estabrook@compaq.com
-----------------------------------------------------------------------------
From: Jay Estabrook <Jay.Estabrook@compaq.com>
To: axp-list@redhat.com
Subject: Re: Hangs with 100baseTX, RedHat 7.1, kernel 2.4.x and AlphaPC
164
In-Reply-To: <3BBCB6E3.F2E5C0@alpha.lists.logout.sh>; from
mpb@alpha.lists.logout.sh on Thu, Oct 04, 2001 at 09:21:46PM +0200
On Thu, Oct 04, 2001 at 09:21:46PM +0200, Mads Peter Bach wrote:
>
> > Yes, well, the 2.2. kernels dealt with a PC164 "anomaly" much
better,
> > and even 2.4.10 deals with it, but ONLY if you've booted from MILO.
>
> Ahhh:-) Palcode fixes?
Actually, no.
History
-------
The PC164 mobos were shipping before it was detected that the IRQ
masking hardware chips were broken. The problem was never fixed in
hardware, correct functioning depends on a software workaround.
Kernel 2.0 and 2.2 IRQ processing didn't require, or could easily be
prevented from using, working IRQ masking hardware.
Kernel 2.4 originally did require working IRQ masking hardware because
it
wants to:
1. MASK off the current interrupt
2. lower IPL to allow any other interrupts (ie any priority) to come
through
Patches were introduced specifically for PC164 that worked around the
problem by not lowering IPL below the current interrupt.
However, they worked only for PC164 running with MILO, because MILO
correctly sets up the HWRPB to indicate EB164 family and PC164
variation, while SRM console indicates EB164 family and (erroneously)
EB164 variation. I don't know how it ever worked even as well as it
did (from SRM).
So, the new patches correctly identify the PC164 variation and
correctly activate the above workaround.
> Colour me impressed! That was quick. The patch seems to work great.
Well, I'd actually worked it out last week from some other reports of
the same problem... ;-}
> Is there a patch for the clock detection problem among the ones that
> have been submitted to Linus? (I currently have to use the cycle
> kernel parameter, to get sane BogoMIPS and timer ticks - even though
> I was quite impressed with 2900 BogoMIPS from a 366 MHz EV56)
Maybe; I solved a problem with a machine which was hanging hard in
the new code that attempts to use the programmable interval timer
to calculate the correct cycle frequency, but I'm not sure it's the
same problem.
I think maybe Ivan has some patches that do a better job in that area,
and I know he's going to submit them soon. Maybe he'll post them here
for some additional testing... :-) :-)
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook Alpha Engineering - LINUX
Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752 Jay.Estabrook@compaq.com
-----------------------------------------------------------------------------
--
James D. Freels, P.E._i, Ph.D.
Oak Ridge National Laboratory
freelsjd@ornl.gov - work
jdfreels@home.com - home
Reply to: