ES1370 Sound problems

1999-06-11 Thread Joe Clarke
I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2
system with the hope of getting Luigi's sound driver working with it.  I
added the following line to my kernel:

device  pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0

Then rebooted.  I see the following in my dmesg output:

es1: AudioPCI ES1370 rev 0x00 int a irq 10 on pci0.15.0
pcm1: using I/O space register mapping at 0x1800

which looks good. The card was detected, and pcm1 was bound to it.  Next,
I cd to /dev, and did a ./MAKEDEV snd1.  This built the necessary device
entries.  I cat my /dev/sndstat, and see the following:

FreeBSD Audio Driver (981002) Jun 11 1999 02:46:46
Installed devices:
pcm1: ENSONIQ AudioPCI at 0x1800 irq 0 dma 0:0

So, that looks promising.  However, when I try to play a sound file or
even cat a file to /dev/audio, I get nothing.  Trying to play an mp3 with
mpg123, I get the following:

Can't reset audio!
Can't reset audio!

Is there something I'm missing?  Any input would be greatly appreciated.
Below is the output from pciconf -l and scanpci.

Joe Clarke

pciconf -l:

ch...@pci0:0:0: class=0x06 card=0x chip=0x71908086 rev=0x03
hdr=0x00
ch...@pci0:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x03
hdr=0x01
ch...@pci0:7:0: class=0x060100 card=0x chip=0x71108086 rev=0x02
hdr=0x00
ide_p...@pci0:7:1:  class=0x010180 card=0x chip=0x71118086
rev=0x01 hdr=0x00
no...@pci0:7:2: class=0x0c0300 card=0x chip=0x71128086 rev=0x01
hdr=0x00
ch...@pci0:7:3: class=0x068000 card=0x chip=0x71138086 rev=0x02
hdr=0x00
r...@pci0:14:0:  class=0x02 card=0x1213 chip=0x1213 rev=0x10
hdr=0x00
e...@pci0:15:0:  class=0x040100 card=0x4c4c4942 chip=0x50001274 rev=0x00
hdr=0x00
a...@pci0:16:0: class=0x01 card=0x78819004 chip=0x81789004 rev=0x01
hdr=0x00
v...@pci1:0:0:  class=0x03 card=0x00201545 chip=0x002010de rev=0x04
hdr=0x00

scanpci:

PCI says configuration type 1

PCI probing configuration type 1
Probing for devices on PCI bus 0:


pci bus 0x0 cardnum 0x00 function 0x: vendor 0x8086 device 0x7190
 Intel 82443BX Host

pci bus 0x0 cardnum 0x01 function 0x: vendor 0x8086 device 0x7191
 Intel 82443BX AGP

pci bus 0x0 cardnum 0x07 function 0x: vendor 0x8086 device 0x7110
 Intel 82371AB PIIX4 ISA

pci bus 0x0 cardnum 0x07 function 0x0001: vendor 0x8086 device 0x7111
 Intel 82371AB PIIX4 IDE

pci bus 0x0 cardnum 0x07 function 0x0002: vendor 0x8086 device 0x7112
 Intel 82371AB PIIX4 USB

pci bus 0x0 cardnum 0x07 function 0x0003: vendor 0x8086 device 0x7113
 Intel 82371AB PIIX4 ACPI

pci bus 0x0 cardnum 0x0e function 0x: vendor 0x1113 device 0x1211
 Device unknown

pci bus 0x0 cardnum 0x0f function 0x: vendor 0x1274 device 0x5000
 Ensoniq AudioPCI

pci bus 0x0 cardnum 0x10 function 0x: vendor 0x9004 device 0x8178
 Adaptec 2940U/UW
Probing for devices on PCI bus 1:


pci bus 0x1 cardnum 0x00 function 0x: vendor 0x10de device 0x0020
 NVidia Riva TNT


-- 

Please use Reply-To: address for response.

Joe Clarke, CE |  |
Customer Support Engineer|  |
Phone: (919) 472-2867   ..:|::|:..
Email: jcla...@cisco.com c i s c o  S y s t e m s






