lkml.org 
[lkml]   [2002]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: GA-7VRXP is a bad motherboard [was Re: PDC20276 Linux driver]
    Bryan, Priit,

    On Tue, Nov 12, 2002 at 11:13:29PM +0200, Priit Laes wrote:
    > Bryan O'Sullivan (bos@serpentine.com) wrote:
    > > On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
    > >
    > > > Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
    > >
    > > The GA-7VRXP is a known bad motherboard. It has a bad electrical
    > > interface to the AGP slot, so if you're using an AGP graphics card
    > > without falling back to PCI access, you are pretty much guaranteed
    > > system hangs or crashes after some time, depending on load.
    > >
    > > This is an issue I confirmed with AMD several (six?) months ago. I
    > > don't know of any workarounds that maintain decent graphics performance,
    > > and last I checked, Gigabyte had not acknowledged the problem.
    > >
    > > Either drop your video card back to not using AGP, or buy a replacement
    > > motherboard.
    > Well actually Gigabyte systems are aware of this bug...
    > According to: www.thetechboard.com (original page has disappeared):
    >
    > A good number of 1.0 versions of this motherboard barely worked at all
    > with GeForce4 cards. Stability was unheard of."
    >


    We do not have a GeForce4 card in there, but we do indeed have an AGP
    card in there. It is a S3 ViRGE.

    I will try disabling the AGP and see what happens.

    I will say, though, that the stuck processes we have seen appear to be
    doing disk I/O in the /home partition (which is disk mirrored with the
    PDC driver), and apart from that, it seemed to be quite stable. If a
    "crash" or a "hang" is described as getting a stuck process in disk I/O
    because of some freak accident that getting an inode pointer can be
    invalid, then yes, otherwise, no.


    > The 1.1 version of this board would sometimes work and sometimes not
    > work. Odds are better of getting a functioning board, but if you have
    > this version of the board and your GeForce4 card does NOT work,
    > increasing the VCore voltage by +7.5 in the BIOS can help. The side
    > effect of this can lead to higher temperatures causing a whole new batch
    > of problems. Better cooling solutions (like a Volcano7 or Coolermaster
    > Heatpipe AT MINIMUM) can pacify the heat issues, but I feel that long
    > term usage at this high of a voltage will cause inevitable failure.
    >


    We do have a cooler master on the CPU fitted on with enough paste. I thought
    was the heat too, so we took it out of the server cabinet and let it stand
    in the open. Unfortuantely, we got stuck processes in disk I/O after
    a while as well. Actually, even in the server cabinet, it is not that
    hot.


    > After calling Gigabyte (you would think that they should call me knowing
    > that they sent me a few hundred motherboards with a "known issue")
    > because I was growing very tired of all of the tech calls I was
    > receiving about the board's stability issues with the GeForce4 card, I
    > was told that the boards needed to be reworked. Older boards were being
    > "updated" by adding a 4.7uF capacitor between the VR at Q36 and a spot
    > on the board where a surface mounted capacitor could go (but isn't
    > installed) at C139. A new revision (2.0) with a resistor (labeled R833)
    > added is already in production and being shipped.
    >
    > I've(www.thetechboard.com) already tested the 2.0 version of the board with a PowerColor brand Ti 4200 128MB DDR and things do seem to be considerably better.
    > "
    > Hope this helps...


    I see.

    I will call Gigabyte to see what are the odds of getting it fixed. But
    surely, if it was a hardware problem, others would have experienced
    similar issues too (processes stuck in disk I/O uninterruptible sleep)?
    I did search before, and don't recall finding similar issues.


    -- G.
    --
    char *p = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
    "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
    "\x80\xe8\xdc\xff\xff\xff/bin/sh";


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.025 / U:59.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site