5.4-RELEASE Athlon64 E3/E4 core support

[Ryan R.]

> 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