On Tue, 29 Feb 2000, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 Feb 2000, John Polstra wrote:
> >
> > > Shouldn't the test against PS_SUSPENDED be "==" inste
On Tue, 29 Feb 2000, John Polstra wrote:
> Either pthread_suspend_np() and pthread_resume_np() are broken in
> -current or I don't understand them. The attached program (cc
> -pthread suspend.c) starts two background threads. Each thread loops
> outputting a character ('1' or '2' according to w
On Fri, 18 Feb 2000, Matthew Dillon wrote:
> :Currently, the threads library only creates one guard page
> :at the top (or bottom depending on how you look at it) of
> :each threads stack (for stacks of default size). Thread
> :stacks are allocated in sequential zones, so they are always
> :plac
> * When you mmap() with MAP_GUARDED|MAP_STACK, you get
> a guarded stack. The system will not create a
> growable stack, though, it pre-reserves the space
> (but, of course, does not allocate physical pages
> for things you haven't touched).
>
> The new semantics
On Fri, 18 Feb 2000, Bruce Evans wrote:
> On Thu, 17 Feb 2000, Daniel Eischen wrote:
>
> > On Thu, 17 Feb 2000, Thimble Smith wrote:
> >
> > > Hi. I recently updated from -stable to -current. I notice now that
> > > pthread.h relies on #defines that
On Thu, 17 Feb 2000, Thimble Smith wrote:
> Hi. I recently updated from -stable to -current. I notice now that
> pthread.h relies on #defines that are in unistd.h; so in order to use
> pthread_attr_setscope you have to include unistd.h before pthread.h.
>
> Is this standard behaviour? I'm wor
> What we had before the _libc_XXX name additions would have worked
> as long as all internal uses of XXX inside libc were changed to
> _XXX, and, when building for libc_r, all renamed (hidden) system
> calls need _XXX defined as weak symbols to _thread_sys_XXX.
Actually, you don't even need to d
Jason Evans wrote:
> Doen't that method still have the problem of propagating cancellation
> points within the libc code? In another email I argued for the need for
> three names, and your response was that three names aren't needed in the
> context of the next-generation threads library, but it
On Wed, 19 Jan 2000, Jason Evans wrote:
> On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > I guess I'm confused as to why you can't do what you need with
> > _XXX (internally used, non-cancellable function) and XXX (weak
> > reference to _XXX) wit
> No, I was just busy doing other things.
>
> There is potentially one good reason to leave these changes in place for
> now: they allow proper thread cancellation in libc_r as it stands right
> now. This seems to me like a good enough reason to leave the changes as is
> until our grand new thre
On Wed, 12 Jan 2000, David O'Brien wrote:
> On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
> > > The buildworld problem that I introduced is due to cc_fbsd directly
> > > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
> > > opinion a questionable practice, sin
Kip Macy <[EMAIL PROTECTED]> wrote:
> Sorry for sending this again but when I first sent it -current was
> embroiled in a flame war.
>
> I would like to use the latest threads source because my application does
> not work correctly with the signal handling bugs in 3.x's threads.
> However, it do
> They're in sys/unistd.h, which is included by unistd.h. That should be
> just fine, and that location appears to be consistent with our other POSIX
> macro definitions.
Ahh, good. I didn't have them because I wasn't up to date.
So the question is now, why wasn't the nist port picking them up
On Tue, 28 Dec 1999, Soren Schmidt wrote:
> It seems Kenneth Wayne Culver wrote:
> > I can't get the nist port to compile:
> > c++ -g -O2 -Wall -DDO_NIST -DPACKAGE=\"ac3dec\" -DVERSION=\"0.5.5\"
> > -I../../inc -c bitstream.c -o bitstream.o
> > In file included from decode.h:24,
> >
> It seem this is relevant.
> Here is the output of "python test_select.py":
>
> Traceback (innermost last):
> File "test_select.py", line 63, in ?
> test()
> File "test_select.py", line 47, in test
> rfd, wfd, xfd = select.select([p], [], [], tout)
> select.error: (4, 'Interrupted sy
> In message <[EMAIL PROTECTED]> Christopher Masto writes:
> : Right now, I have no sound (not detected), no USB (panic on removal),
> : can't use my sio pccard, can't eject my ed pccard, my IDE drives are
> : taking hours to dump and fsck, and my TV card is missing every other
> : line if I try t
other week or so and
I can update them.
>
> *) Signal delivery fixes. I think Daniel Eischen has already taken care of
>this.
Yes, awaiting review by JB.
>
> *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in
>PR bin/7587) need to be implemented.
John Birrell wrote:
> Weak symbols don't work too well _between_ libraries. If libc is linked
> before libpthread, any unresolved references when libc is searched will
> use the weak symbols from there, regardless of the fact that a strong
> symbol exists in libpthread. If libc is linked after lib
John Polstra wrote:
> I know now why it worked on the i386 but not on the Alpha. On the
> i386 a system call "read", for example, produces a strong (normal
> global) symbol "_read" and a weak alias "read". Because the symbols
> were weak, the linker didn't complain about the multiple definitions
Kenneth Wayne Culver wrote:
> Speaking of libc_r, (this is unrelated sort of) I was wondering if anyone
> was planning on adding the pthread_setcancel and other pthread cancel
> stuff to -CURRENT. I was trying to use it the other day when I realized it
> wasn't there... :-) Just a question, I'm n
Doug Rabson wrote:
> I looked at you pnpinfo again and I think this change might be better. It
> accepts the cards description instead of overriding it and adds another ID
> for SUP2080 which your card is compatible with. I also removed the bogus
> descriptions for the USR3031 since the pnpinfo fo
Matthew N. Dodd wrote:
> On Sat, 2 Oct 1999, Daniel M. Eischen wrote:
> > What's the unknown0? Shouldn't that be sio2? Do we need the logical
> > device ID?
>
> Yes. Try adding 0x8024b04e to sio.c
OK, I originally did that to no avail, but I didn't make the change to
the correct file (sys/isa
Marcel Moolenaar wrote:
> Dag-Erling Smorgrav wrote:
> >
> > How about this: early in make world, we check whether or not the
> > current kernel supports the new syscalls. If it does, good. If it
> > doesn't, we build and load a small module which installs syscalls
> > which translate the sigset_
Soren Schmidt wrote:
> It seems Daniel M. Eischen wrote:
> >
> > More info on the kernel hang.
> >
> > Removing pnp from the kernel configuration will allow me to boot
> > and successfully detects my pnp modem. So the culprit seems to
> > be the new pnp code. Suggestions welcome.
>
> Hmm, I a
Marcel Moolenaar wrote:
> So, to start with issue 2:
>
> To start with the beginning:
>
> 1. Should the ucontext_t changes be backed out, or is this the
>way we would like to go? (but only it better :-)
I think we want to keep the ucontext changes. SUSv2 requires them
when SA_SIGINFO is se
Mike Pritchard wrote:
> I've noticed some odd syscons keyboard behaviour over the past
> month or so. Sometimes I get a vty that outputs PC graphics characters
> for all of my input. This is always at a "login:" prompt. I think
> I can duplicate this by typing a bunch of garbage at a login prom
> Did anyone of you took care that you can build an aout gdb on an ELF
> FreeBSD system?
>
> I don't mean a gdb that is aout, but one that can debug aout binaries.
I thought the gdb in our base system could debug aout binaries. Or
am I sadly mistaken.
> That would be most useful to have as a p
Richard Cownie wrote:
> On Sat, 21 Aug 1999, David O'Brien wrote:
> > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > saying you didn't know FreeBSD comes with gdb:
>
> gdb-4.18 is badly broken on all platforms (at least for C++). You can't
> call methods from the gdb c
> Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient
> CPU doesn't have an FPU? And we're talking about the i386 family here...
IIRC, there were a few folks running FreeBSD in an embedded
environment. Perhaps with 80386 FPU coprocessor-less systems?
Dan Eischen
[EMAIL
John Birrell wrote:
> Daniel Eischen wrote:
> > Why don't we make a libc_r_db and provide the necessary interfaces to
> > gdb from that instead of having gdb know about uthread internals?
>
> It would still mean that gdb would be linked to the uthread internals
> which
John Birrell wrote:
> Doug Rabson wrote:
> > Other gdb thread debugging systems tend to export a set of variables from
> > the thread library which describe the important offsets in the thread
> > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> > etc.
>
> > If you think the
> This is the only thing stopping me from upgrading our production machines
> to 3.1-STABLE.
>
> Please, please, please backport these fixes!
I have to echo these feelings. NFS, as both server and client, is
working without noticeable problems for us under the old 2.2-stable.
I am afraid of upg
John Polstra wrote:
> > That statement made me think that Modula-3 had it's own threading
> > support because our native threads using non-blocking file I/O.
>
> For disk I/O? Are you sure? If so then it must use the aio/lio calls
> or something similar. Disk I/O calls _always_ block, even if y
John Polstra wrote:
> > Does Modula-3 use libc_r, or does it have it's own user thread support?
>
> It has its own. It can be ported to use native threads, but it's a
> non-negligible amount of work. It hardly seems worth it for the GUI
> alone.
No argmuent here. It's just that if it was using
John Polstra wrote:
> Correct. I have not tried to analyze where the delays come from.
> But I do have a guess.
>
> CVSup uses user-level threads. If a thread gets blocked waiting for
> network I/O, the thread scheduler can run a different thread while it
> is waiting. A subsequent call to sele
Vladimir Kushnir wrote:
> On Sun, 4 Apr 1999, David O'Brien wrote:
>
> > >The FreeBSD 4.0-CURRENT world appears to be broken. The file that
> > >appears to be causing the problem is pthread_private.h, included by
> > >isatty.c.
> >
> >
> > You're the only one reporting this probl
Kevin G. Eliuk wrote:
> cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc_r/../libc/include
> -DPTHREAD_KERNEL -D_THREAD_SAFE -DNOPOLL -I/usr/src/lib/libc_r/uthread
> -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc_r/../libc/locale
> -DBROKEN_DES -DYP -I/usr/obj/usr/src/tmp
> May I suggest looking at the OpenBSD dhcp client/server? I'm not sure
> which one they're derived from, but the CHANGES file lists a bunch of
> bug and security fixes.
It looks like they're using the ISC dhcp client (and server).
Dan Eischen
eisc...@vigrid.com
To Unsubscribe: send mail to m
> I am planning on adding the Wide-DHCP client to src/contrib/ and
> src/sbin/ in a few days.
>
> I have it bmaked and ready go to. I have choosen the WIDE client because
> it is much smaller space-wise than the ISC client and its configuration
> is simplier.
I tried both, and I must say that I
401 - 439 of 439 matches
Mail list logo
