Messages in this thread | | | Date | Tue, 4 Aug 2009 00:11:24 +0900 | Subject | Re: [tip:x86/asm] x86: Introduce GDT_ENTRY_INIT() | From | Akinobu Mita <> |
| |
2009/8/3 H. Peter Anvin <hpa@zytor.com>: > Ingo Molnar wrote: >> >> * tip-bot for Akinobu Mita <akinobu.mita@gmail.com> wrote: >> >>> Commit-ID: d520da1173abd1f918b7e690220e14ba0fc56cfc >>> Gitweb: >>> http://git.kernel.org/tip/d520da1173abd1f918b7e690220e14ba0fc56cfc >>> Author: Akinobu Mita <akinobu.mita@gmail.com> >>> AuthorDate: Sun, 19 Jul 2009 00:12:20 +0900 >>> Committer: Ingo Molnar <mingo@elte.hu> >>> CommitDate: Sun, 19 Jul 2009 18:27:53 +0200 >>> >>> x86: Introduce GDT_ENTRY_INIT() >>> >>> GDT_ENTRY_INIT is static initializer of desc_struct. >>> >>> We already have similar macro GDT_ENTRY() but it's static >>> initializer for u64 and it cannot be used for desc_struct. >>> >>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> >>> LKML-Reference: <20090718151219.GD11294@localhost.localdomain> >>> Signed-off-by: Ingo Molnar <mingo@elte.hu> >>> > > OK, I spotted the following error, which certainly would explain a crash on > an APM machine: > > /* data */ > - [GDT_ENTRY_APMBIOS_BASE+2] = { { { 0x0000ffff, 0x00409200 } } > }, > + [GDT_ENTRY_APMBIOS_BASE+2] = GDT_ENTRY_INIT(0x409a, 0, 0xffff),
Oops, I really should have checked the binary because the compiler should generate same code with this patch.
> Also, we shouldn't be initializing the A bits to clear unless we actually > plan to check the A (and D) bits... that's just a waste of CPU cycles.
I'll check it, too. -- 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/
| |