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
![]() |