Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757864AbXLaA0Y (ORCPT ); Sun, 30 Dec 2007 19:26:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753741AbXLaA0R (ORCPT ); Sun, 30 Dec 2007 19:26:17 -0500 Received: from terminus.zytor.com ([198.137.202.10]:36064 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753441AbXLaA0Q (ORCPT ); Sun, 30 Dec 2007 19:26:16 -0500 Message-ID: <47783678.9070706@zytor.com> Date: Sun, 30 Dec 2007 16:23:20 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "David P. Reed" CC: Alan Cox , Linus Torvalds , Rene Herman , Ingo Molnar , Islam Amer , Pavel Machek , Ingo Molnar , Andi Kleen , Thomas Gleixner , Linux Kernel Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override References: <477711DC.5030800@keyaccess.nl> <20071230144700.78f4605c@the-village.bc.nu> <20071230152835.GX16946@elte.hu> <20071230153818.1a554a7e@the-village.bc.nu> <20071230160132.GA14311@elte.hu> <20071230164828.039916c8@the-village.bc.nu> <4777E010.7030703@keyaccess.nl> <20071230183927.5a5a3c42@the-village.bc.nu> <4777F297.9070207@keyaccess.nl> <47780B93.4050606@reed.com> <20071230213623.410d480a@the-village.bc.nu> <4778266B.2060502@reed.com> In-Reply-To: <4778266B.2060502@reed.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1259 Lines: 27 David P. Reed wrote: > Alan Cox wrote: >>> Now what's interesting is that the outb to port 80 is *faster* than >>> an outb to an unused port, on my machine. So there's something there >>> - actually accepting the bus transaction. In the ancient 5150 PC, >>> 80 was >> >> Yes and I even told you a while back how to verify where it is. From the >> timing you get its not on the LPC bus but chipset core so pretty >> certainly an SMM trap as other systems with the same chipset don't have >> the bug. Probably all that is needed is a BIOS upgrade >> >> > Actually, I could see whether it was SMM trapping due to AMD MSR's that > would allow such trapping, performance or debug registers. Nothing was > set to trap with SMI or other traps on any port outputs. But I'm > continuing to investigate for a cause. It would be nice if it were a > BIOS-fixable problem. It would be even nicer if the BIOS were GPL... If it was an SMM trap, I would expect it to be trapped in the SuperIO chip. -hpa -- 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/