"modprobe efivars" hangs platform during install on an i386 EFI based
system. Opening another tty session and killing the process allows the
install to continue to completion, though Linux is unable to copy elilo.efi,
elilo.conf, initrd.img, and vmlinuz to the EFI Partition and it cannot
create the Boot Manager variables. Before the install reboots, I can
manually mount the EFI Partition (mount /dev/sda1 /mnt) and copy the
initrd.img and vmlinux files to the EFI Partition. I had to find elilo.efi
and elilo.conf elsewhere and copy them to the EFI Partition manually.

Once the OS is loaded, attempting to "modprobe efivars" causes a
Segmentation Fault.


I am a developer on an EFI BIOS based Intel Core 2 Duo platform (i386). We
have completed our EFI portion of the BIOS that meets the EFI Spec. The code
is based from the code base.

The EFI System Table is believed accurate and does point to the ACPI,
SMBIOS, and MP tables.

Looking at dmesg shows the following:

Linux version 2.6.18-04-686 (Debian 2.6.18.dfsg.1-12) (
(gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar
26 17:17:36 UTC 2007
EFI: Warning: EFI system table major version mismatch: got 2.00, expected
EFI: EFI v2.00 by
ACPI=0xf0030 <6> SMBIOS=0xf0ec0 <6> MPS=0xf1080

Though there is a warning that it was expecting version 1.00, it does parse
the table and find the SMBIOS, ACPI, and MP tables. Later on during dmesg is
where it parses each of those tables (ACPI, SMBIOS, and MP) without error.

There is one error later:
Oops: efitime: can't read time status: 0x80000007

I suspect this is related to Linux not being able to make EFI Runtime calls.

I have looked at the source code for efivars and from the comments it
appears to be using hard-coded addresses to find the EFI System Table. Our
EFI System Table is not at that address. I suspect this is the reason for
the hangs and faults.

I know when EFI launches elilo.efi, it passes the address of the EFI System
Table into it. I assume it uses this address and finds the table and that
the first few lines of dmesg come from either it or initrd.img.

Perhaps the issue is that as Linux continues the boot process, it loses the
address of the EFI System Table by the time efivars wants to load, and
unable to determine the address of the table, the programmer was forced to
use hard-coded address based on the only example at the time, the IA64

I have an American Arium ITP and hardware and BIOS debugging experience,
though I have never attempted to debug Linux.

I am trying to figure out how to debug this module and confirm that it uses
hard-coded memory addresses for the EFI System table. Perhaps as a test I
can then hard-code it to the address of my table, but ultimately this needs
to be fixed such that the address is available to efivars when it needs it.

Thank you for any direction or help.

Charles Abdouch