Re: HEADS UP: Port recompiles needed (Re: Unknown symbol __sF)

2002-10-13 Thread Terry Lambert
Kris Kennaway wrote: On Sun, Oct 13, 2002 at 10:22:48AM +0200, Hellmuth Michaelis wrote: Had a very bad night after upgrading my main machine from a September-based current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like

Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)

2002-10-13 Thread Terry Lambert
Kris Kennaway wrote: On Sun, Oct 13, 2002 at 04:01:53AM -0700, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK

Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote: On Fri, Oct 25, 2002 at 01:43:57PM -0700, Terry Lambert wrote: It's a moderately common case in -CURRENT, when kernel structure sizes change, and you build a new kernel without new modules, and a module refuses to load. It's not technically correct. The old message

Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote: On Fri, Oct 25, 2002 at 12:35:22PM -0700, Brooks Davis wrote: If someone who actually uses pppd could test it, perferably in both sceneios, I'll see about getting it commited. Here's a new patch that gives the user more of a hint at how to add PPP support and only

Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Terry Lambert
Brooks Davis wrote: This isn't going to have an effect on the ability to use kernel ppp for other things. The tty orientation of pppd and the outdated, unmodular design on ppp(4) have taken care of that. This patch gives people the functionality they want (pppd just working) without any

Re: pppd not working on latest current 2002-10-20

2002-10-26 Thread Terry Lambert
Bakul Shah wrote: Thank you for explicating the security argument! I'll also point out that hardwiring module names makes it harder to experiment with replacement modules (i.e. I may want to develop if_super_duper_ppp). Actually, this isn't an issue (I'm assuming that you want it to be named

Re: Type1 font problem (Was: Re: mozilla-devel problems)

2002-10-26 Thread Terry Lambert
Wesley Morgan wrote: Im my many hours of playing with fonts, I seem to recall that the Freetype / XFT module is perfectly capable of rendering the Type1 fonts. Make sure you take the PATH out of your XftConfig in addition to the XF86Config Some fonts have characters with a zero width, and you

Re: burncd/cdcontrol

2002-10-27 Thread Terry Lambert
Nate Lawson wrote: The problem with making burncd work for SCSI is that it doesn't use the ATAPI interface, instead it implements our own ioctl interface. Currently, the ioctls burncd uses that are missing from cd(4) are: [ ... ] Instead of cutting/pasting those from atapi-cd.c, I think it

Re: libgtop port and v_tag changes

2002-10-28 Thread Terry Lambert
John Baldwin wrote: Yes. This means that you don't need to even look at v_tag to see if it is a UFS vnode or not. What does libgtop want with device and inode numbers anways? Does it actually do anything useful with them or does it just print them somewhere? Is a user going to care if the

Re: libgtop port and v_tag changes

2002-10-28 Thread Terry Lambert
John Baldwin wrote: Sheesh, does anyone actually _use_ libgtop against kernel core dumps? If not then it shouldn't be groveling around in the kernel fondling implementation details. Instead, it should be using stat(2), or at the worst using a sysctl to get xvnode structures. As an

Re: libgtop port and v_tag changes

2002-10-28 Thread Terry Lambert
John Baldwin wrote: I mean, do you know what libgtop is used for? It's used to draw little applets that display load averages and other silly system monitor stuff in small spaces in GUI's. It seems to work quite happily w/o any inode numbers or dev_t's for non-UFS filesystems. I just don't

Re: libgtop port and v_tag changes

2002-10-28 Thread Terry Lambert
John Baldwin wrote: To build little applets that activate a flashing red light when certain files are written? Why do you need the inode number to do that. Just kqueue on the file itself using a regular fd, and in that case you can stat(2) the file if you really need the i-node number.

Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)

2002-10-28 Thread Terry Lambert
Loren James Rittle wrote: I will advise RTH about that type of issue. Fortunately, in this case, I think advertising 53-bit precision but really using 64-bit precision (i.e. application code overrode system default) doesn't invalidate the advertised epsilon, in terms of how it is used by the

