Update: I have found out that Memtest86 version 3.5 (that I was using) has a bug in it that causes it to crash when used with 4 GB of memory or more. (See here http://www.memtest86.com/ ) I am now using the patched version 3.5a, and Memtest86 runs until I stop it with no errors. I have run it with 4GB of memory for over an hour and a half on the D510MO. Thought I would poin this out in case anyone else is having this issue with Memtest86.
Update: Looks like this is an issue with the Operating System I am using, and not a memory issue. I am still getting the crashes in the OS, if I have the hyperthreading enabled. If I disable the hyperthreading in the BIOS, then the system is stable. I am using FreeBSD 8.1 RELEASE 64 bit, and I am taking my questions to the FreeBSD Forum. For anyone else using FreeBSD, I get the following message on the console, when a crash occurs.
panic:vm_page_insert: offset already allocated
1 of 1 people found this helpful
I have the same strange issue with the D525MW which is the successor of your board. I use 2 x KVR800D3S8S6/2G Kingston DDR3 Memory Modules which are on the compatibility List for this Borad. I don't think this is a Linux/FreeBSD dependent issue cause I can reproduce the error with a Microsoft OS. With 4GB I wasn't able to install an OS cause the System reboots rendomly during the Installation. If I disable Hyperthreading everything runs fine. I tested both Memory Modules with 20 Rounds of Windows 7 Memory Testing (Advanced Mode) and wasn't able to find a Problem. With Hyperthreading I'll get a the message that a Hardware Problem was found. Last thing I'll try is to change the Powersuply, but this is only a guess.
Edit: I found the Memory Voltage Setting you mentioned. You have to set the 'BIOS Configuration Jumper' to 2-3 and power the System on. At the Memory Menu you'll see the RAM Voltage settings, which unfortunetly could not be edited.
Were these your postings? -
I have the same problem. This board was very stable with FreeBSD under various monthly non-stop workloads until I updated the BIOS from MOPNV10J.86A to MOPNV10N.86A series. My situation is slightly different however, disabling the hyperthreading doesn't help and the system sometimes panics, sometimes reboots.
I was unable to revert BIOS back to MOPNV10J.86A version (tried 0311 and earlier). If anybody is using D510MO under FreeBSD - DO NOT UPDATE BIOS TO THE REVISIONS THAT FOLLOWED 0311 (THEY ARE 0400..0516)!
Yes, those are my postings on the FreeBSD forum and mailing lists. May be a rather obscure issue, as I didn't get much in repsonse. I am not sure now, but I may have had it happen once or twice with the hyperthreading off as well. It sure seems to happen less often with the hyperthreading off.
I am also, trying a couple of other things now. I am moving to FreeBSD 8.2 - RELEASE, and I have set the video memory to fixed in the BIOS from auto. I think the video shares system memory, rather than having its own memory. Perhaps leaving that on auto causes a memory allocation issue.
I have tried the D525MW board as well, which is the updated version of this board, and I have the same issue.
Are you using ZFS on root, or the AHCI driver? I am using both of these, and I am wondering if there is some issue there.
I am using UFS on Kingston 64G SSD. Motherboard BIOS set to AHCI mode. My observations suggest that panics are related to the disk activity, writes in particular, not necessary intensive.
I agree, I think it is related to disk writes as well. That is why I was asking about the disk driver, and the filesystem. Since you are using UFS, and I am using ZFS, then it doesn't seem to be filesystem related. Perhaps something to do with AHCI thought. I am not sure if there are any updates to the AHCI driver in 8.2 - RELEASE, but I am going to try upgrading to see if it makes any difference.
Also, I was initially using a Lexar USB stick, to boot from, but have since moved to an Intel SATA SSD. In both cases I have had the panic occur. I am currently using the 0516 BIOS on the D510MO board, and the 0078 BIOS on the D525MW board.
I guess there could be an issue with the NM10 Express Chipset. Are you aware of any other NM10 based boards being used with FreeBSD?
This is hardly a chipset issue. I have been using D510MO under FreeBSD for almost a year - without single reboot, lockup or panic. It all started after the BIOS upgrade to a post-0311 version.
I can only confirm the issue, with or without hyperthreading. It's exacerbated by writing on a USB drive but happens all the same with sata drives (all using ZFS).
The BIOS is MOPNV10N. Using FreeNAS 8.0 (FreeBSD 8.2-RELEASE-p1) for x86_64.
is there a known solution to this issue? My board is new but unusable because of this problem.
I have bios MOPNV10N.86A.0400 with 1x2Gb, hyperthreading (on/off makes no difference), AHCI is enable.
I use FreeBSD 8.2-RELEASE amd64. I typically get the panic: "panic:vm_page_insert: offset already allocated" during disk I/O (even low).
I'd be grateful for any advice,
Afraid I haven't found, or heard of a solution to this problem yet. Hopefully, something comes up soon, as I really like this board, other than this issue with the kernel panic.
Hello here a quick update.
The board was basically unusable for me due to intermittent kernel panics. This occurs only during disk io (note: I use geli encryption). I've let the board run days on 400% CPU and a continuous memtest without problem. But it crashes within 1 hour during disk activity.
After 3 weeks of testing and trying everything in the bios, I also changed the video memory to manual as suggested by pnintel and since then (about 2 weeks now) I didn't experience a single crash even with build world or heavy disk io. I'll try to reverse the video settings within a few weeks to see if it crashes again.
It might not be a complete cure but it works for now. I also fail to see the relationship between video memory and disk io.
tried all the above and still no luck with freebsd 8.2 using zfs. bios 516n with 4gb ram.
few more weeks away from chucking this board. it's been grief from day one.
anybody suggest a good alternative?