My "Terratec 128i PCI" soundcard probes as "unknown" in current:
pci0: unknown card (vendor=0x125d, dev=0x1969) at 13.0 irq 17
Here are the labels read from the chip on the soundcard:
ESS Solo-1
ES1938S G438
TTUB43833S
P4,214,125
System is:
FreeBSD werner.test.privat.priv 4.0-CURRENT
current's new ppp discards the "#0001"-part from my
german telekom account and makes it impossible to
connect to my provider.
It worked ~ 2 weeks ago with current and works also
in 3.4-Stable.
Werner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
On Tue, 28 Dec 1999, Doug White wrote:
Hello fellow hackers,
I've written up a short patch to add a sysctl to control the appending of
/compat/linux/ to path requests in Linux mode. We had to get ADSM's Linux
client working on FreeBSD so we could do backups of our systems. Luckily
it
Amancio Hasty wrote:
I really doubt that I am the only one here that can get XFree86 3.9.xxx -curr
ent .
Nevertheless if it can help out to fix the default compiler here is the infor
mation which
you reguested.
Command Line executed to generate the output file and with the
On Wed, 29 Dec 1999, Werner Griessl wrote:
current's new ppp discards the "#0001"-part from my
german telekom account and makes it impossible to
connect to my provider.
While we are on the subject, ppp no longer runs an external chat
script. This used to work:
set login "\"!chat -f
Bryan Liesner wrote:
On Wed, 29 Dec 1999, Werner Griessl wrote:
current's new ppp discards the "#0001"-part from my
german telekom account and makes it impossible to
connect to my provider.
While we are on the subject, ppp no longer runs an external chat
script. This used to work:
On Mon, 27 Dec 1999, Emre wrote:
Not really. All my other boxes (NetBSD/OpenBSD) run -current so I'm
used to be on the "bleeding edge" I figured it would be enabled
by default, since FreeBSD promises to be _the_ Server O/S.
Please see
Will egcs affect the size of the kernel or any other compiledcode? I read
that the exception code can add a lot to the object size.
-= jm =-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, 29 Dec 1999 14:47:12 GMT, Jonathon McKitrick wrote:
Will egcs affect the size of the kernel or any other compiledcode?
Yes. Try it out for yourself and have a look, or hunt the -current
mailing list archives.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Sun, 26 Dec 1999, Randy Bush wrote:
mkdep -f .depend -a
-I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/include
-I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include
-I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/krb
Some time ago, Greg wrote:
"USers looking for stability should be damn careful which version of the
-current snapshot they run."
As of right now, which would that be? The august CD snapshot release or
the one available on the cvs servers right now?
-= jm =-
To Unsubscribe: send mail to
On Wed, 29 Dec 1999 15:31:38 GMT, Jonathon McKitrick wrote:
As of right now, which would that be? The august CD snapshot release or
the one available on the cvs servers right now?
If I were you, I'd hold out for 4.0-RELEASE, since it's just around the
corner (January some time).
On Tue, 28 Dec 1999, David O'Brien wrote:
Perhaps a later snapshot of gcc will work .
GCC 2.95.2 is a *RELEASED* version. We don't use snapshots as the base
compiler. What every the problem is 4.0 will live with it unless someone
narrows down the problem more.
The latest Polygraph
I read that the VM system has been revamped and egcs is the default
compiler. Will either of these affect the average user besides larger
binaries?
Also, i'm wondering if maybe i should just wait until the 4.1 release for
everything to settle down...
-= jm =-
To Unsubscribe: send mail to
On Wed, 29 Dec 1999, Jonathon McKitrick wrote:
I read that the VM system has been revamped and egcs is the default
compiler. Will either of these affect the average user besides larger
binaries?
Actually, egcs WAS the default compiler. It is now (output of gcc -v):
$ gcc -v
Using builtin
In message [EMAIL PROTECTED] Sheldon Hearn writes:
: If I were you, I'd hold out for 4.0-RELEASE, since it's just around the
: corner (January some time). Otherwise, just inhale and prepare to
: bleed. :-)
I think that the January some time date may be optimistic given that
we're not in feature
auth 3bd2ca54 subscribe freebsd-current [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
auth 52898cdd subscribe freebsd-stable [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Doug White wrote:
Please let me know if you have comments/suggestions/etc. If no one whines
too badly I'll commit these later this week and finally break my
declaration against making kernel changes. :)
I'm not sure I like this. Please hold off until I've got some time to
think this over.
XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is
sufficient information to reproduce the problem.
Not if you actually want the problem solved. There's this thing
called "making it easy on the people you're demanding things of" in
order that they might have some chance of
On Wed, 29 Dec 1999, Jordan K. Hubbard wrote:
XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is
sufficient information to reproduce the problem.
[snip]
Insisting that someone cvsup the entire X source tree, as you've
clearly *already* done, hardly falls into the
Sending out an attachment of that size to a public mailing list was
hardly necessary, and the increasing stridency of your posts leading
up to this only serve to indicate that you may be heading in the truly
wrong direction with all this and seriously need to rethink your
strategy before you do
On Wed, 29 Dec 1999 15:31:38 GMT, Jonathon McKitrick wrote:
As of right now, which would that be? The august CD snapshot release or
the one available on the cvs servers right now?
If I were you, I'd hold out for 4.0-RELEASE, since it's just around the
corner (January some time).
I ain't done nuttin'!!
I don't see the errors below, I see libroken breaking because libgcc.a
can't be found.
*grumble*
M
On Sun, 26 Dec 1999, Randy Bush wrote:
mkdep -f .depend -a-I/usr/src/kerberosIV/lib/libkadm/../../../crypto/ke
rberosIV/include
:
: FreeBSD -current was last cvsup on my system on Dec 23 18:59.
:
: XFree86 3.9.xxx was cvsup on December 24th I am sorry but this is
: sufficient information to reproduce the problem.
:
:No, it is not, because we can't *get* XFree86 3.9.xxx -current, so we
:cannot reproduce it, can we?
:
Sending out an attachment of that size to a public mailing list was
hardly necessary, and the increasing stridency of your posts leading
up to this only serve to indicate that you may be heading in the truly
wrong direction with all this and seriously need to rethink your
strategy before you
Last days (week?) I silently complaint about slow/hanging xbuffy
process and even mutt reading large inbox (20MB) was very very slow.
Now it is again blindingly fast under -current SMP.
Don't know, what change did it, but thanks to you all !
Andreas ///
--
Andreas Klemm
Bryan Liesner wrote:
On Wed, 29 Dec 1999, Werner Griessl wrote:
current's new ppp discards the "#0001"-part from my
german telekom account and makes it impossible to
connect to my provider.
While we are on the subject, ppp no longer runs an external chat
script. This
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
[cvsupped today :-)]
=== usr.sbin/ifmcstat
cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/i
fmcstat/ifmcstat.c
gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz
/usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function `main':
This was discussed weeks ago, and the new behaviour is correct. You
should be using 'cc -E' instead.
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
On Wed, 29 Dec 1999, Amancio Hasty wrote:
!
!Without -O or -O2 the program compiles okay.
!
!gcc -c bug.c
!
Ouch! This looks an awful lot like the last report with `GCC' and
`problem' in the subject. As Matt just mentionned one or two posts ago,
and as I observed in the last
There are packages such as XFree86 which called directly the installed
cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
for instance defining __FreeBSD__ are now broken .
This was discussed weeks ago, and the new behaviour is correct. You
should be using 'cc -E'
There are packages such as XFree86 which called directly the installed
cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
for instance defining __FreeBSD__ are now broken .
XFree86 is trivial to patch, since it already supports this behaviour (see
our port), and other
Hi,
We just have a buggy version of gcc and it appears that
the register allocator is the main problematic area.
This is not really a problem for me because what I first
try out is a newer version of gcc if I can not get
around the compile problem. At any rate remember
that at least my
It is more of a question of whether the packages for FreeBSD expect
/usr/libexec/cpp to define __FreeBSD__ and in my case XFree86.
Once I managed to find out what was wrong it was indeed easy for
me to fix. If the "other" applications managed to compile correctly
on FreeBSD because of
On Wed, 29 Dec 1999, Amancio Hasty wrote:
There are packages such as XFree86 which called directly the installed
cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
for instance defining __FreeBSD__ are now broken .
... and they will be fixed through bug reports. We now
i=== libroken
cc -O -pipe -I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/include
-I/usr/obj/usr/src/kerberosIV/lib/libroken/../../include
-I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/lib/roken
-I/usr/obj/usr/src/kerberosIV/lib/libroken
I'm running -current that's about a week old. I configed my kernel for
USB support. After turning on the USB interface in BIOS kernel panics
after it probes uchi0. Below is the panic screen, I don't have much else
to go on.
---
uhci0: Intel 82371SB USB Host Controller rev 0x01 int d irq 10 on
Of all the gin joints in all the towns in all the world, Eric D. Futch
had to walk into mine and say:
I'm running -current that's about a week old.
Erm... are you sure? I'm having trouble believing you.
I configed my kernel for
USB support. After turning on the USB interface in BIOS
Seigo Tanimura wrote:
On Mon, 27 Dec 1999 16:08:01 +0900,
Seigo Tanimura [EMAIL PROTECTED] said:
Seigo Another fix was made on feeding and sucking pcm data. Now chn_wrfeed()
Seigo and the other functions do not attempt excessive feeding during DMA
Seigo transfer to eat up the whole
Oh hehe damn did it again. Keep getting my lists mixed up. This machine
is running 3.4-stable and I should have probably posted this to -stable.
Sorry about that... but I really do have 4.0-current running on another
machine.. so I'm not totally crazy :)
--
Eric Futch New York
Hello All,
I've written a small Ethernet TAP driver for FreeBSD-current.
It is useful for Ethernet tunneling. I'm using it with VTUN
(http://vtun.netpedia.net).
The driver sources and description can be found at:
http://home.earthlink.net/~evmax/tap-fbsd-current.tar.gz (~8K)
It would be realy
Forgot to post about this new feature of /usr/libexec/cpp :
NO ONE should have ever have been using /usr/libexec/cpp directly. I
have no idea where this usage came from. /usr/bin/cpp should have been
used.
2. Now a very recent FreeBSD -current
gcc -v
Using builtin specs.
gcc version
On Thu, Dec 30, 1999 at 02:40:46AM +1100, Andy Farkas wrote:
In file included from include/PortMgr.h:29,
from Connection.cc:33:
include/LevelStat.h:55: invalid type `const char[1]' for default argument
to `const String '
..snip..
The "offending" code looks like this:
The usage came about oh about 8 years ago with the very first port
of X to 386bsd by yours truly 8)
Don't forget I did fix the problem on my X build and I am running
the latest XFree86 3.9.xx on my other box.
Take Care
Forgot to post about this new feature of /usr/libexec/cpp :
NO
On Wed, Dec 29, 1999 at 11:37:18AM -0800, Amancio Hasty wrote:
This is the scoop.
..snip..
gcc -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)
..snip..
Without -O or -O2 the program compiles okay.
What other platforms w/gcc 2.95 have you tried to build this X11 version
on?
3. Raise this issue with Cygnus.
Not really Cygnus is the wrong organization to raise this issue .
As someone else pointed out the gcc-devel port does not exhibit the bug
which I posted.
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
I'm running 3.4-stable with source cvsup'd about a week ago.
I configed my kernel for USB support. After turning on the USB interface
in BIOS kernel panics after it probes uchi0. Below is the panic message
plus trace.
% uname -a
FreeBSD quake.nyct.net 3.4-STABLE FreeBSD 3.4-STABLE #3: Wed Dec
Grr damn... please ignore.. I'm sorry.. not gonna post anything else.
--
Eric Futch New York Connect.Net, Ltd.
[EMAIL PROTECTED] Technical Support Staff
http://www.nyct.net (212) 293-2620
"Bringing New York The Internet Access It Deserves"
On Wed, 29 Dec 1999, Eric D.
Will egcs affect the size of the kernel or any other compiledcode?
Verses what other compiler?? Of course the compiler will affect the size
of any compiled code. It may do worse, or even better. Various -O
values will affect the size too.
I read that the exception code can add a lot to the
On Wed, Dec 29, 1999 at 08:57:33PM +0200, Mark Murray wrote:
I don't see the errors below, I see libroken breaking because libgcc.a
can't be found.
Can we track this down? Please post the output from
cc -print-search-dirs
cc -print-libgcc-file-name
I also wouldn't mind to see the
3. Raise this issue with Cygnus.
Not really Cygnus is the wrong organization to raise this issue .
Could you *please* explain why???
Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into
4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new
compiler for
On Thu, Dec 30, 1999 at 02:21:48PM +1100, Andy Farkas wrote:
...the idea was to continue the make process further along to where
another source file that also included LevelStat.h got compiled, to
check whether it bombs as well - it didn't.
``make -k'' might have been a better choice as you
Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into
4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new
compiler for 4.0.
Lets think about this in FreeBSD terms -- 4.0 does not have some problem
that 3.4-R does. However it wasn't known that 3.4-R had
On Wed, Dec 29, 1999 at 07:43:07PM -0800, Amancio Hasty wrote:
Gcc 2.96 will not be out before 4.0. So Gcc 2.95.x is what is going into
4.0. Now should a Gcc 2.95.3 were to come out, then we'd get a new
compiler for 4.0.
Lets think about this in FreeBSD terms -- 4.0 does not have some
Hi David,
Last time, the problem does not exist with the gcc-devel port
which directly implies that the problem has been fixed so I see
no point on reporting the bug to Cygnus. I can in the future
report the bug to Cygnus if the bug has not been fixed
in a subsequent snapshot.
I will play
I reported this issue as PR misc/15127, and
posted once to hackers but get no response at all.
In FreeBSD, _T and other two letter macros are
defined in ctype.h.
Some standard c++ library code use _T as local identifiers.
I mean the library that come with egcs-2.95.[12] and 2.96 191110.
Otay, please tell me how to fix:
=== usr.sbin/ifmcstat
cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/ifmcstat/ifmcstat.c
gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz
/usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function `main':
When I tried to compile my world this fail...
I'm Running FreeBSD 4.0-CURRENT.
sh /usr/src/tools/install.sh -c -o root -g wheel -m 555
/usr/src/usr.bin/yacc/yyfix.sh /usr/obj/usr/src/i386/usr/bin/yyfix
sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 yacc
On Wednesday, 29 December 1999 at 23:17:29 -0600, juan wrote:
When I tried to compile my world this fail...
I'm Running FreeBSD 4.0-CURRENT.
What date?
/usr/obj/usr/src/i386/usr/src/usr.bin/colldef created for
/usr/src/usr.bin/colldef
yacc -d /usr/src/usr.bin/colldef/parse.y
*** Signal
On Wed, Dec 29, 1999 at 08:57:33PM +0200, Mark Murray wrote:
I don't see the errors below, I see libroken breaking because libgcc.a
can't be found.
Can we track this down? Please post the output from
cc -print-search-dirs
cc -print-libgcc-file-name
I found it - its a
On Wednesday, 29 December 1999 at 21:54:42 -0700, Russell L. Carter wrote:
Otay, please tell me how to fix:
=== usr.sbin/ifmcstat
cc -O -pipe -DINET6 -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/ifmcstat/ifmcstat.c
gzip -cn /usr/src/usr.sbin/ifmcstat/ifmcstat.8 ifmcstat.8.gz
63 matches
Mail list logo