Re: make(1) broken!

2002-10-29 Thread Terry Lambert
Juli Mallett wrote: Please test make(1) changes on make release in the future. The standard metric has been 'make buildworld' I thought? Anyway, try with revision 1.2 of var_modify.c, that should do it. Realistically, to prevent any sort of breakage to make(1), we should test make(1) by

Re: gnome on current

2002-10-29 Thread Terry Lambert
Doug Rabson wrote: On investigating one of the crashes more carefully, I discovered that all calls to pthread_*() were being resolved to stubs in libXThrStub.so in spite of the fact that libc_r was also loaded. This caused problems for e.g. flockfile which failed to initialise its mutex

Re: gnome on current

2002-10-29 Thread Terry Lambert
Doug Rabson wrote: When a symbol is defined in multiple libraries, the first library wins. That's how it has always been in Unix, for archive libraries and for shared libraries. This is a big problem then since X11.so links to XThrStub.so. This means that XThrStub will be ahead of

Re: questions about the state of current

2002-10-29 Thread Terry Lambert
Raymond Kohler wrote: I'm now a stable user, and I'm considering moving to current to get a jump on upgrading and help with the testing effort. I have some questions about its performance: 1) How is the speed compared to stable? I remember it being just too slow some months ago and was

Re: gnome on current

2002-10-29 Thread Terry Lambert
Doug Rabson wrote: The point is that with the current setup of the XFree86-4-libraries port, you don't have any choice, since libX11 links to libXThrStub. This is the key problem, IMHO. I have a machine running RedHat 8.0 and they don't have any such thing. On RedHat, libXThrStub doesn't even

Re: Objective-C threads

2002-10-29 Thread Terry Lambert
Chad David wrote: Does anybody know if there is a good reason why libobjc is built with thr-single.c? Historical threads problems. As well, who is the current maintainer of Objective-C? Chad David? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in

Re: Objective-C threads

2002-10-29 Thread Terry Lambert
David O'Brien wrote: On Tue, Oct 29, 2002 at 07:09:41PM -0700, Chad David wrote: Does anybody know if there is a good reason why libobjc is built with thr-single.c? As well, who is the current maintainer of Objective-C? Few of us have ObjC clue. Do you have a patch that makes things

Re: system pauses after deleting large files

2002-10-30 Thread Terry Lambert
Brooks Davis wrote: While moving a large (1GB) file from one parition to another today, I noticed an odd, reproducable pause. Basicly you create a large file somewhere and then delete it like so: [ ... ] Within the next minute or so, I see a pause where the whole system stops for 5-10

Re: speed of -CURRENT [was: questions about the state of current]

2002-10-30 Thread Terry Lambert
Stijn Hoop wrote: I am experiencing a really noticable slower startup time on my very recent -CURRENT laptop for almost all programs. The problem seems to be in getting info in the cache, because it disappears when I start the same program again. It is even noticable when doing a simple 'ls

Re: Objective-C threads

2002-10-30 Thread Terry Lambert
David O'Brien wrote: On Tue, Oct 29, 2002 at 11:52:56PM -0800, Terry Lambert wrote: That said, if you want to make it work for you, I'm behind you 100%: I think any changes you want to make are OK; they can always be backed out, if anyone starts complaining about them breaking things, so

[PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: All you have to do is create a situation where a shared object that links to libc_r is loaded after libX11 and the thing breaks into little pieces. So let's dike out libXThrStub.so, and be done with it. I think the only stub which it defines that libc.so doesn't

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Daniel Eischen wrote: That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the

Re: What's this for ?

2002-10-30 Thread Terry Lambert
Juan Francisco Rodriguez Hervella wrote: I've seen this looking for ISO images of FreeBSD-5.0-DP1: 5.0-DP1-disc2.iso - 5.0 Developer Preview #1 - live filesystem. is it possible to work with this filesystem ? I mean, what can be done ? is it auto-bootable or I need to boot from the

Re: Objective-C threads

2002-10-30 Thread Terry Lambert
Chad David wrote: That said, if you want to make it work for you, I'm behind you 100%: I think any changes you want to make are OK; they can always be backed out, if anyone starts complaining about them breaking things, so I think it's kind of silly for you to ask for permission to

Re: Objective-C threads

2002-10-30 Thread Terry Lambert
Chad David wrote: In your experience, how long is the delay between gcc-patches accepting something and FreeBSD picking it up, ie. is it worth the effort? Jeremey Allison (of SAMBA) and I made patches to ACAP to get it to compile under G++, and that required patches to G++ 2.9.3 to support per

Re: What's this for ?

2002-10-30 Thread Terry Lambert
John Baldwin wrote: It's an installed FreeBSD that is on a CDROM. It depends on your BIOS being able to boot the FS as if it were a hard disk image. Huh? It doesn't do that. If it is bootable, then it boots into sysinstall just like CD #1. What it is useful for is to be used as a

Re: What's this for ?

2002-10-30 Thread Terry Lambert
Terry Lambert wrote: You're right... I confused the Live FS with the Live CD, which is a seperate image distribution. Sorry for the bum information. FWIW, on the original question of what is it for, I personally tend to use it to create chroot environments for hosted builds across FreeBSD

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require

Re: libc size

2002-10-30 Thread Terry Lambert
Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out Move the resolver code out to ibresolv.so, and link

Re: libc size

2002-10-30 Thread Terry Lambert
Peter Wemm wrote: Terry Lambert wrote: Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: On Wed, 30 Oct 2002, Daniel Eischen wrote: Well, it must have the same problem with Solaris then. Somehow, you've got to force it to link libc_r before libc... The only way I can see to do that is to link libX11, libXt and friends against libc_r. What this comes down

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. For what its worth,

Re: libc size

2002-10-30 Thread Terry Lambert
Dan Nelson wrote: In the last episode (Oct 30), Doug Rabson said: On Wed, 30 Oct 2002, Peter Wemm wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting

Re: Lack of real long double support

2002-10-30 Thread Terry Lambert
M. Warner Losh wrote: And there's a comment: * 64-bit precision often gives bad results with high level languages * because it makes the results of calculations depend on whether * intermediate values are stored in memory or in FPU registers. which seems like a compiler issue, not an OS

Re: libc size

2002-10-30 Thread Terry Lambert
Peter Wemm wrote: Note that dynamically-linked executables take significantly longer to exec than statically-linked ones. Indeed yes. Running ld-elf.so.1 isn't free. Also, calling PIC libraries isn't free either. Not only that, but even fork(2) is slower when you come *from* a dynamic

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: You can't have a library that's sort of threaded and sort of not threaded: pick one. Yes you can - libX11 is *thread safe* but doesn't create threads. When a real pthreads implementation is present, libX11 uses its implementation of mutex, cond etc. to ensure its own

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Doug Rabson wrote: For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. No, this would be bad. There's some justification for not doing this, in allowing programs linked againts libraries linked against

Re: Lack of real long double support

2002-10-30 Thread Terry Lambert
M. Warner Losh wrote: : The compiler must emit instructions to truncate and set flags, as : well as generating pseudo-exceptions (should they be called for) : in the case that the storage is in registers bigger than the memory : backing them. IT doesn't do this. I think I don't understand

Re: [PATCH: libc]Re: gnome on current

2002-10-30 Thread Terry Lambert
Alexander Kabaev wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. You people keep saying

Re: libc size

2002-10-30 Thread Terry Lambert
David Schultz wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes please. Our root filesystem space requirements are too high, IMHO.

Re: Lack of real long double support

2002-10-30 Thread Terry Lambert
M. Warner Losh wrote: : This : example shows that we don't support it in printf, since the above : example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is. [ ... ] Terry you are wrong. This has to do with the RANGE not the PRECISION of the floating point number. It is

Re: libc size

2002-10-30 Thread Terry Lambert
David Schultz wrote: At least in the case of the base system, it should be easy to link all programs that actually use the resolver with -lresolv. Is there some standard that says that the resolver is an integral part of the C library, such that separating the two would break compatibility

Re: libc size

2002-10-31 Thread Terry Lambert
Ollivier Robert wrote: According to Terry Lambert: The PIC overhead is likely unavoidable. I'd actually like to see the benchmark run on statically linked PIC vs. non-PIC code, so I remember that when I was working on Perl and the FreeBSD port (back in the early 5.000 days), having

Re: libc size

2002-10-31 Thread Terry Lambert
Ollivier Robert wrote: According to David Schultz: Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. IIRC not exactly. In the dynamic case, some fixups are done by the dynamic linker to link with the

Re: [PATCH: libc]Re: gnome on current

2002-10-31 Thread Terry Lambert
Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: [ ... ] 2. Define weak _pthread_*

Re: [PATCH: libc]Re: gnome on current

2002-10-31 Thread Terry Lambert
Alexander Kabaev wrote: Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are

Re: Lack of real long double support

2002-10-31 Thread Terry Lambert
Bruce Evans wrote: Please forget this wrong example :-). The precision doesn't affect the exponent range. Done. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Re: Lack of real long double support

