Did you run '/etc/rc.d.hostid start' first?
IIRC, it is needed before zfs will mount in single-user mode.
Just curious, as I've been wanting to fiddle around with ZFS in my spare
time... what is the solution here if you have failed hardware and you want
to move your ZFS disks to another
My home computer (no internet access, cannot share results :-) is
single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have seen
that on stable it doesn't behave as speedily as on FreeBSD number 6. I
have checked utility in subject (which is probably not the best
alternative) and it
Hello,
monitor# camcontrol negotiate 0:0 -W 16
Current Parameters:
(pass0:mpt0:0:0:0): sync parameter: 0
(pass0:mpt0:0:0:0): offset: 0
(pass0:mpt0:0:0:0): bus width: 8 bits
(pass0:mpt0:0:0:0): disconnection is enabled
(pass0:mpt0:0:0:0): tagged queueing is enabled
monitor# dd if=/dev/zero
Hello, Daniel
Can you execute camcontrol with some parameters again?
For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'.
--
Shunsuke SHINOMIYA [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
Oh, btw, this make improvements only on 7.0-Release and Stable using ULE
scheduler.
- Using 4BSD Scheduler will improve disk access speed but no cpu usage.
- On FreeBSD 6.2 and 6.3 this make no difference on cpu usage/speed
(about 60mb/sec maximum using 100% cpu).
Thanks,
Daniel
Daniel
Greetings
I am having trouble with suspend/resume on my Thinkpad X31, running
7.0-STABLE as of April 23. Any help would be appreciated.
First problem: When I run acpiconf -s3 from mulituser mode, the
system suspends immediately, without executing /etc/rc.suspend (which
has mode 755); then on
Much better:
endevor# camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000
Current Parameters:
(pass0:mpt0:0:0:0): sync parameter: 8
(pass0:mpt0:0:0:0): frequency: 160.000MHz
(pass0:mpt0:0:0:0): offset: 127
(pass0:mpt0:0:0:0): bus width: 16 bits
(pass0:mpt0:0:0:0): disconnection is enabled
On Mon, May 19, 2008 at 10:24:43PM +1200, James Butler wrote:
Second problem: When the system panics, I don't get a dump (or
textdump for that matter, when I turn them on); in the boot messages,
I see kernel dumps on /dev/ad0s2b and then later (from memory),
Looking for core dumps on
on 16/05/2008 19:48 Scott Long said the following:
There is no write support in UDF in FreeBSD. When I wrote the fs code,
packet writing was the only way to do discrete writes, and it's very
hard to make that work with a traditional VM system. Now with DVD+R,
it's probably worth someone's
Andriy Gapon wrote:
on 16/05/2008 19:48 Scott Long said the following:
There is no write support in UDF in FreeBSD. When I wrote the fs code,
packet writing was the only way to do discrete writes, and it's very
hard to make that work with a traditional VM system. Now with DVD+R,
it's probably
Sources checked out yesterday, updated this morning using cvsup and
repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/libc
/usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp
-I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include
-I/usr/src/lib/libc/i386
This symbol has been added to fcntl.h recently. It appears as if your
build is picking up the installed header rather than the one from the
source tree. Are you using 'make buildworld'?
On 19 May 2008, at 16:17, Dave Uhring wrote:
Sources checked out yesterday, updated this morning using
On May 18, 2008, at 3:26 AM, Ian Smith wrote:
Hashed per flow, (srcip^destip^srcport^dstport) mod
curr_dyn_buckets, so
packets for both directions of a given flow hash to the same
bucket. In
the case you mention, you could likely expect reasonable
distribution by
src_ip/src_port.
JoaoBR [EMAIL PROTECTED] wrote:
man page thar zfs can not be a dump device, not sure if I understand it
as meant but I can dump to zfs very well and fast as long as
recordsize=128
I assume you tried dump(8), while the sentence in the man
page is about using a ZFS volume as dumpon(8) target:
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote:
This symbol has been added to fcntl.h recently. It appears as if your build
is picking up the installed header rather than the one from the source
tree. Are you using 'make buildworld'?
Yes, although at this point is it 'make
On Mon, May 19, 2008 at 11:38:25AM -0500, Dave Uhring wrote:
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote:
This symbol has been added to fcntl.h recently. It appears as if your build
is picking up the installed header rather than the one from the source
tree. Are you using
On 19 May 2008, at 17:38, Dave Uhring wrote:
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote:
This symbol has been added to fcntl.h recently. It appears as if
your build
is picking up the installed header rather than the one from the
source
tree. Are you using 'make
: BTW, Remko has kindly notified me that Reinoud Zandijk has completed his
: long work on UDF write support in NetBSD. I think that porting his work
: is our best chance to get write support in FreeBSD too.
:
:
:I think you'll find that implementing VOPs and filling in UDF data
:structures will
On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote:
On 19 May 2008, at 17:38, Dave Uhring wrote:
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote:
This symbol has been added to fcntl.h recently. It appears as if your
build
is picking up the installed header rather than
On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote:
Is there some reason you're using -DNO_CLEAN, and haven't just nuked
/usr/obj/* and done buildworld normally? I can't reproduce any of this
behaviour on any of our RELENG_7 systems.
I have repeately nuked /usr/obj. That is
On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote:
On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote:
On 19 May 2008, at 17:38, Dave Uhring wrote:
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote:
This symbol has been added to fcntl.h recently. It appears
On 19 May 2008, at 17:58, Dave Uhring wrote:
On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote:
Is there some reason you're using -DNO_CLEAN, and haven't just nuked
/usr/obj/* and done buildworld normally? I can't reproduce any of
this
behaviour on any of our RELENG_7
On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote:
Is there breakage of some sort being caused by your make.conf or (less
probable) your src.conf? Any filesystem corruption (boot single user
and force fsck on all the filesystems)?
[EMAIL PROTECTED] /etc]$ grep -v ^# make.conf
On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote:
On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote:
Is there some reason you're using -DNO_CLEAN, and haven't just nuked
/usr/obj/* and done buildworld normally? I can't reproduce any of this
behaviour on any of
On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote:
On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote:
Is there breakage of some sort being caused by your make.conf or (less
probable) your src.conf? Any filesystem corruption (boot single user
and force fsck on all
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote:
On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote:
[EMAIL PROTECTED] /etc]$ grep -v ^# make.conf
CPUTYPE?=athlon64
CFLAGS= -O2 -fno-strict-aliasing -pipe -m32
CXXFLAGS+= -fconserve-space
MAKE_SHELL?=sh
On Mon, May 19, 2008 at 10:02:23AM -0700, David Wolfskill wrote:
On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote:
The build is going nowhere without the correct header files in
/usr/include/sys.
That appears to indicate that your build environment is fundamentally
broken..
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote:
Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money
is on that I won't be able to reproduce the problem.
Something I thought of while doing the above: there's been reports in
the past of problems with
On Mon, May 19, 2008 at 10:04:28AM -0700, Jeremy Chadwick wrote:
On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote:
I have repeately nuked /usr/obj. That is not going to put updated header
files
where they need to be.
It's apparent you don't quite understand. The updated
On Mon, May 19, 2008 at 06:00:39PM +0100, Doug Rabson wrote:
The thing is that a working buildworld doesn't depend on headers from
/usr/include. One of the first thing it does is install a set of new
headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be
useful to see a
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote:
Something I thought of while doing the above: there's been reports in
the past of problems with buildworld (or building software in general)
bombing out or behaving oddly due to clock issues on the local machine.
If you don't
On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote:
On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote:
I posted the relevant output from make buildworld. Copying the 3 new
header
files from /usr/src/sys/sys to /usr/include/sys solved my original problem.
Dave Uhring [EMAIL PROTECTED] writes:
On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote:
On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote:
I posted the relevant output from make buildworld. Copying the 3 new
header
files from /usr/src/sys/sys to
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote:
This picked up src-all using the RELENG_7 tag. I then attempted a
buildworld (cd /usr/src time make -j2 buildworld). It's just begun
stage 2.3, but so far no issues. I'll report back in about 30 minutes
or so, when it has a
Dave Uhring wrote:
If a -I/some/directory is used as a CFLAG then the *include directive must read
#include driver.h, *not* #include driver.h. The latter demands that the
header file be in the same directory as the source file.
Absolutely not true. Directly from the gcc online manual:
GCC
Hello, Arne.
I try to build storage server for my home (I have a LOT of media
files) with FreeBSD 7, 5xHDD (WD 500Gb) and geom_raid5 (simple
version from perforce, beacuse
http://home.tiscali.de/cmdr_faako/geom_raid5.tbz is not patched for FreeBSD7).
Array FS were created with default
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote:
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote:
This picked up src-all using the RELENG_7 tag. I then attempted a
buildworld (cd /usr/src time make -j2 buildworld). It's just begun
stage 2.3, but so far no
Hello, Arne.
You wrote 19 мая 2008 г., 23:42:20:
I've called `df -h' and it shows, that I have NEGATIVE amount of
space on /usr/home/storage (about -14Mb of 1.8Tb).
Negative amount of USED space, sorry.
--
// Black Lion AKA Lev Serebryakov [EMAIL PROTECTED]
On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote:
Dave Uhring [EMAIL PROTECTED] writes:
If a -I/some/directory is used as a CFLAG then the *include directive must
read
#include driver.h, *not* #include driver.h. The latter demands that the
header file be in the same
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote:
On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote:
Dave Uhring [EMAIL PROTECTED] writes:
If a -I/some/directory is used as a CFLAG then the *include directive
must read
#include driver.h, *not* #include
On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote:
On May 19, 2008, at 1:21 PM, Dave Uhring wrote:
In any case, that problem has been solved by putting the updated header
files
in /usr/include/sys and will be properly fixed when I can finally make
installworld.
I did not
On May 19, 2008, at 1:21 PM, Dave Uhring wrote:
In any case, that problem has been solved by putting the updated
header files
in /usr/include/sys and will be properly fixed when I can finally
make installworld.
I did not have to manually move or copy any header files.
*default
On 2008-May-19 11:38:25 -0500, Dave Uhring [EMAIL PROTECTED] wrote:
Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a
clean
build.
You have this backwards. If you are getting wierd buildworld errors, your
first step should be to delete /usr/obj and then run 'make
On May 19, 2008, at 7:02 PM, Dave Uhring wrote:
On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote:
I did not have to manually move or copy any header files.
Did you start from a RELEASE source tree and userland?
No. I was upgrading from STABLE last built about on April
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote:
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote:
The problem is that gcc is *not* finding the file in the directory
referenced by the -I cflag. If I copy the header files to the directory
where the error occurs
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote:
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote:
The problem is that gcc is *not* finding the file in the directory
referenced by the -I cflag. If I copy the header files to the directory
where the error
Dave Uhring wrote:
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote:
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote:
The problem is that gcc is *not* finding the file in the directory
referenced by the -I cflag. If I copy the header files to the directory
On Mon, May 19, 2008 at 11:02:31AM +0200, Daniel Ponticello wrote:
Hello,
monitor# camcontrol negotiate 0:0 -W 16
Current Parameters:
(pass0:mpt0:0:0:0): sync parameter: 0
(pass0:mpt0:0:0:0): offset: 0
(pass0:mpt0:0:0:0): bus width: 8 bits
(pass0:mpt0:0:0:0): disconnection is
The c compiler is the one shipped with 7.0 RELEASE. Except for the 3
new header files that I placed from cvsupped sources into /usr/include/sys
the entire system is 7.0 RELEASE.
Prior to beginning the build I deliberately set
# export CFLAGS=
Nothing else in my environment would have
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
___
freebsd-stable@freebsd.org mailing list
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
I think what Mark was getting at is that simply setting CFLAGS to
prior to make does not trump the setting of CFLAGS in
On Mon, May 19, 2008 at 10:08:22PM -0400, Josh Carroll wrote:
The c compiler is the one shipped with 7.0 RELEASE. Except for the 3
new header files that I placed from cvsupped sources into /usr/include/sys
the entire system is 7.0 RELEASE.
Prior to beginning the build I deliberately set
No, even though it is a dual-core system. I did not want to chance a
race condition. I simply executed 'make buildworld' initially, then
'make -DNO_CLEAN buildworld' when I encountered problems in the build.
Ok, it was worth asking, just to rule out the obvious.
I'm still not sure where
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
bash is broken. Empty environment variables have meaning.
Mark
--
Mark Andrews, ISC
1
On Mon, May 19, 2008 at 10:59:18PM -0400, Josh Carroll wrote:
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
I think what Mark was getting at is that simply
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
bash is broken. Empty environment variables have meaning.
Mark
And when
On Mon, May 19, 2008 at 11:10:32PM -0400, Josh Carroll wrote:
No, even though it is a dual-core system. I did not want to chance a
race condition. I simply executed 'make buildworld' initially, then
'make -DNO_CLEAN buildworld' when I encountered problems in the build.
Ok, it was worth
On Mon, May 19, 2008 at 03:03:42PM -0500, Dave Uhring wrote:
[EMAIL PROTECTED] /usr/src/contrib/groff]# mount
/dev/ad4s2a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
/dev/ad4s2h on /home (ufs, local, soft-updates)
/dev/ad4s2e on /usr (ufs, local, soft-updates)
/dev/ad4s2g on
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote:
I will attempt the same with your make.conf to see if it's any
different.
I'll add that while I slept, I let a 'make buildworld' go with your
exact make.conf flags -- it completed successfully.
--
| Jeremy Chadwick
59 matches
Mail list logo