To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ES1370 Sound problems

1999-06-11 Thread Luigi Rizzo
 I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2
 system with the hope of getting Luigi's sound driver working with it.  I
 added the following line to my kernel:

 So, that looks promising.  However, when I try to play a sound file or
 even cat a file to /dev/audio, I get nothing.  Trying to play an mp3 with
 mpg123, I get the following:
 
 Can't reset audio!
 Can't reset audio!

first, you might miss symlinks from /dev/dsp-/dev/dsp1 and so on. the
cure for the latter is

cd /dev
./MAKEDEV snd1

first, the volumes default to zero which is not helpful. try

mixer pcm 100

and see if something now comes out

cheers
luigi
---+-
  Luigi RIZZO, lu...@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)

  http://www.iet.unipi.it/~luigi/ngc99/
  First International Workshop on Networked Group Communication  
---+-


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



OSS

1999-06-11 Thread Tomer Weller
i get this error when i try to load soundconf, soundon, soundoff : 
link_elf: symbol cdevsw_module_handler undefined
Failed to load the OSS driver module.
Check that it is not already loaded.

uname -a :
FreeBSD Tomer.DrugsAreGood.org 4.0-CURRENT FreeBSD 4.0-CURRENT #10: Fri Jun 11
13:51:50 IDT 1999 s...@tomer.drugsaregood.org:/usr/src/sys/compile/CURRENT 
i386
==
 Tomer Weller
 s...@i.am
 well...@netvision.net.il
 Drugs are good, and if you do'em 
 pepole think that you're cool, NoFX
 


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Snoop device broken

1999-06-11 Thread Jos Backus
With a kernel built on June 9th, I am seeing the following:

hal:/sys/kern# w -h | grep jos
jos  p1   :0.0 Wed03PM - /usr/local/bin/vim /ho
# watch p1
watch: fatal: cannot attach to tty
#

kdump output:

 25537 watchCALL  open(0xbfbfd8f4,0,0xbfbfd9e4)
 25537 watchNAMI  /dev/snp0
 25537 watchRET   open 3
 25537 watchCALL  stat(0xbfbfd504,0xbfbfd4a4)
 25537 watchNAMI  /dev/ttyp1
 25537 watchRET   stat 0
 25537 watchCALL  ioctl(0x3,SNPSTTY,0x804ac80)
 25537 watchRET   ioctl -1 errno 22 Invalid argument
 25537 watchCALL  ioctl(0,TIOCSETA,0x804b0a0)
 25537 watchRET   ioctl 0
 25537 watchCALL  write(0x2,0xbfbfcd04,0x7)
 25537 watchGIO   fd 2 wrote 7 bytes
   watch: 
 25537 watchRET   write 7
 25537 watchCALL  write(0x2,0xbfbfcd1c,0x1b)
 25537 watchGIO   fd 2 wrote 27 bytes
   fatal: cannot attach to tty
 25537 watchRET   write 27/0x1b
 25537 watchCALL  write(0x2,0xbfbfcd08,0x1)
 25537 watchGIO   fd 2 wrote 1 byte
   
   
 25537 watchRET   write 1
 25537 watchCALL  exit(0x45) 

The following code in sys/kern/tty_snoop.c seems responsible:

tp = snpdevtotty(tdev);
if (!tp)
return (EINVAL);
 
which in turn leads to

static struct tty *
snpdevtotty (dev)
dev_t   dev;
{
struct cdevsw   *cdp;

cdp = devsw(dev);
if (cdp == NULL)
return (NULL);
return ((*cdp-d_devtotty)(dev));
}

Apparently cdp is set to NULL here by the ``devsw(dev)'' call.

I suspect that this issue is related to the recent dev_t changes.

Is anyone else seeing this?


Thanks,
-- 
Jos Backus  _/ _/_/_/  Reliability means never
   _/ _/   _/   having to say you're sorry.
  _/ _/_/_/ -- D. J. Bernstein
 _/  _/ _/_/
