On Mon, May 19, 2008 at 07:02:36PM -0500, Dave Uhring wrote:
> 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
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
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/ad4s
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
>
> > 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.
>
> Ma
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
> 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 Andre
> 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 y
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 deliber
> 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
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
http://lists.freebsd.org/mai
> 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 woul
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 e
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
wh
> 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
> > > w
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 erro
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 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 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 release=cvs
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.
>
>
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 , *not*
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 , *not* #include "driver.h". The latter demands that the
> > header file be in the
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 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
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 argu
Dave Uhring wrote:
If a -I/some/directory is used as a CFLAG then the *include directive must read
#include , *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 looks
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 ha
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/sy
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
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
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 s
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. Th
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 buildwor
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
>
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
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 fsc
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
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.co
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 system
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
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 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
:> 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 wil
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 buildworld'
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
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 -DN
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) targe
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.
Thank
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 cv
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 -D
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
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
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 /de
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 re
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 Pon
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
(pass0:mpt
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
http://lists.freebsd.org/mail
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 of=/va
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
59 matches
Mail list logo
