> > 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=81064794762854
> > 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 ra
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
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 w
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 ac
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 D
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: mem
0xf80f-0xf80f,0xfe9c-0xfe9f irq 46 at device 14.0 on pci2
amr0: Using 64-bit DMA
amr0: delete logical drives supported
> 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
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 actu
> 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 r
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
http://lists.freebsd.org/mailman/listinfo/free
> 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
* 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'
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
http://lists.freeb
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 in
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
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
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 al
On Mon, Oct 15, 2007 at 06:21:43PM +0100, Rick wrote:
> Oct 15 11:26:20 metahusky kernel: smist0: on cpu0
> Oct 15 11:26:20 metahusky kernel: device_attach: smist0 attach returned 6
> Oct 15 11:26:20 metahusky kernel: smist1: on cpu1
> Oct 15 11:26:20 metahusky kernel: device_attach: smist1 attac
24 matches
Mail list logo
