Aureal Vortex soundcard drivers

[Kenneth Wayne Culver]

I was just wondering how the drivers on the aureal vortex are coming
along... I know that Cameron Grant was working on them, but I have not
heard anything on that subject fora while, so I was kinda hoping to hear
about it soon. Thanks.


Kenneth Culver




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: userland ppp - startup

[Josef Karthauser]

On Wed, Jul 07, 1999 at 10:02:44PM +0100, Brian Somers wrote:
> 
> This aside, I think there are more bits required for the patches :*1
> 
> rc.conf.5 needs to be updated - that's the easy bit.
Done - see attached.
 
> I think we also need a src/etc/ppp/ppp.conf that installs with 0600 
> permissions at installation time.  This file would have a default 
> and a papchap entry in it - that's where the url for Waynes ppp.conf 
> comes in - its contents are probably what we're after.  Older versions 
> of src/etc/Makefile installed ppp.conf, so it should be easy to do that 
> side of things.
Done - attached is Waynes ppp.conf and a patch for /usr/src/etc/Makefile.
 
> Sysinstall however is also capable of writing ppp.conf.  It would 
> need to be smart enough to update the default one with the lines that 
> it wants to use (just appending an ``install'' label with the 
> necessary bits is probably the best thing to do).  This answers your 
> other question. src/release/sysinstall/network.c - search for 
> ppp.conf.  That's how sysinstall does it :-)
Attached is network.c.patch, which should do the right thing.  It
simply appends to /etc/ppp/ppp.conf with an 'install' profile, and also
sets the relevent rc.conf variables so that the configuration survives
across reboots.  (This should probably be a little more intelligent,
but lets get the functionality in first and "better" it up later.)

> Ha, and you thought it'd be straight forward ;^P
Of course not ;).
 
Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]


#
# PPP  Sample Configuration File
# Originally written by Toshiharu OHNO
# Simplified 5/14/1999 by [EMAIL PROTECTED]
#
# $Id$
#

default:

 #
 # Instructions:
 #
 # edit the next three lines and replace the items in caps with
 # the values which have been assigned by your ISP.
 #

 set phone PHONE_NUM
 set authname USERNAME
 set authkey PASSWORD

 #
 # Make sure that "device" references the correct serial port
 # for your modem. (cuaa0 = COM1, cuaa1 = COM2)
 #

 set device /dev/cuaa1

 set log Phase Chat LCP IPCP CCP tun command
 set speed 115200
 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK 
\\dATDT\\T TIMEOUT 40 CONNECT"

 set timeout 120
 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
 add default HISADDR
 enable dns



Index: etc/Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.201
diff -u -r1.201 Makefile
--- Makefile1999/07/10 18:02:12 1.201
+++ Makefile1999/07/25 17:46:57
@@ -24,6 +24,7 @@
BSD.var.dist BSD.x11.dist
 NAMEDB= PROTO.localhost.rev named.conf named.root make-localhost
 PPPCNF= ppp.deny ppp.shells.sample
+PPPCF2= ppp.conf
 NOSPAM=Makefile README
 
 
@@ -79,6 +80,8 @@
${NAMEDB} ${DESTDIR}/etc/namedb
cd ${.CURDIR}/ppp; ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 644 \
${PPPCNF} ${DESTDIR}/etc/ppp
+   cd ${.CURDIR}/ppp; ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 600 \
+   ${PPPCF2} ${DESTDIR}/etc/ppp
cd ${.CURDIR}/mail; ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 644 \
${NOSPAM} ${DESTDIR}/etc/mail
${INSTALL} -c -o ${BINOWN} -g operator -m 664 /dev/null \


Index: rc.conf.5
===
RCS file: /home/ncvs/src/share/man/man5/rc.conf.5,v
retrieving revision 1.36
diff -u -r1.36 rc.conf.5
--- rc.conf.5   1999/07/16 09:22:01 1.36
+++ rc.conf.5   1999/07/25 17:19:02
@@ -218,6 +218,30 @@
 .Ed
 Then note that alias4 would \fBnot\fR be added since the search would
 stop with the missing alias3 entry.
