lkml.org 
[lkml]   [2007]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
    After much, much testing (months, off and on, pursuing hypotheses), I've 
    discovered that the use of "outb al,0x80" instructions to "delay" after
    inb and outb instructions causes solid freezes on my HP dv9000z laptop,
    when ACPI is enabled.

    It takes a fair number of out's to 0x80, but the hard freeze is reliably
    reproducible by writing a driver that solely does a loop of 50 outb's to
    0x80 and calling it in a loop 1000 times from user space. !!!

    The serious impact is that the /dev/rtc and /dev/nvram devices are very
    unreliable - thus "hwclock" freezes very reliably while looping waiting
    for a new second value and calling "cat /dev/nvram" in a loop freezes
    the machine if done a few times in a row.

    This is reproducible, but requires a fair number of outb's to the 0x80
    diagnostic port, and seems to require ACPI to be on.

    io_64.h is the source of these particular instructions, via the
    CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I
    wonder if the same problem occurs in 32-bit mode).

    I'm happy to complete and test a patch, but I'm curious what the right
    approach ought to be. I have to say I have no clue as to what ACPI is
    doing on this chipset (nvidia MCP51) that would make port 80 do this.
    A raw random guess is that something is logging POST codes, but if so,
    not clear what is problematic in ACPI mode.

    ANy help/suggestions?

    Changing the delay instruction sequence from the outb to short jumps
    might be the safe thing. But Linus, et al. may have experience with
    that on other architectures like older Pentiums etc.


    \
     
     \ /
      Last update: 2007-12-06 23:41    [W:4.091 / U:0.396 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site