2002-10-31 Thread Terry Lambert
M. Warner Losh wrote: : I await an explanation of how you can fit 2*DBL_MAX into a double, : which has a range of DBL_MIN..DBL_MAX. Look at the code. long double a = DBL_MAX; long double b = DBL_MAX * 2; The original posting said that b would be +Inf at this point, which is

Re: [PATCH: libc]Re: gnome on current

2002-10-31 Thread Terry Lambert
Daniel Eischen wrote: We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore]

Re: [PATCH: libc]Re: gnome on current

2002-10-31 Thread Terry Lambert
Doug Rabson wrote: Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against

Re: [PATCH: libc]Re: gnome on current

2002-10-31 Thread Terry Lambert
Alexander Kabaev wrote: By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did

[PATCH]Re: crash with network load (in tcp syncache ?)

2002-11-01 Thread Terry Lambert
Michal Mertl wrote: I'm getting panics on SMP -CURRENT while running apachebench (binary ab from apache distribution, not the Perl one) against httpd on the machine. The panics don't occur when I have WITNESS and INVARIANTS turned on. [ ... ] #10 0xc01bd46f in panic (fmt=0x0) at

Re: crash with network load (in tcp syncache ?)

2002-11-01 Thread Terry Lambert
Bill Fenner wrote: sonewconn() hands sofree() a self-inconsistent socket -- so-so_head is set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet. Please try this patch. I think this can still crash (just like my patch); the problem is in what happens when it fails to

Re: crash with network load (in tcp syncache ?)

2002-11-01 Thread Terry Lambert
Bill Fenner wrote: I think this can still crash (just like my patch); the problem is in what happens when it fails to allocate memory. Unless you set one of the flags, it's still going to panic in the same place, I think, when you run out of memory. No. The flags are only checked when

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Michal Mertl wrote: This patch fixes the panics for me. Thanks a lot. I believe it should be commited. I agree (Mark Murray -- this was the patch I was talking about). BTW: I get about 850 fetches pers second on UP an 600 SMP (the same machine and settings). Don't know if it's expected in

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Michal Mertl wrote: Do I read you correctly that Bill's patch is probably better than yours (I tested both, both fix the problem)? That's a hard question, and it takes a longer answer. 8-(. They fix the problem different ways. The problem is actually a secondary effect. There are several

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Bill Fenner wrote: I think most of your 9k of reasoning is based on the thought that soreserve() allocates memory. It doesn't, and never has. The real problem is the in_pcballoc() in tcp_attach(), which calls uma_zalloc(). But for mbufs, soreserve allocates space, for potential mbufs, even

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Galen Sampson wrote: With proper tuning, and some minor patches, 7000/second isn't hard to get. If you add the Duke University version of the Rice University patches for LRP, modify the mbuf allocator for static freelisting and then pre-populate it, and tune the kernel properly, you

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Don Bowman wrote: I suspect because of the copyright: http://www.cs.rice.edu/CS/Systems/ScalaServer/code/rescon-lrp/README.html This code is copyrighted software and can NOT be redistributed That explains why the new code was integrate, not why the old code wasn't, when it was initially

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Terry Lambert
Bill Fenner wrote: I really don't understand why you keep claiming that the SYN cache changes anything. Without the SYN cache, tcp_input() calls sonewconn(so, 0) on receipt of a SYN; with the SYN cache, tcp_input() calls some syncache function which calls sonewconn(so, SS_ISCONNECTED) on

Re: WIne freezes -current for half a year

2002-11-03 Thread Terry Lambert
Hiten Pandya wrote: On Sun, Nov 03, 2002 at 07:12:36PM +0100, Jan Stocker wrote the words in effect of: wine freezes my system (always -current) for months (half a year i think). Does anyone have the same prob and/or a solution? Hi there, can you please elaborate on your situation, and

Re: WIne freezes -current for half a year

2002-11-04 Thread Terry Lambert
Alex Zepeda wrote: On Sun, Nov 03, 2002 at 02:36:41PM -0800, Terry Lambert wrote: My understanding of his post was that, 6 months later, the machine unfreezes, and everything works normally... 8-) 8-). Actually, I think he's complaining that WINE isn't working in -current. Yup