+.It Ar ppp_enable
+(bool) If set to
+.Ar YES ,
+run the
+.Xr ppp 8
+daemon.
+.It Ar ppp_mode
+(str) Mode in which to run the
+.Xr ppp 8
+daemon.  Accepted modes are
+.Ar auto , ddial , direct
+and
+.Ar dedicated .
+See the manual for a full description.
+.It Ar ppp_alias
+(bool) If set to
+.Ar YES ,
+enables packet aliasing. Used in conjunction with
+.Ar gateway_enable
+allows hosts on private network addresses access the Internet using
+this host as a network address translating router.
+.It Ar ppp_profile
+(str) The name of the profile to use from
+.Ar /etc/ppp/ppp.conf .
 .It Ar rc_conf_files
 (str) This option is used to specify a list of files that will override
 the settings in


Index: sysinstall.h
===
RCS file: /home/ncvs/src/release/sysinstall/sysinstall.h,v
retrieving revision 1.171
diff -u -r1.171 sysinstall.h
--- sysinstall.h1999/07/19 10:06:17 1.171
+++ sysinstall.h1999/07/25 21:24:15
@@ -148,6 +148,8 @@
 #de

Re: whereis broken?

[Sheldon Hearn]

On Sun, 25 Jul 1999 21:33:55 +0200, Mark Murray wrote:

> > It's been pointed out to me in private mail that current's
> > manpath.config is broken.
> 
> Fixed.

Hi Dan,

You'll need rev 1.11 of src/gnu/usr.bin/man/manpath/manpath.config, but
you should be able to get away with commenting out those
MANDATORY_MANPATH lines that reference /usr/local .

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: whereis broken?

[Mark Murray]

> It's been pointed out to me in private mail that current's
> manpath.config is broken. If nobody's looked at it by tomorrow, I'll do
> so then.

Fixed.

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

Re: whereis broken?

[Jeroen Ruigrok/Asmodai]

* Sheldon Hearn ([EMAIL PROTECTED]) [990725 20:29]:
> 
> 
> On Sun, 25 Jul 1999 14:12:53 -0400, Dan Moschuk wrote:
> 
> > whereis anything yields..
> > 
> > Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
> 
> Staleness. Unfortunately, the whereis(1) manpage doesn't tell you to
> look at the manpath(1) manpage. Do so now and you'll see that you should
> check your /etc/manpath.config and your $MANPATH environment variable.

Prolly didn't use mergemaster after making world eh Dan? ;)

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: whereis broken?

[Sheldon Hearn]

On Sun, 25 Jul 1999 20:12:46 +0200, Sheldon Hearn wrote:

> > Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
> 
> Staleness.