jos.bac...@nl.origin-it.com  _/_/  _/_/_/  use Std::Disclaimer;


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ES1370 Sound problems

1999-06-11 Thread Joe Clarke
I upped the volume to 100, but I am still getting the same errors.  Is
there anything else I should try?  I should also mention that when I cat a
file to /dev/audio or /dev/dsp, it immediately returns.  It looks like the
audio devices are nulls.  All the symlinks are correct and snd1 has been
built.  My Vibra16 in my other machine works just find as pcm1.

Joe Clarke

-- 
Joe Clarke, CE |  |
Customer Support Engineer|  |
Phone: (919) 472-2867   ..:|::|:..
Email: jcla...@cisco.com c i s c o  S y s t e m s




On Fri, 11 Jun 1999, Luigi Rizzo wrote:

  I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2
  system with the hope of getting Luigi's sound driver working with it.  I
  added the following line to my kernel:
 
  So, that looks promising.  However, when I try to play a sound file or
  even cat a file to /dev/audio, I get nothing.  Trying to play an mp3 with
  mpg123, I get the following:
  
  Can't reset audio!
  Can't reset audio!
 
 first, you might miss symlinks from /dev/dsp-/dev/dsp1 and so on. the
 cure for the latter is
 
   cd /dev
   ./MAKEDEV snd1
 
 first, the volumes default to zero which is not helpful. try
 
   mixer pcm 100
 
 and see if something now comes out
 
   cheers
   luigi
 ---+-
   Luigi RIZZO, lu...@iet.unipi.it  . Dip. di Ing. dell'Informazione
   http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
   TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
 
 http://www.iet.unipi.it/~luigi/ngc99/
   First International Workshop on Networked Group Communication  
 ---+-
 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ENABLE_SERIAL_BREAK_KEY...or something?

1999-06-11 Thread Mike Nowlin

 boggle
 Are you guys serious about dropping the box by powering off the console ?
 /boggle

Yup...  Pretty dumb, isn't it?

mike




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: OSS

1999-06-11 Thread Vallo Kallaste
On Fri, Jun 11, 1999 at 02:04:38PM +0300, Tomer Weller s...@i.am wrote:

 i get this error when i try to load soundconf, soundon, soundoff : 
 link_elf: symbol cdevsw_module_handler undefined
 Failed to load the OSS driver module.
 Check that it is not already loaded.

It is related to recent changes in -current. You can see lots of 
changes by phk if you read cvs-all list.
-- 

Vallo Kallaste
va...@matti.ee


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Snoop device broken

1999-06-11 Thread Bruce Evans
The following code in sys/kern/tty_snoop.c seems responsible:

tp = snpdevtotty(tdev);
if (!tp)
return (EINVAL);

tdev is *(dev_t *)data, but should be something like
udev2dev(*(udev_t *)data).

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Snoop device broken

1999-06-11 Thread Jos Backus
On Sat, Jun 12, 1999 at 12:38:04AM +1000, Bruce Evans wrote:
 tdev is *(dev_t *)data, but should be something like
 udev2dev(*(udev_t *)data).

I used

udev2dev(*(udev_t *)data, 0)

because udev2dev wants an extra argument (int b) that is no longer used.

Result: watch works :-)

 Bruce

Thanks Bruce!

-- 
Jos Backus  _/ _/_/_/  Reliability means never
   _/ _/   _/   having to say you're sorry.
  _/ _/_/_/ -- D. J. Bernstein
 _/  _/ _/_/
jos.bac...@nl.origin-it.com  _/_/  _/_/_/  use Std::Disclaimer;


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ES1370 Sound problems

1999-06-11 Thread Christian Weisgerber
Joe Clarke jcla...@cisco.com wrote:

 I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2
 system with the hope of getting Luigi's sound driver working with it.
 
 es1: AudioPCI ES1370 rev 0x00 int a irq 10 on pci0.15.0
  ^^^
 pcm1: using I/O space register mapping at 0x1800

