Re: No sound (Ensoniq Audio PCI 1370)
> I just use: > > device pcm0 > > and no more, since I only have a PCI card. So you reasoned something like This card has nothing to do with ISA, let the PCI routines figure out the parameters by themselves Joachim's Ensoniq driver was the first extension of Luigi's underlying pcm driver for ISA cards towards PCI. Looks like bus issues are not arranged 100%: On my FreeBSD 4.0-CURRENT #10: Fri May 21 19:50:23 CEST 1999 system I changed CONFIG to #device pcm0 at isa? port ? irq 10 drq 1 flags 0x0 device pcm0 at nexus? and got this messages after reboot es0: irq 11 at device 15.0 on pci0 pcm0: using I/O space register mapping at 0x6400 pcm1: unit not configured, perhaps you want pcm0 ? and indeed m...@oranje$ cat /dev/sndstat FreeBSD Audio Driver (981002) May 21 1999 19:50:06 Installed devices: pcm0: at 0x6400 irq 0 dma 0:0 the card is recognized by Luigi's driver. Compare this to what pcm(4) says: device pcm0 ... your first PnP audio card will be unit #1, i.e. it will be accessible as /dev/audio1, /dev/dsp1, etc. Many application default to using /dev/au- dio, so you can create symlinks from /dev/audio etc to the correct device entries as follows: cd /dev rm audio dsp dspW mixer ./MAKEDEV snd1 ln -s audio1 audio ln -s dsp1 dsp ln -s dspW1 dspW ln -s mixer1 mixer (note: the links are laid by MAKEDEV already) instead I had to use unit #0 via ./MAKEDEV snd0 and this way it works OK right now although I think it was not meant to. Regards, Marc To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
Marc van Woerkom wrote: > > > I just use: > > > > device pcm0 > > > > and no more, since I only have a PCI card. > > So you reasoned something like > > This card has nothing to do with ISA, let the PCI routines figure out > the parameters by themselves Exactly -- Eric Hodel hodel...@seattleu.edu "If you understand what you're doing, you're not learning anything." -- A. L. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On Sat, 22 May 1999, Marc van Woerkom wrote: > > I just use: > > > > device pcm0 > > > > and no more, since I only have a PCI card. > > So you reasoned something like > > This card has nothing to do with ISA, let the PCI routines figure out > the parameters by themselves > > Joachim's Ensoniq driver was the first extension of Luigi's underlying > pcm driver for ISA cards towards PCI. > > Looks like bus issues are not arranged 100%: I'm working on it. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
In message <199905192231.qaa09...@narnia.plutotech.com>, "Justin T. Gibbs" writ es: >In article <199905191637.jaa03...@dingo.cdrom.com> you wrote: >> I'm not sure why it happens like this; try putting a DELAY() just >> before we actually set the root device and see if you can put it off. > >Why not just spl() protect that printf call so that its output is >dumped contiguously into the console buffer? Am I missing something here ? We shouldn't set the root device until CAM is done probing, right ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
>In message <199905192231.qaa09...@narnia.plutotech.com>, "Justin T. Gibbs" wri >t >es: >>In article <199905191637.jaa03...@dingo.cdrom.com> you wrote: >>> I'm not sure why it happens like this; try putting a DELAY() just >>> before we actually set the root device and see if you can put it off. >> >>Why not just spl() protect that printf call so that its output is >>dumped contiguously into the console buffer? > >Am I missing something here ? We shouldn't set the root device until >CAM is done probing, right ? CAM has finished probing at this point, but it holds off on announcing devices until it has all necessary info. The drives may need to be spun up, etc. I believe the printf happens before the device has been opened and CAM blocks in the open until the device is really ready for service. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
In message <199905221736.laa08...@pluto.plutotech.com>, "Justin T. Gibbs" write s: >>Am I missing something here ? We shouldn't set the root device until >>CAM is done probing, right ? > >CAM has finished probing at this point, but it holds off on announcing >devices until it has all necessary info. The drives may need to >be spun up, etc. I believe the printf happens before the device has >been opened and CAM blocks in the open until the device is really >ready for service. I think we should hold off the rootdev determination until after the printfs, unless you tell me that this will delay the boot by many seconds in too many cases. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
ES 1370 audio driver and ncr SCSI driver interfere!
> > Joachim's Ensoniq driver was the first extension of Luigi's underlying
> > pcm driver for ISA cards towards PCI.
> >
> > Looks like bus issues are not arranged 100%:
>
> I'm working on it.
Great to hear.
If there is any technical document about FreeBSD drivers and how they should
manage their resources (and that is so recent, that it takes PCI into account)
please tell me. I would like to understand what is going on to help myself -
e.g. the ES1370's MIDI interface is unsupported yet ..
Another remark - I filed a PR some weeks ago where I reported that my
ncr SCSI controller dies during listening to real audio streams.
Friday's -CURRENT still has this problem - but today I observed that it has
nothing special to do with the real player or the Linux emulation layer.
The same ncr confusion happens if I listen to MP3's and have disk activity
(cvsup) at the same time .. so now I believe that it is an interference of
the audio drivers { es0, pcm0 } with ncr0.
Regards,
Marc
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
>>CAM has finished probing at this point, but it holds off on announcing >>devices until it has all necessary info. The drives may need to >>be spun up, etc. I believe the printf happens before the device has >>been opened and CAM blocks in the open until the device is really >>ready for service. > >I think we should hold off the rootdev determination until after the >printfs, unless you tell me that this will delay the boot by many >seconds in too many cases. It will probably add 5->15 seconds for anyone with a cdrom drive with even greater delays for people with more than 2 or 3 devices. There are also devices like scanners and older WORM devices that can take up to a minute to become ready. It seems quite silly to me to hold up booting for devices that are not even referenced during boot. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
In message <199905221811.maa09...@pluto.plutotech.com>, "Justin T. Gibbs" write s: >>>CAM has finished probing at this point, but it holds off on announcing >>>devices until it has all necessary info. The drives may need to >>>be spun up, etc. I believe the printf happens before the device has >>>been opened and CAM blocks in the open until the device is really >>>ready for service. >> >>I think we should hold off the rootdev determination until after the >>printfs, unless you tell me that this will delay the boot by many >>seconds in too many cases. > >It will probably add 5->15 seconds for anyone with a cdrom drive with >even greater delays for people with more than 2 or 3 devices. There >are also devices like scanners and older WORM devices that can take >up to a minute to become ready. It seems quite silly to me to hold >up booting for devices that are not even referenced during boot. Hmm, OK then... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ES 1370 audio driver and ncr SCSI driver interfere!
On Sat, 22 May 1999, Marc van Woerkom wrote: > > > Joachim's Ensoniq driver was the first extension of Luigi's underlying > > > pcm driver for ISA cards towards PCI. > > > > > > Looks like bus issues are not arranged 100%: > > > > I'm working on it. > > Great to hear. > > If there is any technical document about FreeBSD drivers and how they should > manage their resources (and that is so recent, that it takes PCI into account) > please tell me. I would like to understand what is going on to help myself - > e.g. the ES1370's MIDI interface is unsupported yet .. There isn't any such document as yet and some of the interfaces are still in a state of flux. I'm sure that some kind of documentation will be available before 4.0 ships. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
As Doug Rabson wrote ... > On Sat, 15 May 1999, Wilko Bulte wrote: > > > As Doug Rabson wrote ... > > > On Mon, 10 May 1999, Wilko Bulte wrote: > > > > > > > > > > > > > Yeah. That must be why my 164lx won't netboot. > > > > > > > > Could well be. My Aspen Alpine refused to with a DE500. A DE435 (10mbit > > > > only) worked just dandy. > > > > > > That reminds me. Does your Alpine still work after the new-bus stuff? I > > > wasn't sure I hadn't broken it when I changed the apecs driver. > > > > After a buildworld of yesterday's -current and a new kernel things > > work just fine. As an added bonus the serial console seems to work better. > > It used to be very slow, looks like that is gone. > > > > If you want more info you'll have to wait a bit, I'll be offline for > > a week. > > Thats good. The slow serial sounds like it used to be polling (i.e. sio > interrupts weren't getting through). I've been away to Oslo this week, but I plan to bang a bit more on the console to see if it keeps working ok. | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
libg2c.a in -current
Anyone know why libf2c* was renamed to libg2c* in egcs?
Does egcs have a replacement for f2c? Would anyone object
if I installed the header file, g2c.h, along with the
library?
-steve
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile1999/05/01 22:30:14 1.3
+++ Makefile1999/05/22 18:35:59
@@ -120,4 +120,8 @@
@mv ${.TARGET}.tmp ${.TARGET}
.endif
+beforeinstall:
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
+ ${DESTDIR}/usr/include
+
.include
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
FREE Y2K FIX !!! <..,:adv.,,
* * THE GOOD NEWS IS: You can now test your computer for full Y2K compliance,(both BIOS and REAL TIME CLOCKS), and even correct it with a simple inexpensive download. THE GREAT NEWS IS: We offer a FREE TEST & EVALUATION period while you decide whether you want to purchase this solution. No one else offers the comprehensive guarantee that we have for you. For additional information on our free evaluation period, visit our site at: www.freey2kdownload.com * To be removed from this mailing list please reply to: y2kfreetest.com and type REMOVE on the subject line. * To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: priorities
On Fri, 21 May 1999, Doug Rabson wrote:
> > It sounds like we can loads of haggling about the names there... The
> > last one is to take out the dependency on errno being greater than
> > zero.
>
> I would actually quite like to keep the possibility of returning an errno.
> It gives the possibility of returning an appropriate error if something
> strange happened (other than the hardware not being present).
Echo that here. There are few things more annoying than device drivers
that fail for unknown reasons. Even if the error doesn't make sense at
first, we can trace the code back to the true point of failure.
If you've worked on Windows or Macs, you know what I'm talking about
("Device failure" or "Could not switch your connection due to an
error").
Doug White
Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite| www.freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: calcru and upages
>calcru() access p_stats, which is in upages. Therefore, as I understand, >it should not be called on a swapped out process. Neither calcru() nor Does anyone object to moving everything except the stack from the upages to the proc table? Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: calcru and upages
Bruce Evans wrote: > >calcru() access p_stats, which is in upages. Therefore, as I understand, > >it should not be called on a swapped out process. Neither calcru() nor > > Does anyone object to moving everything except the stack from the upages > to the proc table? > > Bruce Well, we have three things that are about the same size: struct pcb u_pcb; 240 bytes struct sigacts u_sigacts; 292 bytes struct pstats u_stats; 248 bytes On the other hand: sizeof (struct proc) = 328 bytes. the pcb contains a heap of space for the FP state. It accounts for 176 of the 240 bytes, leaving 64-odd bytes left for the pcb proper. The ldt pointers need to move to proc scope for rfork()/clone(), and gc'ing a few things that can get it as low as 40 - 48 bytes. pcb_savefpu has padding in case a FPU emulator is used and is actually smaller than 176 bytes, and could be changed depending on whether it's a real or emulated fpu. IMHO, I'd move them to reference counted malloc'ed structs since sigacts needs to be shared for clone/rforked processes. I think there is also benefit to having the sigacts at least malloced, one day we should be able to extend the signals beyond the existing 32 set, at least for the 32 extra RT signals. I personally would love to see this come out of the upages, it makes tracking through a stack overflow even harder. We could put an unmapped red-line page below the bottom stack page to ensure we get a double fault on an overflow instead of mystery corruptions etc. I also think it's a step closer towards seperating thread context vs. process context. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: calcru and upages
In message <199905230245.maa13...@godzilla.zeta.org.au>, Bruce Evans writes: >>calcru() access p_stats, which is in upages. Therefore, as I understand, >>it should not be called on a swapped out process. Neither calcru() nor > >Does anyone object to moving everything except the stack from the upages >to the proc table? not me. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