It's been pointed out to me in private mail that current's
manpath.config is broken. If nobody's looked at it by tomorrow, I'll do
so then.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PLIP is still broken :(

[Bruce Evans]

>>Otherwise,
>>the generic code is missing mainly update of the interrupt masks when
>>an interrupt is unregistered.
>
>For the low level side, we could consider something like the following code.
>But this shall be called by the nexus layer and then needs generic newbus
>support (as you said above, didn't you?).

>/*
> * Switch an irq from a maskptr to another without unregistering the irq
> * handler.
> * This function is supposed to work with only one handler per irq.
> */
>void
>switch_masks(intrmask_t *oldmaskptr, intrmask_t *newmaskptr, int irq)
...

I don't like most of this.  Driver level code won't even know the
correct maskptrs.  (irq, maskptr) pairs depend on i386 implementation
details for uniqueness.  Use { s = splhigh(); BUS_TEARDOWN_INTR(...);
BUS_SETUP_INTR(...); splx(s); } until/unless the newbus level provides
a better interface.  The problem with the masks not being updated when
interrupts are unregistered should be fixed in update*_masks().

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: whereis broken?

[Sheldon Hearn]

On Sun, 25 Jul 1999 14:12:53 -0400, Dan Moschuk wrote:

> whereis anything yields..
> 
> Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!

Staleness. Unfortunately, the whereis(1) manpage doesn't tell you to
look at the manpath(1) manpage. Do so now and you'll see that you should
check your /etc/manpath.config and your $MANPATH environment variable.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

whereis broken?

[Dan Moschuk]

whereis anything yields..

Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!
Warning: couldn't stat file /usr/local/lib/perl5/5.00502/man!

ad infinity.


Cheers,

Dan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PLIP is still broken :(

[Nicolas Souchu]

On Sun, Jul 25, 1999 at 09:35:36AM +1000, Bruce Evans wrote:
>
>>>Possible quick fix (hack): change all the spltty()'s in lpt.c to
>>>splnet()'s.  lpt isn't a tty driver; it just abuses spltty().  Abusing
>>>splnet() instead should work OK for lpt and fix if_plip.
>>
>>This seems good until the intr stuff handle dynamic update of a interrupt spl.
>>Is there some work in progress on that?
>
>Not much.  ppc needs to do most of the work by registering its interrupt
>with the correct interrupt maskptr for the currently attached device.
>This may involve unregistering the interrupt when the device changes.
>The generic code could help here by supporting atomic changing of
>interrupt maskptrs without unregistering the interrupt.  Otherwise,
>the generic code is missing mainly update of the interrupt masks when
>an interrupt is unregistered.

For the low level side, we could consider something like the following code.
But this shall be called by the nexus layer and then needs generic newbus
support (as you said above, didn't you?).

/*
 * Switch an irq from a maskptr to another without unregistering the irq
 * handler.
 * This function is supposed to work with only one handler per irq.
 */
void
switch_masks(intrmask_t *oldmaskptr, intrmask_t *newmaskptr, int irq)
{
int s;
intrec *idesc;
intrmask_t mask = 1 << irq;

if ((oldmaskptr == NULL) || (newmaskptr == NULL))
return;

if (((idesc = find_idesc(oldmaskptr, irq)) == NULL) ||
(find_idesc(newmaskptr, irq) != NULL))
return;

/* block all interrupts */
s = splhigh();

/* update the irq mask ptr */
idesc->maskptr = newmaskptr;

/* remove the irq from the old mask and add it to the new one */
INTRUNMASK(*oldmaskptr, mask);
INTRMASK(*newmaskptr, mask);

/* we need to update all values in the intr_mask[irq] array */
update_intr_masks();
/* update mask in chains of the interrupt multiplex handler as well */
update_mux_masks();

/* restore interrupts */
splx(s);

return;
}

Your opinion?

Nicholas.

-- 
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Zhihui Zhang]

> 
> No.  You can't kill a process which is in kernel mode.  If it doesn't
> come out, you won't be able to stop it.  It seems rather unlikely that
> that's the case here, though.

It seems to me that a process can only suicide after it detects somebody
wants to kill it.  Anyway, it is the process itself that calls exit(). A
process must be runnable to be killed (actually suicide). Am I right?

-Zhihui




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Daniel C. Sobral]

Kris Kennaway wrote:
> 
> Nope. I did attach to it with gdb at one point to try and figure out what
> it was running, but because it was compiled w/o debugging symbols I didn't
> get anything out of a backtrace except for something similar to:

You *can* compile it again, just adding the -g and _without changing
any other option_, and then use that new executable as source of the
symbols.

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"Is it true that you're a millionaire's son who never worked a day
in your life?"
"Yeah, I guess so."
"Lemme tell you, son, you ain't missed a thing."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Amancio Hasty]

> On Sun, 25 Jul 1999, Amancio Hasty wrote:
> 
> > while you are at it try to compile a kernel with symbols ...
> 
> I already have (this is my standard practice). What should I do with it
> here?
> 
> Kris
> 

Well, if the process is not in a zombie state and you can't kill it . We may 
need
to examine the process structure.

Cheers


-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Kris Kennaway]

On Sun, 25 Jul 1999, Amancio Hasty wrote:

> while you are at it try to compile a kernel with symbols ...

I already have (this is my standard practice). What should I do with it
here?

Kris



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Amancio Hasty]

while you are at it try to compile a kernel with symbols ...

-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Kris Kennaway]

On Sun, 25 Jul 1999, Greg Lehey wrote:

> > The tcsh listed below that is a zombie of the running kvt. 
> 
> There aren't any zombies here.  

Right, they'd show up as 'Z' in the state field, I'd guess.

> > This seems to be more of a kvt bug than a freebsd bug. :)
> 
> I don't see that either.  The fact that process 1103 is stopped is one
> thing; is there a gdb process in sight?

