Re: __BSD_VISIBLE and u_int
Hmm, which of these defines claims posix src? -D_ANSI_SOURCE ? cc -O -c -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -I./../include [...] u_int is undocumented and unportable, so it probably shouldn't be used. It's only 3 characters shorter than `unsigned' anyway. It's for ports. And this is once a again a good example why we _really_ need a define (like Solaris'__EXTENSIONS__ ) that sets __BSD_VISIBLE (no matter what) and could be set in CONFIBURE_ENV. Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48683/pgp0.pgp Description: PGP signature
Re: sys/file.h and POSIX
may != MUST. We do not pollute the name space. Providing additional facilities pollutes the name space, breaking strictly conforming programs. Hmm, I can't see why a __EXTENSIONS__ (like Solaris has) would break posix confirming programms. But, it would help for eg. autoconf third-party apps which set POSIX_C_SOURCE. Instead of changing other peoples code, I just could do: setenv CFLAGS -D__EXTENSIONS__=1 ./configure It would be only a little change to sys/cdefs.h and wouldn't break anything. Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48424/pgp0.pgp Description: PGP signature
sys/file.h and POSIX
Hi!
While compiling some third-party code I got this:
gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600
-D_XOPEN_SOURCE_EXTENDED=1 test.c
In file included from test.c:2:
/usr/include/sys/file.h:130: syntax error before u_int
This makes me wonder a bit.. Shouldn't the header at least be includeable ?
Eg. setting __BSD_VISIBLE around xfile ?
Test source:
#include sys/types.h
#include sys/file.h
int main() {
return 0;
}
Regards,
Marc
Premature optimization is the root of all evil. -- Donald E. Knuth
msg48345/pgp0.pgp
Description: PGP signature
Re: sys/file.h and POSIX
Why are you specifying a standard and then using features outside its scope? Either you want a BSD environment (in which case don't specify The standard is specified to get the standard functions. Eg. if i specify _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the OS supports POSIX. This doesn't mean that I don't want rpc. This means that I need to change third party code, which needs POSIX functions, not to declare POSIX/POSIX_C_SOURCE/XSI to get BSD/other functions (and inderectly the POSIX 200112 functions). Since it isn't that way on any UNIX (at least I know about) vendors are forced to do special treatment for FreeBSD. Which is IMHO really bad and may lead to less support for FreeBSD. a standard), or you want a standard environment (where file.h doesn't exist). Indeed what you are trying to do is unsupported. IMHO this is bad and breaks compilation of much third-party code. For details on how to write a conforming application see section 2.2 of POSIX.1-2001. I've read/looked at the standard (see my posting to standards@) and I don't think it forces FreeBSD's behaviour. I even think FreeBSD's behaviour isn't the spirit of the standard. Best regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48356/pgp0.pgp Description: PGP signature
Re: sys/file.h and POSIX
A conforming application cannot make use of facilities outside the scope of the standard. This means that if you define _POSIX_C_SOURCE=200112L you don't want RPC. I don't said that the application is _strictly_ POSIX conforming. It only wants to use POSIX functions and RPC. FreeBSD's way seems to be not to define POSIX/XSI (and so) on to _indirectly_ get it and the BSD stuff 4.4BSD (and earlier?) and most derived systems have many conditionals to prevent namespace pollution in the standards-case. But more in a kind of aggregation like I want this and that (POSIX and stuff..). So why do we do this? To prevent screwage of perfectly valid applications that use the same keywords as system extentions to the standard. For instance, the major() macro in sys/types.h is a very common and likely to be used word, so it is not defined in the standards case to prevent POSIX applications that define a different major() macro from failing to compile. Hmm. The questions what makes more problems.. Maybe a solution could be to make a supported way to change the __BSD_VISIBLE from the outside. Another idea would be to make a WANT_STRICT_POSIX. Not really. Conforming applications have no trouble (obviously), pseudo-conforming applications only need a little work (removing bogus POSIX keywords that specify conformance), and non-conforming BSD applications (the majority of software) have no problems. I had this in mind. http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html: A conforming implementation shall meet all of the following criteria: [...] 4. The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application ). So, defining POSIX should guarantee that a strictly POSIX conforming runs/compiles correctly. But not that a non-strictly POSIX conforming application won't. FreeBSD's behaviour is consistent with BSD's behaviour. No. Eg. the rpc example works out-of-the-box on NetBSD 1.6. And only a _very_ small part of the UNIX world is BSD. Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48359/pgp0.pgp Description: PGP signature
Re: mozilla-devel port on current
mozilla-devel port fails to build on current. I would imagine this is already known, but I haven't seen any posts on the mailing list. ign -Wno-long-long -O -pipe -march=pentium4 -pipe -DNDEBUG -DTRIMMED I'd bet that -march=pentium4 is your problem. Try with -march=pentiumpro (the default). Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
-march=pentiumpro is not the default, -mcpu=pentiumpro is. Anyway, I Nope, -march=pentiumpro is added, if the CPUTYPE is i686 (the default). At least if I had read examples/etc/make.conf and bsd.cpu.mk correctly. doubt this is the cause of the problem. It's more likely to be a stale dependency. Hmm, IMO it's the optimizer: jsdtoa.c:1874: this is the insn: (insn 1797 1796 1798 (set (reg:CCNO 17 flags) [...] Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
The CPUTYPE is not i686 by default. Stupid me... Of course, you're right. Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
There is no default CPUTYPE. If there is no CPUTYPE, and you are on i386, -mcpu=pentiumpro gets added (top of bsd.cpu.mk). Oops! Yes, you're right. I think I got confused by the #CPUTYPE?=i686 in the example make.conf. Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X11/panic after today's cvsup
Hi! After cvsup I got this: kernel: recursed on non-recursive lock (sleep mutex) vm page queue mutex @ ../../../i386/i386/pmap.c:928 kernel: first acquired @ ../../../vm/vm_map.c:2077 kernel: panic: recurse kernel: kernel: syncing disks, buffers remaining... panic: bremfree: bp 0xd359a250 not locked kernel: Uptime: 6m15s kernel: pfs_vncache_unload(): 3 entries remaining kernel: Dumping 1535 MB kernel: ata0: resetting devices .. $FreeBSD: src/sys/vm/vm_map.c,v 1.273 2002/12/01 18:57:56 alc Exp $ $FreeBSD: src/sys/i386/i386/pmap.c,v 1.375 2002/12/02 04:54:21 alc Exp $ Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X11/panic after today's cvsup
Can you say something more about how you produced this? Were you shutting down your X server? It happens right after startx. In any case, the attached patch should resolve this. Thanks I'll try that. Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X11/panic after today's cvsup
In any case, the attached patch should resolve this. Yes, works. Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acquiring duplicate lock of same type: pcm channel
Hi! I'm seeing this lately: acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 $FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.80 2002/11/26 18:16:27 cg Exp $ Marc Premature optimization is the root of all evil. -- Donald E. Knuth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH - changing libc_r to use *context()
I'd like some feedback on whether some heavy threaded apps (GNOME, OpenOffice, Java, etc) have any problems with this patch before asking re@ for commit permission. BTW, it also needs testing on alpha. I tried it on i386 (athon-xp) and every app I've tried stalled/locked or crashed right away. Mozilla gives me: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 4773 error_code 2 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) gnome-cd: (gnome_segv:60260): Gdk-CRITICAL **: file gdkpixbuf-render.c: line 190 (gdk_pixbuf_render_to_drawable): assertion `src_x = 0 src_x + width = pixbuf-width' failed xchat2: (xchat:60267): Gtk-CRITICAL **: file gtkprogress.c: line 550 (gtk_progress_set_percentage): assertion `percentage = 0 percentage = 1.0' failed I've recompiled the ports (and stuff they depend on) before I tried them. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH - changing libc_r to use *context()
Damn, I think I found a problem. Perhaps it might be what's causing your problem. Do you have I686_CPU defined in your kernel? If so can you either try it with a kernel without I686_CPU or with CPU_DISABLE_SSE? Yes, I've I686_CPU and CPU_ENABLE_SSE in my kernel. Trying it without could take a while, because everything is also compiled with -march=athlon-xp.. The kernel doesn't align the FPU registers (context) properly. Actually, neither does anything in userland because the machine contexts lack align directives. You can also try modifying the patched uthread_kern.c, function _thread_kern_sched(). There's a section about halfway down that looks something like this: [..patch] That didn't work (no difference). Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in latest pmap.c
Hi! I got this with the latest pmap.c Nov 23 17:43:07 leeloo kernel: panic: mutex vm page queue mutex not owned at ../../../i386/i386/pmap.c:1881 Nov 23 17:43:07 leeloo kernel: Nov 23 17:43:07 leeloo kernel: syncing disks, buffers remaining... panic: bremfree: bp 0xd359d584 not locked Nov 23 17:43:07 leeloo kernel: Uptime: 9m10s Nov 23 17:43:07 leeloo kernel: pfs_vncache_unload(): 2 entries remaining * $FreeBSD: src/sys/i386/i386/pmap.c,v 1.371 2002/11/23 04:48:13 alc Exp $ Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in latest pmap.c
Can you re-cvsup and update just to make sure everything is current? I did cvsup everything. Every place that pmap_remove_all() is called appears to hold the page queue mutex. The only exception is long-broken code that is compiled under ENABLE_VFS_IOOPT. ENABLE_VFS_IOOPT (vfs.ioopt=1) was the problem. Turning it off fixed it. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
There is neither a gcc 3.2.1 nor a gcc 3.3 yet, so I would't use any of them in a stable release. In fact, there is a gcc 3.2.1 release. And it seems that 3.2.1 pre-release will be the compiler for 5.0R. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
What does it do for all the other code in -ports, and in the comp.source.* archives, and that anyone else has ever written, such that you know it doesn't cause more problems than it solves? I don't think that the system cc is supposed to compile all code ever written. IMHO It should compile the system (and the port versions of gcc) - not more not less. Supposedly, bringing in 3.2 was going to solve more problems than it caused. It turns out the 4.x compiler, GCC 2.95.3, also does not have an ICE as a result of compiling that code. The problem with the ports is mostly badly written C++ code. Since most (all?) Linux distributions are using gcc 3.2.x by now I'm quite sure it will be fixed over the time.. When you are updating tools, it's actually about risk/reward; the risk of not supporting IA64, and the risk of the object file compatability has (supposedly) be addressed. The question is, how big is the Step from a Nov. pre-release to the release version of gcc 3.2.1. The only other reasonable path would be to tie FreeBSD releases to GCC releases, plus some period of time for burn-in, and that really isn't reasonable: 3.3 was supposed to be out already; should FreeBSD's release schedule slip every time GGC's slips? IMHO it would be a big mistake to tie FreeBSD releases to GCC releases. And going for the latest and greatest isn't an option, too. This time it could just fit. I'm wondering if I should mention the new binutils.. :) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
It's a new import, and a complete regression test. Talk to the maintainer: he's already made his statement, and you arguing with I'm fine with it. In fact, I don't if I would be the gcc mainter if I would import it. Probably not I guess.. me because I was willing to stand up and reiterate what he said in shorter sentences won't make him change his mind, I think. 8-). No, I'm arguing with you, because you said it's _that big_ deal.. :) I fell in love with FreeBSD because of the ports. And we've some nice CC's (like icc) in the ports. As long as the system cc compiles the system, I'm happy. :-) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
malloc(0) broken?
Hi! A malloc(0) returns always 0x800 on my system. This causes some third-party software to fail, because they expect malloc(0) to return NULL. Is this a bug or a feature? malloc(3) doesn't mention anything. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc(0) broken?
Feature in malloc and bug in third-party code. C99 says: [..] Thanks! Then I'll try to change it in the third-party app... Also see the V flag listed in malloc(3). Nice. Maybe I just make it my system's default.. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Hard-locks with Linux emulation
Hi! While using Mulberry (mail/mulberry) the system often locks up completely. Nothing but reset helps then. I don't get any error (WITHNESS* is on). Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
There is neither a gcc 3.2.1 nor a gcc 3.3 yet, so I would't use any of them in a stable release. gcc 3.2.1 has been uploaded on ftp.gnu.org at Nov. 19th. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc 3.2.1 release import?
Hi! Will gcc 3.2.1/release be imported before 5.0R ? Just curious.. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
addition to cdefs
Hi! I've made a small patch to make it possible to enable BSD extensions although _POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE has been defined. This is made with a new define _BSD_SOURCE right after the XOPEN_SOURCE handling. It sets __XSI_VISIBLE 600 and __BSD_VISIBLE 1. This is needed for some programs. For example for Python 2.3cvs sets (among others) _POSIX_C_SOURCE 199506L, but also expects to have chroot and friends. Regards, Marc --- cdefs.h.origTue Oct 22 11:44:42 2002 +++ cdefs.h Mon Nov 11 12:47:49 2002 -333,6 +333,12 #endif #endif +/* Allow BSD extensions to POSIX. */ +#if defined(_BSD_SOURCE) (defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)) +#define__XSI_VISIBLE 600 +#define__BSD_VISIBLE 1 +#endif + /* * Deal with all versions of POSIX. The ordering relative to the tests above is * important.
Re: addition to cdefs
Thanks! It looks like unistd.h has some XSI bugs. Is _XOPEN_SOURCE defined anywhere? If so, try the attached patch. If not, this is a bug in Yes, _XOPEN_SOURCE is defined. So, it solves some of the problems. Python (since POSIX doesn't specify chroot()) and should be fixed at their end and in the ports collection. But, there still some problems left. Like fd_set being not defined in sys/select if _BSD_VISIBLE isn't given. _BSD_SOURCE provides mostly the same visibility as not defining any standards constants, so it isn't very useful. IMO it would be nice to have a clean way to toggle __BSD_VISIBLE from the outside. In the default environment I have #define __POSIX_VISIBLE 200112 #define __XSI_VISIBLE 600 #define __BSD_VISIBLE 1 #define __ISO_C_VISIBLE 1999 But, Python for example, wants _POSIX_C_SOURCE 199506,_XOPEN_SOURCE 500 _and_ __BSD_VISIBLE 1. I know, I could also just do a -D__BSD_VISIBLE=1, but I think thats not The Right Thing to do. Regards, Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: addition to cdefs
I've had the attached patch in my tree for a while. I'll try and get it and the unistd.h patch committed today. Thanks! This solves some problems, but there are some left. Mostly socket and rpc related. For example PF_INET and friends are undefined.. The whole point of the standards constants is to specify a strict environment. If you want a BSD environment don't specify a particular standard, it's simple. I'm thinking more of it like an aggregation. IMHO it should be possible, if the user wants to, to get POSIX 199506 and BSD. Regards, Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: HEADS UP: you need to install a new kernel before aninstallworld.
Nearly all GNOME applications crash with an Abort trap error, and the only way I can log out is to restart the X server. Nautilus is particularly evil because it can get into a situation where it crashes, restarts itself, and crashes again--repeating the process indefinitely. I'm running GNOME 2 with kernel and userland of today without any problems. The only problem I have since the KSE MIII merge that I can't build librep. It stalls while compiling it's lisp files. (It hangs in mi_switch()..) Even GNOME 1.4 apps like Evolution are working. With no more info, I'd prolly advise you to update everything to the latest, and if problems persist, rebuild your GNOME stuff, and if problems persist, throw exception... I may do so if backing off freetype2 doesn't fix things. IMHO you should run a full portupgrade.. -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: Another 'buildworld' showstopper
With sources few minutes old (as well as with sources approx. 3h old): === gnu/usr.bin/groff/tmac /usr/src/gnu/usr.bin/groff/tmac/Makefile, line 2: warning: duplicate script for target -s ignored [... 12 times repeated] make: don't know how to make doc-common-s. Stop *** Error code 2 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src. *** Error code 1 You have to rebuild and install make first. Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: New 5.0 ports uploaded
On Sa, 2002-10-19 at 22:36, David W. Chapman Jr. wrote:
Hmm, I've more broken ports on my system.. Like a trouble with net/samba-devel
(because of PAM headers) and I can't compile lang/librep since KSE III.
Are you still having problems with this. If you could show me some
errors I may be able to relay them to the samba developers for you
unless this is something wrong with freebsd.
Yes, I need the attached patch to compile nsswitch/pam_winbind.c.
I'm compiling net/samba-devel with following parameters:
WITH_CUPS=yes WITH_QUOTAS=yes WITH_UTMP=yes WITH_MSDFS=yes
WITH_WINBIND=yes WITH_ACL_SUPPORT=yes WITH_WINBIND_AUTH_CHALLENGE=yes
Marc
--
Premature optimization is the root of all evil. -- Donald E. Knuth
--- nsswitch/pam_winbind.c.orig Thu Sep 26 23:17:53 2002
+++ nsswitch/pam_winbind.c Thu Sep 26 23:19:30 2002
-286,10 +286,10
item = NULL;
return PAM_SUCCESS;
} else if (on(WINBIND_USE_FIRST_PASS_ARG, ctrl)) {
- return PAM_AUTHTOK_RECOVER_ERR; /* didn't work */
+ return PAM_AUTHTOK_RECOVERY_ERR;/* didn't work
+*/
} else if (on(WINBIND_USE_AUTHTOK_ARG, ctrl)
off(WINBIND__OLD_PASSWORD, ctrl)) {
- return PAM_AUTHTOK_RECOVER_ERR;
+ return PAM_AUTHTOK_RECOVERY_ERR;
}
}
/*
-342,7 +342,7
if (!resp[i - 1].resp
|| strcmp(token, resp[i -
1].resp)) {
_pam_delete(token); /*
mistyped */
- retval =
PAM_AUTHTOK_RECOVER_ERR;
+ retval =
+PAM_AUTHTOK_RECOVERY_ERR;
_make_remark(pamh
,PAM_ERROR_MSG, MISTYPED_PASS);
}
}
-361,7 +361,7
} else {
retval = (retval == PAM_SUCCESS)
- ? PAM_AUTHTOK_RECOVER_ERR : retval;
+ ? PAM_AUTHTOK_RECOVERY_ERR : retval;
}
}
signature.asc
Description: This is a digitally signed message part
Re: New 5.0 ports uploaded
A new set of 5.0 packages has been uploaded and is making its way out to mirror sites. I will soon be sending out mail to all maintainers of broken ports asking for submissions of fixes (or at least reporting the breakage to the relevant vendors). Hmm, I've more broken ports on my system.. Like a trouble with net/samba-devel (because of PAM headers) and I can't compile lang/librep since KSE III. (Yes, I rm -rf'ed my /usr/include after the gcc check-ins and recompiled all other ports.) Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: X problems 5.0... -RELEASE?
Note that during these, mp3s keep playing, gtk-gnutella keeps downloading things, etc., it seems X just isn't updating the display... Even a resize But, it's not always so. For me most of the time everything stops. Including playing mp3s/oggs, resizing windows and so on. And after some time just restarts/continues.. of a sizable gtk frame I did while it was frozen took affect when it unfroze... Have you tried loggign into a system during such a freeze to see if it's sleeping or such? I would, except ENOSPAREBOX and if I try to switch to a console the screen getsd this black-and-green wooshy colour and then it sticks there. Switching to the console also doesn't work for me in these situations. But I can't login via SSH and reboot the box. Marc -- Premature optimization is the root of all evil. -- Donald E. Knuth signature.asc Description: This is a digitally signed message part
Re: Ready to connect libbsdxml (nee libexpat) to the build !
What was the concensus on the xmlwf program, did we want it in the tree or not ? Would it be useful to anybody or is it just a hackers-proof-of-concept thing ? IMO we don't need it. It only checks if an XML document is well-formed. It even doesn't check if it's valid. I don't think we need a tool like that in the base-system, there are much better tools in the ports-tree. Marc msg43902/pgp0.pgp Description: PGP signature
Re: expat2 in the base system?
Any famous last words before the fat lady sings ?
I think we should go for it. :)
Well, playing the devil's advocate -- isn't this the type of discussion the
preceeded the introduction of Perl into the base system, the introduction of
which created such a mess that we finally took Perl out of the base system
in -CURRENT?
But expat is only one header and one lib. (IMO xmlwf shoudn't be in the base system.
Anyone who needs it should install the expat port..)
Now I realize that expat is much less complicated than Perl, but have we
fully addressed interoperability concerns? I know that the /usr vs
${LOCALDIR}distinction between the base system and ports fixes most of them,
at least for experienced users.
My biggest concern is the minority of users installing expat2 from
ports/packages and then not being able to figure out how to use it, since
they always get expat1 since /usr/bin comes before /usr/local/bin in $PATH.
There's no bin. (Except the uneeded xmlwf..)
I'm sure there will also be issues with autoconf-based ports that don't do
proper version checking of libraries which will pick up static libs /
headers from /usr instead of /usr/local as well.
If we rename the lib and the header there shouldn't be a problem.
(But there also woudn't be a problem if it's called expat and we keep the version
up-to date... IMO if it is expat - it should be called expat. But I could also live
with an expatXYZ..)
Marc
msg43826/pgp0.pgp
Description: PGP signature
expat2 in the base system?
Hi! I just saw the import of expat 1.95.5 into the base system. And because expat2 is such a moving target I'm a little bit wondering why this did happen. Isn't it better to keep such a beast in the ports-tree? Or is there a major config-file to xml rewrite (or something similar) going on nobody told us users about? :-) I'm a little bit confused and excited at the moment.. :-) Marc msg43733/pgp0.pgp Description: PGP signature
Re: expat2 in the base system?
Rather than write another monster filled with weird structs and enums I decided that ASCII is very extensible, and putting XML structure on top of it meant that readily available libraries and tools could work on it. Yes, it's IMHO the best way to do it. And in fact, I have every reason to believe that it takes less code in the kernel to construct XML with sbuf's than it takes to pack everything in and out in a way which is properly versioned and all that hair. So, I need an XML parser in the userland side of things. No, that it's there maybe other tools could (slowly) start using it. (NB: XML flows from the kernel to userland, not the other way!) Maybe sometime.. :-) [...] I've sent many emails to try to get peoples attention to this subject, but nobody has really expressed much of an interest, but maybe now that it is a more tangible issue that will change. I didn't see any message. After your commit, I made a quick glance through my archives current, hackers and arch ... I have not connected libexpat and xmlwf to the build yet, so nobody will be screwed in any way until we do so. There are two ways this can be done, and I don't really have a preference: 1. Under the name libexpat, in full flying colours. This means that we are obligated to track the official libexpat rather closely and ports will use the in-tree version instead of the ports version. I would go/vote for that. If it's expat then call it expat. Everything else is confusing.. [..] Remembering the perl fiasco[*], I have tried for quite some time to see if anybody had any good input on this, and nothing very conclusional has emerged from any corner. In any ml? I don't plan to commit the next stuff which depends on the existance of this library this for another couple of weeks, so this is your chance to test it out: Here is the patch which connects libexpat in the tree in fashion 1 above. Hmm, with 5.0R in about six weeks wouldn't it be good to build and install the library asap ? Let me know how much it breaks. We'll see. I've some stuff which depends on expat2 (python, apache2, ..) But: No risk - no fun. -:) Marc msg43738/pgp0.pgp Description: PGP signature
Re: expat2 in the base system?
2. Under assumed name, libxmlread or something. This means that nothing which doesn't explicitly ask for it will get in touch with this version of libexpat, and that will only be the programs in the tree. We don't need to track the official libexpat (sort of like the DB(3) situation, except with better isolation I guess). This seems to be a nice idea. Can you trim down our version of expat to only the libxmlread part or so? This way we don't get too much bloat, the perl fiasco won't happen, and once we've got a working version we can update only for bug fixes. IMO 1. would be better with a complete expat. So the ports could use the system version and probably/maybe the drift between the official- and system-version will not be that big. And compared to Perl expat it rather small. So the bloat couldn't be that big.. Marc msg43745/pgp0.pgp Description: PGP signature
could not sleep with... and lock order reversal
Hi! I always get a bunch of .. could sleep with... and lock order reversal messages. There appear in various parts of the kernel.The locks: pcm, xl, drm. The reversals: spec_vnops, vfs_subr, if_xl, sys_pipe. And this was only a quick glance through the logs. IIRC these are considered harmful (possible panics?). But I'm not quite shure if there's any interest in posting them here.. What is the right way to deal with it? Ignore, post here, send to the maintainer, file a PR ? Marc msg43658/pgp0.pgp Description: PGP signature
Re: panic: lockmgr: locking against myself
While local package initilization I get a panic. World and kernel from today. This I found in messages: Sep 30 15:49:55 leeloo kernel: panic: lockmgr: locking against myself This problem is gone with today's kernel. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself
Hi! While local package initilization I get a panic. World and kernel from today. This I found in messages: Sep 30 15:49:55 leeloo kernel: panic: lockmgr: locking against myself Sep 30 15:49:55 leeloo kernel: Sep 30 15:49:55 leeloo kernel: syncing disks... panic: bremfree: bp 0xd381a080 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: Dumping 1535 MB Sep 30 15:49:55 leeloo kernel: ata0: resetting devices .. Sep 30 15:49:55 leeloo kernel: panic: bremfree: bp 0xd3886870 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized The hand-written tr: panic: lockmgr: locking against myself lockmgr vm_map_lookup vm_pfault trap_pfault(18,10,10,0,2e) call trap Please let me know if (and how) I could provide more info. Marc msg43608/pgp0.pgp Description: PGP signature
GEOM panic in current kernel
Hi! After the latest geom_* commits I get a panic while booting. The panic occurs before mounting the disks, so I had to hand-write it down.. panic.. mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f ... g_up_procbody + 0x34 ... Please let me know if/how I could provide more info. Marc msg43545/pgp0.pgp Description: PGP signature
Re: GEOM panic in current kernel
After the latest geom_* commits I get a panic while booting. The panic occurs before mounting the disks, so I had to hand-write it down.. panic.. mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f ... g_up_procbody + 0x34 ... Wow! That was a fast reply. :-) Uhm, what was the actual panic message ? mutex g_up 0xe0499cb8 already initialized Marc msg43549/pgp0.pgp Description: PGP signature
Re: GEOM panic in current kernel
Uhm, what was the actual panic message ? mutex g_up 0xe0499cb8 already initialized Can you try this patch ? Works great! Thanks! Marc msg43552/pgp0.pgp Description: PGP signature
Kernel weirdness..
Hi! I've some very weird problems with yesterday's -current. For some TCP/IP related operations it just plain reboots (== resets _without_ panic). I could 100% reproduce this phenomena with p4 depot xyz and cvs commit. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic
My latest panic.. Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:696 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:696 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:748 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:748 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:673 Sep 25 11:49:40 leeloo kernel: acquiring duplicate lock of same type: inp Sep 25 11:49:40 leeloo kernel: 1st inp ../../../netinet/udp_usrreq.c:288 Sep 25 11:49:40 leeloo kernel: 2nd inp ../../../netinet/udp_usrreq.c:288 Sep 25 12:05:19 leeloo syslogd: kernel boot file is /boot/kernel/kernel Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: Fatal trap 12: page fault while in kernel mode Sep 25 12:05:19 leeloo kernel: fault virtual address = 0x4 Sep 25 12:05:19 leeloo kernel: fault code= supervisor read, page not present Sep 25 12:05:19 leeloo kernel: instruction pointer = 0x8:0xc020acd2 Sep 25 12:05:19 leeloo kernel: stack pointer = 0x10:0xe8c64678 Sep 25 12:05:19 leeloo kernel: frame pointer = 0x10:0xe8c6467c Sep 25 12:05:19 leeloo kernel: code segment = base 0x0, limit 0xf, type 0x1b Sep 25 12:05:19 leeloo kernel: = DPL 0, pres 1, def32 1, gran 1 Sep 25 12:05:19 leeloo kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Sep 25 12:05:19 leeloo kernel: current process = 39662 (vim) Sep 25 12:05:19 leeloo kernel: trap number = 12 Sep 25 12:05:19 leeloo kernel: panic: page fault Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: syncing disks... panic: bremfree: bp 0xd381a080 not locked Sep 25 12:05:19 leeloo kernel: Uptime: 2h22m51s Sep 25 12:05:19 leeloo kernel: pfs_vncache_unload(): 1 entries remaining Sep 25 12:05:19 leeloo kernel: Dumping 1535 MB Sep 25 12:05:19 leeloo kernel: ata0: resetting devicesannel.c:6Copyright (c) 1992-2002 The FreeBSD Project. leeloo# nm kernel.debug | grep c020ac c020ac70 T __setugid c020ac80 T groupmember c020acc0 T suser_cred Please let me know if I could do something to provide more details. I've a kernel.debug file around. BTW, a coredump wasn't written to the disk though there's enough space available. Is there problem with that in current -current? Marc msg43373/pgp0.pgp Description: PGP signature
smbus, geom or ufs attr break the kernel
Hi! Something checked-in yesterday broke the kernel badly.. Some of these options or a combination of these break the kernel badly. If they're activatet then not all devices are created by devfs (ttv* is missing..). Even without devfs ttv* isn't working... Commenting this out of my config fixed the prob for me. options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL options GEOM device smbus# Bus support, required for smb below. device viapm device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge Marc msg43315/pgp0.pgp Description: PGP signature
Re: smbus, geom or ufs attr break the kernel
options UFS_ACL This is a major suspect. Have you read what it does ? Of course. It has been working for weeks.. options GEOM This I can almost guarantee you, is not the culprit. You're right. The smbus/ic/iic/iicsmb stuff is what breaks the kernel for me. Marc msg43321/pgp0.pgp Description: PGP signature
Re: smbus, geom or ufs attr break the kernel
That's an odd set of things to have break in concert. The UFS options should not affect devfs at all. That said, your best bet is probably to turn off sets of related options until you figure out what the source is. Obvious candidates would be to turn off the UFS options as a set, GEOM, and then the smbus support, and see what makes things work again. I did and it's the smbus/ic/iic/iicsmb stuff what breaks the kernel for me. Maybe it was the commit by Nicolas Souchu (smbus.c 1.16). Marc msg43322/pgp0.pgp Description: PGP signature
World broken in ncurses ?!
With -current sources as of today: cc -O -pipe -march=athlon-xp -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c lib_keyname.c -o lib_keyname.o lib_keyname.c:7: `KEY_A1' undeclared here (not in a function) lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0].code') lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0]') lib_keyname.c:8: `KEY_A3' undeclared here (not in a function) lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1].code') lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1]') lib_keyname.c:9: `KEY_B2' undeclared here (not in a function) [...] And so on for every key.. lib_keyname.c:160: (near initialization for `_nc_key_names[153].code') lib_keyname.c:160: initializer element is not constant lib_keyname.c:160: (near initialization for `_nc_key_names[153]') lib_keyname.c:161: initializer element is not constant lib_keyname.c:161: (near initialization for `_nc_key_names[154]') *** Error code 1 Marc msg43179/pgp0.pgp Description: PGP signature
Re: /usr/include/sys/select.h:61: syntax error before fd_set
I'm trying to work out why the latest version of coldsync won't compile on -current, even though it compiles on -stable. I'm getting the compile time error: /usr/include/sys/select.h:61: syntax error before fd_set The coldsync header file looks like: What header am I missing here? sys/types.h (before sys/select.h) Marc msg43187/pgp0.pgp Description: PGP signature
Re: Compiler error XFree86-Server
Yes. But our 5.0-RELEASE is will non-polished; so I think having the
compiler in the same shape is OK if it means we can get bugs fixed and
our needs taken care of.
But it's still a relase. :-)
Many IA-64, and AMD x86-64 bug fixes and improvements aren't merged back
to the 3.{1,2} branch.
Then we we should go for 3.3. You're right. But why don't we import gcc 3.2
in the meantime to fix the currently broken system gcc?
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Compiler error XFree86-Server
system compiler would make bug reports from -CURRENT users even more useful. Indeed. IMHO going to 3.2 is the best we could do. IMO going to 3.3 would be much better -- we can actually get our needs better addressed as the compiler is still in development, but about to head into code slush. We cannot affect GCC 3.2.1 too much due to it being on a release branch, and point release. But the GCC 3.3 release is targeted after 5.0-RELEASE (for Dec 15). And GCC 3.3.1 for Feb 15 2003. Using a pre-release compiler in a release version is IMHO somewhat risky. gcc 3.2 is scheduled for early August, so there's time enough to import and test it. Maybe even for 3.2.1. And the C++ ABI breakages/fixes will hapen with the 3.2 release... Just my 0.02ยค Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiler error XFree86-Server
You might want to try the attached code-snippet I grabbed from the gcc GNATS. It manages to ICE 3.1 and 3.2 with a lot of optimizations, including pentium2/3/4 and athlon-* and is believed to trigger the same bug that borks XFree86 here. XFree works fine (for me) with -O -march=athlon-xp (since days now). Compile with gcc -O -march=arch -c clacrt.c Yeah, this triggers the bug. :-) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiler error XFree86-Server
Because chances are good that the bugs still aren't fixed. I reported a bug related to optimization with -march=athlon recently and the reply If you've got a newer Athlon (XP) then you could compile it with -march=athlon-xp. I've filed a PR with a patch against bsd.cpu.mk (misc/41425) recently. I've got suggests that it's still present in all branches. I get the impression that not too many people really use gcc3 with heavy optimization on big stuff like XFree86 yet ... Of course, updating the XFree86 works like a charm built with -march=athlon-xp . system compiler would make bug reports from -CURRENT users even more useful. Indeed. IMHO going to 3.2 is the best we could do. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mysql-3.23.51 with Current for the last few weeks.
I really don't know where to start looking. Just after the KSE changes at the beginning of July I upgraded mysql. Since then I have had intermittent problems with mysql hanging far too often. It takes 100% of the resources and has to be killed. I get no errors in the mysql log nor in the system logs. This isn't only a mysql problem. The (at least) linux jdk 1.4, jikes and lt_rep (used by librep while building) have the same problem. They're just using CPU time and are doing nothing... (dead-lock?) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mysql-3.23.51 with Current for the last few weeks.
On Fri, 2 Aug 2002 10:08:47 -0700 (PDT) Julian Elischer [EMAIL PROTECTED] wrote: there are several possibilities: 1/ do a ktrace on teh spinning process for a couple of seconds and see what syscalls it is doing. stopped jikes with ctrl-c looks always like: 90998 sh RET read 650/0x28a 90998 sh CALL fork 90998 sh RET fork 91009/0x16381 90998 sh CALL getpgrp 90998 sh RET getpgrp 90998/0x16376 90998 sh CALL wait4(0x,0xbfbff498,0x2,0) 90998 sh RET wait4 -1 errno 4 Interrupted system call 90998 sh PSIG SIGINT caught handler=0x80595b0 mask=0x0 code=0x0 90998 sh CALL sigreturn(0xbfbff2b8) 90998 sh RET sigreturn JUSTRETURN 90998 sh CALL wait4(0x,0xbfbff498,0x2,0) 90998 sh RET wait4 91009/0x16381 90998 sh CALL read(0xa,0x80f6e80,0x3ff) 90998 sh GIO fd 10 read 0 bytes 90998 sh RET read 0 90998 sh CALL exit(0x82) 2/ if it's spinning in the kernel, you can drop into ddb and do a tr pid to see where it is in the kernel... c to continue.. I always get these two: Debugger(manual escape to debugger) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db tr 3402 mi_switch(c30f36c0,c01f23e8,c30f5cc0,f13c8d3c,c0237b5e) at mi_switch+0x15a ithread_schedule(c30dd500,1,f13c8d3c,c79309c0,0) at ithread_schedule+0x11f sched_ithd(5) at sched_ithd+0x43 Xintr5() at Xintr5+0x67 --- interrupt, eip = 0x80decb0, esp = 0xbfbfe4e0, ebp = 0xbfbfe548 --- db c mi_switch(c30e3d40,0,5,0,800) at mi_switch+0x15a ast(f16ddd48) at ast+0x35a doreti_ast() at doreti_ast+0x1a do this several times to ge a sortof 'profile' of where you see it.. Done that. Hope this helps. Please let me know if I could do more to find this problem. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
system hangs/reboots
With -current of today the system resets (without syncing discs) when mozilla is started. This happens everytime when mozilla is started. Other X apps like Sylpheed or mplayer seem to work correctly. zero copy sockets are not turned on and it didn't happen with -current as of a week ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
I started getting unexpected lockups during mozilla sessions after remaking world kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. For the kernel that works, what version of src/sys/kern/subr_mbuf.c did you build it from? I just want to make sure that I didn't break it with any of the changes I've made. My last change was on 2002/07/24 15:11:23 so I don't think it's that, but just to make sure... I've exactly the same problems. My subr_mbuf.c is: * $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.23 2002/07/24 15:11:23 bmilekic Exp $ (cvsup'ed today) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
That's not what I was asking for. He mentionned he had a kernel from the 25th that was working and I wanted the version of subr_mbuf.c that he had used to build _that_ kernel. Oh, sorry. IIRC then (for me) everything worked just fine with r1.22. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mysterious dead-locks with system ssh
I'm getting strange dead-locks/complete lookups when I use the system ssh with port forwarding. Using something like: ssh -L8080:remote:8080 account@remote to forward a remote apache to my local box. When I access http://localhost:8080/ not later than the third click on link (or pressing reload) my box locks up completely. I don't even get into the debugger or get a crash dump. The box is just plain dead. Though normal SSH works perfectly and accessing a local (not forwarded) apache works, too. The world and kernel is of today and IIRC this actually did work last week (or the week before). I've found the reason for this dead-lock. I had turned ZERO_COPY_SOCKETS on. ESound/zero_copy_sockets causes the same dead-lock... Marc msg41231/pgp0.pgp Description: PGP signature
makeinfo broken ?
Hi! Of late I'm getting a signal 10 in makeinfo for numerous ports (eg. gcc31, semantic) and other non-port sources. And IIRC have been able to build the gcc31 port six weeks ago without any problems. world and kernel are of yesterday. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mysterious dead-locks with system ssh
Hi! I'm getting strange dead-locks/complete lookups when I use the system ssh with port forwarding. Using something like: ssh -L8080:remote:8080 account@remote to forward a remote apache to my local box. When I access http://localhost:8080/ not later than the third click on link (or pressing reload) my box locks up completely. I don't even get into the debugger or get a crash dump. The box is just plain dead. Though normal SSH works perfectly and accessing a local (not forwarded) apache works, too. The world and kernel is of today and IIRC this actually did work last week (or the week before). Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
_waitq_remove
While running (newly build) Xine I get following error: Fatal error '_waitq_remove: Not in queue' at line 350 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) Is this an outstanding KSE issue or a problem of the port itself? Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Do you know when it broke? Sorry, I've built today the first time. But, Christian (previous post) said he has the same problem with -STABLE. So, maybe it's a Xine problem. (Or libc_r is broken on both...) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
I get the same message with xine on -STABLE each time i use it. Xine is simply not very stable on FreeBSD, that's why I'm using mplayer now Oh. :-) (which has it's own issues on -CURRENT) IIRC then MPlayer doesn't use threads. So, KSE shouldn't be an issue there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openoffice won't compile on -CURRENT [July 7]
/usr/include/sys/stat.h:127: sizeof applied to an incomplete type /usr/include/sys/stat.h:128: sizeof applied to an incomplete type sys/stat.h is broken hat the moment if _POSIX_SOURCE is defined. This breaks many ports (like gcc295, omniORB, ...). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic with today's pmap
Hi! I got this with today's pmap panic: pmap_new_thread: kstack allocation failed Yesterday's kernel works fine. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with today's pmap
what do you call today's ? Oops, sorry.. I know I missed something.. :-) (version #?) src/sys/i386/i386/pmap.c,v 1.331 2002/07/04 00:35:48 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with today's pmap
try a new vm_glue.c as well. ( 1.140) Yes, this works. Thanks! Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ASUS CUSL2 panic on acpi
Here's a me too.. running on an ASUS A7V266-E Fatal trap 12: page fault while in kernel mode fault virtual address = 0x16 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04f9aca stack pointer = 0x10:0xc054ea14 frame pointer = 0x10:0xc054ea34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax I had a movb 0x16(%eax),%al db trace AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at AcpiExReadDataFromField+0x5a With ACPI disabled (hint.acpi.0.disable=1) the kernel runs without a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Post-KSE disaster with libc_r
Can someone please check out a libc_r tree as of 3 days ago and try that... There was a commit in libc_r/uthreads 2 days ago that might be relevant. failing that, can someone try newly compiled utilities on an older pre-KSE kernel? We need to eliminate one of these two changes... I don't know if this helps, but I've a pre-KSE userland (28.06.), a post-KSE kernel (30.06.) and I've none of the described problems. Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Post-KSE disaster with libc_r
MR I don't know if this helps, but I've a pre-KSE userland (28.06.), a MR post-KSE kernel (30.06.) and I've none of the described problems. MR Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. I updated my current box about an hour ago, and got into trouble too. But you've updated the userland _and_ the kernel. I've only updated the kernel and left the userland int the pre-KSE state. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put errors for ports only in current?
where i've to post a error regarding an installed software from ports, which only occurs on current? How about writing the port maintainer ? Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
