Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
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 the first place. Well, the reason that I did was because I had this in my head: What? This little snippet of code runs bloddy slower than in Linux? Boy... I use Perl happily in FreeBSD, and I can't lie to myself that in some situations, I felt like my FreeBSD perl scripts run slower than in Linux. Well... If I write to [EMAIL PROTECTED], those genius developers might catch this and maybe discuss on how to overcome the problem. I don't know whether anything's useful, but at least if I post, more people will notice and PROBABLY can improve a thing or two. I hate to run my scripts under Linux and will do everything I can to make my scripts run in FreeBSD at least as fast as in Linux! This is not just talking about benchmarks. This situation will probably make people conclude things that are not beneficial at all for FreeBSD. People in my definition are non-C-coders and those-who-just-like-to-generalize-things. Exclude me from that list, but there are many of others who fit to that group. I am not complaining and bugging FreeBSD developers to do anything at all. Well, I can't help myself, but at least I have done my part to post this. Thanks... /john I go, I fight, and I win! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
* 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 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. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
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 silly benchmark situations. 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 *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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
* 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 superfolous (sp?) page faults that David Greenman reported. 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 right that it would be a better optimization, however it's much more code to write than simply passing a flag down to the code responsible for the allocation especially when you _know_ you'll need it. I may be wrong about MADV_WILLNEED making any difference anyhow. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
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 right that it would be a better optimization, however it's much more code to write than simply passing a flag down to the code responsible for the allocation especially when you _know_ you'll need it. Since when has going that extra mile to do it right been the wrong 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 PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panics with CardBus
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 with a page fault in pccard_scan_cis, however with the patches, this now nanifests itself with the panic message vm_fault: fault on nofault entry. I am more than happy to help debug this. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 circumstances involving inline functions and nested degenerate exception handlers, that's why it existed unnoticed for quite some time. On Wed, 13 Mar 2002 22:53:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: 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 one of the few systems that use setjmp/longjmp stack unwinds: to implement exceptions, so when the GCC folks broke that path, it was: never fixed. There are supposedly patches floating around that fix the: problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Per thread exception stacks? THat's where I'd look... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 circumstances involving inline functions and nested degenerate exception handlers, that's why it existed unnoticed for quite some time. On Wed, 13 Mar 2002 22:53:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: 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 one of the few systems that use setjmp/longjmp stack unwinds: to implement exceptions, so when the GCC folks broke that path, it was: never fixed. There are supposedly patches floating around that fix the: problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Per thread exception stacks? THat's where I'd look... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 specific circumstances involving inline functions and nested degenerate exception handlers, that's why it existed unnoticed for quite some time. Do you have a patch for this ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 one of the few systems that use setjmp/longjmp stack unwinds : : to implement exceptions, so when the GCC folks broke that path, it was : : never fixed. There are supposedly patches floating around that fix the : : problem, but they either didn't work as advertised or the ball got dropped. : : H, C++ exceptions work in -stable with -O and have for at least a : year. At least they are working for us in our environment. What's : busted? : : Per thread exception stacks? THat's where I'd look... Yes, that works. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 the body of the message
Linker or startup brokenness?
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 terminated with signal 11, Segmentation fault. #0 0x0 in ?? () (gdb) where #0 0x0 in ?? () #1 0x8181578 in __do_global_ctors_aux () #2 0x80480b6 in _init () (gdb) Any ideas? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: gcc -O broken in CURRENT
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 modified -- Didn't someone told they are the same? 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, i would say, ok... do it now and we'll need to compile or ports... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alexander Kabaev Sent: Thursday, March 14, 2002 5:26 PM To: Martin Blapp Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: gcc -O broken in CURRENT 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 the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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
Re: gcc -O broken in CURRENT
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 discovered = 1. The number of FLAWs discovered = 1. gcc -O2 -o paranoia paranoia.c [paranoia output elided] The number of FAILUREs encountered = 4. The number of SERIOUS DEFECTs discovered = 4. The number of DEFECTs discovered = 2. The number of FLAWs discovered = 2. i assume everyone knows about kahan and paranoia. if not see netlib. oz --- a technology is indistinguishable from | electric: [EMAIL PROTECTED] its implementation. -- Marshall Rose | or 905 415 2878 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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/freebsd.h and /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things have to be modified because we support dual ELF/a.out [still]. b) other options were set at compile time -- Why dont change to the same in the port? I am willing to -- the gcc295 port isn't used very much now AFAIK. However, it will probably be once 5-CURRENT moves to a newer version. The FSF GCC people had settings in the i386/freebsd.h file I did not agree with, but it would have been too much pain to change them in the FSF 2.95 release branch. I am willing (and may have to anyway), make the port more agree with the FreeBSD system compiler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
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://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 by these two compilers is very different as a result. 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, i would say, ok... do it now and we'll need to compile or ports... Pretty much each and every C++ binary and shared library will have to be recompiled. Massive binary compatibility breakage is not an option for -STABLE, one can hope. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 paranoia paranoia.c The number of DEFECTs discovered = 1. The number of FLAWs discovered = 1. gcc -O2 -o paranoia paranoia.c The number of FAILUREs encountered = 4. The number of SERIOUS DEFECTs discovered = 4. The number of DEFECTs discovered = 2. The number of FLAWs discovered = 2. i assume everyone knows about kahan and paranoia. if not see netlib. Add the -ffloat-store flag to your compilation flags (or add -msoft-float). No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P754, except for possibly Double Rounding during Gradual Underflow. The arithmetic diagnosed appears to be Excellent! END OF TEST. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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, i would say, ok... do it now and we'll need to compile or ports... Pretty much each and every C++ binary and shared library will have to be recompiled. Massive binary compatibility breakage is not an option for -STABLE, one can hope. No it is not an option for -STABLE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 the solution, the problem arises because you have fast and *too* correct. -- Raymond WikerMail: [EMAIL PROTECTED] Senior Software Engineer Web: http://www.fast.no/ Fast Search Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 add -O to gcc-freebsd.mk gmake -f gcc-freebsd.mk clean gmake -f gcc-freebsd.mk and see what happens ... This is not a small, [relatively] simple example program. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 incorrect, but NOT fast and correct. Actually, if -ffloat-store is the solution, the problem arises because you have fast and *too* correct. If the gcc manual is to be believed, then yes you are correct. If you really want to investigate FreeBSD FP/math capabilities search for UCBTEST or visit www.cs.berkeley.edu/~jhauser/arithmetic/TestFloat.html -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
float [was Re: gcc -O broken in CURRENT]
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] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
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 globally unique identifiers in FibreChannel. :-) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 -RELEASE versions, not -STABLE versions, since -STABLE versions are moving targets and -RELEASE versions are not. 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? 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, i would say, ok... do it now and we'll need to compile or ports... SOme bugs are related to the FreeBSD use of setjmp/longjmp to do exception unwinding rather than using the DWARF primitives. When you change the toolchain, you change the exception unwinding code when you use the ports version. You also introduce incompatabilities with the installed libstdc++ library, which uses the setjmp/longjmp exception unwinding, which will be in conflict with any exception throwing/handling code compiled with the ports compiler that uses the DWARF2 version. The tests that show it working with the ports version do not test anything other than bare-bones operation, without testing code interoperability eith vendor libraries. Does that clear things up for you? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
: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 *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. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 It would have to be something like: mremap(from, to/NULL, osize, nsize) We have no information on the original size of the mmap() in the system because the original vm_map_entry may (A) get cut up by mprotect() calls and (B) get combined with adjacent vm_map_entry's. Personally speaking I think code that depends on realloc() to the extent that mremap() would be necessary is broken code. - Also, there are other ways of dealing with this problem. A large malloc() or realloc() can certainly mmap() more space then it immediately needs, and then grow into the space (or reuse the extra space for other purposes if UVM gets tight). - MADV_WILLNEED has no effect on pages that are not already in the VM Page cache. A zero-fill page is not so calling madvise() after [s]brk() or mmap(...MAP_ANON...) will have no effect. The mmap manual page describes this in detail. MADV_FREE can be used in liu of munmap() but phkmalloc does not use it quite this way, phkmalloc will still free the page when the cache is blown out. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
: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 PROTECTED] | TCP/IP since RFC 956 :FreeBSD committer | BSD since 4.3-tahoe Or mcopymap(from, to, length, flags) flags: MAP_SHARED share the same content (we back them with the same VM objects). MAP_PRIVATE copy on write, as if you fork()d and the parent was the original area and the child is the new area. But I'm not volunteering. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
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) : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 :FreeBSD committer | BSD since 4.3-tahoe Or 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() flags: MAP_SHARED share the same content (we back them with the same VM objects). MAP_PRIVATE copy on write, as if you fork()d and the parent was the original area and the child is the new area. But I'm not volunteering. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Won't boot after the commits to timecounter code
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 following call chain: tc_init - tc_windup - tco_delta - i8254_get_timecount - mtx_foo - witness_foo - ktr_foo - nanotime, just after nanotime has somehow recursed back into i8254_get_timecounter without causing endless recursion! Yes, I have the following KTR options enabled (I think I brought this from NOTES about a year before): options KTR options KTR_EXTEND options KTR_ENTRIES=1024 options KTR_COMPILE=0x3f options KTR_MASK=0x201208 options KTR_CPUMASK=0x3 but WITNESS is commented out. Try setting MTX_NOWITNESS in the initialization of clock_lock in i386/machdep.c. O.k., I'll try this(but does it affect a kernel without WITNESS?), then try a kernel without KTR options. I've found the following: - KTR alone can make this happen; it locked solid with or without WITNESS. - Setting MTX_NOWITNESS in the initialization of clock_lock didn't work. - If I disable KTR, it just works fine without any patches. - If I enable KTR with KTR_LOCK in options KTR_MASK, it freezes after Timecounter i8254 frequency 1193182 Hz message. - If I enable KTR without KTR_LOCK in options KTR_MASK, it boots but it locks solid the moment I inserted a pccard (I'm using OLDCARD). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
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 serialnumbers? Although it's an isolated case, you do have globally unique identifiers in FibreChannel. :-) Most SCSI devices also have serial numbers. ([EMAIL PROTECTED]) /home/dan# camcontrol inq da0 pass0: QUANTUM ATLAS IV 36 WLS 0808 Fixed Direct Access SCSI-3 device pass0: Serial Number 363904655202 pass0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.x packages and request for help.
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 some of the gnome components also failed. Any porters who have some spare time, please visit http://bento.freebsd.org/errorlogs/5-latest/ and fix some ports; there are still a LOT of compile failures due to things like malloc.h and ports which have not been fixed to work with XFree86-4. It's quite possible that some of the build failures are still spurious and caused by problems with the cluster, so please let me know of any weird failures which you think should not have happened. We have a developer preview snapshot coming up in a few weeks, so it's important that we get as many packages building as possible. Thanks in advance for your help. Kris msg36100/pgp0.pgp Description: PGP signature
CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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 impacting -CURRENT developers. Commits to this branch will require re@ approval. Actually, with my CVS hat on, I have a *huge* problem with this. We have a large number of temporary repo copies in place that are to be deleted (ie: rm -rf) soon. This was with the plan that there would be *NO* persistant branches and that it would be rm'ed long before the RELENG_5 branch began. I had a quick look and I immediately found 55MB of duplicated repo files. That's over 5% of the repo right now. I want to know what expectations people have by calling this a RELENG_5_XX branch.. Given that this stuff is going to be rm'ed within a month, that will break RELENG_5_DP1 when that happens. People will no longer be able to cvsup or check out -r RELENG_5_DP1 and have it build. Specifically, gcc and gdb will not build. 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 a problem, because it cannot last very long at all. Accordingly, I would much prefer that the branch (if we have to have it) would be called SNAPSHOT_5_DP1 or soemthing, so that the RELENG_ prefix doesn't unduely raise expectations that it will keep working, or move the DP1 release elsewhere if we want it to remain cvsup'able long term. The other option is to do some hackery after the branch is set down so that the *.291 and *.295 temporary copies do not exist in the branch, and accordingly wont get broken when they are cvs rm -rf'ed. (Hmm, this might be the best option from a cvs perspective, if people dont mind the fact that -current and DP1 will have some files in different places..) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 significant failures: qt2 is still failing so kde doesn't build, and some of the gnome components also failed. 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 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 some of the gnome components also failed. 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 suppose I'll have to try, but it's going to take me more effort to upgrade the clients. Please do what you can now: most of the problems are not kernel-related, and not caused by the build environment, and afaict it's only a few ports which try and use eaccess(2) which I need to upgrade for. Kris msg36103/pgp0.pgp Description: PGP signature
Re: 5.x packages and request for help.
--- 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 can be solved.. thanks, regards, -- Hiten Pandya -- [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
: 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 same content (we back them with the : same VM objects). : : MAP_PRIVATE copy on write, as if you fork()d and the parent : was the original area and the child is the new : area. : : But I'm not volunteering. : : -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI autoload failed -- unable to install
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 symptoms. *or* after moving through the boot process and forcing the 'OK' prompt, enter: set hw.pcic.intr_path=1 set hw.pcic.irq=0 boot *or* set acpi_load=no set hw.pcic.intr_path=1 set hw.pcic.irq=0 boot *or* unset acpi_load set hw.pcic.intr_path=1 set hw.pcic.irq=0 boot Results in: ACPI autoload failed - no such file or directory - [dump followed] *or* unset acpi_load boot Results in a crash dump before anything else happens What am I missing here? This laptop has been able to successfully boot 4.5-RELEASE CD (with the hw.pcic changes above), install 4.5-RELEASE, boot, and run that OS. A similar issue was reported - but looks to be a different problem. Date: Fri, 14 Sep 2001 20:10:13 +0100 From: David Malone [EMAIL PROTECTED] To:[EMAIL PROTECTED] Subject: ACPI module loading. http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=684341+685945+/usr/local/www/db/text/2001/freebsd-current/20010916.freebsd-current Looking at the floppy images, I do not find /boot/kernel/acpi.ko in either the main image, or in the mfsroot image. There is not enough space on the kern.flp to copy acpi.ko to that floppy, and my belief (which may be incorrect) is that since this is during the kernel load, mfsroot still hasn't appeared to the loader. Nothing clear on disabling acpi in acpi (4) manpage, and the referenced acpi (9) manpage does not come up on the FreeBSD manpage web site (as I don't have 5.0 installed yet). Any suggestions, or is it time for GNATS? Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 significant failures: qt2 is still failing so kde doesn't build, and some of the gnome components also failed. 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 make KDE useable on my -current box (2xP2-450). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
[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 copies in place that are to be deleted (ie: rm -rf) soon. This was with the plan that there would be *NO* persistant branches and that it would be rm'ed long before the RELENG_5 branch began. Is there more to this plan? This is news to me and I would like to get up to speed. I had a quick look and I immediately found 55MB of duplicated repo files. That's over 5% of the repo right now. I want to know what expectations people have by calling this a RELENG_5_XX branch.. Given that this stuff is going to be rm'ed within a month, that will break RELENG_5_DP1 when that happens. People will no longer be able to cvsup or check out -r RELENG_5_DP1 and have it build. Specifically, gcc and gdb will not build. 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 a problem, because it cannot last very long at all. 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 freeze (which we early on decided that we would *not* do). Since it's not a formal release, we won't be doing security fixes, etc. I can't imagine why anyone would expect to cvsup this thing at some point in the distant future, especially after 5.0-DP2 and 5.0-RELEASE. Just thinking off the top of my head, having it break soon after 5.0-DP1 might not be fatal, as long as we have the CDROM and FTP areas still intact. Did you have a definite date for the rm-ing in mind? Thanks, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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 freeze (which we early on decided that we would *not* do). Then you don't need a branch, you just need a simple tag, and you can slide it forward if something needs fixing, and remove it after rolling and shipping the snapshot. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
html META HTTP-EQUIV=Content-Type CONTENT=text/html;charset=iso-8859-1 titleMoissanite: More Fire and Brilliance/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 body bgcolor=#00 LINK=#6699CC VLINK=#6699CC ALINK=FF table width=680 align=center cellspacing=0 cellpadding=4 border=0 bgcolor=#00 tr td align=centerimg src=http://www.moissanite.com/emailads/trade/031102/truth_header.gif; width=500 height=45 border=0 alt=The Truth About Moissanite/td /tr tr tdnbsp;/td /tr tr tdimg src=http://www.moissanite.com/emailads/trade/031102/jfire.jpg; width=680 height=564 border=0 alt=Fact - Moissanite delivers more fire, brilliance and luster than any other hard jewel on Earth./td /tr tr td align=center table width=680 cellspacing=0 cellpadding=8 border=0 tr tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td /tr tr valign=top td width=10img src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFThis unretouched photograph supports the adage that a picture is worth a thousand words. Here, a light source over a similar sized moissanite and diamond placed in shallow water clearly shows the superior fire and brilliance of this unique new jewel./font/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFAnd the picture is supported by measurable facts: the GIA publishes the dispersion (fire) of created moissanite at 0.104, refractive index (brilliance) at 2.65 to 2.69, and luster at 20.4%. No other hard jewel measures up, not even a fine diamond. And only moissanite and diamond are over 9 on the Mohs hardness scale./font/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFMoissanite jewels created by Charles Colvard are available in all popular shapes and sizes.nbsp;/font pfont face=Times New Roman, Times, serif size=3 color=#FFa href=http://www.moissanitesource.com;www.moissanitesource.com/a is the place to buy moissanite jewelry on the internet. Buy with confidence at the best prices in the world.nbsp;/font/p /td td width=10img src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td /tr /table /td /tr tr tdnbsp;brbr/td /tr tr td align=centerimg src=http://www.moissanite.com/emailads/trade/031102/moissanite_logo_wht.gif width=277 height=66 border=0 alt=Moissanite Created By Charles Colvard/td /tr tr tdnbsp;/td /tr tr td align=center pfont face=Times New Roman, Times, serif size=2 color=#FFMoissanite created by Charles Colvard is a unique jewel, not a synthetic diamond./font/p pfont face=Times New Roman, Times, serif size=2 color=#FFMoissanite Source is an authorized distributor of Moissanite./font/p pnbsp;/p pfont face=Times New Roman, Times, serif size=2 color=#FFIf you wish to stop receiving these occasional mailings, simply reply to this email with the word REMOVE inbrthe subject line and we will remove your name and email address from our database./font/p /td /tr /table /body /html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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
Re: 5.x packages and request for help.
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 scratch (which the package cluster does). Kris msg36112/pgp0.pgp Description: PGP signature
Re: ACPI autoload failed -- unable to install (fwd)
Tried the obvious -- manually loading acpi.ko -- still fails
On Thu, 14 Mar 2002, Jeff Kletsky wrote:
Date: Thu, 14 Mar 2002 17:41:01 -0800 (PST)
From: Jeff Kletsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ACPI autoload failed -- unable to install
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 symptoms.
[...]
Results in:
ACPI autoload failed - no such file or directory
-
[dump followed]
Failed workaround:
1) Create floppies using dd
2) Make another copy of the mfsroot floopy,
mount /dev/fd0 /mnt
rm -rf /mnt/*
mkdir -p /mnt/boot/kernel
copy acpi.ko to /mnt/boot/kernel
### Note that copying to root of floppy fails on load attempt ###
### This is inconsistent with the loader (8) manpage in 5.0 ###
umount /mnt
3) Boot from kern.flp
4) Load mfsroot.flp
5) Interrupt boot process
set hw.pcic.intr_path=1
set hw.pcic.irq=0
6) Remove mfsroot.flp, insert 'acpi.ko.flp'
load acpi.ko
('boot'ing here causes the BTX to halt if the acpi.ko.flp is still
in the drive)
7) Remove acpi.ko.flp, insert mfsroot.flp
boot
...and watch the BTX halt
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: ACPI autoload failed -- unable to install
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 NEWCARD and add below a line as reffered by /usr/src/sys/i386/conf/NOTES device acpica ( I didn't try No. 2 method ) Now, can you find acpi.ko module in your /boot/kernel folder?? Cheers.. -Original Message- From: Jeff Kletsky [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 10:41 AM To: [EMAIL PROTECTED] Subject: ACPI autoload failed -- unable to install To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT( 1 week Feature Slush )
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 when it doesn't work. :) -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 compile Qt3 recently I had problems with moc dupming core. Getting rid of any objprelink references solved that. I suggest that something similar be done in the port (maybe make objprelink optional and then off by default). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 scratch (which the package cluster does). Right, when I tried to compile Qt3 recently I had problems with moc dupming core. Getting rid of any objprelink references solved that. I suggest that something similar be done in the port (maybe make objprelink optional and then off by default). Any chance you could work me up a patch to test? Kris msg36117/pgp0.pgp Description: PGP signature
Re: 5.x packages and request for help.
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 scratch (which the package cluster does).
Right, when I tried to compile Qt3 recently I had problems with moc
dupming core. Getting rid of any objprelink references solved that. I
suggest that something similar be done in the port (maybe make objprelink
optional and then off by default).
Actually, I think you might have nailed it..
the qt23 port has this:
.if ${OSVERSION} = 500029
NO_QT_OBJPRELINK= yes
.endif
but the portbuild script is still setting OSVERSION to 500027. I
thought I'd made all of those dynamic based on the version number in
the head of the CVS branch, but looks like I missed some.
Thanks!
Kris
msg36118/pgp0.pgp
Description: PGP signature
[no subject]
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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/releng work on HEAD without calling for a code freeze (which we early on decided that we would *not* do). Then you don't need a branch, you just need a simple tag, and you can slide it forward if something needs fixing, and remove it after rolling and shipping the snapshot. No, in this case that doesn't help. What we want is to grab a stable moment, then to allow development to continue. However, we may then want to tweak that stable moment without impinging on development, which requires a branch. The QA/releng work requires us to modify the stuff being released following the branchpoint. 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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. If it allows you to do your job better and quicker, use it. I was actually going to suggest it myself, but I didn't think anybody would take me seriously... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI autoload failed -- unable to install (fwd)
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 debug unless you can give us information like that. -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 5.x packages and request for help.
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 make KDE useable on my -current box (2xP2-450). Uh, objprelink exists for a reason. It's not just decorative. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panics with CardBus
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 fixed one of the panics I see, with a GlobalVillage : Ethernet/Modem card. The kernel still traps with a page fault in : pccard_scan_cis, however with the patches, this now nanifests itself with : the panic message vm_fault: fault on nofault entry. : : I am more than happy to help debug this. The pccard_scan_cis stuff is due to a memory mapping problem that I'm seeing on some cards. :-(. I'm reverting back to an earlier version of the cardbus code for teh DP1 release and then trying again after DP1 is out. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 really care. For me disabling WITNESS does more than enough to make KDE useable on my -current box (2xP2-450). Uh, objprelink exists for a reason. It's not just decorative. I'll just point out that it's an optimization, and an optimization that breaks a build is not particularly effective at optimizing anything. -- Alan Eldridge Dave's not here, man. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
(no subject)
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 really care. For me disabling WITNESS does more than enough to make KDE useable on my -current box (2xP2-450). Uh, objprelink exists for a reason. It's not just decorative. Actually I thought it is; it was introduced in the ports system as a way to speed up runtime linking of KDE components, but KDE worked relatively well for years beforehand :) Kris msg36127/pgp0.pgp Description: PGP signature
[no subject]
html META HTTP-EQUIV=Content-Type CONTENT=text/html;charset=iso-8859-1 titleMoissanite: More Fire and Brilliance/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 body bgcolor=#00 LINK=#6699CC VLINK=#6699CC ALINK=FF table width=680 align=center cellspacing=0 cellpadding=4 border=0 bgcolor=#00 tr td align=centerimg src=http://www.moissanite.com/emailads/trade/031102/truth_header.gif; width=500 height=45 border=0 alt=The Truth About Moissanite/td /tr tr tdnbsp;/td /tr tr tdimg src=http://www.moissanite.com/emailads/trade/031102/jfire.jpg; width=680 height=564 border=0 alt=Fact - Moissanite delivers more fire, brilliance and luster than any other hard jewel on Earth./td /tr tr td align=center table width=680 cellspacing=0 cellpadding=8 border=0 tr tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=200 height=1 alt=/td tdimg src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td /tr tr valign=top td width=10img src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFThis unretouched photograph supports the adage that a picture is worth a thousand words. Here, a light source over a similar sized moissanite and diamond placed in shallow water clearly shows the superior fire and brilliance of this unique new jewel./font/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFAnd the picture is supported by measurable facts: the GIA publishes the dispersion (fire) of created moissanite at 0.104, refractive index (brilliance) at 2.65 to 2.69, and luster at 20.4%. No other hard jewel measures up, not even a fine diamond. And only moissanite and diamond are over 9 on the Mohs hardness scale./font/td td width=200font face=Times New Roman, Times, serif size=3 color=#FFMoissanite jewels created by Charles Colvard are available in all popular shapes and sizes.nbsp;/font pfont face=Times New Roman, Times, serif size=3 color=#FFa href=http://www.moissanitesource.com;www.moissanitesource.com/a is the place to buy moissanite jewelry on the internet. Buy with confidence at the best prices in the world.nbsp;/font/p /td td width=10img src=http://www.moissanite.com/emailads/trade/031102/shim.gif; width=10 height=1 alt=/td /tr /table /td /tr tr tdnbsp;brbr/td /tr tr td align=centerimg src=http://www.moissanite.com/emailads/trade/031102/moissanite_logo_wht.gif width=277 height=66 border=0 alt=Moissanite Created By Charles Colvard/td /tr tr tdnbsp;/td /tr tr td align=center pfont face=Times New Roman, Times, serif size=2 color=#FFMoissanite created by Charles Colvard is a unique jewel, not a synthetic diamond./font/p pfont face=Times New Roman, Times, serif size=2 color=#FFMoissanite Source is an authorized distributor of Moissanite./font/p pnbsp;/p pfont face=Times New Roman, Times, serif size=2 color=#FFIf you wish to stop receiving these occasional mailings, simply reply to this email with the word REMOVE inbrthe subject line and we will remove your name and email address from our database./font/p /td /tr /table /body /html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 correctly for Qt, but I don't really care. For me disabling WITNESS does more than enough to make KDE useable on my -current box (2xP2-450). Uh, objprelink exists for a reason. It's not just decorative. I'll just point out that it's an optimization, and an optimization that breaks a build is not particularly effective at optimizing anything. It's the tools change that breaks the optimization that breaks the build. THerefore it's the tools change that breaks the build. That's just simple root cause analysis. I think it's idiotic to put spackle over the broken window, paint the wall, and then call it fixed. Working around tools problems removes the incentive to fix the tools. If you want the tools to get fixed, you won't put spackle everywhere the tools deficiencies show through to try to pretend the problems aren't there. This is a developer's release. As such, some things are expected to be broken, in order to cause people to fix the root cause of the problems. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
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 is impossible on i386's. Correct requires assignments and casts to discard any extra precision, and the fastest way to implement this is probably to store to memory and reload. The -ffloat-store kludge only does a subset of the necessary conversions. Doing them all would be slower and correct, which is why gcc doesn't do them. C90 can be read as permitting this incorrectness, but C99 doesn't permit it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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). Right, when I tried to compile Qt3 recently I had problems with moc dupming core. Getting rid of any objprelink references solved that. I suggest that something similar be done in the port (maybe make objprelink optional and then off by default). The objprelink stuff should be fixed now, we need to know if it is not. Have you built world recently (like, in the last day or two)? Do a ls /usr/libdata/ldscripts, and if you do *not* see elf_i386.xc and elf_i386.xsc, then your world is not new enough. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
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 everything qt23 depends on from scratch (which the package cluster does). Right, when I tried to compile Qt3 recently I had problems with moc dupming core. Getting rid of any objprelink references solved that. I suggest that something similar be done in the port (maybe make objprelink optional and then off by default). The objprelink stuff should be fixed now, we need to know if it is not. Have you built world recently (like, in the last day or two)? Do a ls /usr/libdata/ldscripts, and if you do *not* see elf_i386.xc and elf_i386.xsc, then your world is not new enough. I built a world after the recent ld commits, which failed to build qt23. I would have double-checked the tarball right away, except bento just died. fxp0: device timeout fxp0: device timeout [...] Kris msg36134/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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 community. We can't do the QA/releng work on HEAD without calling for a code freeze (which we early on decided that we would *not* do). Then you don't need a branch, you just need a simple tag, and you can slide it forward if something needs fixing, and remove it after rolling and shipping the snapshot. Sliding tags around at the request of hundreds of different developers making thousands of changes to -CURRENT over that time period is not very appealing. However, all of our other options are rapidly being shot down as well. Peter raises some valid concerns about the pains that branching CVS will cause. They would have been much more helpful if voiced to re@ a week ago, but that's another issue. At the very least a tag is going down in approximately 24 hours. - Murray msg36135/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
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 a problem, because it cannot last very long at all. Ongoing security fixes for a SNAPSHOT ??? No, that is definitely not the case. Accordingly, I would much prefer that the branch (if we have to have it) would be called SNAPSHOT_5_DP1 or soemthing, so that the RELENG_ prefix doesn't unduely raise expectations that it will keep working, or move the DP1 release elsewhere if we want it to remain cvsup'able long term. I think that the huge warning signs all over the release documentation will do a lot more to set the expectations that the name of a CVS tag, but just to be sure I suppose we can keep the RELENG namespace for official releases. Your proposed name change works for me. - Murray msg36136/pgp0.pgp Description: PGP signature
Re: 5.x packages and request for help.
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 GNU binutils and compiler. I don't feel much sympathy for the breaking a silly hack that amounts to spackle in the first place by whatever happened to the binutils. FWIW I haven't built KDE or Qt from the ports tree in a while. It seems like it's been about six days since I've cvsup'd and built world. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for Submissions: FreeBSD 5.0 DP1 Testing Guide
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 brief description of the new functionality to be tested. 2. A list of known issues / bugs. 3. Instructions for users who wish to help test the feature. If required, we can add test programs or additional patches to a separate directory of the ISO image and FTP install directory. This is somewhat analogous to the 4.5 Testing Guide, http://www.freebsd.org/releases/4.5R/qa.html, but our focus is slightly different. Please send submissions to [EMAIL PROTECTED] before Wednesday March 20. We would like to allow enough time for translation teams to do their work, so the earlier the better. Thanks, - The Release Engineering Team msg36138/pgp0.pgp Description: PGP signature