Re: Can't resolve hosts via dns on the command line with latest-current

2002-11-04 Thread Terry Lambert
Kelly Yancey wrote: I suspect something in lib/libc/net/res_send.c is using special knowledge of the contents of the socket buffer so calculate the real amount of data that can be read (which this patch does automatically). I'm looking into it. ...To ensure that the read does not block, and

Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken

2002-11-04 Thread Terry Lambert
Nate Lawson wrote: 2. Adding a MI way to call an MD routine that will get the disk's physical geometry. I don't know much about the best way to do this. Perhaps we could invent a Common Access Method (CAM), and make it part of that API... -- Terry To Unsubscribe: send mail to [EMAIL

Re: Can't resolve hosts via dns on the command line with latest-current

2002-11-04 Thread Terry Lambert
Kelly Yancey wrote: It doesn't matter. It isn't just DNS lookups, mountd fails to run too because it cannot connect to portmap via localhost. Oddly, in both cases sendto() is returning with errno = 49 (EADDRNOTAVAIL). I've tracked it down to this code in sys/netinet/ip_output.c: /*

Re: libc size

2002-11-05 Thread Terry Lambert
Max Khon wrote: hi, there! Ok, I put the patch and test program to http://people.freebsd.org/~fjoe/libdl.tar.bz2. Patches are made against RELENG_4 (and all tests were done on RELENG_4) but it will not be that hard to port everything to -CURRENT. This is just a proof-of-concept

Re: Why is my -current system Hard Locking?

2002-11-06 Thread Terry Lambert
Joel M. Baldwin wrote: Is there a way in HARDWARE to FORCE a break into ddb? ^ If you have an open ISA port, a flat-bladed screwdriver, and a Bic lighter, you can cause an NMI that the debugger can trap... -- Terry To Unsubscribe: send mail

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-06 Thread Terry Lambert
Steven G. Kargl wrote: Could someone add the following patch to UPDATING? Change the words to whatever suits your fancy. +20021031 + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. + This changes the visibility of __sF to a symbol internal to + libc. All

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-06 Thread Terry Lambert
Steve Kargl wrote: Any chance we could get rid of all externally visable symbols that are not defined as being there by some standard, and not just __sF, since we are breaking the FORTRAN compiler and other third party code already? This isn't restricted to my Fortran 95 problem, which

Re: XFree

2002-11-07 Thread Terry Lambert
walt wrote: Horen wrote: Posted a week ago the question, didn't get any reaction. Everything with current from last night works fine but killing X or logging out ends in a black screen. No way to activate the display without reboot. Remote login is fine. Typing blind works too. I

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: How long has this been going on? Did it start at any particular point (a specific kernel or XFree86 upgrade)? What video card do you use? Does starting X again not work? Typing blind starts X again. Do you have any idea what could be the problem. xset s off ? --

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread Terry Lambert
Tim Kientzle wrote: Terry Lambert asked: Any chance we could get rid of all externally visable symbols that are not defined as being there by some standard, and not just __sF, since we are breaking the FORTRAN compiler and other third party code already? This cannot be entirely done

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread Terry Lambert
M. Warner Losh wrote: Gotcha. I'm thinking very seriously about keeping __sF support (but creating no new binaries with it in it) and the freeze on sizeof(FILE) through the 5.x series of releases because we botched the compatibility stuff so badly to give people a chance to catch their

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: Tried all combinations. Disabled every chip related feature, that isn't required to bring X up. Screensaver is disabled. No way to get any readable display back without reboot. Installed a fresh XFree86 built from the ports tree, hour before updated. No luck :-( You stated

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: You stated Typing blind starts X again. Can you tell us what you mean by this? o It restarts X, as if you typed startx Exactly that. The problem is clearly in the X11 code, then, since it is not resetting the card to the video mode it was in before X started. You

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: On FreeBSD 4.6 or 4.7 works, on FreeBSD 5.0 it doesn't work. Don't you think it is OS related. ? THere are a lot of MS-DOS programs that won't run on FreeBSD; I don't think that's FreeBSD-related, I think it's the code doing the wrong things to run on FreeBSD. I even installed

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: X has exited cleanly only on 4.6 or 4.7 , never on 5.0 in the Exact same version of the X Server (pkg_info | grep XFree86-Server)? XFree86-Server-4.2.1_5 XFree86-4 X server and related programs That's the version of the source code. Are you running the same binaries? Or were

Re: XFree

2002-11-07 Thread Terry Lambert
Horen wrote: XFree86-Server-4.2.1_5 XFree86-4 X server and related programs Do you think, it makes sense, that I grab an other version, 4.2.0 or even 4.1.x to check ? No, I think the source code version is much less relevent than the platform and compiler which was used to compile the X11

Re: This kernel lacks ppp support?

2002-11-07 Thread Terry Lambert
Greg 'groggy' Lehey wrote: I've just tried to start pppd on two different -CURRENT machines, one built on 26 October, the other on 5 November. In each case I get the following message: pppd: This system lacks kernel support for PPP. To include PPP support in the kernel, please follow

Re: ssh-agent broken with pam_ssh for xdm (+ fix for ssh-agent.c)

2002-11-07 Thread Terry Lambert
Damien Miller wrote: Dag-Erling Smorgrav wrote: Markus Friedl writes: but shouldn't it do something like seteuid(getuid()); setuid(getuid()); executing ssh-agent? It should. It currently uses popen(3), which doesn't. It needs popen(3)-like functionality because

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread Terry Lambert
M. Warner Losh wrote: -current already does this. The problem is that we're trying to shoot the bad access in the head, and that is what is screwing people. So the problem isn't that we're trying to export private data to the world. Quite the contrary, we're trying to eliminate it and

Re: XFree

2002-11-08 Thread Terry Lambert
Horen wrote: On FreeBSD 4.6 or 4.7 works, on FreeBSD 5.0 it doesn't work. Don't you think it is OS related. ? I even installed Linux RedHat 8.0 ( gcc 3.2x ) code. It works. Only on FreeBSD 5,0 , it doesn't work. Install X from FreeBSD 4.6 or 4.7 on FreeBSD 5.0... plain enough? -- Terry To

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-08 Thread Terry Lambert
Doug Rabson wrote: It _would_ be a good idea to document any internal library symbols used by macros. Removing such symbols is a good way to break existing compiled applications. Library design involves a lot of tradeoffs. In the windows world, all this is handled by having a strict

Re: XFree

2002-11-08 Thread Terry Lambert
Horen wrote: Now the missing facts: 4.x binaries will not run on 5.0, lib.c inconsistency. You are not running the most recent 5.x. We can't help you, I think. Identical XFree86 sources compiled nativly on 4.6, 4.7 and 5.0. 4.6-4.7: no problem 5.0: logout from X blocks the

Re: [PATCH: libc]Re: gnome on current

2002-11-08 Thread Terry Lambert
Daniel Eischen wrote: By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did

Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?

2002-11-08 Thread Terry Lambert
Martin Faxer wrote: the nvidia supplied drivers appear to work fine except for libGL* which are compiled on an older system and thus give: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libGL.so.1: Undefined symbol __sF any way to get around this? Yes. Run a newer version of -current. Warner

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-08 Thread Terry Lambert
Andrew Kenneth Milton wrote: +---[ Steve Kargl ]-- | | I agree with Dan. Let's do it now. My understanding is | that 5.0 will be an early adopter release and production | systems should run 4.7{8,9,..} until 5.1 is released. | | To accomplish the change, I think we

Re: USB problem (Who owns USB code in -current?)

2002-11-08 Thread Terry Lambert
Maksim Yevmenkin wrote: 1. Hardware: Attach the USB device into a USB port closer to the root hub. 2. Software: Detect the CRC/Timeout error and count exceeded and attempt to re-queue the packets while changing the length of the packets. Changing the length of the packets will change the

Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?

2002-11-08 Thread Terry Lambert
Matthew N. Dodd wrote: Recompile your kernel with options PCI_ALLOW_UNSUPPORTED_IO_RANGE Given the number of times that this comes up, can we change that to PCI_ALLOW_ACTUALLY_SUPPORTED_IO_RANGE_WHICH_IS_NON_DEFAULT_TO_BE_ANNOYING ? Thanks. -- Terry To Unsubscribe: send mail to [EMAIL

Re: perl5.6.1 wrapper

2002-11-08 Thread Terry Lambert
Ray Kohler wrote: Yes, it's already a mandatory step (remove old includes, or you can't build C++ programs). I mean *all* the cruft -- old modules and config files, deprecated binaries and man pages, even old shlibs if it's safe. You need a registration system which can subsume all

Re: acpid implementation?

2002-11-08 Thread Terry Lambert
Hiten Pandya wrote: I have been searching mailing lists and my friend Google for information about a acpid (like apmd) implementation for FreeBSD, but I have found nothing. Does one exist anywhere, or has anyone started out on something without telling anyone? :) Why do you need an

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-08 Thread Terry Lambert
M. Warner Losh wrote: My plan is as follows: 1) Restore __sF to libc for 5.0. 2) Fix 4.x binaries so that __sF isn't referened in new binaries. This should have been done in Aug 2001, but wasn't. Depending on how things go, __sF will be removed in

