From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 19:25:22 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 26EFD16A41C for ; Sun, 22 May 2005 19:25:22 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from anya.eboundary.com (anya.eboundary.com [69.90.127.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id C628543D1F for ; Sun, 22 May 2005 19:25:21 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from epicofti by anya.eboundary.com with local (Exim 4.51 (FreeBSD)) id 1DZw80-000I17-Kd; Sun, 22 May 2005 15:28:48 -0400 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user freebsd@epicoftimewasted.com) by www.epicoftimewasted.com with HTTP; Sun, 22 May 2005 15:28:48 -0400 (EDT) Message-ID: <1503.127.0.0.1.1116790128.squirrel@www.epicoftimewasted.com> In-Reply-To: <428F7928.60406@samsco.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> <428F7928.60406@samsco.org> Date: Sun, 22 May 2005 15:28:48 -0400 (EDT) From: "Ryan R." To: "Scott Long" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - anya.eboundary.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1018 1019] / [26 6] X-AntiAbuse: Sender Address Domain - epicoftimewasted.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 19:25:22 -0000 > Ryan R. wrote: > >> First off, some info about my setup: >> >> Motherboard: DFI Lanparty SLI-DR, nForce4, socket 939 >> CPU: Athlon64 3700+ "San Diego" core, revision E4, socket 939, 1mb L2 >> cache >> Memory: 2x 512mb OCZ Value VX >> I've run prime95 in Windows for just over 84 hours, with zero errors. >> I've run memtest86+ for about 12 hours, with zero errors. >> >> Now, the problem is that I recently upgraded to this system from a >> socket >> 754 "Clawhammer" (C0 revision) setup, which worked perfectly in >> 5.3-RELEASE/amd64. Before I upgraded the hardware, I didn't think to >> rebuild the kernel/world with a clean make.conf and kernel config. When >> I >> booted the new machine, I got a kernel panic (fatal trap 9) on boot, >> between the detection of my drives and mounting root. I tried a few >> things to get it working, but to no avail. I then decided it has to be >> my >> old world/kernel, so I did a binary upgrade to 5.4-RELEASE/amd64. >> >> After doing the binary upgrade, the system would boot again (at first, >> anyways). Once the system had booted, I figured I should rebuild my >> ports. While I was watching the build, the kernel paniced again (I >> forgot >> the exact message, and I didn't copy it down). I once again tried a few >> things to get it to work, but since I had spent so much time trying to >> get >> it to work before the binary upgrade, I figured it'd be easier to just >> wipe the drive and start over fresh, that way I have a known good system >> to start with if any problems pop up. >> >> So, I wiped the drive, and installed 5.4-RELEASE/amd64 on it. Install >> went fine, system booted, but then the panics came back. It usually >> happened while building some ports, but it happened in a different spot >> each time, so it's not like one specific port was causing me problems. >> It >> also didn't happen only under load. >> >> Now, I have the problem narrowed down to one of two things: >> 1) The hardware is bad. This lead me to run the memtest/prime95 tests, >> but they revealed no problems. This leads me to option 2. >> 2) The amd64 build of FreeBSD. >> >> So, I once again wipe the drive, but this time I install >> 5.4-RELEASE/i386. >> It installs fine, and boots fine. One thing I notice during boot, is >> that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 >> build did detect it). I begin building all my ports, and I was able to >> get my system up and running without even a hint of trouble. >> >> >> So, I'm curious to know if there are any problems with the amd64 release >> with these E3/E4 revision CPUs, maybe relating to the SSE3 instructions? >> Is there anything I can try to narrow down what exactly is causing my >> hardware to panic? I know I should build a kernel with debugging >> support >> (I tried it before installing the i386 release, but got a kernel >> panic... >> go figure), but I probably wouldn't be able to see the problem in a >> trace >> if I tripped over it. >> >> Any help would be appreciated. Thanks. > > It's pretty hard to make an nForce chipset work under FreeBSD 5.x. The > biggest problem seems to be with how the legacy system clocks are > implemented, which FreeBSD 5.x and prior relies on. FreeBSD 6-CURRENT > uses a completely different method that is compatible with the nForce, > so I'd recommend trying that instead. I use it on my desktop nForce4 > machine without any problems (except for the buggy nve ethernet driver). > > Scott > Ok, I've installed 6-CURRENT, and so far things seem to be working, except for my SATA ports. On boot, I get a couple ata2 and ata3 CONNECT/DISCONNECT notices, and then this panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x50 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff80276652 stack pointer = 0x10:0xffffffffa556cac0 frame pointer = 0x10:0xffffffffa556cb10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 8 (thread taskq) [thread pid 8 tid 100031 ] Stopped at device_attach+0x22: cmpq $0,0x50(%r13) db> trace Tracing pid 8 tid 100031 td 0xffffff003db6d4c0 device_attach() at device_attach+0x22 bus_generic_attach() at bus_generic_attach+0x18 ata_identify() at ata_identify+0xe6 ata_sata_phy_event() at ata_sata_phy_event+0xa2 taskqueue_run() at taskqueue_run+0x97 taskqueue_thread_loop() at taskqueue_thread_loop+0x2c fork_exit() at fork_exit+0xbb fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa556cd00, rbp = 0 --- Disabling my SATA ports allows the system to boot. For reference, I have two SATA drives, both are Maxtor 6B300S0/BANC1980, and they're both on the nvidia SATA ports. Moving the drives to the Silicon Image ports still gives me the CONNECT/DISCONNECT messages, but not the panic. I'm not using a GENERIC kernel any more (removed unused SCSI/RAID/network devices), I don't know if that poses any debugging problems. If it makes a difference, I'll rebuild the GENERIC kernel and get a dump from that. It's not much of an issue for me, since the drives are used for storage in Windows only, but still something to mention none the less. Sorry for the second e-mail btw Scott, forgot to CC the mailing list the first time. Ryan