Canonicalize the video mode number as presented to the kernel. The
video mode number may be user-entered (e.g. ASK_VGA), an alias
(e.g. NORMAL_VGA), or a size specification, and that confuses the
suspend wakeup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Apparently XEN does not keep the contents of the 48-bit gdt_48 data
structure that is passed to lgdt in the XEN machine state. Instead it
appears to save the _address_ of the 48-bit descriptor
somewhere. Unfortunately this data happens to reside on the stack and
is probably no longer availiable at the time of the actual protected
mode jump.
This is Xen bug but given that there is a one-line patch to work
around this problem, the linux kernel should probably do this. My fix
is to make the gdt_48 description in setup_gdt static (in setup_idt
this is already the case). This allows the kernel to boot under
Xen HVM again.
Signed-off-by: Christian Ehrhardt <lk@c--e.de>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The VESA BIOS is specified to be register-clean. However, we have now
found at least one system which violates that. Thus, be as paranoid
about VESA calls as about everything else.
Huge thanks to Will Simoneau for reporting, diagnosing, and testing
this out on Dell Inspiron 5150.
Cc: Will Simoneau <simoneau@ele.uri.edu>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Passing a u8 into a register doesn't mean gcc will zero-extend it.
Also, don't depend on thhe register not to change.
Per bug report from Saul Tamari.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
asm() statements need to be volatile when:
a. They have side effects (other than value returned).
b. When the value returned can vary over time.
c. When they have ordering constraints that cannot be expressed to gcc.
In particular, the keyboard and timer reads were violating constraint (b),
which resulted in the keyboard/timeout poll getting
loop-invariant-removed when compiling with gcc 4.2.0.
Thanks to an anonymous bug reporter for pointing this out.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When filling in the MBR signature array, the setup code failed to advance
boot_params.edd_mbr_sig_buf_entries, which resulted in the valid data
being ignored.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
At least one machine has been identified in the field which advertises
EDD for all drives but locks up if one attempts an extended read from
a non-primary drive.
The MBR is always at CHS 0-0-1, so there is no reason to use an
extended read, other than the possibility that the BIOS cannot handle
it.
Although this might break as many machines as it fixes (a small number
either way), the current state is a regression but the reverse is not.
Therefore revert to the previous state of not using extended read.
Quite probably the Right Thing to do is to read using plain (CHS) read
and extended read on failure, but that change would definitely have to
go through -mm first.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The current display page is an 8-bit number, even though struct
screen_info gives it a 16-bit number. The number is returned in %bh,
so it needs to be >> 8 before storing.
Special thanks to Jeff Chua for detailed bug reporting.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a missing =m constraint to the EDD-probing code, that could have
caused improper dead-code elimination.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add memory operand constraint and write-only modifier to the inline
assembly to effect the writing of the EDID block to boot_params.edid_info.
Without this, gcc would think the EDID query was dead code and would
eliminate it.
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup:
[x86 setup] EDD: Fix the computation of the MBR sector buffer
[x86 setup] Newline after setup signature failure message
x86 boot code comments typos
On make install I get the this error:
...
sh /work/crazy/linux-git/linux-2.6/arch/i386/boot/install.sh
2.6.22-g4eb6bf6b arch/i386/boot/bzImage System.map "/boot"
/work/crazy/linux-git/linux-2.6/arch/i386/boot/install.sh: line 54:
/etc/lilo/install: No such file or directory
make[1]: *** [install] Error 127
...
I don't use and don't have lilo installed on this system. The attached
patch fixes the problem for me.
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some BIOSes require that sector buffers not cross 64K
boundaries. As a result, we compute a dynamic address on the
setup heap. Unfortunately, this address computation was just
totally wrong.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
End the "No setup signature found..." with a newline (the puts
routine will automatically add a carriage return.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make "struct ist_info" valid on both i386 and x86-64, and use the
structure by name in the setup code. Additionally, "Intel SpeedStep
IST" is redundant, refer to it as IST consistently.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For APM calls, BX contains the device index, which is zero for
the system BIOS. Disconnect requres BX = 0.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Starting with kernel 2.6.23-rc1, the i386 APM driver fails
on several of my machines with the message:
apm: BIOS not found
This happens because of a bug in the i386 boot code rewrite
from assembler to C. The original assembly code had the
following code in its APM BIOS presence test (boot/setup.S):
andw $0x02, %cx # Is 32 bit supported?
je done_apm_bios # No 32-bit, no (good) APM BIOS
That is, the code bails out if bit 2 is zero.
In the new C version, this is coded as (boot/apm.c):
if (cx & 0x02) /* 32 bits supported? */
return -1;
Here we see that the test has been accidentally inverted.
The fix is to negate the test. I've verified that this
allows the APM driver to work again on my affected machines.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
One of the nice ideas behind paravirt is that CONFIG_XEN=y can be included
in a standard configuration and be no worse for native booting than as a
Xen guest. The glibc feature that supports the vDSO "nosegneg" note is
designed specifically to make this easy. You just have to flip one bit at
boot time. This patch makes Xen flip the bit, so a CONFIG_XEN=y kernel on
bare hardware does not make glibc use the less-optimized library builds.
Signed-off-by: Roland McGrath <roland@redhat.com>
Acked-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With the new setup code, we generate a couple more files
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
[ .. and do the same for x86-64 - Alexey ]
Acked-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Keep the arch/i386/boot directory from being rebuilt every time.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There exists at least one card, Trident TVGA8900CL (BIOS dated 1992/9/8)
which clobbers DS when "scrolling in an SVGA text mode of more than
800x600 pixels." Although we are extremely unlikely to run into that
situation, it is cheap insurance to save and restore DS, and it only adds
a grand total of 50 bytes to the total output.
Pointed out by Etienne Lorrain.
Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If the user has asked for the vertical height registers to be recomputed
by setting bit 15 in the video mode number, we do so without clearing the
Protect bit in the Vertical Retrace Register before setting the Overflow
register. As a result, if the VGA BIOS had set the Protect bit, the
write to the Overflow register will be dropped, and bits [9:8] of the
vertical height will be left unchanged.
This is a bug imported from the assembly version of this code. It was
pointed out by Etienne Lorrain.
Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Fix incorrect assembly constraints. In particular, fix memory
constraints used inside push..pop, which can cause invalid operation
since gcc may generate %esp-relative references.
Additionally:
outl() should have "dN" not "dn".
query_mca() shouldn't listen 16/32-bit registers in an 8-bit only
context.
has_eflag(): the "mask" is only used well after both the stack pointer
and the output registers have been touched; this requires the output
registers to be earlyclobbers (=&) and the input to exclude memory (so
"ri", not "g").
Thanks to Etienne Lorrain and Chuck Ebbert for prompting this review.
Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Correct a comment in arch/i386/boot/build/tools.c; we now build the
kernel from only two components instead of three, since the boot
sector has been integrated in the setup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
arch/i386/xen/xen-asm.S defines some small pieces of code which are
used to implement a few paravirt_ops. They're designed so they can be
used either in-place, or be inline patched into their callsites if
there's enough space.
Some of those operations need to make calls out (specifically, if you
re-enable events [interrupts], and there's a pending event at that
time). These calls need the call instruction to be relocated if the
code is patched inline. In this case xen_foo_reloc is a
section-relative symbol which points to xen_foo's required relocation.
Other operations have no need of a relocation, and so their
corresponding xen_bar_reloc is absolute 0. These are the cases which
are triggering the warning.
This patch adds those symbols to the list of safe abs symbols.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Adrian Bunk <bunk@stusta.de>
This removes the old i386 setup code. This is done as a separate patch
to avoid breaking git bisect as some of the i386 code was also used by
the old x86-64 code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch hooks the new x86 setup code into the Makefile machinery. It
also adapts boot/tools/build.c to a two-file (as opposed to three-file)
universe, and simplifies it substantially.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linker script to define the layout of the new x86 setup code.
Includes assert for size overflow and a misaligned setup header.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The assembly header and initialization code, and the main() routine.
main.c also contains some miscellaneous very short routines.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the code which actually does the switch to protected mode,
including all preparation. It is also responsible for invoking the
boot loader hooks, if present.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Video mode probing for the new x86 setup code. This code breaks down
different drivers into modules. This code deliberately drops support
for a lot of the vendor-specific mode probing present in the assembly
version, since a lot of those probes have been found to be stale in
current versions of those chips -- frequently, support for those modes
have been dropped from recent video BIOSes due to space constraints,
but the video BIOS signatures are still the same.
However, additional drivers should be extremely straightforward to plug
in, if desirable.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Voyager support for the new x86 setup code. This implements the same
functionality as the assembly version.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
MCA probing support for the new x86 setup code. This implements the
same functionality as the assembly version.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Probe EDD and MBR signatures, in order to make it easier to map
physical hard drives to BIOS drives.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Verify that the CPU has enough features to run the kernel. This may
entail enabling features on some CPUs.
By doing this in the setup code we can be guaranteed to still be able to
write to the console through the BIOS.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Module which only includes the kernel version string.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This implements writing text to the console, including printf().
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Simple command-line parser which allows us to access the kernel command
line from the setup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
APM probing code for the new x86 setup code. This implements the
same functionality as the assembly version.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A20 handling code for the new x86 setup code. This implements the same
algorithms as the assembly version.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
strcmp(), memcpy(), memset(), as well as routines to copy to and from
other segments (as pointed to by fs and gs).
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A simple collection of bitops for the new x86 setup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Top header file for the new x86 setup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc for i386 can be used with the assembly prefix ".code16gcc" to generate
16-bit (real-mode) code. This header file provides the assembly prefix.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The relocatable kernel code needs a scratch field for the decompressor
to determine its own location. It was using a location inside
struct screen_info; reserve a free location and document it as scratch
instead.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- boot/setup.S did not print "PANIC: CPU too old for this kernel"
( not visible, also the message did not match )
- I add "# missed before: set ds"
=> somebody should check if I am right with the way to set.
=> seems to be a generic error in setup.S not to set "ds" for error messages.
AK: extracted patch out of other changes
AK: also couldn't find any other case where ds is wrong
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 464bdd33e9.
Peter Anvin correctly points out that VESA modes have nothing to do with
frame buffers per se - they are often just regular extended text modes.
Disabling them just because we don't have frame buffer support is very
wrong.
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Antonino A. Daplas <adaplas@gmail.com>,
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the option vga=<VESA graphics mode> is added to the boot parameter, it will
activate graphics mode, but without any framebuffer support, the user is left
with an unusable display.
Change the behavior such that the user is instead prompted for another mode
(ala vga=ask).
NOTE: People can always use vbetool to set a graphics mode if this is really
desired, but the number of people doing this approaches zero.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