Re: Kernel not booting....Immediate crash

2002-11-08 Thread Terry Lambert
David Schultz wrote: Thus spake Sidcarter [EMAIL PROTECTED]: Fatal trap 12: page fault while in vm86 mode fault virtual address = 0x9fdc8 ^^^ That's a region of memory right before the 640K mark, and your BIOS is trying to use it. This used to work, but

Re: [PATCH] note the __sF change in src/UPDATING

2002-11-08 Thread Terry Lambert
Daniel Eischen wrote: I'm not even close to a shared library/linker expert, but I thought there was a way to have something run when an object file got loaded. From rtld(1): After all shared libraries have been successfully loaded, ld-elf.so.1 proceeds to resolve external references

Re: getting rid of devfs...

2002-11-09 Thread Terry Lambert
Julian Elischer wrote: Ok here are some thought about devfs 1/ devices are coming and going and becoming more portable 2/ disk partitioning schemes are also multiplying 3/ devices such as usb or bluetooth nets can be configured in arbitray ways 4/ there are more than 256 types of device

Re: Deadlock during buildworld

2002-11-09 Thread Terry Lambert
Jeff Roberson wrote: [ ... patch ... looks right to me, but I wonder if it opens a race window in the vput() blocks case ...either way, it's no worse than the code it replaces... ] I'll look into it some more, but it looks like someone is holding the exec map while they are trying

  1   2   3   4   5   6   7   8   9   10   >