At least with 4.0-CURRENT that's a problem. You need to patch
sys/pci/es1370.c, ca. line 150, in struct es_pci_driver. Replace es
by pcm. I then get

pcm0: AudioPCI ES1370 irq 15 at device 9.0 on pci0
pcm0: using I/O space register mapping at 0xe400

on boot-up, and the card is made available correctly.

 Trying to play an mp3 with mpg123, I get the following:
 
 Can't reset audio!
 Can't reset audio!

I get these too, but they don't seem to have any effect. mpg123 works
fine.

-- 
Christian naddy Weisgerber  na...@mips.rhein-neckar.de
carpe librum: books 'n' reviews URL:http://www.carpe.com/buch/



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Further on tape CAM problems

1999-06-11 Thread Christopher T. Johnson
Sorry for the long delay on this.  I finally have working tape again, got
it fixxed about 3 weeks ago.  Upgraded to current as of May 24th and put
the old drive back in.  Everything is working correctly again.  I'm a bit
scared to change out the tape drive for more testing.
Chris


 On Fri, Apr 30, 1999 at 12:36:25AM +0200, Wilko Bulte wrote:
  As Bob Willcox wrote ...
   On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
 On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:

 shipping 8200's (this was right at their end-of-life) was:
 
 MX: 2680
 SV: C034
 
 This is for generic models.  OEM models may have different versions
 due to customizations.

And these are not recommended for general use.
   
   Hmm, why is that?  The newest of the IBM branded Exabyte 8200's that I
  
  That is what I've been told by an Exabyte engineer years back. I can only
  guess that some OEMs need adaptations to the firmware behaviour that are
  incompatible with what the rest of the world needs (or has standardised
  on, e.g. in the ANSI SCSI standard). Again, guessing.
 
 Well, I can only speak for the IBM OEM'd drives that I have (as a
 retired IBMer, I've been picking them up at their employee surplus
 store here in Austin, TX).  For these drives the generic firmware works
 just fine.  I can see why Exabyte wouldn't openly recommend the change
 though.
 
 Back in the late 80's, when I was still working for IBM on AIX, I do
 recall that we did have some customizations in the firmware for the
 RS/6K AIX systems.  In addition to changing the Inquiry command Vendor
 ID data, I believe there were some functional changes (I don't recall
 the details).  I have always suspected that the functional changes are
 likely what made the IBM OEM'd drives fail on FreeBSD!  The upgraded
 firmware IBM drives work on both (as Other SCSI Tape Drive).
 
  
   have have precisely these firmware levels in them (2680  C034).  Also,
  
  Mine works OK with that f/w. Not that I use the 8200 often anymore, 
  I like my DLT4000 much better than the 8200. ;-)
 
 I much prefer my Exabyte Mammouth drives as well  :-)
 
 (But I do seem to get some fun out of playing with the 8200's I get for
 $10 apiece from the surplus store :-)
 
 Bob
 
 -- 
 Bob Willcox The man who follows the crowd will usually get no
 b...@luke.pmr.comfurther than the crowd.  The man who walks alone is
 Austin, TX  likely to find himself in places no one has ever
 been.-- Alan Ashley-Pitt
 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: use of MMAP in new INN code...

1999-06-11 Thread Richard Michael Todd
In message pine.bsf.4.05.9906091450270.49155-100...@thelab.hub.orgMarc 
Fournier writes:
 I'm currently investigating a problem with my server that
 coincedentally(sp?) started right after I upgraded INN to what we
 currently have...
 
 Someone *just* suggested that they thought that 3.2-STABLE of FreeBSD
 still has a slight bug in MMAP that causes a race condition...it just
 clued into me that Richard(?) sent out that response to me about Clayton
 using mmap() more now in nnrpd to share active?

Sigh.  Well, I said earlier that I hadn't seen that problem on 3.1-STABLE.
Well, I spoke too soon.  I came in today and saw innd locked in an unkillable
wait on vmpfw.  I provoked a crash dump out of the system, and managed to
get the following info out of gdb, if this is helpful to anyone. 
I've still got the corefile around if anyone has suggestions on where to look
further.

