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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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_*
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
/*
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
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
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
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
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
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
?
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Frode Nordahl wrote:
Why do you need an acpid?
misc stuff
instruct dhclient to get a new lease on resume (maybe free it on sleep),
try to configure wlan if no link detected on ethernet etc.
I put my computer to sleep instead of turning it of most of the time,
and having to run killall
Doug Rabson wrote:
The kernel ABI is hopeless. It changes almost daily :-(. At one time, I
thought I could change this but these days, I don't think anyone except
me cares about having a stable ABI in the kernel.
I care. It's almost the most important thing to be able to build
anything of
1 - 100 of 1538 matches
Mail list logo
