Text 963, 120 rader
Skriven 2006-11-04 13:17:26 av Frank Haber (1:379/45)
    Kommentar till text 962 av /m (1:379/45)
Ärende: Re: Ubuntu + Dell serious bug
=====================================
From: "Frank Haber" <frhaber@N0SPMrcn.com>

(Sent to m.'s email in error)

It seems all the Debian forks based on Linus' 2.6 kernel have been flailing
around with this since early ***20005***.  Very strange.  Since it's hard to
find what's below, I'm quoting it, for what it's worth.  And most puzzling is
the lack of hard hangs and corrupt CMOS on anything but Dells.

================
[8] What Intel has to say.

    Found by Googling for "8208CA", and then reading Google's
    "cached" copy.  (This stuff isn't easy to find - the original
    has evidently been taken down:

    sunsite.rediris.es/sites/download.intel.nl/
design/chipsets/specupdt/290739.htm
                    ^^ Estonia??)

    This document may or may not explain 2.8.1 real-time clock
    problem.  But for those of you with a hardware manufacturing
    background, can you IMAGINE shipping a piece of equipment with
    design flaws such as these and  requiring BIOS manufacturers
    to develop and test band-aids for them?  And then requiring OS
    developers to do the same work over again?

    Software timers in BIOS?  In the KERNEL??  Arrrgh.

    A chip with an arbitration deadlock which can lock up a bus,
    which they're not going to fix?

    And this stuff is used in ... avionics!  (At least by one
    manufacturer.  Not certified for the airlines, fortunately.)

    Quotes from Intel's document follow.

   "Problem:
    Under certain conditions, a CPU generated I/O read to RTC
    (Real Time Clock) registers 0-9 may return an incorrect
    value. The issue occurs on the read path from the RTC
    registers and the RTC value in the registers is not impacted.
    Should the certain conditions occur, one or more of the bits
    read from the RTC registers may be incorrect. The issue has
    only been found using a synthetic test and has not been seen
    using commercially available software.  [ <= N.B. ]

   "Implication:
    An operating system or software applications which
    synchronizes the time/date value with the RTC <registers may
    get an incorrect value.

   "Workaround:
    BIOS workaround is available in the Intel ICH3-S BIOS
    Specification Update Rev 2.01. The workaround does take into
    account multiple CPUs and Hyper Threading. The workaround uses
    timers to zero-in on the window where invalide RTC I/O read
    data could be returned. Using the software SMI, HPET timers
    and port 71 traps, the BIOS will ensure that there are no
    accesses to the RTC during this timing window.

   "Status:
    There are no plans to fix this erratum."


   "Problem:
    A setup timing issue exists in the ICH3's impedance compensation
    circuit which can cause the USB buffers to shut off, leading to
    missed USB transmit packets.

   "Implication:
    This is likely to result in data loss or may cause data corruption.

   "Workaround:
    A BIOS workaround has been validated.

   "Status:
    There are not plans to fix this erratum."


   "Problem:
    An arbitration deadlock in the ICH3 may occur if IDE traffic
    is combined with heavy graphic traffic and internal/external
    PCI Bus Master traffic to memory.

   "Implication:
    This issue may lockup the IDE bus master causing a system hang.
    This issue was found during ongoing internal validation using
    a synthetic test environment and there have been no failures
    reported by customers.

   "Workaround:
    BIOS needs to set configuration register (Device 31, Function
    1 0, offset FCh, bit 23) to prevent the arbitration deadlock.

   "Status:
    There are no plans to fix this erratum."


The document contains this notice, which may be the best part, on Page 1.

   "Notice: The Intel I/O Controller Hub 3 (ICH3-S) product
    may contain design defects or errors known as errata
    which may cause the product to deviate from published
    specifications. Current characterized errata are
    documented in this specification update."

Yeah, that's the ticket.  Call a design defect an "erratum" and amend the
specification to match the bugs.

Kernel hackers really are gods - how can they write a driver when the hardware
specs are this rubbery?  How does ANYONE test a driver for correct handling of
a "setup timing issue" in impedance compensation?
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)