Re: [Regression] "x86-64/efi: Use EFI to deal with platform wallclock" prevents my machine from booting

[Matt Fleming]

On Tue, 2012-08-07 at 08:14 +0100, Jan Beulich wrote:
> That's not surprising. The question really is what goes wrong
> when the call is being made - page fault, some other fault, or
> silent hang. A page fault would point to an incorrect memory
> map as the prime candidate for causing the problem. My
> primary suspect would be #NM, i.e. the implementation using
> floating point (SSE to be precise) instructions when they're
> unavailable.

I managed to find a machine to reproduce this on and it looks like the
ASUS firmware engineers are upto their old tricks of referencing
physical addresses after we've taken control of the memory map,

[   20.740414] BUG: unable to handle kernel paging request at 00000000fed1f410
[   20.740426] IP: [<ffff8800badf2134>] 0xffff8800badf2133
[   20.740436] PGD 138a81067 PUD 0 
[   20.740443] Oops: 0000 [#1] PREEMPT SMP 
[   20.740452] Modules linked in:
[   20.740457] CPU 1 
[   20.740464] Pid: 1051, comm: bash Not tainted 3.5.0-1.2-desktop+ #82 System manufacturer System Product Name/P8H67-M LE
[   20.740475] RIP: 0010:[<ffff8800badf2134>]  [<ffff8800badf2134>] 0xffff8800badf2133
[   20.740485] RSP: 0018:ffff880138bc5c48  EFLAGS: 00010002
[   20.740491] RAX: ffff880138bc0000 RBX: ffff880138bc5e0b RCX: 00000000fed1f410
[   20.740499] RDX: 0000000000000010 RSI: ffff880138bc5e00 RDI: ffff880138bc5e18
[   20.740506] RBP: ffff880138bc5df8 R08: 0000000000000000 R09: 0000000000000000
[   20.740514] R10: 0000000000000001 R11: 0000000000000001 R12: 00000000fed1f410
[   20.740521] R13: 0000000000000000 R14: ffff880138bc5e18 R15: 0000000000000002
[   20.740529] FS:  00007fe8f1f5a700(0000) GS:ffff88013fa80000(0000) knlGS:0000000000000000
[   20.740538] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   20.740544] CR2: 00000000fed1f410 CR3: 0000000138b54000 CR4: 00000000000407e0
[   20.740552] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   20.740560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   20.740568] Process bash (pid: 1051, threadinfo ffff880138bc4000, task ffff880137d60040)
[   20.740576] Stack:
[   20.740579]  ffff8800badf139d ffffffff00000000 ffffffff81c1f360 0000000000000086
[   20.740591]  ffffffff81c1f2d8 0000000000000007 ffff880138bc5e08 ffff880138bc5e18
[   20.740603]  ffff880138bc5e08 ffff880138bc5e00 ffff8800badf16f3 00000000000003ad
[   20.740615] Call Trace:
[   20.740624]  [<ffffffff8109f35d>] ? trace_hardirqs_off+0xd/0x10
[   20.740636]  [<ffffffff81037740>] ? efi_call2+0x40/0x70
[   20.740645]  [<ffffffff810374e7>] ? virt_efi_get_time+0x57/0x90
[   20.740654]  [<ffffffff8103716a>] efi_get_time+0x4a/0x50
[   20.740664]  [<ffffffff8100ab22>] read_persistent_clock+0x12/0x30
[   20.740674]  [<ffffffff81048a0f>] mjf_proc_dointvec+0x3f/0x50
[   20.740683]  [<ffffffff810478e0>] ? iomem_is_exclusive+0xb0/0xb0
[   20.740694]  [<ffffffff811d1972>] ? sysctl_perm+0x32/0x90
[   20.740704]  [<ffffffff811d1a8c>] proc_sys_call_handler+0xbc/0xd0
[   20.740715]  [<ffffffff811d1aaf>] proc_sys_write+0xf/0x20
[   20.740724]  [<ffffffff81162a76>] vfs_write+0xc6/0x180
[   20.740732]  [<ffffffff81162d8c>] sys_write+0x4c/0x90
[   20.740743]  [<ffffffff8173e8a2>] system_call_fastpath+0x16/0x1b

Relevant bits of the dmesg for the offending address,

[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] efi: mem140: type=11, attr=0x8000000000000001, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000
[    0.251154] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    0.251163] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[    0.265436] pnp 00:08: [mem 0xfed1c000-0xfed1ffff]
[    0.265523] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/