P.S. is there any easier way to get process struct addresses out of kgdb other
than to keep doing p (struct proc 
*)curproc-p_list-le_next-p_list-le_next...
until you find the process struct you're looking for?

Script started on Fri Jun 11 12:15:26 1999
Warning: imported path contains relative components
skywalker# gdb -k kernel.gdb /var/crash/vmcore.3
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 3477504
initial pcb at 2da934
panic messages:
---
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) p *(struct proc *)0xf62e03c0
$1 = {p_procq = {tqe_next = 0x0, tqe_prev = 0xf02dacd4}, p_list = {
le_next = 0xf62df1e0, le_prev = 0xf62158c8}, p_cred = 0xf1014fc0, 
  p_fd = 0xf0f3ff80, p_stats = 0xf6516214, p_limit = 0xf0cdb200, 
  p_upages_obj = 0xf64527f8, p_procsig = 0xf1014260, p_flag = 5, 
  p_stat = 3 '\003', p_pad1 = \000\000, p_pid = 87154, p_hash = {
le_next = 0xf62e2a40, le_prev = 0xf0c589c8}, p_pglist = {
le_next = 0xf62167e0, le_prev = 0xf1015a68}, p_pptr = 0xf6218e60, 
  p_sibling = {le_next = 0xf62e07e0, le_prev = 0xf6218eb0}, p_children = {
lh_first = 0xf62167e0}, p_ithandle = {callout = 0xf357d290}, p_oppid = 0, 
  p_dupfd = 0, p_vmspace = 0xf62d8980, p_estcpu = 43, p_cpticks = 0, 
  p_pctcpu = 0, p_wchan = 0xf04dd610, p_wmesg = 0xf02af73a vmpfw, 
  p_swtime = 24351, p_slptime = 22360, p_realtimer = {it_interval = {
  tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, 
  p_runtime = 162720418, p_switchtime = {tv_sec = 571212, tv_usec = 964442}, 
  p_uticks = 17177, p_sticks = 3063, p_iticks = 576, p_traceflag = 0, 
  p_tracep = 0x0, p_siglist = 524544, p_textvp = 0xf6440880, 
  p_lock = 1 '\001', p_oncpu = 0 '\000', p_lastcpu = 0 '\000', 
  p_pad2 = 0 '\000', p_locks = 0, p_simple_locks = 0, p_stops = 0, 
  p_stype = 0, p_step = 0 '\000', p_pfsflags = 0 '\000', p_pad3 = \000, 
  p_retval = {0, 134813312}, p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, 
  p_oldsigmask = 0, p_sig = 0, p_code = 0, p_sigmask = 0, 
  p_priority = 0 '\000', p_usrpri = 60 '', p_nice = 0 '\000', 
  p_comm = innd\000tart\000\000\000\000\000\000\000, p_pgrp = 0xf1015a60, 
---Type return to continue, or q return to quit---
  p_sysent = 0xf02c4244, p_rtprio = {type = 1, prio = 0}, p_addr = 0xf6516000, 
  p_md = {md_regs = 0xf6517fbc}, p_xstat = 0, p_acflag = 1, p_ru = 0x0, 
  p_nthreads = 0, p_aioinfo = 0x0, p_wakeup = 0, p_peers = 0x0, 
  p_leader = 0xf62e03c0, p_asleep = {as_priority = 0, as_timo = 0}}
(kgdb) proc 0xf62e03c0
(kgdb) bt
#0  mi_switch () at ../../kern/kern_synch.c:830
#1  0xf015e70d in tsleep (ident=0xf04dd610, priority=0, 
wmesg=0xf02af73a vmpfw, timo=0) at ../../kern/kern_synch.c:448
#2  0xf021f356 in vm_fault (map=0xf62d8980, vaddr=68872, 
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:308
#3  0xf0248e76 in trap_pfault (frame=0xf6517fbc, usermode=1, eva=690002184)
at ../../i386/i386/trap.c:816
#4  0xf02489f6 in trap (frame={tf_es = -272695257, tf_ds = -272695257, 
  tf_edi = 136365588, tf_esi = 136896512, tf_ebp = -272640264, 
  tf_isp = -162431004, tf_ebx = 140668256, tf_edx = 0, tf_ecx = 0, 
  tf_eax = 690002184, tf_trapno = 12, tf_err = 4, tf_eip = 134553715, 
  tf_cs = 31, tf_eflags = 66054, tf_esp = -272641860, tf_ss = 39})
