On Wed, Sep 27, 2006 at 11:52:12AM +0200, Tristan Gingold wrote:
> Linux and xen call efi in real mode if set_virtual_address_map fails.
> You may add an option in both xen and linux to force calling efi in real mode.
> This should be really simple and you will be able to make progress.
I took a stab at forcing the call to stay in real mode,
by simply replacing the call to set_virtual_address_map with
a return. This should both prevent the mapping from occuring,
and force the kernel to use the real mode variants of the calls.
Unfortunately, the boot fails with the following log.
A bit of investigation has found that is it dying in
SAL_CALL()
called by: ia64_sal_cache_flush()
called by: ia64_sal_cache_flush()
called by: ia64_sal_init()
Well, when I say dying in, its probably more accurate to say,
never returning from.
The trace below is with 2.6.18. I had identical results with a recent
checkout of ia64-test. I can post my config if needed.
I'm a bit of a loss to know why this is occuring. Though
I do wonder if SAL (and in this case indrectly PAL) calls are
are running into trouble by runing in real mode without
set_virtual_address_map() having being called.
I tried poking around a bit, but to no avail.
Any ideas on where to poke around?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Linux version 2.6.18-kexec-dirty (horms@xxxxxxxxxxxxxxxxxxxxxxxxxxx)
(gcc version 3.4.5) #2 SMP Fri Sep 29 12:38:35 JST 2006 EFI v1.10 by INTEL: SALsystab=0x7fe54980 ACPI=0x7ff99000 ACPI
2.0=0x7ff98000 MPS=0x7ff97000 SMBIOS=0xf0000
Forcing EFI calls to stay in physical mode
booting generic kernel on platform dig
Early serial console at I/O port 0x2f8 (options '115200')
Initial ramdisk at: 0xe00000007aecd000 (10463216 bytes)
SAL 3.20: Intel Corp SR870BH2 version 3.0
SAL Platform features: BusLock
SAL: AP wakeup using external interrupt vector 0xf0
swapper[0]: General Exception: IA-64 Reserved Register/Field fault (data access) 2199023255600 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001210084a2010 ifs : 8000000000000183 ip : [<000000007fe21dc1>]
Not tainted
ip is at 0x7fe21dc1
unat: 0000000000000000 pfs : 0000000000000818 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000aff55d2b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : 000000007fe21ca0 b6 : 000000007fe08010 b7 : a000000100205420
f6 : 0fffafffffffff0000000 f7 : 0ffdef000000000000000
f8 : 10002f000000000000000 f9 : 100038000000000000000
f10 : 0fffeeffffffff1000000 f11 : 1003e0000000000000000
r1 : e000000080095280 r2 : 0000000000000000 r3 : e00000007fe59340
r8 : fffffffffffffffe r9 : 000000000000000f r10 : 0000000000000000
r11 : 0000000000000000 r12 : a00000010057fc30 r13 : a000000100578000
r14 : 000000007fe20300 r15 : 00000000000004d5 r16 : 0000000000000000
r17 : 00001010084a2010 r18 : 000000000007e000 r19 : 80000000aff54cab
r20 : 00000000000006c2 r21 : 0000000000000000 r22 : 0000000000000000
r23 : 0000000000000609 r24 : 00000000003ffc00 r25 : 0000000000000008
r26 : 0000000000000000 r27 : 00000010084a2010 r28 : 000000000000003f
r29 : 0000000000000000 r30 : 0000000000000001 r31 : 0000000000000000
Call Trace:
[<a0000001000124f0>] show_stack+0x50/0xa0
sp=a00000010057f640 bsp=a000000100579368
<4>kernel unaligned access to 0xffffffffffff45c3, ip=0xa0000001000d9451
kernel unaligned access to 0xffffffffffff45c3, ip=0xa0000001000d9470
irq 239, desc: a0000001005b1c80, depth: 1, count: 0, unhandled: 0
->handle_irq(): a00000010050dcd0, __stop___param+0x3550/0x15880
->chip(): a000000100612f88, no_irq_chip+0x0/0x80
->action(): 0000000000000000
IRQ_DISABLED set
Unexpected irq vector 0xef on CPU 0!
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|