# AMD64 Stumped and looking for suggestions



## criley (Oct 22, 2009)

I am in the process of setting up 4 new machines however I am getting very odd results when testing however I can only find one open PR that addresses this scenario.

http://www.freebsd.org/cgi/query-pr.cgi?pr=138876&cat=

However I am using unison to sync the home partition which has 25GB of data to the new machine and not running the server as a mail server.

I did as suggested in the PR and backdated the src to 2009.08.31.11.59.59 and I do not experience the issue however if I CVSup the latest version I can run it once with 50% of the time it working however the next time I run it I will crash with the following type of info file response:

```
Dump header from device /dev/mfid0s1b
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 3550932992B (3386 MB)
  Blocksize: 512
  Dumptime: Tue Oct 20 09:29:39 2009
  Hostname: This.is.my.hostname
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 7.2-STABLE #0: Fri Oct 16 14:32:15 CDT 2009
    [email]root@this.is.my.hostname[/email]:/usr/obj/usr/src/sys/THISISMYKERNEL
  Panic String: UMA: page_free used with invalid flags 4

  Dump Parity: 371267221
  Bounds: 2
  Dump Status: good
```
If after the crash I go and repeat the same process of running it deleting the unison archive files then trying again it will indeed crash again on the latest stable cvs.

I also have a archive of the core.txt file but figured this post was getting long enough.

Any help appreciated.
Chris Riley


----------



## criley (Oct 27, 2009)

No one has a clue as to how to proceed on getting a resolution to this?


----------



## tingo (Oct 27, 2009)

Do your server crash randomly while doing nothing?
Have you tried 8.0-rc1 / 8.0-rc2 on them instead on 7-stable?
Have you ruled out hardware problems?


----------



## criley (Oct 27, 2009)

I have 4 machines that experience the same issue and see the same results. If I run a process such as unison to sync 35 gig of files to another machine it runs fine although I notice I go from 15 Gig of memory free down to around 2 gig. If I delete the archive and run it again it gives me this error. If I go to Stable as of 8/31/09 11:59:59 I do not have the problem. If I try running some various memory handling checking scripts I never see it swap before it crashes. If I do the same on a identical machine running Stable as of 8/31/09 11:59:59 it works fine and as expected. I am hesitant to put 8.0 on the servers because these are production servers 2 of which are for NFS and the other 2 are Mysql servers.


----------



## tingo (Oct 27, 2009)

And you don't have at test server (identical hardware) that you can run your tests on?
That would be best for business, IMHO.


----------



## criley (Oct 27, 2009)

Well these machines are not yet in production but before I can get past this issue I am not upgrading 22 other machines that are older but similar machines since those are in production.


----------



## tingo (Oct 27, 2009)

All the more reason to test before they go into production.
You need to try more things in order to locate the problem.
A few more ideas:
As of your current description, the problem can be related to data 
copying.
Have you tried to copy the same amount of data locally (disk to disk) to see if the problem occurs then?
Have your tried to use another method (ftp, scp) o copy the same amount of data via the network to see if this is a network issue?


----------



## aragon (Oct 27, 2009)

Have you tried posting to one of the mailing lists?


----------



## criley (Nov 2, 2009)

Well I have tried 8-RC2 and it works without a problem so I am now even more confused seeing as 7.2 Stable should mean Stable.


----------



## DutchDaemon (Nov 2, 2009)

'stable' alludes to the source code, not 'performance' or 'functionality'. If you need that type of stability, stick with RELEASE.



			
				&quot said:
			
		

> 24.5.2.1 What Is FreeBSD-STABLE?
> 
> FreeBSD-STABLE is our development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users.


----------

