As part of the release documentation for 5.0 DP1, we would like to
provide a comprehensive testing guide. If you have code in -CURRENT
that you would like to receive feedback on from the developer preview,
then please submit a short email to [EMAIL PROTECTED] with the following:
1. A brie
On Thu, Mar 14, 2002 at 09:01:47PM -0800, Terry Lambert wrote:
> I think it's idiotic to put spackle over the broken window,
> paint the wall, and then call it "fixed".
I know what objprelink is, and as far as I'm concerned it's there to work
around the substandard support that C++ gets from the
On Thu, Mar 14, 2002 at 04:40:08PM -0800, Peter Wemm wrote:
> If this is going to be a "static" release (calling it RELENG_5_anything is
> a mistake IMHO) then this isn't a big deal. But if people are expecting
> it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then
> we have
On Fri, Mar 15, 2002 at 03:32:00AM +0100, Dag-Erling Smorgrav wrote:
> "Bruce A. Mah" <[EMAIL PROTECTED]> writes:
> > Differences of opinion on naming aside...the branch isn't supposed to
> > last long at all. The point is to provide a slightly polished snapshot
> > to the wider developer communi
On Thu, Mar 14, 2002 at 10:16:14PM -0800, Peter Wemm wrote:
> Alex Zepeda wrote:
> > On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote:
> >
> > > The compile problems seem to be related to recent compiler toolchain
> > > changes, which you might not see unless you recompiled everythin
Alex Zepeda wrote:
> On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote:
>
> > The compile problems seem to be related to recent compiler toolchain
> > changes, which you might not see unless you recompiled everything qt23
> > depends on from scratch (which the package cluster does).
>
On Thu, 14 Mar 2002, ozan s. yigit wrote:
> > Add the -ffloat-store flag to your compilation flags (or
> > add -msoft-float).
>
> that really means for this compiler on certain platforms, you
> can have slow and correct or fast and incorrect, but NOT fast
> and correct.
I think fast and correct
Alan Eldridge wrote:
> On Thu, Mar 14, 2002 at 08:25:39PM -0800, Terry Lambert wrote:
> >Alex Zepeda wrote:
> >> As far as Qt goes, rip out that objprelink crap. Without it Qt will build
> >> and work just fine. At least Qt 3.whatever works for me. I don't know
> >> why objprelink isn't working
Moissanite: More Fire and Brilliance
http://www.moissanite.com/emailads/trade/031102/truth_header.gif";
width="500" height="45" border="0" alt="The Truth About Moissanite">
http://www.moissanite.com/emailads/trade/031102/jfire.jpg";
width="680" height="564"
On Thu, Mar 14, 2002 at 09:36:30PM -0500, Robert Watson wrote:
> It's worth noting, BTW, that originally the release engineering team
> planned to use Perforce for this to avoid the branch issue entirely,
> minimize impact on the main tree, etc, but decided not to due to the high
> volume of compl
On Thu, Mar 14, 2002 at 08:25:39PM -0800, Terry Lambert wrote:
> Alex Zepeda wrote:
> > As far as Qt goes, rip out that objprelink crap. Without it Qt will build
> > and work just fine. At least Qt 3.whatever works for me. I don't know
> > why objprelink isn't working correctly for Qt, but I do
subscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, Mar 14, 2002 at 08:25:39PM -0800, Terry Lambert wrote:
>Alex Zepeda wrote:
>> As far as Qt goes, rip out that objprelink crap. Without it Qt will build
>> and work just fine. At least Qt 3.whatever works for me. I don't know
>> why objprelink isn't working correctly for Qt, but I don't
In message: <[EMAIL PROTECTED]>
Gavin Atkinson <[EMAIL PROTECTED]> writes:
: On Mon, 11 Mar 2002, M. Warner Losh wrote:
:
: > John Baldwin also cornered me about these panics. I'll be looking at
: > them tonight. I think he gave me a good way to recreate them.
:
: The patches never
Alex Zepeda wrote:
> As far as Qt goes, rip out that objprelink crap. Without it Qt will build
> and work just fine. At least Qt 3.whatever works for me. I don't know
> why objprelink isn't working correctly for Qt, but I don't really care.
> For me disabling WITNESS does more than enough to ma
On Fri, 2002-03-15 at 14:49, Jeff Kletsky wrote:
> Tried the "obvious" -- manually loading acpi.ko -- still fails
[snip]
> 7) Remove acpi.ko.flp, insert mfsroot.flp
>
> boot
>
> ...and watch the BTX halt
Can you provide a copy of the BTX fault information?
It's a bit hard to debu
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, Mar 14, 2002 at 06:56:53PM -0800, Alex Zepeda wrote:
> On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote:
>
> > The compile problems seem to be related to recent compiler toolchain
> > changes, which you might not see unless you recompiled everything qt23
> > depends on from s
> > "Bruce A. Mah" <[EMAIL PROTECTED]> writes:
> > > Differences of opinion on naming aside...the branch isn't supposed to
> > > last long at all. The point is to provide a slightly polished snapshot
> > > to the wider developer community. We can't do the QA/releng work on
> > > HEAD without cal
On Thu, Mar 14, 2002 at 06:56:53PM -0800, Alex Zepeda wrote:
> On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote:
>
> > The compile problems seem to be related to recent compiler toolchain
> > changes, which you might not see unless you recompiled everything qt23
> > depends on from s
Robert Watson <[EMAIL PROTECTED]> writes:
> It's worth noting, BTW, that originally the release engineering team
> planned to use Perforce for this to avoid the branch issue entirely,
> minimize impact on the main tree, etc, but decided not to due to the high
> volume of complaints on the topic.
On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote:
> The compile problems seem to be related to recent compiler toolchain
> changes, which you might not see unless you recompiled everything qt23
> depends on from scratch (which the package cluster does).
Right, when I tried to compil
On Thu, 14 Mar 2002, Bruce A. Mah wrote:
> I can't imagine why anyone would expect to cvsup this thing at some
> point in the distant future
Rule number one of release engineering... user's will do all kinds
of wacky stuff that you would never expect them to do, and complain
bitterly whe
Try this ...
Do you have your own /etc/make.conf file ?
If then, I hope you did not use NO_MODULES="YES" as I was. :(
1. Did you do 'make buildkernel & installkernel' with KERNCONF=GENERIC
first ?
After reboot once, I re-compiled my own kernel using NEWCARD &
NEWCARD.hints.
2. Modify NEWCAR
l
>
> Having been unable to confirm a complete and proper installation of
> 5.0-CURRENT on my Sony PCG-SRX7/EP (similar to SRX77) laptop using the
> 4.5-RELEASE installer, I have made a bootable CD from
> 5.0-20020313-CURRENT, as well as floppies from 5.0-20020314-CURRE
On Fri, Mar 15, 2002 at 08:36:29AM +0600, Maxim M. Kazachek wrote:
> I've installed qt23 from ports painlessly
Fine, I'm glad to hear it :)
The compile problems seem to be related to recent compiler toolchain
changes, which you might not see unless you recompiled everything qt23
depends on from
On 15 Mar 2002, Dag-Erling Smorgrav wrote:
> "Bruce A. Mah" <[EMAIL PROTECTED]> writes:
> > Differences of opinion on naming aside...the branch isn't supposed to
> > last long at all. The point is to provide a slightly polished snapshot
> > to the wider developer community. We can't do the QA/
I've installed qt23 from ports painlessly
Sincerely, Maxim M. Kazachek
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Moissanite: More Fire and Brilliance
http://www.moissanite.com/emailads/trade/031102/truth_header.gif";
width="500" height="45" border="0" alt="The Truth About Moissanite">
http://www.moissanite.com/emailads/trade/031102/jfire.jpg";
width="680" height="564"
"Bruce A. Mah" <[EMAIL PROTECTED]> writes:
> Differences of opinion on naming aside...the branch isn't supposed to
> last long at all. The point is to provide a slightly polished snapshot
> to the wider developer community. We can't do the QA/releng work on
> HEAD without calling for a code free
[Trimming Cc list a little bit]
If memory serves me right, Peter Wemm wrote:
> Actually, with my CVS hat on, I have a *huge* problem with this.
In the future, if you see such huge problems come up, a little more
advance notice might be nice. :-(
> We have a large number of "temporary" repo co
On Thu, Mar 14, 2002 at 04:31:44PM -0800, Kris Kennaway wrote:
> I'm just uploading a new 5.x package set. This run was better than
> the previous (5364 packages vs. 5123 for the last run, but far fewer
> than the 5973 packages which are building in 4.x), but there were
> still a number of signi
Having been unable to confirm a complete and proper installation of
5.0-CURRENT on my Sony PCG-SRX7/EP (similar to SRX77) laptop using the
4.5-RELEASE installer, I have made a bootable CD from
5.0-20020313-CURRENT, as well as floppies from 5.0-20020314-CURRENT.
Both exhibit the same set of
:> mcopymap(from, to, length, flags)
:
:I'm not sure you want to copy it..
:I mean you want the dta di disappear from the old address.
:It's more a "movepages()"
MAP_MOVE|MAP_SHARED
-Matt
:>
:> flags:
:>
:> MAP_SHARED share the sa
--- David O'Brien <[EMAIL PROTECTED]> wrote:
> Will you be doing a run on a Tru5-CURRENT box?
> Some of these it is hard to say anything about due to the very special
> environment you built them under.
I have a tru 5.0-CURRENT environment.. also.. is there any changes where
my ENABLE_NLS dillema
On Thu, Mar 14, 2002 at 04:41:59PM -0800, David O'Brien wrote:
> On Thu, Mar 14, 2002 at 04:31:44PM -0800, Kris Kennaway wrote:
> > I'm just uploading a new 5.x package set. This run was better than
> > the previous (5364 packages vs. 5123 for the last run, but far fewer
> > than the 5973 package
On Thu, Mar 14, 2002 at 04:31:44PM -0800, Kris Kennaway wrote:
> I'm just uploading a new 5.x package set. This run was better than
> the previous (5364 packages vs. 5123 for the last run, but far fewer
> than the 5973 packages which are building in 4.x), but there were
> still a number of signif
Murray Stokely wrote:
> On March 15, a RELENG_5_0_DP1 branch will be created in CVS for
> final release polishing. This will allow us to provide translated
> release notes, sync up sysinstall and the package set, bump version
> numbers, and tweak default diagnostic settings without further
> i
Hi all,
I'm just uploading a new 5.x package set. This run was better than
the previous (5364 packages vs. 5123 for the last run, but far fewer
than the 5973 packages which are building in 4.x), but there were
still a number of significant failures: qt2 is still failing so kde
doesn't build, and
On Thu, Mar 07, 2002 at 10:40:07AM +0900, I wrote:
> > Apparently you have KTR enabled (not the default in GENERIC). I think
> > WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and
> > we now get an endless loop when nanotime() is called with an invalid
> > timecounter in the f
On Thu, 14 Mar 2002, Matthew Dillon wrote:
>
> :thing to do in FreeBSD ? :-)
> :
> :And everybody with VM clue I've asked says it would be trivial to
> :flip two page-table entries, so for all I care it can be
> :
> : mexchangemapping(void *from, void *to, size_t length)
> :
> :--
> :Pou
:thing to do in FreeBSD ? :-)
:
:And everybody with VM clue I've asked says it would be trivial to
:flip two page-table entries, so for all I care it can be
:
: mexchangemapping(void *from, void *to, size_t length)
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTEC
:>Have you thought about issuing a madvise(MADV_WILLNEED) after the
:>brk/mmap call in malloc, at least doing it when it's called via
:>realloc, this might get rid of the superfolous (sp?) page faults
:>that David Greenman reported.
:
:It would be much more valuable to add a
: mremap(void *
In the last episode (Mar 14), Doug White said:
> On Tue, 12 Mar 2002, Rasmus Skaarup wrote:
> > Hmm, but I'm not sure all kinds of storage devices have
> > serialnumbers that could be fetched (tape devices for instance?)
> > and can we rely on the hardware manufacturers to provide unique
> > seria
Jan Stocker wrote:
> So now i am a little bit confused... State of the art:
>
> 1) Bug is in -stable and -current
>--> This means possible patches only in -current arent responsible for
>this behaviour
Unless they were MFC'ed to -STABLE. THis is why you generally
should compare -REL
On Tue, 12 Mar 2002, Rasmus Skaarup wrote:
> Hmm, but I'm not sure all kinds of storage devices have serialnumbers that
> could be fetched (tape devices for instance?) and can we rely on the
> hardware manufacturers to provide unique serialnumbers?
Although it's an isolated case, you do have glo
> If you really want to investigate FreeBSD FP/math capabilities
> search for UCBTEST or visit
> www.cs.berkeley.edu/~jhauser/arithmetic/TestFloat.html
cool! thanks for the pointer.
oz
---
gag reflex is an essential part of computing. -- anon
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
On Thu, Mar 14, 2002 at 07:50:38PM +0100, Raymond Wiker wrote:
> ozan s. yigit writes:
> > > Add the -ffloat-store flag to your compilation flags (or
> > > add -msoft-float).
> >
> > that really means for this compiler on certain platforms, you
> > can have slow and correct or fast and incor
On Wed, Mar 13, 2002 at 10:24:20PM +0100, Martin Blapp wrote:
> > We are using a set of patches that were part of gcc 2.95.3_test3.
> > Do you have a sample program in which exceptions are still broken on
> > FreeBSD 4.5?
>
> cd /usr/ports/devel/stlport
> make install
> cd work/STL*/test/eh
>
>
ozan s. yigit writes:
> > Add the -ffloat-store flag to your compilation flags (or
> > add -msoft-float).
>
> that really means for this compiler on certain platforms, you
> can have slow and correct or fast and incorrect, but NOT fast
> and correct.
Actually, if -ffloat-store is t
> Add the -ffloat-store flag to your compilation flags (or
> add -msoft-float).
that really means for this compiler on certain platforms, you
can have slow and correct or fast and incorrect, but NOT fast
and correct.
oz
---
freedom has a mental cost. -- peter roosen-runge
To Unsubscribe: send
On Thu, Mar 14, 2002 at 01:20:51PM -0500, Alexander Kabaev wrote:
> >b) other options were set at compile time
> > --> Why dont change to the same in the port?
> > Leads it to a broken world?
> > If the only difference is the lost of binary compatibility,
> >
On Thu, Mar 14, 2002 at 12:59:31PM -0500, ozan s. yigit wrote:
> in a related tangential note, i recently found (out of sheer irritation)
> in less than an hour that several (including the latest) versions of GCC
> -O and -O2 failed the paranoia test in different ways, to wit:
>
> gcc -o paranoi
> 2) Bug is in os delivered gcc but not in port gcc.
>a) port has more or less patches / os gcc has been modified
> --> Didn't someone told they are the same?
GCC from ports uses DWARF2 exception unwinding while GCC in src tree
uses sjlj exceptions. The exception handling code generated
>And everybody with VM clue I've asked says it would be trivial to
>flip two page-table entries, so for all I care it can be
It's going to take a fair bit more than just swapping some page table
entries, but it's certainly doable.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://ww
On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote:
> 2) Bug is in os delivered gcc but not in port gcc.
>a) port has more or less patches / os gcc has been modified
> --> Didn't someone told they are the same?
Port has less patches. If you look at
/usr/src/contrib/gcc/contrib
in a related tangential note, i recently found (out of sheer irritation)
in less than an hour that several (including the latest) versions of GCC
-O and -O2 failed the paranoia test in different ways, to wit:
gcc -o paranoia paranoia.c
[paranoia output elided]
The number of DEFECTs discovere
Do you have a small, reproducible test case?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
So now i am a little bit confused... State of the art:
1) Bug is in -stable and -current
--> This means possible patches only in -current arent responsible for
this behaviour
2) Bug is in os delivered gcc but not in port gcc.
a) port has more or less patches / os gcc has been modifie
Hi
When building the gcl port (ports/lang/gcl), the build dies when
``saved_gcl'' is run. The symptiom during the buld is a sig11 and
a core dump. This is _after_ the patches that Peter worked out
(and David O'B later committed).
Here is a backtrace:
Core was generated by `saved_gcl'.
Program t
> Do you have a patch for this ?
I do not fully understand the parts of GCC involved, so I need some
time to verify my initial diagnosis and to create a patch. In other
words - not yet :)
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > In message: <[EMAIL PROTECTED]>
: > Ed Hall <[EMAIL PROTECTED]> writes:
: > : Exception-handling is broken with -O in -stable, and has been for years.
: > : FreeBSD is on
Hi,
> This is a case of exception context register getting clobbered in
> shared library function call. GCC does not reload it when needed and
> this ultimately leads to semi-random word in program memory decremented
> by the __cp_pop_exception function. The bug is only triggered under very
> s
This is a case of exception context register getting clobbered in
shared library function call. GCC does not reload it when needed and
this ultimately leads to semi-random word in program memory decremented
by the __cp_pop_exception function. The bug is only triggered under very
specific circums
This is a case of exception context register getting clobbered in
shared library function call. GCC does not reload it when needed and
this ultimately leads to semi-random word in program memory decremented
by the __cp_pop_exception function. The bug is only triggered under very
specific circums
On Mon, 11 Mar 2002, M. Warner Losh wrote:
> John Baldwin also cornered me about these panics. I'll be looking at
> them tonight. I think he gave me a good way to recreate them.
The patches never fixed one of the panics I see, with a GlobalVillage
Ethernet/Modem card. The kernel still traps wi
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> It would be much more valuable to add a
>> mremap(void *from, void *to, size_t length);
>>
>> since that can _solve_ the problem in _all_ cases, rather than
>> add more or less byzantine workarounds for silly benchmarks.
>
>You're
* Poul-Henning Kamp <[EMAIL PROTECTED]> [020314 01:53] wrote:
> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
> >
> >Have you thought about issuing a madvise(MADV_WILLNEED) after the
> >brk/mmap call in malloc, at least doing it when it's called via
> >realloc, this might get rid of the
Hi John,
On Thu, Mar 14, 2002 at 03:15:02PM +0700, John Indra wrote:
> On Thu, Mar 14, 2002 at 07:40:04AM +0100, Poul-Henning Kamp wrote:
[...]
> This is not just talking about benchmarks. This situation will probably make
> people conclude things that are not beneficial at all for FreeBSD. Peopl
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>* Poul-Henning Kamp <[EMAIL PROTECTED]> [020313 22:43] wrote:
>>
>> But if somebody wants to try to code this optimization, I'll be more
>> than happy to review the result. I just don't expect it to do much
>> in "real-life" as opposed to
> Per thread exception stacks? THat's where I'd look...
Hmm, good point. The programms that crashed were all threaded ...
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
* Poul-Henning Kamp <[EMAIL PROTECTED]> [020313 22:43] wrote:
>
> But if somebody wants to try to code this optimization, I'll be more
> than happy to review the result. I just don't expect it to do much
> in "real-life" as opposed to "silly benchmark" situations.
Have you thought about issuing
On Thu, Mar 14, 2002 at 07:40:04AM +0100, Poul-Henning Kamp wrote:
>But if somebody wants to try to code this optimization, I'll be more
>than happy to review the result. I just don't expect it to do much
>in "real-life" as opposed to "silly benchmark" situations.
Sorry to start this thread at
73 matches
Mail list logo