at ../../i386/i386/trap.c:358
#5  0x8052073 in ?? ()
#6  0x805b282 in ?? ()
#7  0x805c5c4 in ?? ()
#8  0x805ccba in ?? ()
#9  0x8057e00 in ?? ()
#10 0x805ad36 in ?? ()
#11 0x804e521 in ?? ()
(kgdb) fr 2
#2  0xf021f356 in vm_fault (map=0xf62d8980, vaddr=68872, 
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:308
308 tsleep(fs.m, PSWP, vmpfw, 0);
(kgdb) l
303 unlock_things(fs);
304 s = 

Re: sysinstall manpage installation question

1999-06-11 Thread David O'Brien
On this machine, the sysinstall manpage is not installed onto
 the system during make world.

Yes, it is because ``make world'' does not build  install sysinstall.
Thus you do not get the manpage.  I was going to add the manpage to the
normal ``make world'', but I could not find a clean place to put it in
/usr/src/Makefile.inc1

-- 
-- David(obr...@nuxi.com  -or-  obr...@freebsd.org)


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: tcp_wrapper in contrib and ports?

1999-06-11 Thread David O'Brien
 Are not there  any other uses for it? Like  xinetd? If everything else
 (the libwrap, the man pages) is there, why not install the tcpd as well?

BECAUSE IT IS NOT NEEDED by the base system.
 
-- 
-- David(obr...@nuxi.com  -or-  obr...@freebsd.org)


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: tcp_wrapper in contrib and ports?

1999-06-11 Thread Mikhail Teterin
David O'Brien once wrote:

  Are not  there any other uses  for it? Like xinetd?  If everything
  else (the libwrap, the man pages) is there, why not install the tcpd
  as well?
 
 BECAUSE IT IS NOT NEEDED by the base system.

It's Ok, no  need to yell. There  are a number of things,  not needed by
the system, that are in the system.  Not just the fortran and xtend, but
also, say, bc(1) or cal(1). It may be usefull, and it requires no effort
to have -- in fact, it probably needed some effort to be ripped out. But
most importantly, it is hard to  _add_ gracefuly to an installed system.
Porter will have to work hard to make the tcp_wrapper port work with the
system libwrap, while having two libwrap-s is just plain ugly.

-mi


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



newbus, sio performance and 'the worst interrupt culprit'

1999-06-11 Thread George Michaelson

I too have current (as of last week), newbus, and sio as well as pcm0

I see heaps of lost interrupts. 

The mail archive has one message saying newbus broke fast interrupts'
but no (not much?) followup to clarify (a) if its still true and (b)
what exactly it implies for finding which driver is stealing the
interrupt cycle time and causing byteloss on the serial ports.

Can somebody provide a canonical answer to why for some people the
serial driver performance is off right now?

cheers
-George


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Real Producer and FreeBSD

1999-06-11 Thread Joseph T. Klein
Has anyone gotten real producer to run under FreeBSD, or am
I to resort to Linux?
--
j...@titania.net [arin-jk70]


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Real Producer and FreeBSD

1999-06-11 Thread Daniel C. Sobral
Joseph T. Klein wrote:
 
 Has anyone gotten real producer to run under FreeBSD, or am
 I to resort to Linux?

Whatever is you are calling a producer (in my vocabulary, it is a
resource generation agent), if there is one that runs on Linux, why
not use it under FreeBSD?

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

Given infinite time, 100 monkeys could type out the complete works
of Shakespeare.
Win 98 source code? Eight monkeys, five minutes.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message