[lug] sad hardware announcement :(

Tue Jul 18 23:25:47 MDT 2000

FYI....We have the exact same problem with the Win2k Server and Advanced
Server....
The BIOS beta code update DID fix the problem...
Hope this helps..

SGS

>From: "D. Stimits" <stimits at idcomm.com>
>Reply-To: lug at lug.boulder.co.us
>To: BLUG <lug at lug.boulder.co.us>
>Subject: [lug] sad hardware announcement :(
>Date: Tue, 18 Jul 2000 21:08:41 -0600
>MIME-Version: 1.0
>Received: from [216.17.150.53] by hotmail.com (3.2) with ESMTP id 
>MHotMailBB3E670C002AD820F3B3D811963507CC0; Tue Jul 18 20:10:05 2000
>Received: (qmail 16231 invoked from network); 19 Jul 2000 03:09:43 -0000
>Received: from localhost (HELO dev.tummy.com) (alias at 127.0.0.1)  by 
>localhost with SMTP; 19 Jul 2000 03:09:43 -0000
>Received: (qmail 16059 invoked from network); 19 Jul 2000 03:09:32 -0000
>Received: from www.tummy.com (HELO tummy.com) (qmailr at 216.17.150.34)  by 
>lists.lug.boulder.co.us with SMTP; 19 Jul 2000 03:09:32 -0000
>Received: (qmail 6439 invoked by alias); 19 Jul 2000 03:09:31 -0000
>Received: (qmail 6436 invoked from network); 19 Jul 2000 03:09:30 -0000
>Received: from brainstem.idcomm.com (207.40.196.12)  by www.tummy.com with 
>SMTP; 19 Jul 2000 03:09:30 -0000
>Received: from idcomm.com (IDENT:stimits at k56-pip71.idcomm.com 
>[209.60.72.198] (may be forged))by brainstem.idcomm.com (8.9.3/8.9.3) with 
>ESMTP id VAA13281for <lug at lug.boulder.co.us>; Tue, 18 Jul 2000 21:09:28 
>-0600
>From lug-admin at lug.boulder.co.us Tue Jul 18 20:13:24 2000
>Return-Path: <blugdom-lug-owner at lug.boulder.co.us>
>Delivered-To: blugdom-lug at lists.lug.boulder.co.us
>Delivered-To: blugdom-lug at lug.boulder.co.us
>Message-ID: <39751BB9.6664E5B4 at idcomm.com>
>X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.15-config.2 i686)
>X-Accept-Language: en
>Sender: lug-admin at lug.boulder.co.us
>Errors-To: lug-admin at lug.boulder.co.us
>X-Mailman-Version: 1.0
>Precedence: bulk
>List-Id: Boulder (Colorado) Linux Users Group -- General Mailing List 
><lug.lug.boulder.co.us>
>X-BeenThere: lug at lug.boulder.co.us
>
>I have used SuperMicro motherboards for years now, and recently picked
>up a PIIIDM3, which at first seemed stable. I'm not sure how many of you
>have noted sporadic reports of some server boxes locking up under high
>i/o, but Redhat and others have made notes on this. I've found out that
>this is a problem with all of the SuperMicro i840 chipset boards as
>well.
>
>The problem isn't entirely high i/o, but this tends to generate the
>conditions that trigger it. The problem is an unknown IO-APIC, which is
>a device responsible for reprogrammable IRQ steering between multiple
>cpu's. When i/o doesn't lock up the system prior to logging failure, a
>note is found as the last entry of /var/log/messages, "kernel:
>unexpected IRQ vector 217 on CPU#0!" (or on CPU#1). In other locations
>of the log, you'll likely see the entry "WARNING: unexpected IO-APIC,
>please mail".
>
>After speaking with SuperMicro, they simply state "it runs fine on NT",
>and they won't help. In the past they were interested in Linux, but
>SuperMicro has apparently changed its mind and is not interested
>anymore. I've contacted Allen Cox to see what else can be done, but for
>now, you should consider all i840 SuperMicro boards incompatible with
>Linux (I also saw very similar reports on FreeBSD and other open source
>o/s's).
>
>The temporary workaround is to boot with the kernel option "noapic".
>This removes irq redirection to the 2nd cpu, meaning all device i/o is
>entirely on the first cpu. Additionally, some PCI devices which might
>have been at an irq value will be changed or at an unreachable irq.
>There is some explanation of this sort of problem in the kernel source
>Documentation directory: "IO-APIC.txt".
>
>At this point, I am looking for a new motherboard, dual cpu, with 4x
>AGP-pro (I'm looking at high end OpenGL graphics cards) and 64 bit, 66
>MHz PCI slots (required for ultra 160, which I plan to continue using).
>Iwill has a dual slot 2 board, the DCA200, which unfortunately requires
>rdram (expensive and increased latency, with no ability to reuse my
>current pc133 ram), which might be the route to go if nothing else
>appears. Anyone know if this board really is stable under linux? The
>Intel OR840 would be a candidate, but it lacks 64 bit PCI. Does anyone
>know if the Via Apollo Pro 133A chipset is a solution? Do any of the
>133A boards have 64 bit PCI slots?
>
>And is there anyone who is interested in buying a good non-linux
>motherboard, a PIIIDM3 SuperMicro?
>
>Thanks,
>D. Stimits, stimits at idcomm.com
>
>_______________________________________________
>Web Page:  http://lug.boulder.co.us
>Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com