From owner-freebsd-hackers Mon Sep 3 10:49: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 7154D37B401 for ; Mon, 3 Sep 2001 10:48:58 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f83HnIg23330; Mon, 3 Sep 2001 19:49:18 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200109031749.f83HnIg23330@freebsd.dk> Subject: Re: Via Chipset Fix In-Reply-To: <000b01c13497$0f6f1a10$aa240018@cx443070b> "from Jeremiah Gowdy at Sep 3, 2001 09:39:54 am" To: Jeremiah Gowdy Date: Mon, 3 Sep 2001 19:49:17 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Jeremiah Gowdy wrote: > I noticed the following thread about the Via chipset problem. I run a > production server off a Tyan Tiger 133A, which also has this problem. Tyan > does not have a BIOS fix, nor does it look like they ever will. When you > contact them, they point to the Windows driver fix. They don't seem to > understand there are non-Windows systems. If you could add such code to the > kernel it would help me get past a 20 day uptime which has been the record > this box has had. It simply panics on heavy IDE useage. / /usr /var /tmp > and swap are all on very fast SCSI. /usr/home is on a large IDE UDMA66 for > storage. if you go to /usr/home and do something like du -h (there's about > 30 gigs in there) or ls -R or something of that nature it will almost > certainly panic. We've made some adjustments and the frequency of the > problem is reduced, but a kernel option for a hack on this chipset would be > very worthy in the eyes of those of us stuck with these motherboards running > FreeBSD. This is just a single example, I also have a KX133 which is > affected, with no patch from Asus. Hmm, what you should try is change pci reg 0x76 of the K?133 chip, that is most likely on pci0:0:0. Then using pciconf set bit 5 to 0 and bit 4 to 1, the other bits should be left untouched. Does that help ? if not you are probably having another problem.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message