From owner-freebsd-amd64@FreeBSD.ORG Mon Apr 4 15:43:09 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 245AD16A4CE for ; Mon, 4 Apr 2005 15:43:09 +0000 (GMT) Received: from pigeon.infotechfl.com (mailrelay.infotechfl.com [209.251.147.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2433343D41 for ; Mon, 4 Apr 2005 15:43:08 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from [172.20.0.75] (gmulder.infotechfl.com [172.20.0.75]) by pigeon.infotechfl.com (8.11.6/8.11.6) with ESMTP id j34Djh227199 for ; Mon, 4 Apr 2005 09:45:43 -0400 Message-ID: <42514508.90303@infotechfl.com> Date: Mon, 04 Apr 2005 09:45:44 -0400 From: Gary Mu1der User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <3f9aa5aef19c41837cce1563e2c97a21@khera.org> <424C215E.5080201@infotechfl.com> <424C4EED.5070601@infotechfl.com> <1112312243.6323.10.camel@lanshark.dmv.com> <424D58F7.1010005@infotechfl.com> <424DA4B3.3070703@infotechfl.com> <20050401201907.U95587@carver.gumbysoft.com> In-Reply-To: <20050401201907.U95587@carver.gumbysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Tyan k8sr lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 15:43:09 -0000 I had suspected that, but I've done the same on a P4 system with 5.3REL, Solaris on Sparc (although I don't know if Sparc has memory mapped I/O), and other Unixes, and had no problems. It was a quick a dirty way to stress the memory and CPU. Thanks for the reply, Gary Doug White wrote: > On Fri, 1 Apr 2005, Gary Mu1der wrote: > > >>I have isolated the crash to the following dd command: >> >> dd if=/dev/mem of=/dev/null bs=1024k skip=4040 count=1 > > > Reading from random places in /dev/mem will cause unpredicatable behavior. > Memory at that offset is in PCI memory-mapped device space, and reading > from there may disrupt the PCI bridge, enable or disable interrupts, or > worse. >