Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753844Ab2HGJam (ORCPT ); Tue, 7 Aug 2012 05:30:42 -0400 Received: from mga06.intel.com ([134.134.136.21]:29590 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753766Ab2HGJai (ORCPT ); Tue, 7 Aug 2012 05:30:38 -0400 Subject: Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting From: Matt Fleming To: Jan Beulich Cc: =?ISO-8859-1?Q?J=E9r=F4meCarretero?= , Ingo Molnar , Matthew Garrett , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, "H. PeterAnvin" In-Reply-To: <5020DC5F02000078000931C2@nat28.tlf.novell.com> References: <20120805172903.5f8bb24c@zougloub.eu> <501EF3A2.20200@zytor.com> <501F83F20200007800092C1C@nat28.tlf.novell.com> <20120806125216.GA11863@srcf.ucam.org> <501FDDD30200007800092DDE@nat28.tlf.novell.com> <20120806091627.2ad5ed2e@zougloub.eu> <20120806223208.5301be0d@zougloub.eu> <20120806230629.153d33bd@zougloub.eu> <5020DC5F02000078000931C2@nat28.tlf.novell.com> Content-Type: text/plain; charset="UTF-8" Organization: Intel Corporation (UK) Ltd. - Registered No. 1134945 - Pipers Way, Swindon SN3 1RJ Date: Tue, 07 Aug 2012 10:30:30 +0100 Message-ID: <1344331830.7208.6.camel@mfleming-mobl1.ger.corp.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4116 Lines: 69 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: [] 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:[] [] 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] [] ? trace_hardirqs_off+0xd/0x10 [ 20.740636] [] ? efi_call2+0x40/0x70 [ 20.740645] [] ? virt_efi_get_time+0x57/0x90 [ 20.740654] [] efi_get_time+0x4a/0x50 [ 20.740664] [] read_persistent_clock+0x12/0x30 [ 20.740674] [] mjf_proc_dointvec+0x3f/0x50 [ 20.740683] [] ? iomem_is_exclusive+0xb0/0xb0 [ 20.740694] [] ? sysctl_perm+0x32/0x90 [ 20.740704] [] proc_sys_call_handler+0xbc/0xd0 [ 20.740715] [] proc_sys_write+0xf/0x20 [ 20.740724] [] vfs_write+0xc6/0x180 [ 20.740732] [] sys_write+0x4c/0x90 [ 20.740743] [] 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/