Re: Patch for critical_enter()/critical_exit() interrupt assem
:I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to cpu_switch solve that problem :with critical_exit almost unchanged. The savecrit stuff should really :just be made MD. If cpu_critical_exit was changed to take the thread :as its argument as I suggested before this would be easy. fork_exit() is a good example. The existing code explicitly initializes td-td_critnest to 1 and then sets td-td_savecrit to CRITICAL_FORK: td-td_critnest = 1; td-td_savecrit = CRITICAL_FORK; It then proceeds to unlock the sched_lock spin lock. This code only works because interrupts are hard-disabled in the fork trampoline code. In otherwords, the code assumes that cpu_critical_enter() and cpu_critical_exit() play with hard interrupt disablement. If interrupts were enabled there would be two severe race conditions in the code: The first upon entering fork_exit prior to ke_oncpu being set, and the second when td-td_critnest is set to 1 prior to td_savecrit being set to CRITICAL_FORK. The current ast() code is another example. This code calls cpu_critical_enter() and cpu_critical_exit() without bothering to bump the critical nesting count (i.e. bypasses critical_enter() and critical_exit()). Peter's hack to fix IPI deadlocks (no longer in -current) is a third example. He enters a critical section using critical_enter() and then calls cpu_critical_exit() while still holding td_critnest = 1, which breaks even a conservative reading of the API :-) -- There are also a huge number of places where cpu_critical_*() is used specifically in the I386 code for interrupt disablement. I am happy to clean it up, but not until after the multiple stages of my current patch set are in the tree because there are just too many places that have to be modified for me to feel comfortable doing both at once. Nor do I believe it makes sense to clean up cpu_critical_*() just to try to keep critical_*() in MI code (see below two sections). :Specifically I think that all of the current uses of cpu_critical_enter :exit outside of critical_enter exit are bugs. The use in ktr is bogus because Certainly in MI code, I agree. These cases can be attacked incrementally. fork_exit() will be fixed completely by my patches since it has to be for my code to work properly. I was planning on leaving ast() alone for the moment (because I am not planning on making cpu_critical_enter() a NOP any time soon). I would be willing to work on this after my patch is staged in (carrot and stick). :there in the first place. I think that witness is an example of where :we need a different specifically defined to be hard interrupt disable api. :This is why I suggested the intr_disable/intr_restore api, which should only :be used in MD code and in dire circumstances otherwise, of which this case :qualifies. The code in ast is just structured wrong. I think that before :the loop was in assembler outside of the routine itself, so that it didn't Witness is a special case allright. I don't know if I agree with extending a hard interrupt disablement API out to MI code though. :make so many assumptions about interrupt disablement. doreti which calls :it should look like this: : :loop: : cli; : if (there is an ast we can handle) : goto ast; : iret; :ast: : sti; : call ast; : goto loop; : :In which case ast doesn't need to loop or use critical sections at all. :All of the MD code I could find I think should use a different api for :hard interrupt disablement. They are all very MD and need this specifically, :which cpu_critical_enter need not necessarily do. I would agree with this methodology. :With these changes I don't see why the critical_enter/exit functions can't :or shouldn't remain MI. Cleaning up cpu_critical_enter()/exit would require a huge number of changes that I am not prepared to do right now, not only in i386, but in all architectures using cpu_critical_enter() and cpu_critical_exit() - alpha, i386 (many places), and ia64, not to mention ast(), fork_exit(), witness, subr_trap.c, and ktr.c. I suppose the routines could simply be renamed in the MD sections but the MI sections are going to be harder to fix. It doesn't make much sense to me to spend so much effort to leave two essentially one-line procedures, critical_enter() and critical_exit(), (++td-td_critnest + MD call, --td-td_critnest + MD call) MI when all the rest of the work they have to do is MD. Why are you so rabid about keeping critical_enter() and critical_exit() in MI sections? From my point of view leaving them MI simply makes the code more obfuscated, less
Re: 5-CURRENT, make buildworld break?
On Wed, Mar 06, 2002 at 01:25:01PM +0100, Dag-Erling Smorgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote: Last I checked, 'make release' checks the sources out from CVS, and is therefore useless to test changes that haven't yet been committed. There's such a thing as LOCAL_PATCHES since at least 1996. Great! Now if only that was *documented* somewhere... It _IS_ documented in the release engineering paper : http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/extensibility.html - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. However, we do request that re be consulted for any commits with a substantial risk. This includes non-trivial changes to the VM system, filesystems, network stack, important userland components, and others. If unsure about a commit, please ask. Changes specific to emerging architectures (sparc64, ia64, powerpc) are exempt from this approval requirement no matter how substantial the change (as long as it only affects the given architecture). 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. For further information about our plans for 5.0 Developer Previews, and the eventual release of FreeBSD 5.0 in November, please see the new release engineering section of the FreeBSD web site : http://www.FreeBSD.org/releng If you would like to help out with some of the quality-assurance work for the upcoming developer preview, please install a -CURRENT snapshot from : ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/i386 - or - ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386 And post your findings to current or qa@. (Sorry, Alpha -CURRENT snapshots are harder to come by at the moment, but Compaq just donated some hardware to alleviate this problem in the future.) Thanks for your cooperation, - Murray (on behalf of The Release Engineering Team) msg35781/pgp0.pgp Description: PGP signature
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Should I postpone my allocator commit then? Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbus problem
On Thursday 07 March 2002 17.13, M. Warner Losh wrote: In message: [EMAIL PROTECTED] : I have xl0: watchdog timeout on my 3Com cardbus card after updating : kernel recently. Everything seems to be OK during boot, : but xl0: watchdog timeout starts directly after ifconfig, and makes : network incredibly slow. : boot -v will not boot at all, it stops somewhere around : cardbus_attach_card. : : It seems the problem is in recent changes to sys/dev/cardbus, because : taking the August version of sys/dev/cardbus/* files resolved the : problem. So using a completely -current kernel, except for the august version of sys/dev/cardbus/*? I wouldn't have expected that to compile, but that's a good data point if true. Yes, it compiled. The only complain was about DETACH_NOWARN. : xl0: 3Com 3c656B Fast Etherlink XL port 0x1000-0x107f mem : 0x84002000-0x8400207f,0x84002000-0x840020ff irq 11 at device 0.0 on : cardbus1 xl0: Ethernet address: 00:50:04:92:29:17 What does vmstat -i say about irq 11? This is for the new kernel: interrupt total rate stray irq0 1 0 stray irq6 1 0 npx0 irq13 1 0 ata0 irq14 1323 12 pccbb1 irq111 0 atkbd0 irq1 200 1 clk irq010417100 Total 11944114 This is for kernel with august cardbus: interrupt total rate stray irq0 1 0 stray irq6 1 0 npx0 irq13 1 0 ata0 irq14 1371 19 atkbd0 irq1 133 1 clk irq0 6868 99 xl0 irq11 63 0 So its pccbb1 on irq 11 in the first case, and xl0 in the second. Yuri Warner /me gets out his 656 cardbus card and gives it a whirl. -- Yuri Khotyaintsev Swedish Institute of Space Physics To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Jake Burkholder wrote: Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; The primary objections I've seen from Jake, and he posted them as part of the earlier thread prior to the commit, was that the API changes proposed by Matt don't make sense for the sparc64 implementation, uni-processor or multi-processor, and that while these changes might be appropriate for i386, he wanted to see the APIs set up in such a way that the differences in architectures were hidden in the MD code. This suggests working some more on the API before moving on, and my reading of earlier posts in the thread from John was that that was what he had in mind also. Yes. What I would like and what I mentioned before is for this to be hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter would be a null macro for i386, which would turn critical_enter into just an increment, as Matt wanted. cpu_critical_exit would do all the magic of unpending interrupts. The reason for this is that I would like to see critical_exit handled any pending preemptions for a thread. We do not yet know exactly how this will work so I would like this to be done in MI code to start with. The code must not make assumptions that are not valid on all platforms. This is easiest if they use the same code. This is not about duplication of code in several MD files. There must be something that disables all interrupts, since fast interrupt handlers and other very-time-critical code needs to disable all interrupts. That something must have an MI interface, and it is currently named cpu_critical_enter(), so cpu_critical_enter() (or whatever it is named) must not be null. Your scheme basically needs another level of criticality between cpu_critical and plain critical (currently, criticality is not very hierarchial, but it should be). This level and the plain level must not mask fast interrupts (if any), since masking interrupts in not-very-critical code like the scheduler makes them non-fast. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). 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: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 11:16:53 +, Mark Murray wrote: To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). Mark, please, before the date don't forget to commit _trivial_ random() - arc4random() fix for pam_unix() I ugre on for a long time. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). It's probably worth holding off for now and committing it after the 7 days. The 2 months between then and the DP2 release can shake out any problems it causes. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs in -current?
Ok, I've committed a slight reorg to NOTES on -CURRENT to reflect the much more logical layout in LINT on -STABLE WRT NETSMB, SMBFS, and NETSMBCRYPTO. No idea where the weird ordering came from, but I think it's fixed now. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Fri, 8 Mar 2002, Boris Popov wrote: On Wed, 6 Mar 2002, Seth Hettich wrote: I have both: options SMBFS options NETSMB in my config. Perhaps someone could give a little explanation, and add it to NOTES? Thanks for pointing to it. For some reason LINT from -stable have this explanation and NOTES doesn't. For now quote from LINT: cut # SMB/CIFS requester # NETSMB enables support for SMB protocol, it requires LIBMCHAIN and LIBICONV # options. # NETSMBCRYPTO enables support for encrypted passwords. options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB cut -- Boris Popov http://rbp.euro.ru 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: cardbus problem
OK. I've recreated this problem. It looks like I broke interrupts to cardbus with the large cleanup. I could have sworn I'd tested that, but it looks like my testing metholology was flawed. I'm looking into it. Thanks. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Does this include getting someone to fix picobsd for -CURRENT? Is this important for the snapshots? Later, George *** Making static libraries cd /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a -nostdinc -DSTANDARD_INCLUDE_DIR=/home/gnn/FreeBSD/src.la t est../usr/include -I/home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/../common / home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crti.S /home/gnn/FreeBSD/src.latest /lib/csu/i386-elf/crtn.S mkdep -f .depend -a -nostdinc -DSTANDARD_INCLUDE_DIR=/home/gnn/FreeBSD/src.la t est../usr/include -I/home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/../common /ho me/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:30: stddef.h: No such file or directory /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:31: stdlib.h: No such file or directory In file included from /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:32: /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/../common/crtbrand.c:28: sys/param .h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf. *** Error code 1 Stop in /home/gnn/FreeBSD/src.latest. *** Error code 1 -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. If you're referring to the problems loading libpng.so (and probably other shared libraries), I can confirm that it's been fixed now. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Weird binutils error (libintl.h not found) in 5.0-CURRENT
Hi all, I am getting this weird binutils error, which says, that I am lacking a file called libintl.h. I checked my /usr/include, and /usr/src/include. Also, I checked the src/contrib/binutils directory, but I cannot find that particular header file at all. I have the most updated source, as of Fri Mar 8 17:18:35 GMT 2002. Am I doing something wrong? All help is appreciated. Included, is my 'make buildworld' output. I will supply anything else for this, if needed. Thanks, Regards, -- Hiten Pandya http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) htto://www.FreeBSD.org - The Power to Serve mkdep -f .depend -a-D_GNU_SOURCE -I. -I/data/dev/src/gnu/usr.bin/binutils/libbfd/i386 -I/data/dev/src/gnu/usr.bin/binutils/libbfd -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_vec -DHAVE_bfd_elf32_i386_vec -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20020221\ -DBFD_VERSION_DATE=20020221 -DBFD_VERSION_STRING=\2.12.0 pre-release snap [FreeBSD] 20020221\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DSELECT_VECS= bfd_elf32_i386_vec /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cpu-i386.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archive.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archive64.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/bfd.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/binary.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cache.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/coffgen.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/corefile.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf-eh-frame.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf-strtab.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/format.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/hash.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/ihex.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/init.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/libbfd.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/linker.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/merge.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/opncls.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/reloc.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/section.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/srec.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/stab-syms.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/stabs.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/syms.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/targets.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/tekhex.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf1.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cpu-i386.c:22: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:24: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfcode.h:68, from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32.c:22: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:22:
linprocfs.ko is broken
root[244] kldstat Id Refs AddressSize Name 1 12 0xc010 26714c kernel 21 0xc0368000 18330linux.ko 32 0xc0381000 15480miibus.ko 41 0xc0397000 7798 if_rl.ko 52 0xc039f000 1a14csnd_pcm.ko 61 0xc03ba000 9538 snd_maestro3.ko 71 0xc03c4000 c860 agp.ko 81 0xc14b7000 2000 blank_saver.ko root[245] kldload linprocfs KLD linprocfs.ko: depends on linux - not available kldload: can't load linprocfs: Exec format error root[246] Mar 8 09:57:30 12-230-81-20 kernel: KLD linprocfs.ko: depends \ on linux - not available Mar 8 09:57:30 12-230-81-20 kernel: KLD linprocfs.ko: depends on linux - \ not available This is with fresh sources from circa 8 am PST, today. Linux-netscape works. I haven't tried to fired up staroffice, yet. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weird binutils error (libintl.h not found) in 5.0-CURRENT
Hiten, pedicular~;locate libintl.h /usr/local/include/libintl.h /usr/src/contrib/texinfo/lib/libintl.h pedicular~;pkg_info -W /usr/local/include/libintl.h /usr/local/include/libintl.h was installed by package gettext-0.10.35_1 pedicular~; On Fri, Mar 08, 2002 at 05:56:08PM +, Hiten Pandya wrote: Hi all, I am getting this weird binutils error, which says, that I am lacking a file called libintl.h. I checked my /usr/include, and /usr/src/include. Also, I checked the src/contrib/binutils directory, but I cannot find that particular header file at all. I have the most updated source, as of Fri Mar 8 17:18:35 GMT 2002. Am I doing something wrong? All help is appreciated. Included, is my 'make buildworld' output. I will supply anything else for this, if needed. Thanks, Regards, -- Hiten Pandya http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) htto://www.FreeBSD.org - The Power to Serve mkdep -f .depend -a-D_GNU_SOURCE -I. -I/data/dev/src/gnu/usr.bin/binutils/libbfd/i386 -I/data/dev/src/gnu/usr.bin/binutils/libbfd -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_vec -DHAVE_bfd_elf32_i386_vec -I/data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20020221\ -DBFD_VERSION_DATE=20020221 -DBFD_VERSION_STRING=\2.12.0 pre-release snap [FreeBSD] 20020221\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DSELECT_VECS= bfd_elf32_i386_vec /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cpu-i386.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archive.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archive64.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/bfd.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/binary.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cache.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/coffgen.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/corefile.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf-eh-frame.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf-strtab.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/format.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil inutils/libbfd/../../../../contrib/binutils/bfd/ihex.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/init.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/libbfd.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/linker.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/merge.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/opncls.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/reloc.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/section.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/srec.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/stab-syms.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/stabs.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/syms.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/targets.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/tekhex.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf1.c /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/cpu-i386.c:22: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:24: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory In file included from /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfcode.h:68, from
Re: Weird binutils error (libintl.h not found) in 5.0-CURRENT
--- Michael Lucas [EMAIL PROTECTED] wrote: pedicular~;locate libintl.h /usr/local/include/libintl.h /usr/src/contrib/texinfo/lib/libintl.h pedicular~;pkg_info -W /usr/local/include/libintl.h /usr/local/include/libintl.h was installed by package gettext-0.10.35_1 pedicular~; Thanks! :) -- Hiten __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gnome in -currurent
With the latest source gnome-session, panel, sawfish, etc all: pid 1096 (gnome-session), uid 1001: exited on signal 10 (core dumped) gnome-session: #0 0x285c02ad in exit () from /usr/lib/libc.so.5 #1 0x285be052 in __qdivrem () from /usr/lib/libc.so.5 #2 0x285a6975 in _nsyy_create_buffer () from /usr/lib/libc.so.5 #3 0x285a68cb in _nsyy_switch_to_buffer () from /usr/lib/libc.so.5 #4 0x285a5d17 in __putlong () from /usr/lib/libc.so.5 #5 0x2859e960 in ___toupper () from /usr/lib/libc.so.5 #6 0x285a0349 in _nsdbtget () from /usr/lib/libc.so.5 #7 0x285a04c8 in _nsdbtput () from /usr/lib/libc.so.5 #8 0x2857772a in netname2host () from /usr/lib/libc.so.5 #9 0x2850aa1f in g_get_any_init () from /usr/local/lib/libglib12.so.3 #10 0x2850accd in g_get_home_dir () from /usr/local/lib/libglib12.so.3 #11 0x28499d97 in gnomelib_init () from /usr/X11R6/lib/libgnome.so.5 #12 0x804ffe4 in main () #13 0x804d1d1 in _start () panel: #0 0x286792ad in exit () from /usr/lib/libc.so.5 #1 0x28677052 in __qdivrem () from /usr/lib/libc.so.5 #2 0x2865f975 in _nsyy_create_buffer () from /usr/lib/libc.so.5 #3 0x2865f8cb in _nsyy_switch_to_buffer () from /usr/lib/libc.so.5 #4 0x2865ed17 in __putlong () from /usr/lib/libc.so.5 #5 0x28657960 in ___toupper () from /usr/lib/libc.so.5 #6 0x28659349 in _nsdbtget () from /usr/lib/libc.so.5 #7 0x286594c8 in _nsdbtput () from /usr/lib/libc.so.5 #8 0x2863072a in netname2host () from /usr/lib/libc.so.5 #9 0x2814da1f in g_get_any_init () from /usr/local/lib/libglib12.so.3 #10 0x2814dccd in g_get_home_dir () from /usr/local/lib/libglib12.so.3 #11 0x2859bd97 in gnomelib_init () from /usr/X11R6/lib/libgnome.so.5 #12 0x282123bf in gnome_init_with_popt_table () from /usr/X11R6/lib/libgnomeui.so.5 #13 0x282124ae in gnome_init () from /usr/X11R6/lib/libgnomeui.so.5 #14 0x281765b5 in gnome_CORBA_init () from /usr/X11R6/lib/libgnorba.so.5 #15 0x805dcef in main () #16 0x8058ee5 in _start () sawfish: #0 0x2807413a in reloc_plt () from /usr/libexec/ld-elf.so.1 #1 0x28071b7c in find_symdef () from /usr/libexec/ld-elf.so.1 #2 0x280706af in _rtld () from /usr/libexec/ld-elf.so.1 etc. Is this happening to anyone else? I recompiled most of these w/ the latest port... -Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, 8 Mar 2002, David W. Chapman Jr. wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. Hmm. My impression was that the libpng stuff had been fixed, could you confirm that KDE still doesn't build on 5.0-CURRENT? 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: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 08:59:53AM -0600, David W. Chapman Jr. wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. It works if you don't use objprelink, and then change a bunch of files to include arpa/inet.h I spent some time fixing this yesterday... Here are my notes: #include arpa/inet.h in kdelibs-2.2.2: kdecore/kextsock.cpp kio/ftp/ftp.cc kio/tcpslavebase.cpp arts/mcop/tcpconnection.cc qt2.3.1: src/kernel/qfont_x11.cpp src/kernel/qpainter_x11.cpp src/network/qdns.cpp src/network/qsocketdevice_unix.cpp also uic gets a weird dependency on libclms.so_edata, so you need to run ln -s /usr/local/lib/liblcms.so.1 /usr/local/lib/liblcms.so_edata ldconfig -R kdenetwork-2.2.2: kit/kitsocket.cpp kmail/kmacctimap.cpp kmail/kmacctexppop.cpp kmail/accountdialog.cpp ktalkd/ktalkd/machines/forwmach.cpp ktalkd/ktalkd/machines/talkconn.cpp ktalkd/ktalkd/print.cpp ktalkd/ktalkd/process.cpp ktalkd/ktalkd/table.cpp to make kdemultimedia-2.2.2 compile, don't use the FreeBSD-specific byteswapping functions defined in kmidi/config.h, instead use the generic ones (which should have been used in the first place anyway, imo) remove the ifdef #FreeBSD-blah near XCHG_(LONG|SHORT) I installed all those ports using make NO_DEPENDS=yes install since I'm too lazy to figure out where the objprelink dep is defined. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. I agree... -CURRENT was fine until the new binutils came into the tree. First the libpng, then the KDE problems. I think we should wait a while and fix ports using ntohl and friends (since someone seem to have decided that netinet/in.h shouldn't define it or something) and make KDE build again before making a developer preview, but that's just my opinion. // Joel Wilsson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. Hmm. My impression was that the libpng stuff had been fixed, could you confirm that KDE still doesn't build on 5.0-CURRENT? Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. To say that this sucks is an understatement. I already have an open PR on the arpa/inet.h problem. Now that the reverse dependency has been made to occur, I have written portmgr@ requesting a referral to a mainline developer who can handle this mess in an expedient manner. In the meantime, you need to find every occurence of either of those files being included, and make sure the other is included as well. netinet/in.h needs to come first. Since the problem is a large one, and any change will not happen without a reasonable amount of deliberation, I suggest you submit a PR with a patch for kdelibs source tree. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 10:17:16AM -0600, David W. Chapman Jr. wrote: currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. Hmm. My impression was that the libpng stuff had been fixed, could you confirm that KDE still doesn't build on 5.0-CURRENT? Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] You said binutils upgrade broke KDE -- the quoted mail has nothing to do with binutils. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. If you're referring to the problems loading libpng.so (and probably other shared libraries), I can confirm that it's been fixed now. I was curious about that, but it wasn't my main concern. Have you been able to run anything that uses OBJPRELINK? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 11:20:35AM -0500, Will Andrews wrote: On Fri, Mar 08, 2002 at 10:17:16AM -0600, David W. Chapman Jr. wrote: currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. Hmm. My impression was that the libpng stuff had been fixed, could you confirm that KDE still doesn't build on 5.0-CURRENT? Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] You said binutils upgrade broke KDE -- the quoted mail has nothing to do with binutils. I'm sorry for the lack of clarity in my email, if I didn't explain it the way I wanted to here is a better attempt. I cannot recompile kde due to the reasons stated in the quoted email so I'm not sure if the binutils problem has been fixed, but apparently a few people can vouch that it has. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 10:17:16AM -0600, David W. Chapman Jr. wrote: currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. [snip] I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. FWIW, Alan filed a PR about that - bin/35598. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? msg35804/pgp0.pgp Description: PGP signature
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Sounds to me like there are fixes in the pipeline from Mike and Thomas. Hopefully they'll get that committed in the next day or two so that KDE can be happy on -CURRENT before the snapshot. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Fri, 8 Mar 2002, Peter Pentchev wrote: On Fri, Mar 08, 2002 at 10:17:16AM -0600, David W. Chapman Jr. wrote: currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. [snip] I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. FWIW, Alan filed a PR about that - bin/35598. G'luck, Peter -- Peter Pentchev[EMAIL PROTECTED][EMAIL PROTECTED] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
There seem to be two distinct problems. The header one seems to have resolution,I got around it by the nested include. The second one may be OBJPRELINK, but does seem to be nailed down yet. Martin Blapp ran into what might be related problems in the OpenOffice port. I've only seen it on g++ related programs. Good hunting... Sounds to me like there are fixes in the pipeline from Mike and Thomas. Hopefully they'll get that committed in the next day or two so that KDE can be happy on -CURRENT before the snapshot. 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: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, 8 Mar 2002, David W. Chapman Jr. wrote: Hmm. My impression was that the libpng stuff had been fixed, could you confirm that KDE still doesn't build on 5.0-CURRENT? Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. This is actually caused by the last round of endianness changes (in sys/param.h and machine/endian.h) breaking the previous round of endianness changes in (arpa/inet.h, netinet/in.h, sys/param.h and machine/endian.h). Another round is planned to fix this. I'm surprised that everyone hasn't complained about world breakage from this. It has been broken for almost 2 weeks now. Everything that goes near ntohl and has WARNS = 2 fails to compile. Without WARNS, the bug is reported as above, but a bogus version of __hton* is found in the library and only optimization of hton* is broken. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
At 10:17 AM -0600 3/8/02, David W. Chapman Jr. wrote: Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. As you might guess, this is a less than desirable situation. [A #includes B] and [B #includes A] is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. To say that this sucks is an understatement. [...] Since the problem is a large one, and any change will not happen without a reasonable amount of deliberation, I suggest you submit a PR with a patch for kdelibs source tree. Mike Barcroft, Bruce Evans, and maybe a few others are working on an update to about eight different include files which should clear up many of these issues. I think it would be very desirable to get this include-file-cleanup patch committed before the snapshot is done. The present version of this patch clears up a lot of the compile-time warnings that come up when doing a buildworld of current, but it still isn't quite right. If this current snapshot means more people will be running current, then I'd hate to see them chasing after compile-time warnings which are due to the present state of the system include files... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
I'm surprised that everyone hasn't complained about world breakage from this. It has been broken for almost 2 weeks now. Everything that goes near ntohl and has WARNS = 2 fails to compile. Without WARNS, the bug is reported as above, but a bogus version of __hton* is found in the library and only optimization of hton* is broken. Very strange, I have been making world over the past few weeks (just did one yesterday) with no problems, maybe I have some stuff that it stale? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can someone explain this change to bsd.lib.mk ?
In message [EMAIL PROTECTED] Luigi Rizzo writes: : The attached portion of the 1.100 - 1.101 patch to src/share/mk/bsd.lib.mk ... : I wonder, how does a make world get around this problem : (so i can try to reproduce the 'fix' in the picobsd script) ? Make world gets around this problem by doing things in stages so that the build tools are built first using the host environment, then the target binaries are built using the host tools. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On 08-Mar-02 Matthew Dillon wrote: :I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to cpu_switch solve that problem :with critical_exit almost unchanged. The savecrit stuff should really :just be made MD. If cpu_critical_exit was changed to take the thread :as its argument as I suggested before this would be easy. Hmm, I agree with getting rid of td_savecrit as an MI field and changing the API for cpu_critical_*. I also agree that cpu_critical_* is abused in many cases. I just fixed a few that can be fixed. I think most others can be fixed with the explicit intr_disable/intr_restore API which shouldn't be a problem since it's basically what cpu_critical_* is now but just misnamed. This would fix the remaining instance in witness for example. ast() is harder to solve, and although I don't like having stuff duplicated all over the place making maintenance harder, moving the loop and test out to MD code in either asm or C as Jake suggested would work fine. fork_exit() is a good example. The existing code explicitly initializes td-td_critnest to 1 and then sets td-td_savecrit to CRITICAL_FORK: td-td_critnest = 1; td-td_savecrit = CRITICAL_FORK; It then proceeds to unlock the sched_lock spin lock. This code only works because interrupts are hard-disabled in the fork trampoline code. In otherwords, the code assumes that cpu_critical_enter() and cpu_critical_exit() play with hard interrupt disablement. If interrupts were enabled there would be two severe race conditions in the code: The first upon entering fork_exit prior to ke_oncpu being set, and the second when td-td_critnest is set to 1 prior to td_savecrit being set to CRITICAL_FORK. No, the savecrit does assume that, but the critnest is still correct and will still work fine. By definition, you don't switch inside a critical section (taht's what critical sections do) so critnest will always be 1 here. Any interrupt or what not that comes in if interrutps aren't disabled might dink with teh count but the count will still be 1 by the time we get to releasing sched_lock. Alternatively, we could set td_critnest to 1 in fork() which would be ok with me. Peter's hack to fix IPI deadlocks (no longer in -current) is a third example. He enters a critical section using critical_enter() and then calls cpu_critical_exit() while still holding td_critnest = 1, which breaks even a conservative reading of the API :-) I always said that Peter's hack was gross. I didn't like it when he did it originally either. Actually, doing cpu_critical_exit() though is safe since all we need is for the critnest to be = 1 to prevent context switches (which is all critical sections do if you read the manpage that documents them). We only ever need to defer bottom-half code (or Primary Interrupt Context as Apple likes to call it) while holding a spin mutex. The MD code does abuse cpu_critical_* which I am quite happy to fix using intr_*(). Once this is done cpu_critical_* should be out of bogus land and you should be able to adjust your patches to change that API's implementation. I'm willing to do all the work to fixup the cpu_critical_* abuse right now before doing anything else. It really needs to be done anyway. :With these changes I don't see why the critical_enter/exit functions can't :or shouldn't remain MI. Cleaning up cpu_critical_enter()/exit would require a huge number of changes that I am not prepared to do right now, not only in i386, but in all architectures using cpu_critical_enter() and cpu_critical_exit() - alpha, i386 (many places), and ia64, not to mention ast(), fork_exit(), witness, subr_trap.c, and ktr.c. I suppose the routines could simply be renamed in the MD sections but the MI sections are going to be harder to fix. It doesn't make much sense to me to spend so much effort to leave two essentially one-line procedures, critical_enter() and critical_exit(), (++td-td_critnest + MD call, --td-td_critnest + MD call) MI when all the rest of the work they have to do is MD. They won't stay one line. That's the whole point. The entire reason we have MI versions is that I committed part of the preemption tree specifically to try and minimize the amount of the preemption code not currently checked in. The MI versions are still a WIP part of the preemption tree. They wouldn't even exist if it weren't for the preemption tree. I defer to Jake's opinions on the style and profiling issues. All that I ask is that you let me cleanup and fix the cpu_critical_* bogusness which will then allow you to implement your changes in that API while not breaking the kernel preemption WIP. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users
Re: Preparing innocent users for -current
In message [EMAIL PROTECTED] Doug Barton writes: : 1. phk malloc debugging flags enabled by default. Solutions include : recompiling apps, and toggling things off in /etc/malloc.conf. Recompiling apps isn't going to change things. The default is in the system. : 2. pam modules break backwards compatibility with pam apps compiled on : RELENG_4. The only solution I've been offered is to recompile things (or, : my preferred solution, don't use pam). Yes. There's nothing here except to recompile. : 3. xconsole causes periodic panics. The problem (according to BDE) is a : well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when : printf() is called while sched_lock is held. I reported this bug in : October 2001, if anyone wants to look through the archives. This isn't happening often enough to worry about. I run xconsole and I've not seen a panic with it in months of running current with xconsole. Of course, maybe I'm just lucky. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Anyone using DIAGNOSTIC td_ucred stuff?
Is anyone using the DIAGNOSTIC cached td_ucred stuff in current? If not, I'd like to replace it with a much simpler version that doesn't use the cached references but is still under DIAGNOSTIC. I use the simpler version in my test kernels (albeit under INVARIANTS, but I'll leave it under DIAGNOSTIC in CVS). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
Shouldn't this be CC'ed to -doc as well? Maybe someone will write an article on a little release note kinda thing for this issue. Just an opinion from a -current user. :) -- Hiten --- Doug Barton [EMAIL PROTECTED] wrote: On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. As much as I still think this is really bad timing for all the reasons I expressed at the summit, if we're going to do this one of the things we must absolutely do is create the list of Things in -current that will bite unsuspecting RELENG_4 users in the ass, and their solutions, if any. Off the top of my head: 1. phk malloc debugging flags enabled by default. Solutions include recompiling apps, and toggling things off in /etc/malloc.conf. 2. pam modules break backwards compatibility with pam apps compiled on RELENG_4. The only solution I've been offered is to recompile things (or, my preferred solution, don't use pam). 3. xconsole causes periodic panics. The problem (according to BDE) is a well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when printf() is called while sched_lock is held. I reported this bug in October 2001, if anyone wants to look through the archives. Related to 2. above, since the port of XFree86-4 is still at 4.1.0, I went to the xfree86.org web page and installed their packaged version of 4.2.0. Because of the pam breakage, xdm from that package doesn't work. Therefore, it would be nice to have the port upgraded so that the only solution available to users would actually be available. Other than that, -current works pretty well for me. I use it daily on my workstation at home, and have for years. My strategy is to keep good backups, especially of a known-safe kernel. I used to compile -current every few days, and I'd usually install it too. I stopped doing that after the smpng work started, but I still try to update at least once a month. The periods of instability are a price I'm willing to pay for a better system down the road, even if it's frustrating sometimes. __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
--- Warner Losh [EMAIL PROTECTED] wrote: : 3. xconsole causes periodic panics. The problem (according to BDE) is a : well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when : printf() is called while sched_lock is held. I reported this bug in : October 2001, if anyone wants to look through the archives. This isn't happening often enough to worry about. I run xconsole and I've not seen a panic with it in months of running current with xconsole. Of course, maybe I'm just lucky. I haven't either. I am running XDM (xconsole with it obviously..) on an SMP system, but no panics till now, running CURRENT for more than six months or so.. :) -- Hiten __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
On Fri, Mar 08, 2002 at 11:33:27AM -0800, Hiten Pandya wrote: Shouldn't this be CC'ed to -doc as well? Maybe someone will write an article on a little release note kinda thing for this issue. Just an opinion from a -current user. :) We're collecting notes for a Testing Guide similar to the one we published leading up to FreeBSD 4.5. More than anything, we need information from developers about how users can best test the new functionality. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
--- Murray Stokely [EMAIL PROTECTED] wrote: On Fri, Mar 08, 2002 at 11:33:27AM -0800, Hiten Pandya wrote: Shouldn't this be CC'ed to -doc as well? Maybe someone will write an article on a little release note kinda thing for this issue. Just an opinion from a -current user. :) We're collecting notes for a Testing Guide similar to the one we published leading up to FreeBSD 4.5. More than anything, we need information from developers about how users can best test the new functionality. - Murray __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
--- Murray Stokely [EMAIL PROTECTED] wrote: We're collecting notes for a Testing Guide similar to the one we published leading up to FreeBSD 4.5. More than anything, we need information from developers about how users can best test the new functionality. Using k-options such as INVARIANTS, MUTEX_DEBUG, WITNESS*. I will make up a list of the ones I know, and is there a place where I can send these to? -- Hiten __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
Per Doug's note, is there a schedule to pull the XFree86-4 back up to 4.2.0? Since it was pulled back because of the 4.5 release, it would be a shame for it to be also held back by a -current snapshot. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
Apparently, On Fri, Mar 08, 2002 at 01:23:01AM -0800, Matthew Dillon said words to the effect of; :I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to cpu_switch solve that problem :with critical_exit almost unchanged. The savecrit stuff should really :just be made MD. If cpu_critical_exit was changed to take the thread :as its argument as I suggested before this would be easy. fork_exit() is a good example. The existing code explicitly initializes td-td_critnest to 1 and then sets td-td_savecrit to CRITICAL_FORK: td-td_critnest = 1; td-td_savecrit = CRITICAL_FORK; It then proceeds to unlock the sched_lock spin lock. This code only works because interrupts are hard-disabled in the fork trampoline code. In otherwords, the code assumes that cpu_critical_enter() and cpu_critical_exit() play with hard interrupt disablement. If interrupts were enabled there would be two severe race conditions in the code: The first upon entering fork_exit prior to ke_oncpu being set, and the second when td-td_critnest is set to 1 prior to td_savecrit being set to CRITICAL_FORK. The current ast() code is another example. This code calls cpu_critical_enter() and cpu_critical_exit() without bothering to bump the critical nesting count (i.e. bypasses critical_enter() and critical_exit()). Peter's hack to fix IPI deadlocks (no longer in -current) is a third example. He enters a critical section using critical_enter() and then calls cpu_critical_exit() while still holding td_critnest = 1, which breaks even a conservative reading of the API :-) -- There are also a huge number of places where cpu_critical_*() is used specifically in the I386 code for interrupt disablement. I am happy to clean it up, but not until after the multiple stages of my current patch set are in the tree because there are just too many places that have to be modified for me to feel comfortable doing both at once. Nor do I believe it makes sense to clean up cpu_critical_*() just to try to keep critical_*() in MI code (see below two sections). :Specifically I think that all of the current uses of cpu_critical_enter :exit outside of critical_enter exit are bugs. The use in ktr is bogus because Certainly in MI code, I agree. These cases can be attacked incrementally. fork_exit() will be fixed completely by my patches since it has to be for my code to work properly. I was planning on leaving ast() alone for the moment (because I am not planning on making cpu_critical_enter() a NOP any time soon). I would be willing to work on this after my patch is staged in (carrot and stick). Ok. :there in the first place. I think that witness is an example of where :we need a different specifically defined to be hard interrupt disable api. :This is why I suggested the intr_disable/intr_restore api, which should only :be used in MD code and in dire circumstances otherwise, of which this case :qualifies. The code in ast is just structured wrong. I think that before :the loop was in assembler outside of the routine itself, so that it didn't Witness is a special case allright. I don't know if I agree with extending a hard interrupt disablement API out to MI code though. I agree that it should be avoided. John would know better why exactly this is needed and he may have already fixed it. :make so many assumptions about interrupt disablement. doreti which calls :it should look like this: : :loop: : cli; : if (there is an ast we can handle) : goto ast; : iret; :ast: : sti; : call ast; : goto loop; : :In which case ast doesn't need to loop or use critical sections at all. :All of the MD code I could find I think should use a different api for :hard interrupt disablement. They are all very MD and need this specifically, :which cpu_critical_enter need not necessarily do. I would agree with this methodology. :With these changes I don't see why the critical_enter/exit functions can't :or shouldn't remain MI. Cleaning up cpu_critical_enter()/exit would require a huge number of changes that I am not prepared to do right now, not only in i386, but in all architectures using cpu_critical_enter() and cpu_critical_exit() - alpha, i386 (many places), and ia64, not to mention ast(), fork_exit(), witness, subr_trap.c, and ktr.c. I suppose the routines could simply be renamed in the MD sections but the MI sections are going to be harder to fix. It doesn't make much sense to me to spend so much effort to leave two essentially one-line procedures, critical_enter() and critical_exit(),
Re: Weird binutils error (libintl.h not found) in 5.0-CURRENT
On Fri, Mar 08, 2002 at 05:56:08PM +, Hiten Pandya wrote: /data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135: libintl.h: No such file or directory This only happens if ENABLE_NLS is defined. However, $ cd /usr/src/gnu/usr.bin/binutils $ find . -type f |xargs grep ENABLE_NLS ./as/alpha-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/i386-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/powerpc-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/sparc64-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/ia64-freebsd/config.h:/* #undef ENABLE_NLS */ ./gdb/config.h:#define ENABLE_NLS 1 ./ld/config.h:/* #define ENABLE_NLS 1 */ ./libbfd/config.h.fbsd:/* #define ENABLE_NLS 1 */ ./libbinutils/config.h:/* #define ENABLE_NLS 1 */ ./libopcodes/config.h:/* #define ENABLE_NLS 1 */ ./gdb5/config.h:#define ENABLE_NLS 1 ./ld.emu/config.h:/* #define ENABLE_NLS 1 */ shows it is not enabled for non-gdb bits. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Anyone using DIAGNOSTIC td_ucred stuff?
I've been running it but I am about to turn it off because I want to cache the value over userland. The code is completely gone in the KSE patch. On Fri, 8 Mar 2002, John Baldwin wrote: Is anyone using the DIAGNOSTIC cached td_ucred stuff in current? If not, I'd like to replace it with a much simpler version that doesn't use the cached references but is still under DIAGNOSTIC. I use the simpler version in my test kernels (albeit under INVARIANTS, but I'll leave it under DIAGNOSTIC in CVS). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ 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: Weird binutils error (libintl.h not found) in 5.0-CURRENT
Saying that, I haven't use ENABLE_NLS anywhere. This happened to me, a couple of weeks ago, but I had to go Germany, so I wasn't able to report it then. All my buildworld's use to work perfectly, but I am getting this problem for some reason which I can't seem to figure out. Also, I downloaded a clean copy of the binutils tree, but I am still having the same problem. I tried this: #cd /usr/src/contrib #rm -rf binutils #cd /usr/src/supfiles #cvsup -L2 -g srcsup U binutils/... .. .. But still.. the same problem occurs to me. Shall I try with the copy from http://www.gnu.org and see if it works? --- David O'Brien [EMAIL PROTECTED] wrote: This only happens if ENABLE_NLS is defined. However, $ cd /usr/src/gnu/usr.bin/binutils $ find . -type f |xargs grep ENABLE_NLS ./as/alpha-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/i386-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/powerpc-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/sparc64-freebsd/config.h:/* #define ENABLE_NLS 1 */ ./as/ia64-freebsd/config.h:/* #undef ENABLE_NLS */ ./gdb/config.h:#define ENABLE_NLS 1 ./ld/config.h:/* #define ENABLE_NLS 1 */ ./libbfd/config.h.fbsd:/* #define ENABLE_NLS 1 */ ./libbinutils/config.h:/* #define ENABLE_NLS 1 */ ./libopcodes/config.h:/* #define ENABLE_NLS 1 */ ./gdb5/config.h:#define ENABLE_NLS 1 ./ld.emu/config.h:/* #define ENABLE_NLS 1 */ shows it is not enabled for non-gdb bits. __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bus_alloc_resouce() failure for OPTi 82C861
From: M. Warner Losh [EMAIL PROTECTED] Subject: Re: bus_alloc_resouce() failure for OPTi 82C861 Date: Thu, 07 Mar 2002 01:37:13 -0700 (MST) Message-ID: [EMAIL PROTECTED] : [boot message] : ohci0: OPTi 82C861 (FireLink) USB controller irq 10 at device 5.0 on pci0 : ohci0: Could not map memory : device_probe_and_attach: ohci0 attach returned 6 : It seems the function bus_alloc_resource() returns NULL. : : How can I avoid this failure? You can't. However, you can work around it like the pccbb driver does. It would be better if these things were handled in the pci bus layer, but someone would need to implement that. Thanks for your advice. I tried to work around like pccbb driver does, it seems work. [boot message] ohci0: OPTi 82C861 (FireLink) USB controller irq 10 at device 5.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: OPTi 82C861 (FireLink) USB controller on ohci0 usb0: USB revision 1.0 uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered TIA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
On Fri, Mar 08, 2002 at 02:58:40PM -0500, Michael G. Petry wrote: Per Doug's note, is there a schedule to pull the XFree86-4 back up to 4.2.0? Since it was pulled back because of the 4.5 release, it would be a shame for it to be also held back by a -current snapshot. Yes, I am handling that. I've been testing a version of the upgrade on 2 of my machines for several weeks, but haven't had time to fix a few more things, which is the reason for the delay, aside from the fact that I was previously waiting on the people who actually wrote the patch to commit it. However, since my midterms are over and spring break is upon me, I will focus a large part of the next few days getting the upgrade done and committed. It should be done by Saturday, March 9 at the earliest and Saturday, March 16 at the latest, and probably on Sunday or Monday. Thanks, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weird binutils error (libintl.h not found) in 5.0-CURRENT
On Fri, Mar 08, 2002 at 12:26:09PM -0800, Hiten Pandya wrote: Saying that, I haven't use ENABLE_NLS anywhere. This happened to me, a couple of weeks ago, but I had to go Germany, so I wasn't able to report it then. All my buildworld's use to work perfectly, but I am getting this problem for some reason which I can't seem to figure out. Also, I downloaded a clean copy of the binutils tree, but I am still having the same problem. I tried this: #cd /usr/src/contrib #rm -rf binutils #cd /usr/src/supfiles #cvsup -L2 -g srcsup U binutils/... .. .. The problem would be in /usr/src/gnu/usr.bin/binutils (or some other header you've installed). I should ask I guess, what is the output of: which cc cc -v echo $CC But still.. the same problem occurs to me. Shall I try with the copy from http://www.gnu.org and see if it works? That will tell you nothing. Your problem is the building of Binutils within /usr/src. We build it very differently than the stock FSF way. Can you debug this more? You know what appears to be defined. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. Dunno if this is already known, but I just had a kernel from a cvsup of the 5th of this month go bang about half an hour ago; I'm afraid I don't have a lot of info available as it was unattended at the time and auto- rebooted (and I deleted the core files before I read this because I needed the disc space... sorry) so the only info I can offer is that it was in the process of doing a make -j10 buildworld and barfed in pmap_remove_pages (via exec_new_vmspace - exec_elf_imgact - execve); hardware is a dual P3 with SMP enabled, 512MB core, 2GB swap (total of two partitions) If this is important/unexpected, I'll try to reproduce it with more info. Cheers, Chris. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
At 4:57 AM +1100 3/9/02, Bruce Evans wrote: I'm surprised that everyone hasn't complained about world breakage from this. It has been broken for almost 2 weeks now. Everything that goes near ntohl and has WARNS = 2 fails to compile. Without WARNS, the bug is reported as above, but a bogus version of __hton* is found in the library and only optimization of hton* is broken. Well, I get compile-time warning messages when doing a buildworld of current, but nothing actually breaks. I do not do much of anything fancy with resetting WARNS, so my guess is that the default buildworld settings will not run into a show-stopping error due to these loose ends. I think part of it is that some things (like 'lpr' for instance) were changed to use 'BDECFLAGS' instead of some compiler-specific list of flags (in -stable lpr has '-Wall -Wnested-externs -Wmissing-prototypes -Wno-unused -Wredundant-decls -Wstrict-prototypes'). That probably sounds like a step up in warning level, except that we also removed BDECFLAGS from /etc/defaults/make.conf. In fact, there is no /etc/defaults/make.conf in current, it was moved to /usr/share/examples/etc/make.conf. So I expect that most people (including me) have effectively gone to compiling with zero special CWARNFLAGS parameters for those modules. I'll make a wild guess and say that it's possible that Bruce might have some BDECFLAGS set in his /etc/make.conf, so he is probably seeing more warning messages than the average person... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
And FWIW, alpha kernels on some Uniprocessor boxes freeze up. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
One thing to keep in mind here is that this is still going to be a snapshot of -current, and not a production release of -stable. We want a snapshot that does not have any serious problems, but innocent users should still realize that there are definitely going to be a lot of loose ends and rough edges around. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
On Fri, 2002/03/08 at 11:23:36 -0800, Doug Barton wrote: 3. xconsole causes periodic panics. The problem (according to BDE) is a well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when printf() is called while sched_lock is held. I reported this bug in October 2001, if anyone wants to look through the archives. While this issue is still present, printf()s with sched_lock held seem to fortunately be quite rare. IIRC your panics were caused by the microuptime went backwards message, which was recently removed. The only other relatively frequently reported printf() in this category I can think of at the moment is for the calcru: negative time... message. - thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c src/secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c
This comment is false. On my -CURRENT system with this commit in place 'passwd' and 'login'/'su' commands loops forever computing MD5 password. After reverting crypt-md5.c to rev. 1.8 all thouse commands work as always. Same thing happened to me, but it appears to have been fixed. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Keyboard (quasi-)lockup running script
Is anyone else seeing this? Running -CURRENT (been tracking it daily for a while, now), I find that if I run script(1), things basically run as expected... until I try to close script's stdin (normally, by entering EOT (^D)). At that point, I can use the mouse (if I'm in an environment where that makes sense); I can switch among the ttyvNs (up to a point), but nothing indicates that any (other) characters are being read -- I can't use Ctl+Alt+Esc to break into the debugger; can't Ctl+Alt+Del to reboot -- it's power-cycle time (unless I remembered[*] that this was going to happen, and set up an at task to reboot at some auspicious time in the (near) future. I first noticed this a few days ago, in conjunction with my normal build sequence: I would fire up screen(1), within that screen session, fire up script(1), do the make buildworld friends; after the mergemaster, I'd exit script(1), then reboot. Except that (starting a few days ago -- between Sunday - Tuesday, I think) I would hit ^D on the script session, and fail to get a shell prompt back. I could still type on xterms displayed on my laptop (the machine I was upgrading at the time) that were actually running on other machines (and get expected/useful responses back, too). And as alluded to above, setting up an at task ahead of time appears to work OK. I had thought that there might be some correlation bewteen this and some whines (warning messages) I was seeing from sudo(8), since I needed to have a different sudo executable for -CURRENT than I do for -STABLE. So, this afternoon, I removed sudo re-built it (under today's -CURRENT). But then I discovered that the behavior (quasi-lockup) occurs even if I use script(1) as a normal user -- no use of sudo at all. This would seem to be A Bad Thing. Here's my recent CVSup history: freebeast(4.5-S)[4] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Mon Mar 4 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Mar 4 03:53:29 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Mar 5 03:47:07 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Mar 5 03:54:20 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Mar 6 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Mar 6 03:53:38 PST 2002 CVSup begin from cvsup14.freebsd.org at Thu Mar 7 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Mar 7 03:53:22 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Mar 8 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Mar 8 03:53:39 PST 2002 And the laptop is presently running: g1-6(5.0-C)[1] uname -a FreeBSD g1-6.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #93: Fri Mar 8 08:17:09 PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W i386 g1-6(5.0-C)[2] If some kind soul would care to loan me a clue, I'll be happy to hunt for causes and such. I can provide kernel configs, dmesg output, and the like on a Web page, if that would be useful -- but what I'm asking for at this point is hints for narrowing the scope down somewhat from the entire known universe. (OK; that was melodramatic. Sorry.) * It's a poor sort of memory that only works backaards, the Queen remarked. -- Lewis Carroll; _Through the Looking-Glass_ (Wool and Water) Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 01:35:47PM -0800, Matthew Jacob wrote: And FWIW, alpha kernels on some Uniprocessor boxes freeze up. Yes. Or panic. See my posts earlier this week. I managed to get 2 buildworlds without accidents, but all make release attempts either paniced or froze. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Sorry- couldn't see your posts. Majordomo bounced my resubscribe request to the list owner who seems to not to have gotten it. On Fri, 8 Mar 2002, Wilko Bulte wrote: On Fri, Mar 08, 2002 at 01:35:47PM -0800, Matthew Jacob wrote: And FWIW, alpha kernels on some Uniprocessor boxes freeze up. Yes. Or panic. See my posts earlier this week. I managed to get 2 buildworlds without accidents, but all make release attempts either paniced or froze. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: linprocfs.ko is broken
On Fri, Mar 08, 2002 at 10:03:02AM -0800, Steve Kargl wrote: root[244] kldstat Id Refs AddressSize Name 1 12 0xc010 26714c kernel 21 0xc0368000 18330linux.ko 32 0xc0381000 15480miibus.ko 41 0xc0397000 7798 if_rl.ko 52 0xc039f000 1a14csnd_pcm.ko 61 0xc03ba000 9538 snd_maestro3.ko 71 0xc03c4000 c860 agp.ko 81 0xc14b7000 2000 blank_saver.ko root[245] kldload linprocfs KLD linprocfs.ko: depends on linux - not available kldload: can't load linprocfs: Exec format error This is often a signal of stale modules..are you sure linprocfs is up to date? Kris msg35841/pgp0.pgp Description: PGP signature
Re: Keyboard (quasi-)lockup running script
cvs checkout -D 8PM last Monday :-) (or similar) On Fri, 8 Mar 2002, David Wolfskill wrote: Is anyone else seeing this? Running -CURRENT (been tracking it daily for a while, now), I find that if I run script(1), things basically run as expected... until I try to close script's stdin (normally, by entering EOT (^D)). At that point, I can use the mouse (if I'm in an environment where that makes sense); I can switch among the ttyvNs (up to a point), but nothing indicates that any (other) characters are being read -- I can't use Ctl+Alt+Esc to break into the debugger; can't Ctl+Alt+Del to reboot -- it's power-cycle time (unless I remembered[*] that this was going to happen, and set up an at task to reboot at some auspicious time in the (near) future. I first noticed this a few days ago, in conjunction with my normal build sequence: I would fire up screen(1), within that screen session, fire up script(1), do the make buildworld friends; after the mergemaster, I'd exit script(1), then reboot. Except that (starting a few days ago -- between Sunday - Tuesday, I think) I would hit ^D on the script session, and fail to get a shell prompt back. I could still type on xterms displayed on my laptop (the machine I was upgrading at the time) that were actually running on other machines (and get expected/useful responses back, too). And as alluded to above, setting up an at task ahead of time appears to work OK. I had thought that there might be some correlation bewteen this and some whines (warning messages) I was seeing from sudo(8), since I needed to have a different sudo executable for -CURRENT than I do for -STABLE. So, this afternoon, I removed sudo re-built it (under today's -CURRENT). But then I discovered that the behavior (quasi-lockup) occurs even if I use script(1) as a normal user -- no use of sudo at all. This would seem to be A Bad Thing. Here's my recent CVSup history: freebeast(4.5-S)[4] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Mon Mar 4 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Mar 4 03:53:29 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Mar 5 03:47:07 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Mar 5 03:54:20 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Mar 6 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Mar 6 03:53:38 PST 2002 CVSup begin from cvsup14.freebsd.org at Thu Mar 7 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Mar 7 03:53:22 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Mar 8 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Mar 8 03:53:39 PST 2002 And the laptop is presently running: g1-6(5.0-C)[1] uname -a FreeBSD g1-6.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #93: Fri Mar 8 08:17:09 PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W i386 g1-6(5.0-C)[2] If some kind soul would care to loan me a clue, I'll be happy to hunt for causes and such. I can provide kernel configs, dmesg output, and the like on a Web page, if that would be useful -- but what I'm asking for at this point is hints for narrowing the scope down somewhat from the entire known universe. (OK; that was melodramatic. Sorry.) * It's a poor sort of memory that only works backaards, the Queen remarked. -- Lewis Carroll; _Through the Looking-Glass_ (Wool and Water) Thanks, david -- David H. Wolfskill[EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. 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: Preparing innocent users for -current
Warner Losh wrote: : 2. pam modules break backwards compatibility with pam apps compiled on : RELENG_4. The only solution I've been offered is to recompile things (or, : my preferred solution, don't use pam). Yes. There's nothing here except to recompile. And linker changes, if they happen to be KDE modules... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Joel Wilsson [EMAIL PROTECTED] writes: On Fri, Mar 08, 2002 at 08:59:53AM -0600, David W. Chapman Jr. wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. It works if you don't use objprelink, and then change a bunch of files to include arpa/inet.h htonl()/htons()/ntohl()/ntohs() can be defined by including arpa/inet.h, netinet/in.h, or sys/param.h (the first two are POSIX-required, the final one is temporary until the base system no long requires it). Previously these functions were leaked to all sorts different headers. Weak aliases exist for these functions so even if software depended on, for instance ntohl() being prototyped sys/types.h, this should not be fatal. There's a few small issues with the prototypes which can lead to some compiler diagnostics (this should be fixed by Sunday). If someone can provide a compiler error and source file, I can figure out what the problem is. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
[ Could we CC a few more lists? I'm not sure everyone that uses FreeBSD has read this yet. :) ] David W. Chapman Jr. [EMAIL PROTECTED] writes: Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Hmm. This should be non-fatal in any event, but which header does it include to get it's htons() and htonl() prototypes? netinet/in.h, arpa/inet.h, or sys/param.h? Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. This is almost completely bogus. I recently saw a PR of similar bogusness. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. Hello? I've been overhauling arpa/inet.h (and netinet/in.h) for over six months. The new kernel endian functions complicated things much more. In the meantime, you need to find every occurence of either of those files being included, and make sure the other is included as well. netinet/in.h needs to come first. This is untrue. arpa/inet.h can appear before netinet/in.h or vice versa (remember to include sys/types.h before netinet/in.h, since netinet/in.h isn't a POSIX-2001 header yet). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Hmm. This should be non-fatal in any event, but which header does it include to get it's htons() and htonl() prototypes? netinet/in.h, arpa/inet.h, or sys/param.h? Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. From reading all the posts, I believe the solution has been to manually modify the kde port to do this. This is almost completely bogus. I recently saw a PR of similar bogusness. This was most likely quoted from the same person who submitted the pr you read. I'm not sure how I can help you because I'm not a programmer, but I'd be happy to boot into -current and give you any information you need if there is actually a problem(I don't totally understand what it is at the moment). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: linprocfs.ko is broken
On Fri, Mar 08, 2002 at 02:55:40PM -0800, Kris Kennaway wrote:
On Fri, Mar 08, 2002 at 10:03:02AM -0800, Steve Kargl wrote:
root[244] kldstat
Id Refs AddressSize Name
1 12 0xc010 26714c kernel
21 0xc0368000 18330linux.ko
[snip]
root[245] kldload linprocfs
KLD linprocfs.ko: depends on linux - not available
kldload: can't load linprocfs: Exec format error
This is often a signal of stale modules..are you sure linprocfs is up
to date?
It is up to date.
kargl[201] ls -l /boot/kernel
total 2938
-r-xr-xr-x 1 root wheel48712 Mar 8 09:56 agp.ko*
-r-xr-xr-x 1 root wheel 4025 Mar 8 09:56 blank_saver.ko*
-r-xr-xr-x 1 root wheel27602 Mar 8 09:56 if_rl.ko*
-r-xr-xr-x 1 root wheel 2228249 Mar 8 09:56 kernel*
-rw--- 1 root wheel15432 Mar 8 09:56 linker.hints
-r-xr-xr-x 1 root wheel19581 Mar 8 09:56 linprocfs.ko*
-r-xr-xr-x 1 root wheel97319 Mar 8 09:56 linux.ko*
-r-xr-xr-x 1 root wheel85262 Mar 8 09:56 miibus.ko*
-r-xr-xr-x 1 root wheel35293 Mar 8 09:56 snd_maestro3.ko*
-r-xr-xr-x 1 root wheel 100604 Mar 8 09:56 snd_pcm.ko*
If I run into a problems, I do
1) rm -rf /usr/obj/*
2) cvsup source again
3) make sequence, ie., build{world,kernel}, install{kernel,world}, MM.
4) reboot
5) report problem
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Keyboard (quasi-)lockup running script
I can reproduce this on a 5.0-CURRENT from yesterday, although I do appear to be able to break into the serial debugger. I get the following: db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 1955 c9737600 c97790000 1954 1955 0006002 3 ttywai c1bd8074 csh 1954 c9736700 c97bb0000 1951 1954 0004002 3 pgrpsess c03d801c script 1951 c9736d00 c97730000 1872 1951 2004002 3 pause c9773000 csh 1872 c9737f00 c975e0000 1 1872 0004102 3wait c9737f00 login db trace 1954 mi_switch(c03d8000,c03d801c,c0383380,c97beb08,c023d2f0) at mi_switch+0x17c cv_wait(c03d801c,c040dac0,c9736700,c18be400,0) at cv_wait+0x1b7 _sx_slock(c03d8000,c0383380,78a,0,c982ec00) at _sx_slock+0x5c ttwrite(c18be400,c97bec90,7f0001,c040b9c0,c97bebf8) at ttwrite+0xa4 siowrite(c040b9c0,c97bec90,7f0001,c040b9c0,4) at siowrite+0x78 spec_write(c97bec24,c97bec38,c027b637,c97bec24,4) at spec_write+0x5d spec_vnoperate(c97bec24,4,c97bed20,0,1) at spec_vnoperate+0x15 vn_write(c1bd11c0,c97bec90,c1b1c600,0,c9736800) at vn_write+0x1a3 dofilewrite(c9736800,c1bd11c0,1,bfbff790,4) at dofilewrite+0xb6 write(c9736800,c97bed20,0,4,11) at write+0x51 syscall(2f,2f,2f,11,4) at syscall+0x21f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x280c3fd7, esp = 0xbfbff2cc, ebp = 0xbfbffc18 --- So it looks like the process is writing to its tty, and a lock is attempting to be grabbed on the session group. Unfortunately, 'show locks' now seems to be broken for me, perhaps I don't have WITNESS compiled in...? I'll try to track it down further. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Fri, 8 Mar 2002, David Wolfskill wrote: Is anyone else seeing this? Running -CURRENT (been tracking it daily for a while, now), I find that if I run script(1), things basically run as expected... until I try to close script's stdin (normally, by entering EOT (^D)). At that point, I can use the mouse (if I'm in an environment where that makes sense); I can switch among the ttyvNs (up to a point), but nothing indicates that any (other) characters are being read -- I can't use Ctl+Alt+Esc to break into the debugger; can't Ctl+Alt+Del to reboot -- it's power-cycle time (unless I remembered[*] that this was going to happen, and set up an at task to reboot at some auspicious time in the (near) future. I first noticed this a few days ago, in conjunction with my normal build sequence: I would fire up screen(1), within that screen session, fire up script(1), do the make buildworld friends; after the mergemaster, I'd exit script(1), then reboot. Except that (starting a few days ago -- between Sunday - Tuesday, I think) I would hit ^D on the script session, and fail to get a shell prompt back. I could still type on xterms displayed on my laptop (the machine I was upgrading at the time) that were actually running on other machines (and get expected/useful responses back, too). And as alluded to above, setting up an at task ahead of time appears to work OK. I had thought that there might be some correlation bewteen this and some whines (warning messages) I was seeing from sudo(8), since I needed to have a different sudo executable for -CURRENT than I do for -STABLE. So, this afternoon, I removed sudo re-built it (under today's -CURRENT). But then I discovered that the behavior (quasi-lockup) occurs even if I use script(1) as a normal user -- no use of sudo at all. This would seem to be A Bad Thing. Here's my recent CVSup history: freebeast(4.5-S)[4] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Mon Mar 4 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Mar 4 03:53:29 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Mar 5 03:47:07 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Mar 5 03:54:20 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Mar 6 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Mar 6 03:53:38 PST 2002 CVSup begin from cvsup14.freebsd.org at Thu Mar 7 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Mar 7 03:53:22 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Mar 8 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Mar 8 03:53:39 PST 2002 And the laptop is presently running: g1-6(5.0-C)[1] uname -a FreeBSD g1-6.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #93: Fri Mar 8 08:17:09 PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W i386 g1-6(5.0-C)[2] If some kind soul would care to loan me a clue, I'll be happy to hunt for causes and such. I can provide kernel configs, dmesg output, and the like on a Web page, if that would be useful -- but what I'm asking for at this point is hints for narrowing the scope down somewhat from the entire known universe. (OK; that was
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Garance A Drosihn wrote: On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) That was not planned until the second developer snapshot before release, according to the discussion at the developer's summit at BSDCon. I thought someone was going to accumulate and post minutes for that meeting?!? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
On Fri, 8 Mar 2002, Thomas Moestl wrote: On Fri, 2002/03/08 at 11:23:36 -0800, Doug Barton wrote: 3. xconsole causes periodic panics. The problem (according to BDE) is a well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when printf() is called while sched_lock is held. I reported this bug in October 2001, if anyone wants to look through the archives. While this issue is still present, printf()s with sched_lock held seem to fortunately be quite rare. IIRC your panics were caused by the microuptime went backwards message, which was recently removed. The only other relatively frequently reported printf() in this category I can think of at the moment is for the calcru: negative time... message. Well, I have a fairly verbose console on some of my systems, which is why I think I panic'ed with this problem more than most. Given that we're opening things to a wider audience, this should be listed as a gotcha, even if it only affects a small percentage of users. -- 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: Preparing innocent users for -current
On Fri, 8 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Doug Barton writes: : 1. phk malloc debugging flags enabled by default. Solutions include : recompiling apps, and toggling things off in /etc/malloc.conf. Recompiling apps isn't going to change things. The default is in the system. Errr... right. Sorry... must get more sleep. : 3. xconsole causes periodic panics. The problem (according to BDE) is a : well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when : printf() is called while sched_lock is held. I reported this bug in : October 2001, if anyone wants to look through the archives. This isn't happening often enough to worry about. Funny, I worry about it a lot when it happens to me. :) Especially when I'm working from home and I have to spend an extra 10-15 minutes tunnelling through proxies, etc. to get back to work after every panic. For those users who are affected, knowing to disable xconsole to enhance their stability will be valuable. Of course, if someone were to actually FIX the problem... -- 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: Preparing innocent users for -current
On Fri, 8 Mar 2002, Hiten Pandya wrote: Shouldn't this be CC'ed to -doc as well? I trust Murray as releng, and Bruce as release docs guy to DTRT with the information. :) -- 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: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, 8 Mar 2002, Terry Lambert wrote: Garance A Drosihn wrote: On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) That was not planned until the second developer snapshot before release, according to the discussion at the developer's summit at BSDCon. I thought someone was going to accumulate and post minutes for that meeting?!? Yeah, we have extensive notes and a complete recording, I've just been stalled on getting them out the door due to other priorities and lack of a docs person wanting to docify them. I'll post the text version sometime in the next day or two, and we can let the docified version come later. Look for a post on sometime this weekend. 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: Patch for critical_enter()/critical_exit() interrupt assem
:On 08-Mar-02 Matthew Dillon wrote:
:
::I agree that the use of cpu_critical_enter/exit could use cleaning up.
::Can you give an example of where critical_enter is used improperly?
::You mean in fork_exit? Your changes to cpu_switch solve that problem
::with critical_exit almost unchanged. The savecrit stuff should really
::just be made MD. If cpu_critical_exit was changed to take the thread
::as its argument as I suggested before this would be easy.
:
:Hmm, I agree with getting rid of td_savecrit as an MI field and changing the
:API for cpu_critical_*. I also agree that cpu_critical_* is abused in many
:cases. I just fixed a few that can be fixed. I think most others can be fixed
:with the explicit intr_disable/intr_restore API which shouldn't be a problem
:since it's basically what cpu_critical_* is now but just misnamed. This would
:fix the remaining instance in witness for example. ast() is harder to solve,
:and although I don't like having stuff duplicated all over the place making
:maintenance harder, moving the loop and test out to MD code in either asm or C
:as Jake suggested would work fine.
:
: fork_exit() is a good example. The existing code explicitly
: initializes td-td_critnest to 1 and then sets td-td_savecrit
: to CRITICAL_FORK:
:
: td-td_critnest = 1;
: td-td_savecrit = CRITICAL_FORK;
:
: It then proceeds to unlock the sched_lock spin lock.
:
: This code only works because interrupts are hard-disabled in the
: fork trampoline code. In otherwords, the code assumes that
: cpu_critical_enter() and cpu_critical_exit() play with hard interrupt
: disablement. If interrupts were enabled there would be two severe
: race conditions in the code: The first upon entering fork_exit
: prior to ke_oncpu being set, and the second when td-td_critnest is set
: to 1 prior to td_savecrit being set to CRITICAL_FORK.
:
:No, the savecrit does assume that, but the critnest is still correct and will
:still work fine. By definition, you don't switch inside a critical section
:(taht's what critical sections do) so critnest will always be 1 here. Any
:interrupt or what not that comes in if interrutps aren't disabled might dink
:with teh count but the count will still be 1 by the time we get to releasing
:sched_lock. Alternatively, we could set td_critnest to 1 in fork() which would
:be ok with me.
Huh? Are you actually advocating that it is ok to allow an interrupt
to occur while curthread is in an inconsistent state? I mean, we aren't
talking about a little inconsistency here John, we are talking about
the sched_lock being in a weird state, and we are talking about
curthread's ke_oncpu not being set properly.
We could set td_critnest to 1 in fork(). I considered doing that but
decided it was easier to keep my code as close to the existing code
as possible so I clean it up in the fork trampoline code while
interrupts really are disabled. With the critical section in a
completely consistent state I can then enable interrupts prior
to calling fork_exit().
:I always said that Peter's hack was gross. I didn't like it when he did it
:originally either. Actually, doing cpu_critical_exit() though is safe since
:all we need is for the critnest to be = 1 to prevent context switches (which
:is all critical sections do if you read the manpage that documents them). We
:only ever need to defer bottom-half code (or Primary Interrupt Context as Apple
:likes to call it) while holding a spin mutex.
By my read of the code it is not safe to allow interrupts to be enabled
while critnest = 1 because while the interrupt may not context
switch, it will still attempt to schedule a new thread which requires
interactions with spin locks which the interrupted process may be
holding. The result: the interrupted process is not protected
by the spin lock it thought protected it because the interrupt can
pop in and do something horrible.
:The MD code does abuse cpu_critical_* which I am quite happy to fix using
:intr_*(). Once this is done cpu_critical_* should be out of bogus land and you
:should be able to adjust your patches to change that API's implementation.
:I'm willing to do all the work to fixup the cpu_critical_* abuse right now
:before doing anything else. It really needs to be done anyway.
:...
:They won't stay one line. That's the whole point. The entire reason we have
:MI versions is that I committed part of the preemption tree specifically to
:try and minimize the amount of the preemption code not currently checked in.
:The MI versions are still a WIP part of the preemption tree. They wouldn't
:even exist if it weren't for the preemption tree.
I find it highly unlikely that they will ever exceed four or five lines.
About the worst I can envision is a conditional like this:
critical_exit()
{
if (--td-td_critnest == 0) {this
Re: Patch for critical_enter()/critical_exit() interrupt assem
:The reason is that if they are in MI code they automatically apply to all :platforms and can't get out sync. When they are modified to handle preemption :the freebsd kernel will be fully preemptive. Not, it works on i386 and its :believed to work on alpha and powerpc is not preemptive at all and we don't If the routines were large this would be an issue, but we are talking between 1 and 5 lines of MI code verses potentially many more lines of MD code and I find it virtually impossible for such a small amount of code to 'get out of sync'. :even know about ia64 (not to dump on other platforms, this is just example of :how things go sometimes). I understand that this argument may be sentimental :and may not hold water in a technial discussion. As such I will not stop you :from making them MD if you disagree (not to imply that I have the power to do :so, I don't), I just think that keeping them MI is the right thing to do. : :I must admit that having them be MD will allow me to make optimizations for :sparc64 that I have wanted to. However, I do not think that this is better :for freebsd as a whole. : : : :... :... :The point is not wether its easy or not, the point is that this is an :important feature that may have been forgotten about. I use this on :a daily basis in sparc64 development and I would be upset if it was :broken there for any amount of time, not that this patch will affect it. :I am confident that you will fix any problems that arise, but I would :rather the next person that tries to do some debugging not be confused :by something being different, or by it not working and having to wait for :a fix, even if that amount of time is insignificant. If you do not feel :that this needs to be looked at before you commit then that is fine, again :I cannot stop you. I know many other committers who would not feel that :way about a patch of their own and I think that standard is worth adhereing :to. I apologize if this sounds like a lecture or if this offends you, it :is just how I feel. : :Jake I'm not sure what you are refering to here. The fast interrupt deferral stuff only applies to I386. In anycase, I certainly haven't forgotten about debugger support for I386, but I didn't go to great lengths to test whether the DDB backtrace operates as expected for the fast-interrupt-restart case either. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Matthew Jacob writes: And FWIW, alpha kernels on some Uniprocessor boxes freeze up. I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). I'm on the west coast right now, away from my alphas, but I had several buildworlds complete last week with ithread preemption disabled. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Keyboard (quasi-)lockup running script
Some more details, now I have WITNESS compiled in... crash1# script ls Script started, output file is ls crash1# crash1# exitStopped at siointr1+0xf2: movl$0,brk_state1.702 db trace siointr1(c185f400,c0446ec0,0,c03a0260,662) at siointr1+0xf2 siointr(c185f400,18,c86c0010,c0230010,0) at siointr+0x23 Xfastintr4() at Xfastintr4+0x32 --- interrupt, eip = 0xc0329e52, esp = 0xc86cad14, ebp = 0xc86cad14 --- cpu_idle(c86cad34,c0228798,0,c86cad48,0) at cpu_idle+0x1e idle_proc(0,c86cad48,0,c02288f4,0) at idle_proc+0x21 fork_exit(c02288f4,0,c86cad48) at fork_exit+0x98 fork_trampoline() at fork_trampoline+0x8 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 193 c9722c00 c975a0000 192 193 0006002 3 ttywai c1b1c674 csh 192 c8cf2600 c97280000 189 192 0004002 3 pgrpsess c03dc0fc script 189 c8cf2300 c972e0000 188 189 2004002 3 pause c972e000 csh 188 c9722f00 c97490000 1 188 0004102 3wait c9722f00 login ... db trace 192 mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c cv_wait(c03dc0fc,c0413564,c8cf2600,c18be400,0) at cv_wait+0x1fb _sx_slock(c03dc0e0,c03873e0,78a,0,c91b78a0) at _sx_slock+0x5c ttwrite(c18be400,c972bc90,6e0001,c0410360,c972bbf8) at ttwrite+0xa4 siowrite(c0410360,c972bc90,6e0001,c0410360,3) at siowrite+0x78 spec_write(c972bc24,c972bc38,c027d9a7,c972bc24,3) at spec_write+0x5d spec_vnoperate(c972bc24,3,c972bd20,0,1) at spec_vnoperate+0x15 vn_write(c1b1bd40,c972bc90,c1b1fb00,0,c8cf2700) at vn_write+0x1a3 dofilewrite(c8cf2700,c1b1bd40,1,bfbff790,3) at dofilewrite+0xb6 write(c8cf2700,c972bd20,0,4,11) at write+0x51 syscall(2f,2f,2f,11,4) at syscall+0x21f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x280c3fd7, esp = 0xbfbff2cc, ebp = 0xbfbffc18 --- db show locks exclusive (spin mutex) sio (0xc0446ec0) locked @ /cboss/p4/rwatson/trustedbsd/mac/sys/dev/sio/sio.c:1634 I suspect, unfortunately, that that is only my kernel debugger entry point. So, here's what happens if I do it using a pty for the script session, keeping the kernel debugger out of the picture: (pty0) crash1# script ls Script started, output file is ls crash1# exit (serial console) pid proc addruid ppid pgrp flag stat wmesg wchan cmd 194 c973a900 c975f0000 193 194 0006002 3 ttywai c1b28674 csh 193 c8cf2900 c971b0000 190 193 0004002 3 pgrpsess c03dc0fc script 190 c8cf2600 c97280000 189 190 2004002 3 pause c9728000 csh 189 c8cf2300 c972e0000 156 156 000 3 select c03de548 sshd 188 c973ac00 c97540000 1 188 0004002 3 pgrpsess c03dc0fc getty 187 c973af00 c974f0000 1 187 0004002 3 ttyin c1b0b610 getty ... db trace 193 # script mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c cv_wait(c03dc0fc,c0413564,c8cf2900,c1b0b228,0) at cv_wait+0x1fb _sx_slock(c03dc0e0,c03873e0,78a,c1b1c600,c96f3620) at _sx_slock+0x5c ttwrite(c1b0b228,c971ec90,620001,c971ebf8,c0212d79) at ttwrite+0xa4 ptswrite(c1b1c600,c971ec90,620001,c1b1c600,3) at ptswrite+0x28 spec_write(c971ec24,c971ec38,c027d9a7,c971ec24,3) at spec_write+0x5d spec_vnoperate(c971ec24,3,c971ed20,0,1) at spec_vnoperate+0x15 vn_write(c1af2100,c971ec90,c0b2db00,0,c8cf2a00) at vn_write+0x1a3 dofilewrite(c8cf2a00,c1af2100,1,bfbff73c,3) at dofilewrite+0xb6 write(c8cf2a00,c971ed20,0,4,11) at write+0x51 syscall(2f,2f,2f,11,4) at syscall+0x21f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x280c3fd7, esp = 0xbfbff278, ebp = 0xbfbffbc4 --- db trace 188 # getty mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c cv_wait(c03dc0fc,c0413564,c973ac00,c18be400,0) at cv_wait+0x1fb _sx_slock(c03dc0e0,c03873e0,78a,0,c91b78a0) at _sx_slock+0x5c ttwrite(c18be400,c9757c90,40001,c0410360,c9757bf8) at ttwrite+0xa4 siowrite(c0410360,c9757c90,40001,c0410360,1) at siowrite+0x78 spec_write(c9757c24,c9757c38,c027d9a7,c9757c24,1) at spec_write+0x5d spec_vnoperate(c9757c24,1,c9757d20,0,1) at spec_vnoperate+0x15 vn_write(c1b1bf80,c9757c90,c1b1cc00,0,c973ad00) at vn_write+0x1a3 dofilewrite(c973ad00,c1b1bf80,1,8050680,1) at dofilewrite+0xb6 write(c973ad00,c9757d20,bfbffde4,805072c,80507cc) at write+0x51 syscall(2f,2f,2f,80507cc,805072c) at syscall+0x21f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x280c7fd7, esp = 0xbfbffcf0, ebp = 0xbfbffd0c --- So perhaps there's a deadlock. Or at least, it looks like both processes hang trying to get a shared lock for the session, and block waiting. Perhaps the lock is getting corrupted somehow, or has not properly been initialized? Unfortunately, it looks like 'show locks' only knows about the mutex in the sio code, presumably from the serial debugger: db show locks exclusive (spin mutex) sio (0xc0446ec0) locked @
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Apparently, On Fri, Mar 08, 2002 at 05:33:28PM -0500, Garance A Drosihn said words to the effect of; On Fri, 8 Mar 2002, Murray Stokely wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) Yes, absolutely. I'm really excited that the sparc64 port is ready to be part of this. It will probably not be a regaular freebsd release, there will be (already is) a bootable iso that has all the tools needed to install a distribution from a tarball quickly and easily (the cd boots multi user). There will be a self hosted toolchain which can be used to build a custom kernel. This can also be used to build userland and ports natively, but make buildworld may not work. I will be cutting another iso this weekend which fixes a couple problems with the first one. Anyone who has a sparc64 machine is invited to subscribe to the freebsd-sparc mailing list and be testers for the first semi-official fresbsd/sparc64 release. tears come to Jake's eyes. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Yes, Peter also suggested this. Alas, at some point over the last couple of days, something also broke so that polled mailbox commands for ISP are now broken. Dunno why. *shrug* On Fri, 8 Mar 2002, Andrew Gallatin wrote: Matthew Jacob writes: And FWIW, alpha kernels on some Uniprocessor boxes freeze up. I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). I'm on the west coast right now, away from my alphas, but I had several buildworlds complete last week with ithread preemption disabled. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Jake Burkholder wrote: Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) Yes, absolutely. Wow. This is really impressive. I thought it wasn't going to be available until the preview just before the final release! Good work! Make Robert update his notes... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Apparently, On Fri, Mar 08, 2002 at 04:12:47PM -0800, Terry Lambert said words to the effect of; Jake Burkholder wrote: Will this release include some kind of bootable-install support for any new hardware platforms, such as sparc64? (this snapshot is meant to be available as some kind of CD-package, right?) Yes, absolutely. Wow. This is really impressive. I thought it wasn't going to be available until the preview just before the final release! Good work! Make Robert update his notes... Thanks. Alot of this actually happened since the meeting ;) Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Fri, Mar 08, 2002 at 02:17:24AM -0800, Murray Stokely wrote: To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. Some of the 5.x package builds on bento are dying with SIGBUS in the port compilation process, for example gnomelibs which is dying in the configure script. Apparently this is a widely experienced problem (a workaround is to compile without optimization, but I don't want to do that for the package builds unless I have to). Is anyone looking into this? Kris msg35862/pgp0.pgp Description: PGP signature
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
David W. Chapman Jr. [EMAIL PROTECTED] writes: Hmm. This should be non-fatal in any event, but which header does it include to get it's htons() and htonl() prototypes? netinet/in.h, arpa/inet.h, or sys/param.h? Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. From reading all the posts, I believe the solution has been to manually modify the kde port to do this. Maybe not. I think missing prototypes might be fatal in C++. If this is the case, my new endian patch will fix this. Try compiling KDE after installing a world with the following patch applied: http://people.FreeBSD.org/~mike/patches/endian-ng3.diff I plan on committing this on Sunday. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Mike Barcroft [EMAIL PROTECTED] writes: Maybe not. I think missing prototypes might be fatal in C++. Yes. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Maybe not. I think missing prototypes might be fatal in C++. If this is the case, my new endian patch will fix this. Try compiling KDE after installing a world with the following patch applied: http://people.FreeBSD.org/~mike/patches/endian-ng3.diff I plan on committing this on Sunday. I don't know if its related to this patch, but I get this when I buildworld now cc -O -pipe -march=k6 -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -W non-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/sub.c cc -O -pipe -march=k6 -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -W non-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/undo.c gzip -cn /usr/src/bin/ed/ed.1 ed.1.gz cc -O -pipe -march=k6 -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -W non-const-format -Wno-format-extra-args -Werror -static -o ed buf.o cbc.o glbl .o io.o main.o re.o sub.o undo.o -lcipher cbc.o: In function `get_keyword': cbc.o(.text+0x17d): undefined reference to `getpass' *** Error code 1 1 error *** Error code 2 -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Keyboard (quasi-)lockup running script
Found it:
db show locks 255
exclusive (sx) pgrpsess (0xc03dc0e0) locked @
/cboss/p4/rwatson/trustedbsd/mac/sys/kern/kern_exit.c:234
db trace 255
mi_switch(0,c1b2ea28,c9735300,c0232341,1) at mi_switch+0x17c
msleep(c1b2ea74,0,15a,c038743f,7530) at msleep+0x31a
ttysleep(c1b2ea28,c1b2ea74,15a,c038743f,7530) at ttysleep+0x21
ttywait(c1b2ea28) at ttywait+0x45
exit1(c9735400,0,c03f3260,0,c037df20) at exit1+0x43e
sys_exit(c9735400,c977fd20,1,0,0) at sys_exit+0x2a
syscall(2f,2f,2f,0,0) at syscall+0x21f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (1, FreeBSD ELF, sys_exit), eip = 0x80a5c8f, esp = 0xbfbfda14, ebp =
0xbfbfda40 ---
I didn't realize 'show locks' used curthread by default only. There
doesn't appear to be a 'show locks all'. In any case, it looks like the
exclusive lock is grabbed in kern_exit:
PGRPSESS_XLOCK();
if (SESS_LEADER(p)) {
...
PGRP_UNLOCK(sp-s_ttyp-t_pgrp);
}
/* XXX tp should be locked. */
(void) ttywait(tp);
/*
* The tty could have been revoked
* if we blocked.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Fri, 8 Mar 2002, Robert Watson wrote:
Some more details, now I have WITNESS compiled in...
crash1# script ls
Script started, output file is ls
crash1#
crash1# exitStopped at siointr1+0xf2: movl$0,brk_state1.702
db trace
siointr1(c185f400,c0446ec0,0,c03a0260,662) at siointr1+0xf2
siointr(c185f400,18,c86c0010,c0230010,0) at siointr+0x23
Xfastintr4() at Xfastintr4+0x32
--- interrupt, eip = 0xc0329e52, esp = 0xc86cad14, ebp = 0xc86cad14 ---
cpu_idle(c86cad34,c0228798,0,c86cad48,0) at cpu_idle+0x1e
idle_proc(0,c86cad48,0,c02288f4,0) at idle_proc+0x21
fork_exit(c02288f4,0,c86cad48) at fork_exit+0x98
fork_trampoline() at fork_trampoline+0x8
db ps
pid proc addruid ppid pgrp flag stat wmesg wchan cmd
193 c9722c00 c975a0000 192 193 0006002 3 ttywai c1b1c674 csh
192 c8cf2600 c97280000 189 192 0004002 3 pgrpsess c03dc0fc script
189 c8cf2300 c972e0000 188 189 2004002 3 pause c972e000 csh
188 c9722f00 c97490000 1 188 0004102 3wait c9722f00 login
...
db trace 192
mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c
cv_wait(c03dc0fc,c0413564,c8cf2600,c18be400,0) at cv_wait+0x1fb
_sx_slock(c03dc0e0,c03873e0,78a,0,c91b78a0) at _sx_slock+0x5c
ttwrite(c18be400,c972bc90,6e0001,c0410360,c972bbf8) at ttwrite+0xa4
siowrite(c0410360,c972bc90,6e0001,c0410360,3) at siowrite+0x78
spec_write(c972bc24,c972bc38,c027d9a7,c972bc24,3) at spec_write+0x5d
spec_vnoperate(c972bc24,3,c972bd20,0,1) at spec_vnoperate+0x15
vn_write(c1b1bd40,c972bc90,c1b1fb00,0,c8cf2700) at vn_write+0x1a3
dofilewrite(c8cf2700,c1b1bd40,1,bfbff790,3) at dofilewrite+0xb6
write(c8cf2700,c972bd20,0,4,11) at write+0x51
syscall(2f,2f,2f,11,4) at syscall+0x21f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (4, FreeBSD ELF, write), eip = 0x280c3fd7, esp = 0xbfbff2cc, ebp =
0xbfbffc18 ---
db show locks
exclusive (spin mutex) sio (0xc0446ec0) locked @
/cboss/p4/rwatson/trustedbsd/mac/sys/dev/sio/sio.c:1634
I suspect, unfortunately, that that is only my kernel debugger entry
point. So, here's what happens if I do it using a pty for the script
session, keeping the kernel debugger out of the picture:
(pty0)
crash1# script ls
Script started, output file is ls
crash1# exit
(serial console)
pid proc addruid ppid pgrp flag stat wmesg wchan cmd
194 c973a900 c975f0000 193 194 0006002 3 ttywai c1b28674 csh
193 c8cf2900 c971b0000 190 193 0004002 3 pgrpsess c03dc0fc script
190 c8cf2600 c97280000 189 190 2004002 3 pause c9728000 csh
189 c8cf2300 c972e0000 156 156 000 3 select c03de548 sshd
188 c973ac00 c97540000 1 188 0004002 3 pgrpsess c03dc0fc getty
187 c973af00 c974f0000 1 187 0004002 3 ttyin c1b0b610 getty
...
db trace 193 # script
mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c
cv_wait(c03dc0fc,c0413564,c8cf2900,c1b0b228,0) at cv_wait+0x1fb
_sx_slock(c03dc0e0,c03873e0,78a,c1b1c600,c96f3620) at _sx_slock+0x5c
ttwrite(c1b0b228,c971ec90,620001,c971ebf8,c0212d79) at ttwrite+0xa4
ptswrite(c1b1c600,c971ec90,620001,c1b1c600,3) at ptswrite+0x28
spec_write(c971ec24,c971ec38,c027d9a7,c971ec24,3) at spec_write+0x5d
spec_vnoperate(c971ec24,3,c971ed20,0,1) at spec_vnoperate+0x15
vn_write(c1af2100,c971ec90,c0b2db00,0,c8cf2a00) at vn_write+0x1a3
dofilewrite(c8cf2a00,c1af2100,1,bfbff73c,3) at dofilewrite+0xb6
write(c8cf2a00,c971ed20,0,4,11) at write+0x51
syscall(2f,2f,2f,11,4) at
Re: Keyboard (quasi-)lockup running script
FYI, process 255 here is csh. In this case, getty isn't also blocked in
trying to get pgrpsess:
db ps
pid proc addruid ppid pgrp flag stat wmesg wchan cmd
255 c9735300 c97550000 254 255 0006002 3 ttywai c1b2ea74 csh
254 c9734d00 c97710000 248 254 0004002 3 pgrpsess c03dc0fc script
248 c8cf2300 c972e0000 247 248 2004002 3 pause c972e000 csh
247 c8cf2600 c97280000 156 156 000 3 select c03de548 sshd
188 c9735f00 c97490000 1 188 0004002 3 ttyin c18be410 getty
187 c9736200 c97440000 1 187 0004002 3 ttyin c1b06410 getty
So basically, csh grabs the exclusive lock as it exits, then calls
ttywait(). Then csh and other processes stack up on pgrpsess.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Fri, 8 Mar 2002, Robert Watson wrote:
Found it:
db show locks 255
exclusive (sx) pgrpsess (0xc03dc0e0) locked @
/cboss/p4/rwatson/trustedbsd/mac/sys/kern/kern_exit.c:234
db trace 255
mi_switch(0,c1b2ea28,c9735300,c0232341,1) at mi_switch+0x17c
msleep(c1b2ea74,0,15a,c038743f,7530) at msleep+0x31a
ttysleep(c1b2ea28,c1b2ea74,15a,c038743f,7530) at ttysleep+0x21
ttywait(c1b2ea28) at ttywait+0x45
exit1(c9735400,0,c03f3260,0,c037df20) at exit1+0x43e
sys_exit(c9735400,c977fd20,1,0,0) at sys_exit+0x2a
syscall(2f,2f,2f,0,0) at syscall+0x21f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (1, FreeBSD ELF, sys_exit), eip = 0x80a5c8f, esp = 0xbfbfda14, ebp =
0xbfbfda40 ---
I didn't realize 'show locks' used curthread by default only. There
doesn't appear to be a 'show locks all'. In any case, it looks like the
exclusive lock is grabbed in kern_exit:
PGRPSESS_XLOCK();
if (SESS_LEADER(p)) {
...
PGRP_UNLOCK(sp-s_ttyp-t_pgrp);
}
/* XXX tp should be locked. */
(void) ttywait(tp);
/*
* The tty could have been revoked
* if we blocked.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Fri, 8 Mar 2002, Robert Watson wrote:
Some more details, now I have WITNESS compiled in...
crash1# script ls
Script started, output file is ls
crash1#
crash1# exitStopped at siointr1+0xf2: movl$0,brk_state1.702
db trace
siointr1(c185f400,c0446ec0,0,c03a0260,662) at siointr1+0xf2
siointr(c185f400,18,c86c0010,c0230010,0) at siointr+0x23
Xfastintr4() at Xfastintr4+0x32
--- interrupt, eip = 0xc0329e52, esp = 0xc86cad14, ebp = 0xc86cad14 ---
cpu_idle(c86cad34,c0228798,0,c86cad48,0) at cpu_idle+0x1e
idle_proc(0,c86cad48,0,c02288f4,0) at idle_proc+0x21
fork_exit(c02288f4,0,c86cad48) at fork_exit+0x98
fork_trampoline() at fork_trampoline+0x8
db ps
pid proc addruid ppid pgrp flag stat wmesg wchan cmd
193 c9722c00 c975a0000 192 193 0006002 3 ttywai c1b1c674 csh
192 c8cf2600 c97280000 189 192 0004002 3 pgrpsess c03dc0fc script
189 c8cf2300 c972e0000 188 189 2004002 3 pause c972e000 csh
188 c9722f00 c97490000 1 188 0004102 3wait c9722f00 login
...
db trace 192
mi_switch(c03dc0e0,c03dc0fc,78a,c0385a20,14f) at mi_switch+0x17c
cv_wait(c03dc0fc,c0413564,c8cf2600,c18be400,0) at cv_wait+0x1fb
_sx_slock(c03dc0e0,c03873e0,78a,0,c91b78a0) at _sx_slock+0x5c
ttwrite(c18be400,c972bc90,6e0001,c0410360,c972bbf8) at ttwrite+0xa4
siowrite(c0410360,c972bc90,6e0001,c0410360,3) at siowrite+0x78
spec_write(c972bc24,c972bc38,c027d9a7,c972bc24,3) at spec_write+0x5d
spec_vnoperate(c972bc24,3,c972bd20,0,1) at spec_vnoperate+0x15
vn_write(c1b1bd40,c972bc90,c1b1fb00,0,c8cf2700) at vn_write+0x1a3
dofilewrite(c8cf2700,c1b1bd40,1,bfbff790,3) at dofilewrite+0xb6
write(c8cf2700,c972bd20,0,4,11) at write+0x51
syscall(2f,2f,2f,11,4) at syscall+0x21f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (4, FreeBSD ELF, write), eip = 0x280c3fd7, esp = 0xbfbff2cc, ebp =
0xbfbffc18 ---
db show locks
exclusive (spin mutex) sio (0xc0446ec0) locked @
/cboss/p4/rwatson/trustedbsd/mac/sys/dev/sio/sio.c:1634
I suspect, unfortunately, that that is only my kernel debugger entry
point. So, here's what happens if I do it using a pty for the script
session, keeping the kernel debugger out of the picture:
(pty0)
crash1# script ls
Script started, output file is ls
crash1# exit
(serial console)
pid proc addruid ppid pgrp flag stat wmesg wchan cmd
194 c973a900 c975f0000 193 194 0006002 3 ttywai c1b28674 csh
193 c8cf2900 c971b0000 190 193 0004002 3 pgrpsess c03dc0fc script
190 c8cf2600
binutils (libintl.h) problem (was: weird binutils problem)
Hi, I am attaching the output you requested, but I am sure, this wouldn't be very helpful though: /usr/bin/cc (which cc) Using builtin specs. gcc version 2.95.3 20010315 (release) (cc -v) I also looked at all the Makefiles, but couldn't find a problem related to this. Out of curiosity, could it be because of a kernel option(s) which I am using? Regards, -- Hiten Pandya http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) http://www.FreeBSD.org - The Power to Serve msg35868/pgp0.pgp Description: PGP signature
readpassphrase breaks world
The recent commit to readpassphrase appears to cause === bin/ed cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/buf.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/cbc.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/glbl.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/io.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/main.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/re.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/sub.c cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -c /usr/src/bin/ed/undo.c gzip -cn /usr/src/bin/ed/ed.1 ed.1.gz cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -static -o ed buf.o cbc.o glbl.o io.o main.o re.o sub.o undo.o -lcipher cbc.o: In function `get_keyword': cbc.o(.text+0x17d): undefined reference to `getpass' *** Error code 1 1 error *** Error code 2 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: binutils (libintl.h) problem (was: weird binutils problem)
On Sat, Mar 09, 2002 at 03:13:39AM +, Hiten Pandya wrote: Hi, I am attaching the output you requested, but I am sure, this wouldn't be very helpful though: /usr/bin/cc (which cc) Using builtin specs. gcc version 2.95.3 20010315 (release) (cc -v) I also looked at all the Makefiles, but couldn't find a problem related to this. Out of curiosity, could it be because of a kernel option(s) which I am using? Nope. Please verify my hypothesis by applying this patch: Index: contrib/binutils/bfd/sysdep.h === RCS file: /home/ncvs/src/contrib/binutils/bfd/sysdep.h,v retrieving revision 1.1.1.6 diff -u -r1.1.1.6 sysdep.h --- contrib/binutils/bfd/sysdep.h 27 Jan 2002 11:58:14 - 1.1.1.6 +++ contrib/binutils/bfd/sysdep.h 9 Mar 2002 03:22:17 - @@ -132,6 +132,7 @@ #endif #ifdef ENABLE_NLS +#error ENABLE_NLS defined !! #include libintl.h /* Note the use of dgetext() and PACKAGE here, rather than gettext(). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: readpassphrase breaks world
* Steve Kargl [EMAIL PROTECTED] [020308 19:18] wrote: The recent commit to readpassphrase appears to cause cc -O -pipe -DDES -Wall -Wformat -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extra-args -Werror -static -o ed buf.o cbc.o glbl.o io.o main.o re.o sub.o undo.o -lcipher cbc.o: In function `get_keyword': cbc.o(.text+0x17d): undefined reference to `getpass' *** Error code 1 I already handed Brian the pointy hat for this and it appears fixed. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
At 6:32 PM -0600 3/8/02, David W. Chapman Jr. wrote: Try compiling KDE after installing a world with the following patch applied: http://people.FreeBSD.org/~mike/patches/endian-ng3.diff I plan on committing this on Sunday. I don't know if its related to this patch, but I get this when I buildworld now I just did a complete buildworld + installworld with no trouble, and I then added the above patch and did another complete buildworld + installworld. I had no problems with either build. Applying the above patch got rid of about 81 warning messages in the buildworld process, and another 9 from buildkernel. Applying the patch causes no new warning messages (for me, with my kernel options, make options, on i386, etc etc). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
I don't know if its related to this patch, but I get this when I buildworld now I just did a complete buildworld + installworld with no trouble, and I then added the above patch and did another complete buildworld + installworld. I had no problems with either build. Applying the above patch got rid of about 81 warning messages in the buildworld process, and another 9 from buildkernel. Applying the patch causes no new warning messages (for me, with my kernel options, make options, on i386, etc etc). I wonder what's broken, I did a buildworld twice with the same result, I'll try to cvsup tomorrow and see if its fixed, maybe I caught it between commits. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
== Feel Look 10 Years Younger in 10 Weeks With HGH == 30151076
One more bulk email --- aren't you the least bit curious to find out what it's about? Well, visit our site: 1) http://theclinicforhgh.yeah.net OR, read on ... HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? (This product works best for people over 35) Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us anytime (24hrs) TOLL FREE 1-888-248-4571 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-248-4571. If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging. Dr. Daniel Rudman, MD, New England Journal of Medicine. Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly. D.W., New Jersey We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying! C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Call us now 1-888-248-4571 Offer expires March 20, 2002 *** === End of message To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and enter remove in the email subject line then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA WA. Screening of addresses has been done to the best of our technical ability. *** http://TheClinic.netxun.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs in -current?
On Fri, 8 Mar 2002, Robert Watson wrote: Ok, I've committed a slight reorg to NOTES on -CURRENT to reflect the much more logical layout in LINT on -STABLE WRT NETSMB, SMBFS, and NETSMBCRYPTO. No idea where the weird ordering came from, but I think it's fixed now. :-) Thank you. Probably these lines falled of the board on initial import and later Bruce included them into 'undocumented' section. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
linprocfs.ko and kld loader problem?
I'm stumped by the following. My /boot/loader.conf contains miibus_load=YES if_rl_load=YES snd_pcm_load=YES snd_maestro3_load=YES linux_load=YES agp_load=YES hint.acpi.0.disable=1 After booting, kldstat shows that everthing is loaded. root[201] kldstat Id Refs AddressSize Name 1 12 0xc010 26714c kernel 21 0xc0368000 18330linux.ko 32 0xc0381000 15480miibus.ko 41 0xc0397000 7798 if_rl.ko 52 0xc039f000 1a14csnd_pcm.ko 61 0xc03ba000 9538 snd_maestro3.ko 71 0xc03c4000 c860 agp.ko 81 0xc14a5000 2000 blank_saver.ko Now, the problem. root[202] kldload linprocfs kldload: can't load linprocfs: Exec format error The following message is on the system console: KLD linprocfs.ko: depends on linux - not available root[203] kldunload linux root[204] kldload linux root[205] kldload linprocfs root[206] kldstat Id Refs AddressSize Name 1 15 0xc010 26714c kernel 32 0xc0381000 15480miibus.ko 41 0xc0397000 7798 if_rl.ko 52 0xc039f000 1a14csnd_pcm.ko 61 0xc03ba000 9538 snd_maestro3.ko 71 0xc03c4000 c860 agp.ko 81 0xc14a5000 2000 blank_saver.ko 92 0xc15f8000 14000linux.ko 101 0xc1612000 5000 linprocfs.ko This is with current sources from 2200 PST, 07 Mar 02 . The following procedure was used to build the system rm -rf /usr/obj/* cd /usr/src make cleandir make cleandir make buildworld make -DNO_WERROR buildkernel KERNCONF=HOTRATS make installkernel make installworld mergemaster -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
On Tue, Mar 05, 2002 at 07:20:42PM +0100, Wilko Bulte wrote: On Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote: On 04-Mar-02 Wilko Bulte wrote: alpha_dispatch_intr() at alpha_dispatch_intr+0x130 interrupt() at interrupt+0x138 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 vm_fault1() at vm_fault1+0x110c vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- pmap_enter_quick() at pmap_enter_quick+0x1d4 Ugh, this is probably the real bug. :( Can you do a list on this address? (kgdb) l *pmap_enter_quick+0x1d4 0xfc52c314 is in pmap_enter_quick (../../../alpha/alpha/pmap.c:2422). 2417pmap_insert_entry(pmap, va, mpte, m); 2418 2419/* 2420 * Increment counters 2421 */ 2422pmap-pm_stats.resident_count++; 2423 2424/* 2425 * Now validate mapping with RO protection 2426 */ (kgdb) I hope this makes sense. I still hope to catch a dump. Or alternatively I hope it get's caught by ddb. Does anyone already knows the reason? If not I will take a look into tomorrow. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