Nope. I did attach to it with gdb at one point to try and figure out what
it was running, but because it was compiled w/o debugging symbols I didn't
get anything out of a backtrace except for something similar to:

#0  0x28557c28 in ?? ()
#1  0x804f0c7 in ?? ()
#2  
#3  0x2851f918 in ?? ()
#4  0x8053038 in ?? ()
#5  0x8050273 in ?? ()
#6  0x8056369 in ?? ()
#7  0x28388581 in ?? ()
#8  0x28388369 in ?? ()
#9  0x2838960c in ?? ()
#10 0x283882f5 in ?? ()
#11 0x805dca2 in ?? ()
#12 0x804f020 in ?? ()

(this is from process 92724 which is still running).

I might try and compile kvt with debugging support and see what it's
doing; I think I can repeat the problem at will.

Kris



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: FreeBSD-current and Netscape Java

[Sheldon Hearn]

[Hijacked from the freebsd-current mailing list]

On Sat, 24 Jul 1999 19:46:52 -0400, Bill Pechter wrote:

> Are there any tricks to getting Java in Netscape running with
> FreeBSD --current.  

Just because CURRENT is the platform you use when you encounter a
problem, doesn't mean that the freebsd-current mailing list is the right
place to discuss it.

I'd suggest the freebsd-ports, assuming good old freebsd-questions isn't
good enough for you. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IDE_DELAY

[Sheldon Hearn]

On Sat, 24 Jul 1999 20:26:56 +0200, Thomas Schuerger wrote:

> I've set the option
> 
>   IDE_DELAY=1500

Did you read the warning in LINT about this one?

# Setting this below 1 violate the IDE specs, but may still work for
# you (it will work for most people).

_May_ still work for you implies may not. What happens when you set it
to 1?

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PR 12634

[Sheldon Hearn]

On Sat, 24 Jul 1999 18:47:37 +0200, Nick Hibma wrote:

> PR 12634 mentions the increase of MAXSYMLINKS (src/sys/sys/param.h) to
> 64.

There has to be a limit. Like so many limits, it has to increase as more
and more people bump up against it, provided:

1) They're not bumping up against it just because they've done
   something silly.

2) They've all hiked the limit in question locally and haven't
   observed any problems for a while.

I don't think we clear either of these two with this PR.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unkillable processes

[Greg Lehey]

On Sunday, 25 July 1999 at  1:21:03 -0500, Kevin Day wrote:
>> On Saturday, 24 July 1999 at 20:51:37 -0500, Kevin Day wrote:
 On Sat, 24 Jul 1999, Kevin Day wrote:

> For one, do another 'ps' with the 'l' option, so you can see what it's stuck
> on.

   UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT   TIME COMMAND
  1000  1103  1086  29  75 20  5740  384 -  TWN   ??0:00.00 (kvt)
  1000  1109  1103   0   4  0  15040 ttywri IWs+  p10:00.00 (tcsh)

  1000 92724  1086 279 105 20  5736  356 -  RN??  139:40.13 kvt -T Termi
  1000 92743 92724   2  18  0  15760 pause  IWs   p80:00.00 (tcsh)

>>> Well, since the CPU time in the active process (92724) went up since your
>>> last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the
>>> STAT), it looks like the process is just spinning, eating CPU.
>>
>> Right.
>>
>>> The tcsh listed below that is a zombie of the running kvt.
>>
>> There aren't any zombies here.
>>
>> It's a child of the kvt.  It's not a zombie.  Take a look at the STAT
>> field (and ps(1)): process
>
> Good point, i didn't notice that, i saw the ()'s from his first message,

They mean that ps can't access the command line information, for
example because the process has been swapped.

>> Process 92724 is runnable, nice and running (no WCHAN).  I really
>> don't understand why you can't stop this one.
>
> The only time I've seen this is when my console is getting flooded with
> 'vm_fault: pager error' messages for that process. Otherwise, there's no
> reason why a running process can't be killed, correct?

No.  You can't kill a process which is in kernel mode.  If it doesn't
come out, you won't be able to stop it.  It seems rather unlikely that
that's the case here, though.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message