Every time they ask you why we do things the way we do, and after you
have taken the N minutes to explain it, ask them to go ask Sun the
same question, out of fairness to FreeBSD. It might put these ``Sun is
the world'' guys back into thier place. Or atleast it might get them
off your
On Sun, 5 Sep 1999, David Scheidt wrote:
On Sun, 5 Sep 1999, Doug Rabson wrote:
On Sun, 5 Sep 1999, David Scheidt wrote:
Yesterday's -current fails to find my soundcard. It's an Opti chipset thing
that worked fine (for a $12 soundcard...) with the old driver. What is
decent
On Sun, 5 Sep 1999, Manfred Antar wrote:
I'm having a similar problem with the newpcm stuff.
I have a Intel PR440FX motherboard with builtin sound (Crystal Sound System)
It worked fine until the recent changes in pnp.
I can get it to work with the Voxware drivers no problem.
Here is the
Doug Rabson wrote:
On Sun, 5 Sep 1999, David Scheidt wrote:
On Sun, 5 Sep 1999, Doug Rabson wrote:
On Sun, 5 Sep 1999, David Scheidt wrote:
Yesterday's -current fails to find my soundcard. It's an Opti chipset
thing
that worked fine (for a $12 soundcard...) with the
On Mon, 6 Sep 1999, Peter Wemm wrote:
Doug Rabson wrote:
On Sun, 5 Sep 1999, David Scheidt wrote:
On Sun, 5 Sep 1999, Doug Rabson wrote:
On Sun, 5 Sep 1999, David Scheidt wrote:
Yesterday's -current fails to find my soundcard. It's an Opti chipset
thing
Here's (most of) the relevant information. Sources are from July 31st,
the kernel was built on August 2nd. The panic occurred while I was
doing a large rm -rf (deleting a full copy of the src/contrib tree).
The "symbols.1" file referenced below is an unstripped copy of the
kernel that panicked.
Randy Bush [EMAIL PROTECTED] writes:
cc -O -pipe -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall
-I/usr/src/libexec/ftpd/../../contrib-crypto/telnet -DINTERNAL_LS -Dmain=ls_main
-I/usr/src/libexec/ftpd/../../bin/ls -DKERBEROS -I/usr/obj/usr/src/tmp/usr/include
-o ftpd ftpd.o
Disclaimer:
This is still work in progress.
Description:
When we want to support Linux binaries in the future and possibly also want
real-time signals, then we need to support more than 32 signals.
Current status:
The diffs result in a working backwards compatible GENERIC kernel. The
Description:
When we want to support Linux binaries in the future and possibly also want
real-time signals, then we need to support more than 32 signals.
Current status:
The diffs result in a working backwards compatible GENERIC kernel. The
linuxulator also doesn't seem to be broken.
Description:
When we want to support Linux binaries in the future and possibly also want
real-time signals, then we need to support more than 32 signals...
I thought about this a bit more and thought of a good two-step process:
1. Immediately do roughly what you displayed only without
Peter Dufault wrote:
Firstly, you should get rid of any explicit 32, 31, etc and anything
else tied to the assumed number of bits in an int.
You first need to get rid of any code that assumes that siget_t is an
(unsigned) integer. Use macros to abstract the access to the new sigset_t
so that
Peter Dufault wrote:
Firstly, you should get rid of any explicit 32, 31, etc and anything
else tied to the assumed number of bits in an int.
You first need to get rid of any code that assumes that siget_t is an
(unsigned) integer. Use macros to abstract the access to the new sigset_t
At 08:56 AM 09/06/99 +0100, Doug Rabson wrote:
On Sun, 5 Sep 1999, Manfred Antar wrote:
I'm having a similar problem with the newpcm stuff.
I have a Intel PR440FX motherboard with builtin sound (Crystal Sound
System)
It worked fine until the recent changes in pnp.
I can get it to work
typedef struct {
unsigned int n;
uint64_t v;
} sigset_t;
You can't use any BSD or FreeBSD specific types (such as u_int32)t) in
publicly visible types (such as sigset_t). It breaks programs because it's
not ANSI and/or Posix.
You can use internal names like
Peter Dufault wrote:
Peter Dufault wrote:
Firstly, you should get rid of any explicit 32, 31, etc and anything
else tied to the assumed number of bits in an int.
You first need to get rid of any code that assumes that siget_t is an
(unsigned) integer. Use macros to abstract the
Peter Dufault wrote:
1. Immediately do roughly what you displayed only without increasing
the number of signals but instead using two sixteen bit ints, and
commit after testing.
[snip]
2. Switch to the higher number of signals using the approach I
suggested making the high 16 bits
Not
#ifdef _SIGNAL_HEADER
But
#if _SIGNAL_HEADER == 1
of course.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Mon, 6 Sep 1999 10:08:21 -0400 (EDT), Peter Dufault [EMAIL PROTECTED] said:
This is a particularly safe implementation typedef,
since I don't anticipate uint64_t ever being used in a future specification
as a different data type.
I don't know about ANSI.
It's in C9x.
-GAWollman
--
On Mon, 6 Sep 1999 10:51:41 -0400 (EDT), Peter Dufault [EMAIL PROTECTED] said:
/* Now just insert the macros to make this work...
*/
I'd be inclined to make sigemptyset() and sigfillset(), at a minimum,
functions only (not macros).
I'd define sigaddset something like this (function
On Mon, 06 Sep 1999 11:03:35 +0200, Marcel Moolenaar [EMAIL PROTECTED] said:
Known problems:
Building world fails because the freshly built cpp segfaults. A setjmp call
that may be involved matches the problem of a return address being 0. gdb
does not display a complete backtrace...
The
On Mon, 06 Sep 1999 11:03:35 +0200, Marcel Moolenaar [EMAIL PROTECTED] said:
kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
There appear to be some fairly gratuitous name changes in here.
Also, my own feeling is that it would be better to continue to use
integral types
Garrett Wollman wrote:
Peter D. and I have been discussing this topic over the past few days,
and I was about to sit down and do the implementation when I saw your
message. I'd appreciate it if you can hold off on yours for a bit.
Yes, but why?
--
Marcel Moolenaar
On Mon, Sep 06, 1999 at 11:25:05AM +1000, Peter Jeremy wrote:
: On Thu Sep 2 11:35:53 1999 -1000, I wrote:
: I notice that -current supports the 3C574, but not the newer 3C574B.
:
: I can offer some good news and some bad news:
:
: The good news: Support is trivial - at least in PAO3, and the
Garrett Wollman wrote:
On Mon, 06 Sep 1999 11:03:35 +0200, Marcel Moolenaar [EMAIL PROTECTED] said:
kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
There appear to be some fairly gratuitous name changes in here.
Elaborate, please.
Also, my own feeling is that it
On Mon, 6 Sep 1999 14:33:16 -0400 (EDT), I misspoke thusly:
It's true that this would (currently) slow down uthreads.
Actually, uthreads uses the signal-preserving versions (setjmp and
longjmp), so it's already entering the kernel on every context switch.
-GAWollman
--
Garrett A. Wollman |
On Mon, 06 Sep 1999 19:34:06 +0200, Marcel Moolenaar [EMAIL PROTECTED] said:
The setjump/longjump family of functions are userland function
AFAICT.
POSIX doesn't make any such distinction. Remember that setjmp/longjmp
*already* enter the kernel, in order to save/restore the signal mask,
so
On Mon, 06 Sep 1999 11:06:51 -0700, Jason Nordwick [EMAIL PROTECTED]
said:
Wouldn't you hose uthread performance? I thought that one of the major
benefits it that a context switch in uthreads did not require kernel
intervention and a syscall.
It's true that this would (currently) slow down
will someone please shout when this is unbroken? need to build to debug
this darn pcm issue.
I fixed this a few hourws ago already...
then it did not propagate to cvsup[12] as of an hour ago.
what version of what module?
randy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Anything that knows about sigset_t will already be using the POSIX
macros for it, since sigset_t was a POSIX invention. The old
`sigmask'-style functions don't have such an API, so they need to be
left as-is. (Such programs would not know about high-numbered signals
anyway, so this is no
what version of what module?
src/libexec/ftpd/Makefile 1.28
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP:
The log file for cron has moved from
/var/cron/log
to
/var/log/cron
newsyslog.conf has been updated, so normal rotation of the logfile
should work.
Cheers,
Nick
--
e-Mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
} src/libexec/ftpd/Makefile 1.28
This certainly fixed the kerberized ftpd, but I also had to make similar
changes to the Makefiles for rshd and rlogind in libexec and for su, rlogin
and rsh in usr.bin to get 'make world' to complete.
Aaaah! That makes sense!
M
--
Mark Murray
Join the
On Fri, Sep 03, 1999 at 03:59:37PM -0700, Jordan K. Hubbard wrote:
Have the snapshots for later dates (Sept) been moved?
No, they simply haven't been created. :)
-current has not been stable enough to snapshot yet in September. The
builds have fallen over for one reason or another with
HEADS UP:
The variables MODLOAD and MODUNLOAD in bsd.kmod.mk have changed to
KMODLOAD and KMODUNLOAD for conistency with the rest of the file. The
targets load and unload for modules should work again, i.e.
cd /usr/src/sys/modules/xl
make
make install
make load
On Mon, 6 Sep 1999, Thomas Schuerger wrote:
Hi!
I built and installed a new world today. My last make world
was some months ago.
It seems that the boot loader has changed. Now, my AWE64
soundcard is not detected anymore.
My kernel.config looks like this
pnp 1 0 os enable port0
will someone please shout when this is unbroken? need to build to debug
this darn pcm issue.
I fixed this a few hourws ago already...
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
According to Manfred Antar:
All I can think of is there must be a conflict with one of the other cards
on the board.
Matrox Millenium or the DPT Raid controller.
I have a ET6000-based card (see below) and no DPT.
FreeBSD 4.0-CURRENT #22: Sat Sep 4 22:40:07 CEST 1999
[...]
What can I do in order to reenable my soundcard?
Any help is appreciated!
Please try using the new pcm driver if you are not already. You should be
able to do this by having these lines in your kernel config:
controller pnp0
device pcm0
Note that you must not
Do you know the appropriate channel to contact the XFree86 folks? In the
mean while, I can take Sheldon's advice, submit it to our XFree86 port.
By the way, I've just thought of something you should consider. I think
there's still a problem with xdm, where trying to change vty while it's
Hi,
make release is doing better, we're now up to a failure in
rlogind with respect to libkrb...
cc -O -pipe -Wall -DKERBEROS -DCRYPT -DHAVE_CONFIG_H
-I/usr/src/libexec/rlogind/../../kerberosIV/include
-I/usr/src/libexec/rlogind/../../crypto/kerberosIV/include
Can we have an entry for mii.ko in /boot/defaults/loader.conf?
##
### Networking drivers #
##
mii_load="NO"
ax_load="NO"#
cc -O -pipe -Wall -DKERBEROS -DCRYPT -DHAVE_CONFIG_H -I/usr/src/libexec/rlog
ind/../../kerberosIV/include -I/usr/src/libexec/rlogind/../../crypto/kerberosI
V/include -I/usr/src/libexec/rlogind/../../crypto/kerberosIV/lib/roken -I/usr
/src/libexec/rlogind/../../crypto/kerberosIV/appl/bsd
42 matches
Mail list logo
