we are trying to diagnose errors seen on 6.2, SMP, amd64,
cvsup'ed of
2007-10-09
Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x
Opteron 2216, da3 is on a 3ware 9550-12
we are seeing this error:
g_vfs_done():da3s1a[READ(offset=81064794762854400,
One basic question to ask: where does the value for offset= in
g_vfs_done() come from ?
Either from the file system or from bugs in the code. I don't
remember seeing similar reports before so the probability of
there being bugs in the code is fairly small.
This is all on raw
On 15/10/2007, d_elbracht [EMAIL PROTECTED] wrote:
One basic question to ask: where does the value for offset= in g_vfs_done()
come from ?
Either from the file system or from bugs in the code. I don't remember
seeing similar reports before so the probability of there being bugs
in the code is
Dear All,
I am new to FreeBSD and I need a help from you all please..
I have installed FreeBSD 6.2-RELEASE and did Binary Security Update
from freebsd-update.
Then I have tried to rebuild the kernel with Disk Quota support, but
kernel source was not available in my new server. I gave a try
Artem Kuchin wrote:
Hello!
Maybe someone with deeper knowledge of the internals of FreeBSD
can clean up something for me (any for many others)^
Here are lines from my top:
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND
9258 hordelo_ru1 40 40992K 4260K
Two years ago Christian S.J. Peron had increased total number of SysV shm
pages on 64-bit platform, that allows to create many shm segments more than 2G
in sum. However, the patch does not allow to create a single large segment
more than 2G. The attached patches against 6.x and 7.x allow to create
On Mon, Oct 15, 2007 at 06:09:02PM +0530, Chaminda Indrajith wrote:
Dear All,
Hi,
I am new to FreeBSD and I need a help from you all please..
I have installed FreeBSD 6.2-RELEASE and did Binary Security Update
from freebsd-update.
Then I have tried to rebuild the kernel with Disk
William LeFebvre wrote:
Artem Kuchin wrote:
Hello!
Maybe someone with deeper knowledge of the internals of FreeBSD
can clean up something for me (any for many others)^
Here are lines from my top:
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU
COMMAND 9258 hordelo_ru1
Hi.
I have 3 Dell 2850 with DELL PERC4 SCSI RAID5 6x300GB running lighttpd
serving flash video at around 200Mbit/s.
%grep amr /var/run/dmesg.boot
amr0: LSILogic MegaRAID 1.53 mem
0xf80f-0xf80f,0xfe9c-0xfe9f irq 46 at device 14.0 on pci2
amr0: Using 64-bit DMA
amr0: delete
From: Alson van der Meulen [EMAIL PROTECTED]
This sounds like the documented behavior if the drive was empty or had
no long filenames when you mounted it. From mount_msdosfs(8):
If neither -s nor -l are given, mount_msdosfs searches the root
Artem Kuchin wrote:
CPU is more than just enough in my case. There will a a lot https
sitting there but load, i am sure, will be low.
If the load is low then you may not need very many processes.
Swapping is simply unacceptable, so i am counting only real physical ram.
Whether there is
From: Alson van der Meulen [EMAIL PROTECTED]
This sounds like the documented behavior if the drive was empty or had
no long filenames when you mounted it. From mount_msdosfs(8):
If neither -s nor -l are given, mount_msdosfs searches the root
William LeFebvre wrote:
Artem Kuchin wrote:
CPU is more than just enough in my case. There will a a lot https
sitting there but load, i am sure, will be low.
If the load is low then you may not need very many processes.
They belong to different sites ;) so they need to be run constantly
and
I should just be able to change the TAG in standard-supfile from 6_1 to 6_2,
do a cvsup, and the builds etc to end up with 6.2-RELEASE right?
yes? no?
ta
rob
___
freebsd-stable@freebsd.org mailing list
I should just be able to change the TAG in standard-supfile from 6_1 to 6_2,
do a cvsup, and the builds etc to end up with 6.2-RELEASE right?
yes? no?
Yep:
1. make buildworld
2. make buildkernel (add KERNCONF=mykernel to /etc/make.conf)
3. mergemaster -p
4. make installkernel
5. shutdown -r
On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote:
Esa Karkkainen wrote:
I get Fatal double fault error when writing to a filesystem
mounted from NFS server.
I got an offlist reply in which he suggested that the problem might be
in nve driver.
I installed an additional Intel
* William LeFebvre [EMAIL PROTECTED] [071015 06:49] wrote:
Unfortunately, freebsd does not appear to track the amount of shared
virtual memory for each process. It could be obtained by walking
through all the pages in a process's vm map, but that would really slow
top down. I don't know
Robert Chalmers escribió:
I should just be able to change the TAG in standard-supfile from 6_1 to 6_2,
do a cvsup, and the builds etc to end up with 6.2-RELEASE right?
yes? no?
ta
rob
___
freebsd-stable@freebsd.org mailing list
Esa Karkkainen wrote:
On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote:
Esa Karkkainen wrote:
I get Fatal double fault error when writing to a filesystem
mounted from NFS server.
I got an offlist reply in which he suggested that the problem might be
in nve driver.
I
Alexey Popov wrote:
After some time of running under high load disk performance become
expremely poor. At that periods 'systat -vm 1' shows something like this:
What does high load mean? You need to explain the system workload more.
Disks amrd0
KB/t 85.39
tps 5
MB/s 0.38
% busy
On Mon, Oct 15, 2007 at 11:32:02PM +0300, Esa Karkkainen wrote:
On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote:
Esa Karkkainen wrote:
I get Fatal double fault error when writing to a filesystem
mounted from NFS server.
I got an offlist reply in which he suggested
On Mon, Oct 15, 2007 at 03:08:36PM -0700, Alfred Perlstein wrote:
* William LeFebvre [EMAIL PROTECTED] [071015 06:49] wrote:
Unfortunately, freebsd does not appear to track the amount of shared
virtual memory for each process. It could be obtained by walking
through all the pages in a
This is a pointer to the headsup I posted to freebsd-ports@ detailing the
switch of portsmon's default build environment from i386-6 to i386-7.
This controls such things as determination of whether a port is marked
broken (e.g. with gcc4.2.)
The first set of email reminders based on this have
On Mon, Oct 15, 2007 at 06:21:43PM +0100, Rick wrote:
Oct 15 11:26:20 metahusky kernel: smist0: SpeedStep SMI on cpu0
Oct 15 11:26:20 metahusky kernel: device_attach: smist0 attach returned 6
Oct 15 11:26:20 metahusky kernel: smist1: SpeedStep SMI on cpu1
Oct 15 11:26:20 metahusky kernel:
24 matches
Mail list logo