Re: /dev/audio & /dev/dsp WORK NOW!!!
Thanks
to everybody who answered my questions regarding the non-working
/dev/audio, dev/dsp on my SB16 under linux-2.0.15 .
It proved indeed to be "Device or resource busy"!
NAS was to blame...and me of course!
I found it out, after having recompiled and rebooted the kernel tausend
times. Finally I overcommed my tire and examined the kernel boot and daemon
log messages and see, there it was..."NAS starting...".
I updated Debian recently and have unwillingly marked NAS for installation,
without first asking myself whether I need the raw /dev/audio and
/dev/dsp.
Thanks Ian, your suggestion would have brought me to the point
15 minutes earlier, but I was not on the Net at that time :-) . Thanks
anyway!
> Stoyan Kenderov writes ("/dev/audio & /dev/dsp Device or resource busy ???"):
> ...
> > The sparing comments in the source point to an IRQ or DMA conflict when one
> > gets constant "Device or Resource busy" mesages on each:
> >
> > cat blabla.au > /dev/audioor
> > cat uuhuu.wav > /dev/dsp
>
> Have you installed `nas' (the `network audio system') ? It takes over
> your sound hardware permanently. If you have then deinstall it.
>
> Ian.
>
regards,
Stoyan
PS: It's really very relaxing to know that such a great list stands behind
you, when you are in trouble! Keep the good work!
--
Stoyan Kenderov/
NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 220
Geschaeftsbereich/\ LINK fax: +49 721 9652 210
Vincenz-Priessnitz-Str. 3 /___ email: [EMAIL PROTECTED]
D-76131 Karlsruhe, Germany http://www.xlink.net/~kenderov
PGP Key fingerprint = 72 EC 34 1F BC 74 89 BA FF 74 29 85 40 6B 5C F9
Re: Debian Installation Boot Program missing something
In article <[EMAIL PROTECTED]>,
Bhaskar Manda <[EMAIL PROTECTED]> wrote:
>
>My disk controller seems to be wanting to be "reset", but the
>Debian install boot doesn't do this. As a consequence, it just
>keeps repeating
> hda: hda: Status error: status=0x01 { Error }
> hda: Status error: error=0x04 { DriveStatusError }
> hda: Drive not ready for command.
Oh - oh. This indicates a hardware problem. Either you have a conflict
on the bus, or your harddisk is dying.
>The Slackware install boot on the other hand, does the following.
>
> hda: hda: Status error: status=0x01 { Error }
> hda: Status error: error=0x04 { DriveStatusError }
> hda: Drive not ready for command.
>[.. this error msg is repeated thrice.. ]
> ide0: reset success
> hda1 hda2 hda3
> VFS: Insert root floppy disk to be loaded into ramdisk and press ENTER.
Slackware probably uses an 1.2.13 kernel, while Debian uses 2.0.6. I've
noticed that in some respects the 2.0.x kernel is less forgiving, alas.
>I guess no Debian for me for now.
Shame :) Anyway I would really check your hardware. I would be _really_
scared if I saw that on my screen. If you keep seeing this message you
will experience massive data loss and your system might even get unbootable
(which isn't too strange when your harddisk's dead).
Mike.
--
+ Miquel van Smoorenburg + Cistron Internet Services + Living is a |
| [EMAIL PROTECTED] (SP6) | Independent Dutch ISP | horizontal |
+ [EMAIL PROTECTED] + http://www.cistron.nl/+ fall+
Re: /dev/audio & /dev/dsp Device or resource busy ???
Stoyan Kenderov writes ("/dev/audio & /dev/dsp Device or resource busy ???"):
...
> The sparing comments in the source point to an IRQ or DMA conflict when one
> gets constant "Device or Resource busy" mesages on each:
>
> cat blabla.au > /dev/audioor
> cat uuhuu.wav > /dev/dsp
Have you installed `nas' (the `network audio system') ? It takes over
your sound hardware permanently. If you have then deinstall it.
Ian.
Re: inconsistency/confusion in aout-svgalib of Debian 1.1
Sebastian Kuzminsky writes ("inconsistency/confusion in aout-svgalib of Debian
1.1"):
>I'm not sure this is the right place to send this bug report...
>
>There's an inconsistency in Debian 1.1. When the aout-svgalib
> package is installed, it puts the libary files in
> /usr/i486-linuxaout/lib, but ld.so is not configured to look there for
> libraries, so the aout svgalibs are unusable.
>
>
>There seem to be two simple ways to fix the problem:
>
>* a one-line addition to /etc/ld.so.conf
>* installing the libraries etc in /usr/lib/i486-linuxaout instead
>
>
>I'm not sure which way is The One True Way.
I thought that libc4 was responsible for adding the entry to
ld.so.conf.
Ian.
Re: Source Packages
Haakan Ardoe writes ("Source Packages"):
> how does the source packages work? If I understand everyting right I am
> supposed to unpack them with dpkg-source -x .dsc. But then I need the
> .dsc file, which not seems to be included in any of the availble
> source packages. Where can I find or generate them?
We're still phasing in the new source packages. If there is no .dsc
and .orig.tar.gz you have to just unpack the .tar.gz (and not apply
the .diff.gz).
Ian.
Re: XFree86 3.1.2F plans?
In article <[EMAIL PROTECTED]> you write: > XFree86 3.1.2F is out, according to http://www.xfree86.org. I am > wondering if a Debian package of this beta software will be made > available. Anyone have any plans to make this available??? I do not intend to package any versions of XFree86 other than released versions - i.e. versions for which source is publically available. I believe the next proper release of XFree86 will occur in the next couple of months, but see www.xfree86.org for a better estimate. People who need the functionality in the beta servers should install the new server binary and modify /etc/X11/Xserver to point to the appropriate place. People who need the functionality in the rest of the XFree86 beta will have to install it themselves. It will probably be easiest for you to remove your existing Debian X installation (using the --force-depends option in dpkg wherever necessary), and then when the next set of Debian X packages are released remove the XFree86 beta and install the packages. The X packages are fairly similar to the 'plain' version of XFree86. There are a couple of security fixes applied to the binaries, but the major change is the movement of configuration files from /usr/X11R6/lib/X11 to /etc/X11 in order to comply with the filesystem standard. This is currently accomplished by putting symlinks in appropriate places in /usr/X11R6/lib/X11, rather than modifying the compiled-in paths. Steve Early [EMAIL PROTECTED]
Re: Gcc won't compile :-)
Thanks everybody I didn't have the crt*.o in my lib directory. It should be in the libc-dev*.deb right? Also another question how do I swich ELF compile to a.out compile? I've seen it in the documentation but I thought since I have *.deb it was by default ELF. Thanks again.
Re: dselect 1.3.9: cursor keys locked after search
Martin Dinkloh writes ("dselect 1.3.9: cursor keys locked after search"):
> In dselect 1.3.9 the cursor keys do not work anymore after having done a
> search (with '/').
This is a known bug in ncurses, recorded as #4298, #2962 and #3974.
Ian.
Re: irqtune: improve serial port performance by 3x?
Hi again.. In my never-ending battle to make the kernel behave well by default without needing "irqtune" (which is very setup-specific, and as such not something the kernel can do automatically), I was thinking of doing interrupt priority rotations instead of the current fixed mode. Now, doing a rotating interrupt priority means that the priorities essentially go away completely, which is not the optimal solution (having high serial line priorities is good, no question about it). However, while not exactly optimal, it _is_ a fair solution, and likely to be better than what we currently have. Rotating priorities should also work reasonably well for multiple serial interrupt sources, which irqtune doesn't really handle (depending on what the interrupt numbers are, irqtune can work well, though). Also, unlike irqtune, there shouldn't be any unfairness toward other devices so it should work well under wildly different circumstances. In short, rotating priorities are a reasonable thing to do by default, and I'd like people who have been trying out "irqtune" (and who actually see some differences with it) to try out this very simple patch.. How does this work for you? (This is actually how Linux/alpha has been handling interrupts from the very beginning) Linus - --- v2.0.16/linux/include/asm-i386/irq.hThu Aug 29 19:15:14 1996 +++ linux/include/asm-i386/irq.hSun Sep 1 10:53:04 1996 @@ -90,7 +90,7 @@ "outb %al,$0x21\n\t" \ "jmp 1f\n" \ "1:\tjmp 1f\n" \ - "1:\tmovb $0x60+"#nr",%al\n\t" \ + "1:\tmovb $0xE0+"#nr",%al\n\t" \ "outb %al,$0x20\n\t" #define ACK_SECOND(mask,nr) \ @@ -102,11 +102,11 @@ "outb %al,$0xA1\n\t" \ "jmp 1f\n" \ "1:\tjmp 1f\n" \ - "1:\tmovb $0x60+"#nr",%al\n\t" \ + "1:\tmovb $0xE0+"#nr",%al\n\t" \ "outb %al,$0xA0\n\t" \ "jmp 1f\n" \ "1:\tjmp 1f\n" \ - "1:\tmovb $0x62,%al\n\t" \ + "1:\tmovb $0xE2,%al\n\t" \ "outb %al,$0x20\n\t" #define UNBLK_FIRST(mask) \
Re: Debian Color-ls Command?
On Sat, 31 Aug 1996, Chris Westwood wrote: [SNIP] > *** Excerpt from .bash_profile *** > > # set up color-ls > LS_COLORS='di=1;34:bd=40;33;1:ln=1;36:cd=40;33;1:ex=1;32:*.tar=1;31:*.tgz=1;31:*.gz=1;31:' > export LS_COLORS; > LS_OPTIONS='--8bit --color=tty -F'; > export LS_OPTIONS; > alias ls='/usr/bin/color-ls $LS_OPTIONS '; > alias dir='/usr/bin/color-ls $LS_OPTIONS --format=vertical'; > alias vdir='/usr/bin/color-ls $LS_OPTIONS --format=long'; > alias d=dir; > alias v=vdir; Hi. If the above works on your system, then you are running fileutils-3.12 and my color-ls package which is obsolete as of fileutils-3.13. When you do upgrade to fileutils-3.13, you will need to do something different along the lines of my previous posting. Anyway, I'm glad you have it working. Syrus. -- Syrus Nemat-Nasser <[EMAIL PROTECTED]>UCSD Physics Dept.
Re: Reorganizing linux.* hierachy
In article <[EMAIL PROTECTED]>, Christoph Lameter <[EMAIL PROTECTED]> wrote: >Miquel van Smoorenburg ([EMAIL PROTECTED]) wrote: >: In article <[EMAIL PROTECTED]>, >: Christoph Lameter <[EMAIL PROTECTED]> wrote: >: >I think we should do the following. >: > >: >1. Map all high traffic groups / mailing lists linux.xxx to >: > comp.os.linux.* >: >: No, *please* don't do this with, for example, linux.dev.kernel. It has >: enough junk in it as it is; spreading this through all of usenet will make >: the group useless. The real kernel hackers will find a new mailinglist >: and use that instead (in fact that's already happening at the moment, >: as I understand) and it will leave you with another group with lots of >: traffic and no actual content. >It has content even if the "real kernel hackers" find other ways of discussing >the issues. The group is appearently needed otherwise it would not have that >high a volume. You cannot avoid junk. But you can try to avoid having too much groups around; the equivalent of linux.dev.kernel _is_ comp.os.linux.development.system. What now happens on linux.dev.kernel used to go on on colds, until most real developers moved away from it (for a reason..). You don't want to have someone asking how to use "Z" modem if he has a "Hayes" modem in linux.dev.kernel ;) This point comes up every once in a while; eventually after a lot of discussion it is decided that creating extra newsgroups under c.o.l is a bad idea (I think it wouldn't get through the RFD either) >: Remember linux.* is really a gateway to a mailing list. BTW, do you >: have your moderators file set up right? When I post something in linux.*, >: it shows up on our news server within a matter of _minutes_. You do have >: "linux.*:[EMAIL PROTECTED]" in your moderators file, right? >Exactly. And I have had repeatedly problems with that host rejecting e-mail and >delaying delivery for hours. I have never had a message show up within >minutes. >The reason for the delays might also be my NNTP access. >Is there any location I can draw a faster NNTP feed for linux.* from? >I currently get linux.* via PSI. Ah. We get it from ratatosk.yggdrasil.com directly, that might explain the difference. If you're a few hops away and the hosts in between run innxmit every hour or so a delay of a couple of hours is not unusual. But making the groups unmoderated is not going to change that in any way. It just shows up on your _local_ site immideately. Perhaps you can find out (through the Path: header) who the intermideate sites are, and try to get a feed from a host higher up in the hierarchy. It would be even nicer if they'd use nntplink or innfeed, then you would have almost no delay at all. Mike. -- + Miquel van Smoorenburg + Cistron Internet Services + Living is a | | [EMAIL PROTECTED] (SP6) | Independent Dutch ISP | horizontal | + [EMAIL PROTECTED] + http://www.cistron.nl/+ fall+
Re: Do you use SLIP or a variant with Debian?
I use SLIP because I have been using it for years and would need to reconfigure things to use ppp. Also, SLIP is easy to set up: you set five parameters, and it works -- with PPP, it only really needs one (the phone number) but if it doesn't work, the debugging problem is harder. (SLIP is also more available on unix systems - I run older systems too, and some of them don't have PPP.)
