Dick:
>First, look at /usr/src/linux/.config . Make certain that no
>DEC Alpha stuff is enabled. Here is an example.
I checked for any Alpha lines in the .config and found none. Also
remember that the kernels I have been building will boot fine on
other systems. I would expect that the kernel would not work at all
if any Alpha config options were enabled.
>Next if Video BIOS shadow is enabled, at least temporarily turn it off.
>Actually if any BIOS shadow is enabled, turn it off. the BIOS is
>only used during boot so any shadowing will do nothing once Linux is
>up except waste RAM which Linux could be using.
I disabled all the BIOS shadow with no change. I also tried disabling
internal and external cache with no change. I disabled something called
"fast boot" with no change (execpt it now hangs very slowly). I tried
disabling the IDE "Smart" function also without change. I also pulled
out version 4 of RedHat to test with and found that it's install kernel,
(v2.0) hangs. Unlike RedHat version 5.2/6.0/6.1 that will install without
error. I don't know what to do next.
On some other hardware platforms that I have worked on, (PDP11, VAX, SPARC
are
some examples), after a hang you can press some key/keys that will interrupt
the
processor, save the CPU state, and return to a ROM monitor. In that
environment
it would be easy to work on this problem because I could examine the state
of
CPU and memory after the hang. But with the Intel hardware it would seem
that
the only way to recover is to reset, and that destroys all evidence of what
happened. Would it be possible to add a code to setup.S that would allow
me to recover control of the CPU? Maybe set some hardware timer that would
force an interrupt after X seconds, call the debugging routine, that
saves the state of the CPU and drops into a simple monitor? Another
idea I had would involve adding a hardware card that could provide
the monitor function in BIOS code, (but that would be a big project),
(I wonder if any vender sells something like this?). The only other way
to debug this is to wander around the source code looking for anthing that
may affect this problem, modify it, and test. This method will take forever!
I would also need to be much more intimate with the Intel architecture to be
any good at this so add a big learning curve. (I think I will shop for a
used
Sparc or Alpha at the Dayton Hamvention, and curse Intel!!!!!)
Any help or ideas about this problem are welcome!
Todd Markley
-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
Sent: Monday, January 31, 2000 9:24 AM
To: 'linux-kernel@vger.rutgers.edu'
Subject: RE: Hangs after "Loading" but before "Uncompressing"
On Sun, 30 Jan 2000, Markley, Todd wrote:
> Dick:
> I installed version 2.3.40 of the linux kernel and
> installed your patch. The result is that it still hangs
> the same way. So now I have continued to add debugging
> prints to video.S to find the exact location of the hang.
> The result is that it locks up in the "basic_detect:"
> routine at the first "int $0x10". It looks to me like
> this routine is trying to identify the type of display.
> So I tried to help out a little by changing the subroutine
> to read this way:
>
> basic_detect:
> movb $0x1a, %al # 1a means VGA...
> incb adapter
> incb adapter
> ret
>
>
> If I understand what the routine is doing then this should
> return as if a VGA was detected. (I may have missed something
> here, but it boots ok on another system.) The kernel will now
> do the "vga=ask", and I can select mode zero. Next the system
> hangs in the "restore_screen:" subroutine. Do you have any new
> ideas? Is this "int $0x10" function in the motherboard BIOS or
> in the video card BIOS? Could this problem have anything to do
> with video BIOS shadow settings?
First, look at /usr/src/linux/.config . Make certain that no
DEC Alpha stuff is enabled. Here is an example.
#
# Video For Linux
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# ONLY for DEC Alpha architectures
#
CONFIG_FT_ALPHA_CLOCK=0
# CONFIG_DRM is not set
# CONFIG_DRM_TDFX is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
Next if Video BIOS shadow is enabled, at least temporarily turn it off.
Actually if any BIOS shadow is enabled, turn it off. the BIOS is
only used during boot so any shadowing will do nothing once Linux is
up except waste RAM which Linux could be using.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.39 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:11 EST