Re: pcm(4) related panic
On Nov 25, Don Lewis wrote:
On 25 Nov, Don Lewis wrote:
On 25 Nov, Artur Poplawski wrote:
Artur Poplawski [EMAIL PROTECTED] wrote:
Hello,
On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic
like this:
Sleeping on swread with the following non-sleepable locks held:
exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \
/usr/src/sys/dev/sound/pcm/dsp.c:146
This enables the panic.
panic: sleeping thread (pid 583) owns a non-sleepable lock
Then the panic happens when another thread tries to grab the mutex.
The problem is that the pcm code attempts to hold a mutex across a call
to uiomove(), which can sleep if the userland buffer that it is trying
to access is paged out. Either the buffer has to be pre-wired before
calling getchns(), or the mutex has to be dropped around the call to
uiomove(). The amount of memory to be wired should be limited to
'sz' as calculated by chn_read() and chn_write(), which complicates the
logic. Dropping the mutex probably has other issues.
Following up to myself ...
It might be safe to drop the mutex for the uiomove() call if the code
set flags to enforce a limit of one reader and one writer at a time to
keep the code from being re-entered. The buffer pointer manipulations
in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
protected by the mutex. If this can be made to work, it would probably
be preferable to wiring the buffer. It would have a lot less CPU
overhead, and would work better with large buffers, which could still be
allowed to page normally.
Don,
I never would have suspected that uio might sleep and panic,
thanks for the clue.
Artur,
Could you try the attached patch.
Thanks,
--Mat
--
Any idiot can face a crisis; it is this day-to-day living
that wears you out.
- Chekhov
--- channel.c Sun Nov 9 04:17:22 2003
+++ /sys/dev/sound/pcm/channel.cWed Nov 26 02:21:14 2003
@@ -250,6 +250,8 @@
{
int ret, timeout, newsize, count, sz;
struct snd_dbuf *bs = c-bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
/*
@@ -291,7 +293,22 @@
sz = MIN(sz, buf-uio_resid);
KASSERT(sz 0, (confusion in chn_write));
/* printf(sz: %d\n, sz); */
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 togo 0) {
+ p = sndbuf_getfreeptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_acquire(bs, NULL, t);
+ }
+ ret = 0;
+#endif
if (ret == 0 !(c-flags CHN_F_TRIGGERED))
chn_start(c, 0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm(4) related panic
Mathew Kanner [EMAIL PROTECTED] wrote: On Nov 25, Don Lewis wrote: On 25 Nov, Don Lewis wrote: On 25 Nov, Artur Poplawski wrote: Artur Poplawski [EMAIL PROTECTED] wrote: Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: Sleeping on swread with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. Following up to myself ... It might be safe to drop the mutex for the uiomove() call if the code set flags to enforce a limit of one reader and one writer at a time to keep the code from being re-entered. The buffer pointer manipulations in sndbuf_dispose() and sndbuf_acquire() would probably still have to be protected by the mutex. If this can be made to work, it would probably be preferable to wiring the buffer. It would have a lot less CPU overhead, and would work better with large buffers, which could still be allowed to page normally. Don, I never would have suspected that uio might sleep and panic, thanks for the clue. Artur, Could you try the attached patch. I've tried the patch -- and it works great! :-) I was unable to trigger the panic with the patch applied, although I tried really hard -- so I guess the problem is solved. Mat and Don, I'm really very thankful for your help. Best regards, Artur ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm(4) related panic
Artur Poplawski [EMAIL PROTECTED] wrote: Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: (watch out for folded lines; the stack backtrace below is rewritten by hand from ddb) lock order reversal 1st 0xc22a45ac vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc06c0420 swap_pager swhash (swap_pager swhash) @ \ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace witness_lock _mtx_lock_flags obj_allock slab_zalloc uma_zone_slab uma_zalloc_internal uma_zalloc_arg swp_pager_meta_build swap_pager_putpages default_pager_putpages vm_pageout_flush vm_pageout_clean vm_pageout_scan vm_pageout fork_exit fork_trampoline Sleeping on swread with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 panic: sleeping thread (pid 583) owns a non-sleepable lock syncing disks, buffers remaining... 1410 1410 panic: mi_switch: \ switch in a critical section Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep [... repeated few more times] Fatal double fault: eip = 0xc05e3916 esp = 0xc8db8ff4 ebp = 0xc8db9004 panic: double fault Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s [...] And the machine suddenly reboots, so there is no coredump. eip address points close to: c05e3910 T sc_vtb_putc To reproduce this panic just start some audio player app (like xmms), and launch countless memory-eating applications (like mozilla ;). The machine starts swapping, and it panics. % uname -a FreeBSD kaszanka.domek 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 01:23:10\ CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA i386 dmesg fragments: CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU) pcm0: AudioPCI ES1373-B port 0xec00-0xec3f irq 10 at device 8.0 on pci0 pcm0: Cirrus Logic CS4297A AC97 Codec rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem \ 0xdf00-0xdfff ir q 10 at device 10.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem \ 0xde00-0xdeff ir q 10 at device 11.0 on pci0 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto In the meantime I've managed to get a coredump, by directly calling doadump() from ddb. Results: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA# gdb -k kernel.debug /var/crash/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as i386-undermydesk-freebsd... panic: sleeping thread (pid 568) owns a non-sleepable lock panic messages: --- panic: sleeping thread (pid 568) owns a non-sleepable lock syncing disks, buffers remaining... panic: msleep Dumping 128 MB 16 32 48 64 80 96 112 --- Reading symbols from /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/netgraph.ko...done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_pppoe.ko...done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/ng_socket.ko...done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/mga.ko...done. Loaded symbols for /boot/kernel/mga.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04292cd in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xc8dba7bc à×hÀ) at /usr/src/sys/ddb/db_command.c:548 #2 0xc042906a in db_command
Re: pcm(4) related panic
On 25 Nov, Artur Poplawski wrote: Artur Poplawski [EMAIL PROTECTED] wrote: Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: Sleeping on swread with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm(4) related panic
On 25 Nov, Don Lewis wrote: On 25 Nov, Artur Poplawski wrote: Artur Poplawski [EMAIL PROTECTED] wrote: Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: Sleeping on swread with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. Following up to myself ... It might be safe to drop the mutex for the uiomove() call if the code set flags to enforce a limit of one reader and one writer at a time to keep the code from being re-entered. The buffer pointer manipulations in sndbuf_dispose() and sndbuf_acquire() would probably still have to be protected by the mutex. If this can be made to work, it would probably be preferable to wiring the buffer. It would have a lot less CPU overhead, and would work better with large buffers, which could still be allowed to page normally. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm exclusive sleep mutex with Oct19 CURRENT
Hello Paolo,
See below.
On Oct 20, Paolo Pisati wrote:
from my dmesg:
[snip]
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @
/usr/src/sys/dev/sound/pcm/mixer.c:322
Could you try deleting the snd_mtxlock and snd_mtxunlock in
mixer_hwvol_init() in mixer.c? I think it's uneeded as the function
is only called in particular device instance creation and no-one
should be able touch it yet.
acquiring duplicate lock of same type: pcm channel
1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
Stack backtrace:
Please try my wild guess patch that is attached. I tried to
re-arrange the routine to only hold one locked channel at a time. I
suppose another option would be flag the lock type as having
duplicates ok.
--Mat
--
If you optimize everything, you will always be unhappy.
- Don Knuth
--- dspold.cSun Sep 14 17:49:38 2003
+++ dsp.c Tue Oct 21 14:38:44 2003
@@ -174,6 +174,8 @@
intrmask_t s;
u_int32_t fmt;
int devtype;
+ int rdref;
+ int error;
s = spltty();
d = dsp_get_info(i_dev);
@@ -209,6 +211,8 @@
panic(impossible devtype %d, devtype);
}
+ rdref = 0;
+
/* lock snddev so nobody else can monkey with it */
pcm_lock(d);
@@ -251,67 +255,66 @@
return EBUSY;
}
/* got a channel, already locked for us */
- }
-
- if (flags FWRITE) {
- /* open for write */
- wrch = pcm_chnalloc(d, PCMDIR_PLAY, td-td_proc-p_pid, -1);
- if (!wrch) {
- /* no channel available */
- if (flags FREAD) {
- /* just opened a read channel, release it */
- pcm_chnrelease(rdch);
- }
- /* exit */
- pcm_unlock(d);
- splx(s);
- return EBUSY;
- }
- /* got a channel, already locked for us */
- }
-
- i_dev-si_drv1 = rdch;
- i_dev-si_drv2 = wrch;
-
- /* Bump refcounts, reset and unlock any channels that we just opened,
-* and then release device lock.
-*/
- if (flags FREAD) {
if (chn_reset(rdch, fmt)) {
pcm_chnrelease(rdch);
i_dev-si_drv1 = NULL;
- if (wrch (flags FWRITE)) {
- pcm_chnrelease(wrch);
- i_dev-si_drv2 = NULL;
- }
pcm_unlock(d);
splx(s);
return ENODEV;
}
+
if (flags O_NONBLOCK)
rdch-flags |= CHN_F_NBIO;
pcm_chnref(rdch, 1);
CHN_UNLOCK(rdch);
+ rdref = 1;
+ /*
+* Record channel created, ref'ed and unlocked
+*/
}
+
if (flags FWRITE) {
- if (chn_reset(wrch, fmt)) {
- pcm_chnrelease(wrch);
- i_dev-si_drv2 = NULL;
- if (flags FREAD) {
- CHN_LOCK(rdch);
- pcm_chnref(rdch, -1);
- pcm_chnrelease(rdch);
- i_dev-si_drv1 = NULL;
- }
- pcm_unlock(d);
- splx(s);
- return ENODEV;
+ /* open for write */
+ wrch = pcm_chnalloc(d, PCMDIR_PLAY, td-td_proc-p_pid, -1);
+ error = 0;
+
+ if (!wrch)
+ error = EBUSY; /* XXX Right return code? */
+ else if (chn_reset(wrch, fmt))
+ error = ENODEV;
+
+ if (error != 0) {
+ if (wrch) {
+ /*
+* Free play channel
+*/
+ pcm_chnrelease(wrch);
+ i_dev-si_drv2 = NULL;
}
- if (flags O_NONBLOCK)
- wrch-flags |= CHN_F_NBIO;
- pcm_chnref(wrch, 1);
- CHN_UNLOCK(wrch);
+ if (rdref) {
+ /*
+* Lock, deref and release previously created record channel
+*/
+ CHN_LOCK(rdch);
+ pcm_chnref(rdch, -1);
+ pcm_chnrelease(rdch);
+ i_dev-si_drv1 = NULL;
+ }
+
+ pcm_unlock(d);
+ splx(s);
+ return error;
+ }
+
+ if (flags O_NONBLOCK)
+ wrch-flags |= CHN_F_NBIO;
+ pcm_chnref(wrch,
Re: pcm exclusive sleep mutex with Oct19 CURRENT
On Mon, Oct 20, 2003 at 07:15:19PM +0200, Paolo Pisati wrote: from my dmesg: [snip] pcm0: ESS Technology Allegro-1 port 0xb800-0xb8ff irq 5 at device 1.0 on pci2 pcm0: failed to enable memory mapping! pcm0: ESS Technology ES1988 AC97 Codec malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 Unfortunately none of the sound developers have been interested in looking at the locking problems in the code. acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 Stack backtrace: with no backtrace at all. FWIW, the backtrace would have been reported on the system console. Kris pgp0.pgp Description: PGP signature
Re: pcm exclusive sleep mutex with Oct19 CURRENT
On Mon, Oct 20, 2003 at 10:37:00AM -0700, Kris Kennaway wrote: Unfortunately none of the sound developers have been interested in looking at the locking problems in the code. =( acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 Stack backtrace: with no backtrace at all. FWIW, the backtrace would have been reported on the system console. righty right kris, here we go: backtrace(c0836d0c,c2d41754,c0a257d1,c3,246) at backtrace+0x17 witness_lock(c2d347c0,8,c0a257d1,c3,c2d34500) at witness_lock+0x672 _mtx_lock_flags(c2d347c0,0,c0a257d1,c3,3) at _mtx_lock_flags+0xba pcm_chnalloc(c2d1f400,1,9e7c,,8) at pcm_chnalloc+0x56 dsp_open(c08f10f0,803,2000,c340d130,c06947a2) at dsp_open+0x19f spec_open(cf175a68,cf175b24,c069c6b2,cf175a68,0) at spec_open+0x30b spec_vnoperate(cf175a68,0,c08fe0e0,c340d130,c392b248) at spec_vnoperate+0x18 vn_open_cred(cf175bd8,cf175cd8,0,c3ef6880,20) at vn_open_cred+0x432 vn_open(cf175bd8,cf175cd8,0,20,c08f7b30) at vn_open+0x30 kern_open(c340d130,8ae2050,0,803,0) at kern_open+0x140 open(c340d130,cf175d10,c084f404,3ed,3) at open+0x30 syscall(1002f,893002f,bfbf002f,29a975b5,8ae2058) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5), eip = 0x2853ed3f, esp = 0xbfbfb4fc, ebp = 0xbfbfb518 --- and backtrace(c0836dc3,c102f110,c08497be,c08497be,c0849659) at backtrace+0x17 witness_lock(c102f110,8,c0849659,148,0) at witness_lock+0x672 _mtx_lock_flags(c102f110,0,c0849659,148,3) at _mtx_lock_flags+0xba _vm_map_lock(c102f0b0,c0849659,148,c08f5de0,2b4) at _vm_map_lock+0x36 kmem_malloc(c102f0b0,1000,101,ce70a810,c07996f7) at kmem_malloc+0x3a page_alloc(c103a3c0,1000,ce70a803,101,c083326a) at page_alloc+0x27 slab_zalloc(c103a3c0,1,8,c084afa2,68c) at slab_zalloc+0xb7 uma_zone_slab(c103a3c0,1,c084afa2,68c,0) at uma_zone_slab+0xe6 uma_zalloc_internal(c103a3c0,0,1,0,c101f470) at uma_zalloc_internal+0x3e bucket_alloc(44,1,c084afa2,70b,0) at bucket_alloc+0x5e uma_zfree_arg(c101f3c0,ce77ae04,0,778,0) at uma_zfree_arg+0x2c6 swp_pager_meta_free_all(c30e5cb8,c0848f76,c0848edb,21a) at swp_pager_meta_free_a ll+0xf2 swap_pager_dealloc(c30e5cb8,1,c084af06,104,0) at swap_pager_dealloc+0x11a vm_pager_deallocate(c30e5cb8,0,c084a0eb,260,c084afa2) at vm_pager_deallocate+0x3 d vm_object_terminate(c30e5cb8,0,c084a0eb,207,c062d650) at vm_object_terminate+0x2 03 vm_object_deallocate(c30e5cb8,c2ee8d98,c30e5cb8,c2ee8d98,ce70a9c8) at vm_object_ deallocate+0x371 vm_map_entry_delete(c16d59d8,c2ee8d98,c0849834,8b6,0) at vm_map_entry_delete+0x3 b vm_map_delete(c16d59d8,0,bfc0,c16d59d8,c16d59d8) at vm_map_delete+0x383 vm_map_remove(c16d59d8,0,bfc0,356,804f2c4) at vm_map_remove+0x55 exec_new_vmspace(ce70ab88,c08c7ac0,c0830c69,296,0) at exec_new_vmspace+0x235 exec_elf32_imgact(ce70ab88,0,c08318b5,ff,c08f77e8) at exec_elf32_imgact+0x1b0 kern_execve(c2d38980,8051080,bfbffd1c,804f2c0,0) at kern_execve+0x38c execve(c2d38980,ce70ad10,c084f404,3ed,3) at execve+0x30 syscall(2f,2f,2f,1,bfbffd1c) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (59), eip = 0x280d683f, esp = 0xbfbffd0c, ebp = 0xbfbffd38 --- hope this helps. -- Paolo Italian FreeBSD User Group: http://www.gufi.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCM freezes the box
Is anything printed on the console (or the first vty)? Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ Nope. I get complete blackout - I'm unable to switch vtys, move mouse, start a new process, etc. Just like a crash in Windows - only reset button works. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCM freezes the box
On Thu, 7 Aug 2003 [EMAIL PROTECTED] wrote: I have problems with my 5.1-Release and 5.1-STABLE boxes: they freeze if I play anything different from audio CDs. The cards are ESS 1938, options pcm is in the kernel. If I try to run xmms/mpg123/KDE or any other application related with artsd/esound/audiofile, the machines freeze, leaving not a single chance to escape to shell and kill the process. Is anything printed on the console (or the first vty)? Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm breakage
I'm definitely seeing this, and I assumed it's related to my witness complain about cmi (though it only started recently -- but, then, this message has only been added recently, afaik). I have no sound problems, though. In between crashes for other problems, that is. La Temperanza wrote: I haven't seen a message about this show up yet, so I'm thinking it may be an isolated glitch. I rebuilt my system this morning to try and solve some spurious reboots while using X, and ended up with this message being spammed about ten times on startup. /usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/sound.c:191 When I attempt to play any sound now, an annoying high-pitched whine comes out the speakers until the process is terminated, and the dmesg buffer is overwritten by hundreds of instances of this unhelpful message- pcm0: pci error. XMMS quits properly, but console commands like 'cat /dev/urandom /dev/dsp' seem to lock out Ctrl-C and need to be killed from another shell. My exact environment: FreeBSD tomoyo.sakura 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Tue Feb 25 10:14:41 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TOMOYO i386 Some (possibly) relevant devices: acpi0: AMIINT SiS735XX on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7760 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcm0: Creative EMU10K1 port 0xd800-0xd81f irq 11 at device 11.0 on pci0 pcm0: TriTech TR28602 ac97 codec I hope someone can figure this out. Let me know if I can do more to diagnose the problem. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The secret of success is sincerity. Once you can fake that you've got it made. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm remaining problem (possible ACPI too)
Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. uname -av is FreeBSD cartier.home 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Dec 4 23:07:36 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 Kernel config is simply a modified GENERIC, with options SMP, APIC_IO, and ident GENERI. Below is what I've got in my dmesg. Complete dmesg is at http://fatpipi.cirx.org/~clive/cartier_dmesg.txt lock order reversal 1st 0xc6992900 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc0524600 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 wakeup from sleeping state (slept 00:02:06) ata0: resetting devices .. done I think the real problem is in pcm on MP system as you said, IRQ 9 maybe shared with pcm0 and acpi. Could you show me this? # acpidump | grep SCI_INT Also, I'd like to see which acpi event was occured on ramdom sleep. Backtrace is helpful to track this down. Press Ctrl+Alt+Esc into DDB, enter db b acpi_SetSleepState to set break point, then send me the output of db t when the ramdom sleep is occurred. BTW, you can set ignoring some of acpi events like this: # sysctl hw.acpi.power_button_state=NONE # sysctl hw.acpi.sleep_button_state=NONE # sysctl hw.acpi.lid_switch_state=NONE acpi0: RCCRCCNILE on motherboard # I worry about this... :P Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm remaining problem (possible ACPI too)
On Sat, Dec 07, 2002 at 01:00:44AM +0800, Clive Lin wrote: Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. [deleted] I updated my -CURRENT, with uname -av below: FreeBSD cartier.home 5.0-RC FreeBSD 5.0-RC #0: Sat Dec 7 02:40:46 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 This does not help anything. But, if I disable ACPI in BIOS, everything is fine. No more sleep. The dmesg output without ACPI is at: http://fatpipi.cirx.org/~clive/cartier_dmesg_no_ACPI.txt Clive To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pcm / mic
A Creative Soundblaster PCI64 (Ensoniq Audio PCI)... $cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: AudioPCI ES1370 at io 0xd000 irq 10 (1p/1r/0v channels duplex default) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Long, Scott Sent: Thursday, April 18, 2002 10:23 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: pcm / mic Hi, i cant record from /dev/dsp with the record device 'mic'. Is there support for the microphone input? What sound card are you using? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pcm / mic
Hi, i cant record from /dev/dsp with the record device 'mic'. Is there support for the microphone input? What sound card are you using? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm?
--- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- msg37284/pgp0.pgp Description: PGP signature
Re: pcm?
Hiten Pandya wrote: --- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Well I don't have any dmesg log from my old install. I use ac97 Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm?
At 04:30 PM 4/15/2002 +0100, you wrote: --- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- I am trying to get my SB Audigy working under -CURRENT as well. Is there going to be any support for it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCM sound problems in -current ??
I'm having problems with both an internal VIA'686 and a PCI base ESS Solo1, both seem to loose interrupts. The interrupts doesn't even show up in a vmstat -i / systat so something is definitly wrong. BTW the exact same HW work just fine with -stable ? while i've not tested either of these chips for a while (lack of slots, anyone know of a motherboard with ~20 pci and ~10 isa slots?) i can't think of any changes that might cause this except possibly the introduction of INTR_TYPE_AV - and then only if you're using modules and your modules are built from newer source than your kernel. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCM sound problems in -current ??
It seems Cameron Grant wrote: I'm having problems with both an internal VIA'686 and a PCI base ESS Solo1, both seem to loose interrupts. The interrupts doesn't even show up in a vmstat -i / systat so something is definitly wrong. BTW the exact same HW work just fine with -stable ? while i've not tested either of these chips for a while (lack of slots, anyone know of a motherboard with ~20 pci and ~10 isa slots?) i can't think of any changes that might cause this except possibly the introduction of INTR_TYPE_AV - and then only if you're using modules and your modules are built from newer source than your kernel. Maybe you should test them now :) Anyhow, the VIA driver doesn't use INTR_TYPE_AV it uses 0, and a quick grep amongst the pci sound card drivers reveals that 0, .._AV, .._MPSAFE is used in a way that doesn't make sense to me at least... To make it short I tried playing with those, no effect i still get the dreaded channel dead message. An no I dont use modules, its all compiled into the kernel.. And yes, its still works in -stable... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCM sound problems in -current ??
In message 006501c0fa71$7fa71a40$0504020a@haveblue Cameron Grant writes: : while i've not tested either of these chips for a while (lack of slots, : anyone know of a motherboard with ~20 pci and ~10 isa slots?) i can't think : of any changes that might cause this except possibly the introduction of : INTR_TYPE_AV - and then only if you're using modules and your modules are : built from newer source than your kernel. We use 15 ISA slot passive backplanes at work. But we make them ourselves. I have seen these in industrial control catalogs in the past. The most PCI slots I've seen is 7. I take that back, I did once see a specialized motherboard with 4 or 5 PCI buses, each with 4 slots. But that was made my a different company for its own private use. Something to do with data gathering or signal replication. I'm not completely sure. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pcm driver and DEVFS
Hello, Thank you for advices. Now I obtain same environment as of pre-devfs days. From: Alex Kapranoff [EMAIL PROTECTED] Date: Fri, 2 Feb 2001 15:29:09 +0300 Yep. I have these in my /etc/rc.devfs: = ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer = This produces almost exactly same environment both with DEVFS and without. I tried this solusion. Everything around sound drivers works. But, the another solution From: John Baldwin [EMAIL PROTECTED] Date: Fri, 02 Feb 2001 11:33:34 -0800 (PST) Add 'hw.snd.unit=1' to /boot/loader.conf. also works fine. The links suggested by the above also created automatically. In order to examin this, I commented out the lines looks like: ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer and reboot the system, I found actually /dev/dsp, /dev/audio and so on. Finally, please let me point out that there are no description about hw.snd.unit MIB in sysctl(8) manpage yet. Thanks!! koya To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm driver and DEVFS
On Fri, Feb 02, 2001 at 04:11:29PM +0900, Yoshihiro Koya wrote: Hello, I did make world a couple days ago. The system was built from cvsup'd source on Jan 30: -- elf make world started on Tue Jan 30 06:23:38 JST 2001 -- The system uses DEVFS. But I have some issue around sound drivers. I usually use mpg123(Version 0.59r (1999/Jun/15)) or x11amp(version 0.8). Before using DEVFS, I was able to adjust sound volume in the sophisticated manner. But, after installing DEVFS, I wasnt adjust sound volume. It might be difficult to run x11amp with DEVFS. On the other hand, mpg123 works. But, its sound is too loud. Added to this, before install DEVFS, I found /dev/dsp1 or /dev/dsp0 in /dev. But I only found the different kind of files: % ls /dev [skip] The files /dev/dsp1.0 and /dev/dsp1.1 are new to me. Of course, I tried to do % x11amp -e /dev/dsp1.0 % x11amp -e /dev/dsp1.1 % x11amp -e /dev/dspW1.0 % x11amp -e /dev/dspW1.1 But in vain. Does some have solution or suggestion? Yep. I have these in my /etc/rc.devfs: = ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer = This produces almost exactly same environment both with DEVFS and without. -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 32 days in the brand new millenium... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pcm driver and DEVFS
On 02-Feb-01 Yoshihiro Koya wrote: Hello, I did make world a couple days ago. The system was built from cvsup'd source on Jan 30: -- elf make world started on Tue Jan 30 06:23:38 JST 2001 -- The system uses DEVFS. But I have some issue around sound drivers. I usually use mpg123(Version 0.59r (1999/Jun/15)) or x11amp(version 0.8). Before using DEVFS, I was able to adjust sound volume in the sophisticated manner. But, after installing DEVFS, I wasnt adjust sound volume. It might be difficult to run x11amp with DEVFS. On the other hand, mpg123 works. But, its sound is too loud. Added to this, before install DEVFS, I found /dev/dsp1 or /dev/dsp0 in /dev. But I only found the different kind of files: % ls /dev acd0a cuala0 ptyp0 ttyv3 acd0c dsp1.0 ptyp1 ttyv4 ad0 dsp1.1 random ttyv5 ad0s1g dspW1.0 sndstat ttyv6 ad0s2a dspW1.1 stderr@ ttyv7 ad0s2b fd/ stdin@ ttyv8 ad0s2e fd0 stdout@ ttyv9 ad0s2f io sysmousettyva apm kbd0tty ttyvb apmctl klogttyd0 ttyvc audio1.0kmemttyid0 ttyvd audio1.1log@ttyld0 ttyve bpsm0 mem ttyp0 ttyvf console mixer1 ttyp1 tun0 consolectl nullttyv0 urandom cuaa0 pci ttyv1 vga@ cuaia0 psm0ttyv2 zero The files /dev/dsp1.0 and /dev/dsp1.1 are new to me. Of course, I tried to do % x11amp -e /dev/dsp1.0 % x11amp -e /dev/dsp1.1 % x11amp -e /dev/dspW1.0 % x11amp -e /dev/dspW1.1 But in vain. Does some have solution or suggestion? Add 'hw.snd.unit=1' to /boot/loader.conf. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm driver and DEVFS
On Fri, Feb 02, 2001 at 04:11:29PM +0900, Yoshihiro Koya wrote: Hello, I did make world a couple days ago. The system was built from cvsup'd source on Jan 30: -- elf make world started on Tue Jan 30 06:23:38 JST 2001 -- The system uses DEVFS. But I have some issue around sound drivers. I usually use mpg123(Version 0.59r (1999/Jun/15)) or x11amp(version 0.8). Before using DEVFS, I was able to adjust sound volume in the sophisticated manner. But, after installing DEVFS, I wasnt adjust sound volume. It might be difficult to run x11amp with DEVFS. On the other hand, mpg123 works. But, its sound is too loud. Added to this, before install DEVFS, I found /dev/dsp1 or /dev/dsp0 in /dev. But I only found the different kind of files: % ls /dev [skip] The files /dev/dsp1.0 and /dev/dsp1.1 are new to me. Of course, I tried to do % x11amp -e /dev/dsp1.0 % x11amp -e /dev/dsp1.1 % x11amp -e /dev/dspW1.0 % x11amp -e /dev/dspW1.1 But in vain. Does some have solution or suggestion? Yep. I have these in my /etc/rc.devfs: = ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer = This produces almost exactly same environment both with DEVFS and without. Strange. I have a stock rc.devfs and get the above links too :-) $ cd /sys/dev/sounds/pcm $ fgrep make_dev_alias *.c sound.c:dsp = make_dev_alias(pdev, "dsp"); sound.c:dspW = make_dev_alias(pdev, "dspW"); sound.c:audio = make_dev_alias(pdev, "audio"); sound.c:mixer = make_dev_alias(pdev, "mixer"); -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 32 days in the brand new millenium... -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. On Fri, Jan 19, 2001 at 11:42:32PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Sean Kelly writes: : I did not have this behavior in -STABLE, but now I do since I upgraded : to -CURRENT. -current's interrupt latency is horrible these days, which seems to manifest itself in problem with the sound driver. I have a -current laptop and get all kinds of artifacts on it. I have a laptop that is running -stable and has 1/3 the power of the -current laptop and plays w/o a hitch. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
If it helps at all, it's marginal. I still get skips. On Sat, Jan 20, 2001 at 05:36:08PM +0200, Mark Murray wrote: This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
OK, please try this, then; change the HARVEST_RING_SIZE in sys/dev/random/yarrow.h to a smaller power-of-2 (256 or 128 would be good), and let me know how that helps-or-not. Thanks! M If it helps at all, it's marginal. I still get skips. On Sat, Jan 20, 2001 at 05:36:08PM +0200, Mark Murray wrote: This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
In message [EMAIL PROTECTED] Sean Kelly writes: : I did not have this behavior in -STABLE, but now I do since I upgraded : to -CURRENT. -current's interrupt latency is horrible these days, which seems to manifest itself in problem with the sound driver. I have a -current laptop and get all kinds of artifacts on it. I have a laptop that is running -stable and has 1/3 the power of the -current laptop and plays w/o a hitch. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm SoundBlaster Live! PCI card
Are you really using the latest FREEBSD_5.0_CURRENT ? I have just device pcm in my kernel config (without PNPBIOS) and the SBLive works fine (many thanks to Cameron for his nice driver). Make sure that the line dev/sound/pci/emu10k1.c optional pcm pci is not commented (in /usr/src/sys/conf/files) norbert Kent Hauser wrote: Hi all, I can't for the life of me get my new gateway computer to make any noise (at least with FreeBSD). I've tried all the PNP/nonPNP combinations from LINT (and then some). The card is a "Creative Labs Soundblaster Live!" PCI card. The gateway blurb is found on: http://www.gateway.com/mes/default.asp?page=soundcards The sound config lines dmesg output are attached. Any pointers would be greatly appreciated. Thanks a bunch. Kent = options PNPBIOS device pcm device sbc device csa device pca0 at isa? port IO_TIMER1 = Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Apr 5 19:14:25 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GW Calibrating clock(s) ... TSC clock: 696358058 Hz, i8254 clock: 1193099 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon (696.41-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x00462000 - 0x040fcfff, 63549440 bytes (15515 pages) 0x0410 - 0x07ff7fff, 66027520 bytes (16120 pages) avail memory = 126103552 (123148K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6a90 bios32: Entry = 0xfd780 (c00fd780) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x203 pnpbios: Found PnP BIOS data at 0xc00f6ae0 pnpbios: Entry = f:9e33 Rev = 1.0 Other BIOS signatures found: ACPI: 000f6ac0 Preloaded elf kernel "kernel" at 0xc0449000. Pentium Pro MTRR support enabled md0: Malloc disk Creating DISK md0 Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base f800, size 26, enabled found- vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base 1400, size 4, enabled found- vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base 10c0, size 5, enabled found- vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 7000, size 4, enabled found- vendor=0x14f1, dev=0x1036, revid=0x08 class=07-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=5 map[10]: type 1, range 32, base f400, size 16, enabled map[14]: type 1, range 32, base 1410, size 3, enabled found- vendor=0x1102, dev=0x0002, revid=0x07 class=04-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base 10e0, size 5, enabled found- vendor=0x1102, dev=0x7002, revid=0x07 class=09-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 map[10]: type 3, range 32, base 1418, size 3, enabled found- vendor=0x105a, dev=0x4d38, revid=0x01 class=01-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base 1430, size 3,
Re: pcm use /dev/dsp to where?
I am using the new pcm driver which works great, however, I managed to remove the ln -s to dsp. I do not know what it was linked and 'sh MAKEDEV snd' links dsp to dsp. How can I fix this? pcm0: AudioPCI ES1371 port 0xef00-0xef3f irq 7 at device 16.0 on pci0 ^ sh MAKEDEV snd0 (you would use 'snd1' if your card was detected as pcm1, etc). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm use /dev/dsp to where?
Thanks Steve, That did it, I figured it was something minor I had screwed up. Aaron On Mon, 13 Mar 2000, Steve Coltrin wrote: I am using the new pcm driver which works great, however, I managed to remove the ln -s to dsp. I do not know what it was linked and 'sh MAKEDEV snd' links dsp to dsp. How can I fix this? pcm0: AudioPCI ES1371 port 0xef00-0xef3f irq 7 at device 16.0 on pci0 ^ sh MAKEDEV snd0 (you would use 'snd1' if your card was detected as pcm1, etc). - Aaron Hughes - [EMAIL PROTECTED] - For public PGP key: finger [EMAIL PROTECTED] - Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm on Thinkpad 600E
Christopher T. Griffiths stated: Hello, I am trying to get the pcm device to work under current on my Thinkpad 600e. Here is my kernel line: # Sound card support device pcm0at isa? port ? irq 5 drq 1 flags 0x10 I also made the device in /dev with: ./MAKEDEV snd0 Here is the kernel output that I am getting: csa0: Crystal Semiconductor CS4610/4611 Audio accelerator mem 0x5000-0x500 f,0x5010-0x50100fff irq 11 at device 6.0 on pci0 pcm0: CS461x PCM Audio on csa0 pcm0: ac97 codec reports dac not ready Any Ideas?? Chris- This a PCI card all you should need is: device pcm0 device csa0 and you may want/need to add options PNPBIOS I have installed -current on a Thinkpad 570. This seems to work fine for audio cd's (the mixer portion); however, I get nothing but silence from the /dev/audio or /dev/dsp (things like waveplay and realaudio are noops for me :( ) S --- Sean O'ConnellEmail: [EMAIL PROTECTED] Institute of Statistics and Decision Sciences Phone: (919) 684-5419 Duke University Fax: (919) 684-8594 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:15:39PM -0800, R Joseph Wright wrote: In 4.0, the pcm sound driver works with my es1371 chipset soundcard for playing cds. But I cannot play mp3s. When I use mpg123, I get the error message "can't open /dev/dsp!" This is an improvement over 3.4, however, where I could not get pcm to work at all. The first pcm device is now pcm0 not pcm1 for PCI devices. Did you do a "MAKEDEV snd0" after upgrading. My es1371 is working great streaming mp3s off of my.mp3.com using xmms. Beautiful. Thank you :) What about for isa cards? Which one is used for them now? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
The first pcm device is now pcm0 not pcm1 for PCI devices. Did you do a "MAKEDEV snd0" after upgrading. My es1371 is working great streaming mp3s off of my.mp3.com using xmms. Beautiful. Thank you :) What about for isa cards? Which one is used for them now? See the output of dmesgt for the pcm[0-9] device that attaches to it. Then check what the /dev/ entries say. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. I actually do not have an isa sound card, I was merely curious because in 3.x, pcm0 was reserved for isa cards and pcm1 was used for pci. Is it now set up so that it doesn't matter whether the card is isa or pci, you just use pcm0? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, Feb 23, 2000 at 03:26:07PM -0800, R Joseph Wright wrote: On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. I actually do not have an isa sound card, I was merely curious because in 3.x, pcm0 was reserved for isa cards and pcm1 was used for pci. Is it now set up so that it doesn't matter whether the card is isa or pci, you just use pcm0? Basicaly, yes. The current system avoids skipping numbers where the old one would skip entries where you had provided isa probe hints, but there wasn't a card there. I believe there was some talk about changing things so device hints mean something like, "if there is a device matching these parameters use this entry, otherwise, don't." This would allow things like wiring devices to slots on PCI. It is possiably I misunderstood the proposal and it certaintly won't make it into 4.0. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
I too notice these problems of mpg123 skipping during disk activity or X graphics ops but I have always had these problems, both with -STABLE and -CURRENT. I notice this with xmms too. So this is nothing new. Isn't this simply a typical issue of IDE hardware? I too notice xmms skipping on heavy disk activity (typically the find command that runs from cron at 01:59). This happens even though I have two processors and a disk that can do 16 Mb/sec on UDMA66. One would expect such a system to be able to do a find and play mp3's simultaneously. Pressing Ctrl-Z repeats the same quarter second fragment forever. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
Nick Hibma wrote: Pressing Ctrl-Z repeats the same quarter second fragment forever. I know the pcm driver uses a circular buffer. Maybe a small chunk of the sound gets stuck in the buffer, and when you press ^Z, the app is unable to tell the sound driver to break out of the loop. Also, RealPlayer still repeats a small fragment over and over when the data flow is interrupted due to net congestion. This is RealPlayer 5, though... - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
On Sat, 29 Jan 2000, Nick Hibma wrote: I too notice these problems of mpg123 skipping during disk activity or X graphics ops but I have always had these problems, both with -STABLE and -CURRENT. I notice this with xmms too. So this is nothing new. Isn't this simply a typical issue of IDE hardware? I too notice xmms skipping on heavy disk activity (typically the find command that runs from cron at 01:59). This happens even though I have two processors and a disk that can do 16 Mb/sec on UDMA66. One would expect such a system to be able to do a find and play mp3's simultaneously. Pressing Ctrl-Z repeats the same quarter second fragment forever. And 'fg' doesn't always make it continue properly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm
Just to let someone know, my ViBRA16X is still having the problem with static. i've replicated it, but have no idea of the cause. i'll probably rework the sb driver when i rip it and the ess driver apart, but that will wait until i get an ess card. - cameron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
Nick Hibma writes: The output of my ESS 1869 stutters whenever there is no new data fed to it. For example pressing Ctrl-Z, or heavy disk usage (normally making mpg123 jump). The stuttering is repetition of one short fragment of about a quarter of a second, indefinitely Anything I can try with this machine current as of jan.24 02:00 GMT? I don't know much about sound, but it seems like pcm doesn't deal very gracefully with underflow. I have a very wimpy machine (133MHz P5 laptop): CPU: Pentium/P54C (133.64-MHz 586-class CPU) ... sbc0: ESS ES1688 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1 on isa0 pcm0: SB DSP 3.01 (ESS mode) on sbc0 I cannot play anything with amp -- the song starts to stutter after a second or two of play. I can use mgp123 which (I think) uses a more efficient decoder. Using mpg123, I see the same symptoms as you report. RealPlayerG2 seems to do better than amp. Especially if I tell it to "disable custom sampling rates." But still not as good as mpg123. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
It is rumoured that Devin Butterfield had the courage to say: I too notice these problems of mpg123 skipping during disk activity or X graphics ops but I have always had these problems, both with -STABLE and -CURRENT. I notice this with xmms too. So this is nothing new. Isn't this simply a typical issue of IDE hardware? I too notice xmms skipping on heavy disk activity (typically the find command that runs from cron at 01:59). This happens even though I have two processors and a disk that can do 16 Mb/sec on UDMA66. One would expect such a system to be able to do a find and play mp3's simultaneously. However, AFAIK the IDE hardware typically handles only one request at a time and handles all requests sequentially, contrary to scsi. It may thus happen that the read requests from xmms, small as they may be, get delayed too long and unnecessary. I'm not an expert on this, but I believe scatter/gather is the way scsi handles this problem in hardware. Perhaps the ata driver could be made to do something similar on the driver level. I have experienced significantly better responsiveness during high disk usage of much slower systems that are running with scsi disks only. In fact, I have a 486 that has better response times (it has an EISA bus and adaptec 2740 scsi with a disk that can do -- and does! -- 8 Mb/sec disk-memory) than my Abit BP6 dual celeron UDMA66 system during the cron job at 1:59. Regards, Dave Boers. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
Nick Hibma wrote: The output of my ESS 1869 stutters whenever there is no new data fed to it. For example pressing Ctrl-Z, or heavy disk usage (normally making mpg123 jump). The stuttering is repetition of one short fragment of about a quarter of a second, indefinitely I can confirm this. Whenever there is any substantial disk activity, the output of mpg123 starts to jump and quiver (and sometimes skip). Why would disk activity do this? Must be an issue with bus latency, because the ata and sound driver are trying to access the bus at the same time. Also, it seems like certain graphics ops in XFree86 3.9.17 make mpg123 jump and skip. Strangely, RealPlayer doesn't suffer from these problems. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - stutters
On Tue, 25 Jan 2000, Donn Miller wrote: Nick Hibma wrote: The output of my ESS 1869 stutters whenever there is no new data fed to it. For example pressing Ctrl-Z, or heavy disk usage (normally making mpg123 jump). The stuttering is repetition of one short fragment of about a quarter of a second, indefinitely I can confirm this. Whenever there is any substantial disk activity, the output of mpg123 starts to jump and quiver (and sometimes skip). Why would disk activity do this? Must be an issue with bus latency, because the ata and sound driver are trying to access the bus at the same time. Also, it seems like certain graphics ops in XFree86 3.9.17 make mpg123 jump and skip. Strangely, RealPlayer doesn't suffer from these problems. I too notice these problems of mpg123 skipping during disk activity or X graphics ops but I have always had these problems, both with -STABLE and -CURRENT. I notice this with xmms too. So this is nothing new. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
According to [EMAIL PROTECTED]: (I couldn't find the device to create in /dev except for /dev/snd0 and /dev/snd1, so that is what I made.) Bad. Just use "sh MAKEDEV snd0". It will create suitable devices (old Voxware, pcm and newpcm all use the same devices) for any sound card. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, Mike Smith wrote:
On Dec 24, [EMAIL PROTECTED] wrote:
On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
I'm getting the following when I enabled pcm and sbc in the kernel:
unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0
sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0
sbc0: alloc_resource
device_probe_and_attach: sbc0 attach returned 6
unknown1: PnP Sound Chip at port 0x208-0x20f on isa0
unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
I changed sys/dev/sound/isa/sbc.c to
{0x0120, "Avance Logic ALS120 -00"},
{0x0121, "Avance Logic ALS120 -01"},
and got
sbc0: Avance Logic ALS120 -00 at port 0x220-0x22f irq 5 drq 1,0 on\
isa0
sbc0: setting card to irq 5, drq 1, 0
pcm0: SB DSP 4.02 on sbc0
sbc1: Avance Logic ALS120 -01 at port 0x388-0x38f on isa0
sbc1: alloc_resource
device_probe_and_attach: sbc1 attach returned 6
That was silly. The -00 device is a soundblaster, but the -01 device
certainly isn't. 8)
Sorry, I don't follow. Is leaving the -01 device in there
silly? I just assumed that it for something in the first place. (Not
my card, somebody elses)
--Mat
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, Mike Smith wrote:
On Dec 24, [EMAIL PROTECTED] wrote:
On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
I'm getting the following when I enabled pcm and sbc in the kernel:
unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0
sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0
sbc0: alloc_resource
device_probe_and_attach: sbc0 attach returned 6
unknown1: PnP Sound Chip at port 0x208-0x20f on isa0
unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
I changed sys/dev/sound/isa/sbc.c to
{0x0120, "Avance Logic ALS120 -00"},
{0x0121, "Avance Logic ALS120 -01"},
and got
sbc0: Avance Logic ALS120 -00 at port 0x220-0x22f irq 5 drq 1,0 on\
isa0
sbc0: setting card to irq 5, drq 1, 0
pcm0: SB DSP 4.02 on sbc0
sbc1: Avance Logic ALS120 -01 at port 0x388-0x38f on isa0
sbc1: alloc_resource
device_probe_and_attach: sbc1 attach returned 6
That was silly. The -00 device is a soundblaster, but the -01 device
certainly isn't. 8)
Sorry, I don't follow. Is leaving the -01 device in there
silly? I just assumed that it for something in the first place. (Not
my card, somebody elses)
It's definitely silly, since it's not a soundblaster and trying to attach
the soundblaster driver to it is pointless (and may be harmful).
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, [EMAIL PROTECTED] wrote:
On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
I'm getting the following when I enabled pcm and sbc in the kernel:
unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0
sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0
sbc0: alloc_resource
device_probe_and_attach: sbc0 attach returned 6
unknown1: PnP Sound Chip at port 0x208-0x20f on isa0
unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
I changed sys/dev/sound/isa/sbc.c to
{0x0120, "Avance Logic ALS120 -00"},
{0x0121, "Avance Logic ALS120 -01"},
and got
sbc0: Avance Logic ALS120 -00 at port 0x220-0x22f irq 5 drq 1,0 on\
isa0
sbc0: setting card to irq 5, drq 1, 0
pcm0: SB DSP 4.02 on sbc0
sbc1: Avance Logic ALS120 -01 at port 0x388-0x38f on isa0
sbc1: alloc_resource
device_probe_and_attach: sbc1 attach returned 6
unknown6: PnP Sound Chip at port 0x200-0x207 on isa0
unknown7: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
--Mat
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Fri, 24 Dec 1999 [EMAIL PROTECTED] wrote:
unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0
sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0
sbc0: alloc_resource
device_probe_and_attach: sbc0 attach returned 6
unknown1: PnP Sound Chip at port 0x208-0x20f on isa0
unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
Try this patch. I had the exact problem with my ALS 110, and I
submitted a patch fixing an error in the device number. I suspect
that all of the ALS devices end with 0, not 1. I didn't want to
submit it with the ALS 120 fix because I couldn't test it.
--- /usr/src/sys/dev/sound/isa/sbc.cTue Dec 21 20:38:03 1999
+++ sbc.c Fri Dec 24 12:24:59 1999
@@ -200,13 +200,13 @@
{0x42008c0e, "Creative SB AWE64"}, /* CTL0042 */
{0x43008c0e, "Creative ViBRA16X"}, /* CTL0043 */
{0x44008c0e, "Creative SB AWE64 Gold"}, /* CTL0044 */
{0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
{0x0110, "Avance Asound 110"}, /* @@@1001 */
- {0x0121, "Avance Logic ALS120"},/* @@@2001 */
+ {0x0120, "Avance Logic ALS120"},/* @@@2001 */
{0x68187316, "ESS ES1868"}, /* ESS1868 */
{0x69187316, "ESS ES1869"}, /* ESS1869 */
{0xacb0110e, "ESS ES1869 (Compaq OEM)"},/* CPQb0ac */
{0x79187316, "ESS ES1879"}, /* ESS1879 */
{0x88187316, "ESS ES1888"}, /* ESS1888 */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
Hi, On Fri, Dec 24, 1999 at 08:52:51AM -0500, [EMAIL PROTECTED] wrote: unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0 sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0 sbc0: alloc_resource device_probe_and_attach: sbc0 attach returned 6 unknown1: PnP Sound Chip at port 0x208-0x20f on isa0 unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0 Up until now, I have been using the OSS drivers, but they no longer work (errors with link_elf: symbol register_intr undefined) Ihave the same card, and it was working (sort of) in my kernel (Nov 20). This was before the sbc commits. But it's seen as an SBPro when it's really ab SB 16, so it doesn't do 16-bit stereo at 44kHz. The think the best I saw reported was 8-bit at 22kHz. In case anyone cares, there seems to be fairly complete documtation at http://www.avance.com/avance/download.htm, but sound cards are a bit out of my league. This isn't a big thing for me, but I thought I would mention it. Not for me either, the pass through from my CD-ROM started working with the +- Nov 20 commits, and that's all I use it for... It only cost $10, so if anyone wants one I'll see if I can find one and ship it. If you need it 'smuggled' into the UK, then yell quickly and I'll try to organise it on Monday with a friend heading in that direction. Regards, -Jeremy -- |- --+-- "What a crazy world we live in, | we save the whales yet support abortion" - MIC |- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, [EMAIL PROTECTED] wrote:
On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
I'm getting the following when I enabled pcm and sbc in the kernel:
unknown0: PnP Sound Chip at port 0x220-0x22f irq 5 drq 1,0 on isa0
sbc0: Avance Logic ALS120 at port 0x388-0x38f on isa0
sbc0: alloc_resource
device_probe_and_attach: sbc0 attach returned 6
unknown1: PnP Sound Chip at port 0x208-0x20f on isa0
unknown2: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
I changed sys/dev/sound/isa/sbc.c to
{0x0120, "Avance Logic ALS120 -00"},
{0x0121, "Avance Logic ALS120 -01"},
and got
sbc0: Avance Logic ALS120 -00 at port 0x220-0x22f irq 5 drq 1,0 on\
isa0
sbc0: setting card to irq 5, drq 1, 0
pcm0: SB DSP 4.02 on sbc0
sbc1: Avance Logic ALS120 -01 at port 0x388-0x38f on isa0
sbc1: alloc_resource
device_probe_and_attach: sbc1 attach returned 6
That was silly. The -00 device is a soundblaster, but the -01 device
certainly isn't. 8)
unknown6: PnP Sound Chip at port 0x200-0x207 on isa0
That's probably the joystick port (you can check that by adding the joy0
driver).
unknown7: PnP Sound Chip at port 0x330-0x331 irq 9 on isa0
And that's the Midi interface, I'd guess.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm driver breakage
[Followup to myself] With the latest changes to the pcm driver, a downgrade of channel.c to 1.8 doesn't help any more: I cannot hear anything while playing something (in my case with mpg123). A verbose output of mpg123 shows me that the application seems to hang after a few write()'s to the sound device (with no sound output). There also doesn't seem to be any interrupt activity on the pcm interrupt. Two days before (but with rev 1.8 of channel.c) I could play any pcm file I have with only some noise at the end if I interrupt mpg123 with ^C. Here the latest configuration information (I can post full output if requested). Kernel config: [...] device pcm0 device sbc0 options PNPBIOS [also without PNPBIOS but with device sbc0at isa? port 0x220 irq 5 drq 1 flags 0x10 no difference] dmesg output from a verbose boot: sbc0: ESS ES1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: SB DSP 3.01 on sbc0 pcm: setmap 3, ff00; 0xcd4b5000 - 3 pcm: setmap 4, ff00; 0xcd4c5000 - 4 Daniel "D. Rock" wrote: Hi, something broke between rev 1.8 and 1.9 of /sys/dev/sound/pcm/channel.c The driver probes as a: pcm0: ESS1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 The relevant kernel config entries are device pcm0 options PNPBIOS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - I can only get noice from it
My collegue just made my day :-) device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15 did it. /Jesper On Mon, Nov 29, 1999 at 03:22:45PM +0100, Jesper Skriver wrote: Hi, Just managed to get hold of a old Soundblaster 16 card, but I can only get noice from it when I try to play som mp3 files ... It's found upon boot like pcm0: SoundBlaster 16 4.13 at port 0x220-0x22f irq 5 drq 1 on isa0 I have it wired in the kernel config file, if I don't it wont find it (I have controller pnp0 in there too), it's like device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x0 Any ideas ? /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm/ES1370 PCI soundcard problem
According to Marc van Woerkom: device pcm0 at pci0 in the kernel configuration file. Try device pcm0 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm oddity
On Fri, Sep 24, 1999 at 11:52:26PM -0400, Wes Morgan wrote: I noticed a little quirk in the pcm driver -- it is reversing the channels in my sb16! The first couple times I play a certain mp3 that starts out (normally) in the left channel, it plays correctly in the left channel. Then suddenly it will switch, and start out in the right channel. My kernel is -current as of late sept 22. Can anyone else duplicate this? Hi, I can reproduce your findings. I run regular buildworld every few days. I have been having this problem for at least two weeks (and possibly before, I have been away for a few months and was stuck with Irix). An easy way to reproduce the problem is to start x11amp and hit play several times. I also found several other "quirks" in the pcm driver while I was programming: 1. If I read() from /dev/dsp in 16 bits single channel mode, I get rubbish even if the mic and igain mixers are set to zero. If I read some 8 bits single channel data just before you read the 16 bits data, the problem disappears. Seems to be an initialization problem. 2. Reading large blocks from /dev/dsp (like 8192 bytes), generates a kernel panic (uiomove failed). Cutting down the blocksize to 256 bytes appears to solve the problem. Maybe something overflowing or a timing problem. 3. If I change the mixer setttings using ioctl() calls for /dev/dsp, then the settings for /dev/mixer do not change accordingly. I have an original Sb16 PnP. I am running smp for dual celeron on an Abit mainboard. Maybe someone wants to look into this, as I don't have any device driver programming experience (and little time to learn also). Best wishes, Dave. -- Dave J. Boers [EMAIL PROTECTED] I will *NOT* read email sent to Graduate student of Theoretical Physics [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm, bktr, etc....
On Fri, 3 Sep 1999, Kenneth Culver wrote: Also, my bios is really freaky. It refuses to assign any irqs except 10 and 11 to installed PCI devices. I can't figure it out. I've completely rearranged everything and it still refuses to work properly. The BIOS usually lets you mark IRQs as 'reserved for legacy ISA' or 'auto'. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm, bktr, etc....
On Fri, 3 Sep 1999, Kenneth Culver wrote: Also, my bios is really freaky. It refuses to assign any irqs except 10 and 11 to installed PCI devices. I can't figure it out. I've completely rearranged everything and it still refuses to work properly. The BIOS usually lets you mark IRQs as 'reserved for legacy ISA' or 'auto'. That doesn't help anything. It just picks 2 different IRQs and assigns them to everything. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm, bktr, etc....
On Fri, 3 Sep 1999, Kenneth Culver wrote: What motherboard? What version of BIOS? Is the BIOS version the latest? Well, I figured it out I think. It is Award BIOS, and it's the latest version. I have 2 VooDoo 2's and at the place I had them, they were causing problems, I moved them, and now everything works fine. I still had to remove the Vortex though, it wasn't working right. This is a board with 5 PCI slots right? If so then you are aware that 1 of the slots is a 'clone' of the other and only cards that can cope with sharing PCI INT pins should be used in those 2 slots. Your motherboard manual will have more information. Yeah, it has 5 pci slots and 2 ISA, and one of the PCI is shared. I think I may have had the soundcard, and the bktr card both in the shared slots. Anyway, That problem is fixed, but the aureal driver has some problems. It plays sound (dsp) but in xmms, the slower the kbps, the faster it plays. 56kbps sound sounds like The Chipmunks, and 128 Kbps sound is just a little too fast. Also, when a sound stops, it stutters until another app tries to use the dsp device. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pcm for SB 128 PCI in -current is broken...
On 29-May-99 Osokin Sergey wrote: Hello! pcm driver for SB 128 PCI in -current is broken... # dmesg | more . es0: AudioPCI ES1370 irq 5 at device 11.0 on pci0 pcm0: using I/O space register mapping at 0xe800 play, waveplay, wmsound dont' work correct. Does someone have any idea? And when it fixed? That's odd, working here! I just built world and the kernel about an hour ago. A few random thoughts.. did you set the mixer volumes? do you have the right entries in /dev (snd0 in current)? when was this last working? are there any error messages? *Happily playing a wav with waveplay* --- Chris PiazzaAbbotsford, BC, Canada cpia...@home.net finger n...@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: pcm still broken in -current (at least for me)
The same happens with snd0 instead of pcm. It looks like it can't register the interrupt handler - is it now supposed to be registered in a different way (perhaps via nexus)? I'm seeing the exact same problem, only with the Voxware driver and a PAS16. I've held off upgrading the soundcard because all the local vendors only seem to sell cards we don't have drivers for. Sigh. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM problem solved (?)
On Wed, May 05, 1999 at 08:49:53AM +0200, Erik H. Bakke wrote: In what may have seemed a desperate move to try to find out where the sound drivers decided to stop, I took a look at my config file. I tried to change the attachment of the pcm device from isa? to nexus?, trying to move it closer to the source of the interrupts. (This is with an SB PCI 128) When I had rebuilt the kernel and rebooted, the error messages seemed a bit different. It was actually suggested that I should try to use pcm0 instead of pcm1. A quick remake of the devices, and suddenly, the sound was back. Will this approach solve the problems for you other people with the same problem? I haven't had a chance to test it out yet to be sure, but: dfr 1999/05/04 14:18:23 PDT Modified files: sys/i386/isa intr_machdep.c Log: Use unit, not device_id as an argument to an old-style ISA interrupt handler. This fixes pnp interrupts and would have fixed pccard interrupts but a workaround has been applied there. This the sound driver problems which people have reported with new-bus. Revision ChangesPath 1.21 +3 -3 src/sys/i386/isa/intr_machdep.c was appearantly the problem... -- Zach Heilig z...@uffdaonline.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
On Sat, May 01, 1999 at 04:22:25PM +0800, Peter Wemm pe...@netplex.com.au wrote: I've run two systems with PCM right since the first newbus commit, and it's worked for me. Admittedly I don't use it all that often, but it's never paniced and I don't recall getting any more sound problems than usual. I checked that the isa_dma.c code is an exact split of the dma code that used to be in the old isa.c, there are zero changes to the isa dma code. The sound broke for me between Apr.20 and 21. My onboard Vibra16X doesn't work either with pcm or Voxware drivers. Voxware complains about second DMA (1/3) and pcm just simply emits silence. Apr.20 kernel works well. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
On Sun, 2 May 1999, Vallo Kallaste wrote: On Sat, May 01, 1999 at 04:22:25PM +0800, Peter Wemm pe...@netplex.com.au wrote: I've run two systems with PCM right since the first newbus commit, and it's worked for me. Admittedly I don't use it all that often, but it's never paniced and I don't recall getting any more sound problems than usual. I checked that the isa_dma.c code is an exact split of the dma code that used to be in the old isa.c, there are zero changes to the isa dma code. The sound broke for me between Apr.20 and 21. My onboard Vibra16X doesn't work either with pcm or Voxware drivers. Voxware complains about second DMA (1/3) and pcm just simply emits silence. Apr.20 kernel works well. I will fix this. I just need to find the time to rip the PNP soundcard out of one of my machines and put it into a place where I can debug it. Probably not today. -- 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: PCM
On 2 May, Vallo Kallaste wrote:
The sound broke for me between Apr.20 and 21. My onboard Vibra16X
doesn't work either with pcm or Voxware drivers. Voxware complains
about second DMA (1/3) and pcm just simply emits silence. Apr.20
kernel works well.
FreeBSD 4.0-CURRENT #6: Sun Apr 25 20:08:42 CEST 1999
sb0 at port 0x220 irq 5 drq 1 on isa0
snd0: SoundBlaster 16 4.13
sb0: interrupting at irq 5
sbxvi0 at drq 5 on isa0
snd0: SoundBlaster 16 4.13
It's not onboard.
Voxware works for me.
pcm is able to produce something I'm not able to recognize, because it's
to short in time, even if the audiofile has data for more than one
minute (cat something /dev/dsp{W,}).
Bye,
Alexander.
--
http://netchild.home.pages.de A.Leidinger @ wurzelausix.cs.uni-sb.de
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: PCM
On Fri, 30 Apr 1999, Jordan K. Hubbard wrote: It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit number I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) Do you have 'npx0 at isa?' in your config file by any chance? -- 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: PCM
Heh, the panic problem might be solved, but Ive just cvsupped with the latest 4.0-CURRENT and the problems with pcm are definatly not over, Im getting very jerky sound, its repeating bits of it over and over... and I get messages like this while trying to play mp3s with mpg123: May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt 0xfff994bc flags 0x0141 Cheers Andrew On Sat, 1 May 1999, Doug Rabson wrote: On Fri, 30 Apr 1999, Jordan K. Hubbard wrote: It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit number I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) Do you have 'npx0 at isa?' in your config file by any chance? -- 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 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
vortexia wrote: Heh, the panic problem might be solved, but Ive just cvsupped with the latest 4.0-CURRENT and the problems with pcm are definatly not over, Im getting very jerky sound, its repeating bits of it over and over... and I get messages like this while trying to play mp3s with mpg123: May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt 0xfff994bc flags 0x0141 Cheers Andrew I've run two systems with PCM right since the first newbus commit, and it's worked for me. Admittedly I don't use it all that often, but it's never paniced and I don't recall getting any more sound problems than usual. I checked that the isa_dma.c code is an exact split of the dma code that used to be in the old isa.c, there are zero changes to the isa dma code. On Sat, 1 May 1999, Doug Rabson wrote: On Fri, 30 Apr 1999, Jordan K. Hubbard wrote: It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit numbe r I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) Do you have 'npx0 at isa?' in your config file by any chance? -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
Do you have 'npx0 at isa?' in your config file by any chance? Whoops! That's the problem; I failed to see that change in GENERIC despite having scrolled past it more than several times. My face is red. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
hrmmm strange, I booted this system with a 3.0-STABLE drive just now and I have no problems with the sound, so Im not sure what it is, but its definatly not hardware. Cheers Andrew On Sat, 1 May 1999, Peter Wemm wrote: vortexia wrote: Heh, the panic problem might be solved, but Ive just cvsupped with the latest 4.0-CURRENT and the problems with pcm are definatly not over, Im getting very jerky sound, its repeating bits of it over and over... and I get messages like this while trying to play mp3s with mpg123: May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt 0xfff994bc flags 0x0141 Cheers Andrew I've run two systems with PCM right since the first newbus commit, and it's worked for me. Admittedly I don't use it all that often, but it's never paniced and I don't recall getting any more sound problems than usual. I checked that the isa_dma.c code is an exact split of the dma code that used to be in the old isa.c, there are zero changes to the isa dma code. On Sat, 1 May 1999, Doug Rabson wrote: On Fri, 30 Apr 1999, Jordan K. Hubbard wrote: It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit numbe r I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) Do you have 'npx0 at isa?' in your config file by any chance? -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd.Phone: +44 181 442 9037 Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
On Sat, May 01, 1999 at 04:22:25PM +0800, Peter Wemm wrote: vortexia wrote: Heh, the panic problem might be solved, but Ive just cvsupped with the latest 4.0-CURRENT and the problems with pcm are definatly not over, Im getting very jerky sound, its repeating bits of it over and over... and I get messages like this while trying to play mp3s with mpg123: May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt 0xfff994bc flags 0x0141 Cheers Andrew I've run two systems with PCM right since the first newbus commit, and it's worked for me. Admittedly I don't use it all that often, but it's never paniced and I don't recall getting any more sound problems than usual. I checked that the isa_dma.c code is an exact split of the dma code that used to be in the old isa.c, there are zero changes to the isa dma code. Ok, the discussion seems to be here, I posted a debugging log in -multimedia last night. (It basically shows a bunch of data being queued up, one interrupt, and some buffer being filled). One more thing to add to that is: pcm1 (SB16pnp SB16 PnP sn 0x12b9118f) at 0x220-0x22f irq 9 drq 0 flags 0x17 on isa and vmstat -i: interrupt total rate old irq910 mux irq10 478981 fdc0 irq6 20 wdc0 irq14 247000 wdc1 irq152070 atkbd0 irq1 363610 psm0 irq12 12150 sio1 irq3 3379354 90 ppc0 irq7 10 ed0 irq5 2380 clk irq0 3752093 99 rtc irq8 4802629 127 Total12044699 320 The sound driver is definately not getting the interrupts it should on my system. Everything worked properly in the first half of April. What I'm about to do is compile a kernel from every day since I last knew it worked and see where it breaks... -- Zach Heilig z...@uffdaonline.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
I'm using a _PnP_ card, and mine comes up as: pcm1 (CS423x/Yamaha/AD1816 Yamaha SA2 sn 0x) at 0x530-0x537 irq 5 drq 0 flags 0x11 on isa When I use NAS I get an interesting 'riffing' effect (last 2 second sample repeated over and over). The only way to shut it up is to kill the NAS server. Killing nas generates the following kernel message: timeout flushing dbuf_out, chan 0 cnt 0xfffa3acc flags 0x40c1 which, originates in /sys/i386/isa/snd/dmabuf.c snd_flush(), which is called by mss_close(). Interestingly other things like xanim and mpg123 are unaffected. Andrew. -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
I found the commit that broke sound (beyond that, I don't know how to fix it): peter 1999/04/21 00:26:31 PDT Modified files: sys/alpha/isaisa.c sys/alpha/pcipcibus.c sys/cam cam_xpt.c sys/dev/ata ata-all.c sys/i386/i386nexus.c sys/i386/include types.h sys/i386/isa clock.c intr_machdep.c intr_machdep.h ipl_funcs.c isa_device.h isa_dma.c random_machdep.c sys/isa isavar.h sys/kern kern_intr.c sys/pci intpm.c sys/sys interrupt.h systm.h Log: Stage 1 of a cleanup of the i386 interrupt registration mechanism. Interrupts under the new scheme are managed by the i386 nexus with the awareness of the resource manager. There is further room for optimizing the interfaces still. All the users of register_intr()/intr_create() should be gone, with the exception of pcic and i386/isa/clock.c. Revision ChangesPath 1.11 +3 -3 src/sys/alpha/isa/isa.c 1.11 +1 -36 src/sys/alpha/pci/pcibus.c 1.53 +1 -3 src/sys/cam/cam_xpt.c 1.9 +28 -33src/sys/dev/ata/ata-all.c 1.4 +7 -6 src/sys/i386/i386/nexus.c 1.17 +2 -1 src/sys/i386/include/types.h 1.130 +12 -16src/sys/i386/isa/clock.c 1.19 +426 -42 src/sys/i386/isa/intr_machdep.c 1.14 +16 -3 src/sys/i386/isa/intr_machdep.h 1.16 +9 -1 src/sys/i386/isa/ipl_funcs.c 1.60 +1 -3 src/sys/i386/isa/isa_device.h 1.2 +1 -2 src/sys/i386/isa/isa_dma.c 1.30 +2 -1 src/sys/i386/isa/random_machdep.c 1.4 +3 -3 src/sys/isa/isavar.h 1.22 +1 -405src/sys/kern/kern_intr.c 1.5 +4 -8 src/sys/pci/intpm.c 1.8 +4 -19 src/sys/sys/interrupt.h 1.88 +1 -4 src/sys/sys/systm.h A kernel from right before that works for sound, and one from right after it is broken. -- Zach Heilig z...@uffdaonline.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
On Sat, 1 May 1999, Zach Heilig wrote: I found the commit that broke sound (beyond that, I don't know how to fix it): Now this is interesting. You are saying that the previous mega-commit (the new-bus one) didn't break sound? That gives us a bit more to go on. -- 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: PCM
On Sat, 1 May 1999, Doug Rabson wrote: On Sat, 1 May 1999, Zach Heilig wrote: I found the commit that broke sound (beyond that, I don't know how to fix it): Now this is interesting. You are saying that the previous mega-commit (the new-bus one) didn't break sound? That gives us a bit more to go on. I have managed to reproduce the problem with some old hardware. I have to rearrange things a bit to debug it but I'll see what I can do tomorrow. -- 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: PCM
In article pine.bsf.4.03.9904291137380.1166-100...@resnet.uoregon.edu,
Doug White dwh...@resnet.uoregon.edu wrote:
Yes, we know that audio is broken; it's been broken since April 20th.
Well, it's worse than broken. Merely including pcm0 in the kernel
config file causes instant panic on boot-up with my machine (new
kernel built last night from fresh sources):
BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015983c
stack pointer = 0x10:0xc0303f68
frame pointer = 0x10:0xc0303f70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 ()
interrupt mask = net tty bio cam
kernel: type 12 trap, code=0
Stopped at 0xc015983c: movl0(%ecx),%ebx
KGDB says there's a NULL item in sysctl_set:
(kgdb) where
#0 sysctl_register_oid (oidp=0x0) at ../../kern/kern_sysctl.c:79
#1 0xc01598f1 in sysctl_register_set (lsp=0xc02885b8)
at ../../kern/kern_sysctl.c:127
#2 0xc0159941 in sysctl_register_all (arg=0x0) at
../../kern/kern_sysctl.c:145
#3 0xc014954a in main (framep=0xc0303fb4) at ../../kern/init_main.c:231
(kgdb) up
#1 0xc01598f1 in sysctl_register_set (lsp=0xc02885b8)
at ../../kern/kern_sysctl.c:127
127 sysctl_register_oid((struct sysctl_oid *)
lsp-ls_items[i]);
(kgdb) p *lsp
$1 = {ls_length = 414, ls_items = {0xc026e3e0}}
(kgdb) p i
$2 = 412
(kgdb) p lsp-ls_items[411]
$4 = (void *) 0xc0285bc0
(kgdb) p lsp-ls_items[412]
$5 = (void *) 0x0
(kgdb) p lsp-ls_items[413]
$6 = (void *) 0x4
(kgdb) up
#2 0xc0159941 in sysctl_register_all (arg=0x0) at
../../kern/kern_sysctl.c:145
145 sysctl_register_set(sysctl_set);
(kgdb) up
#3 0xc014954a in main (framep=0xc0303fb4) at ../../kern/init_main.c:231
231 (*((*sipp)-func))((*sipp)-udata);
I can gather more information if anybody wants it. The kernel works
fine if I take pcm0 out of the config file.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Self-interest is the aphrodisiac of belief. -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: PCM
John Polstra wrote: In article pine.bsf.4.03.9904291137380.1166-100...@resnet.uoregon.edu, Doug White dwh...@resnet.uoregon.edu wrote: Yes, we know that audio is broken; it's been broken since April 20th. Well, it's worse than broken. Merely including pcm0 in the kernel config file causes instant panic on boot-up with my machine (new kernel built last night from fresh sources): It must be something that entered the tree late yesterday afternoon or an interaction between devices. FreeBSD 4.0-CURRENT #1: Thu Apr 29 15:41:29 PDT 1999 r...@troutmask.apl.washington.edu:/usr/src/sys/compile/TROUTMASK Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping=9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 268435456 (262144K bytes) avail memory = 258375680 (252320K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02f9000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CTL00a5 [0xa5008c0e] Serial 0x9df7 Comp ID: @@@ \ [0x] SoundBlaster: DSP Command(0xe1) timeout. IRQ conflict ? pcm1 (SB16pnp SB16 PnP sn 0x9df7) at 0x640-0x64f irq 0 drq 4 flags 0x10 \ on isa CSN 2 Vendor ID: CTL0080 [0x80008c0e] Serial 0x Comp ID: @@@ \ [0x] pcm2 (SB16pnp SB16 PnP sn 0x) at 0x220-0x22f irq 5 drq 1 flags 0x15\ on isa -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
In article 199904301717.kaa03...@troutmask.apl.washington.edu, Steve Kargl s...@troutmask.apl.washington.edu wrote: John Polstra wrote: Well, it's worse than broken. Merely including pcm0 in the kernel config file causes instant panic on boot-up with my machine (new kernel built last night from fresh sources): It must be something that entered the tree late yesterday afternoon or an interaction between devices. [successful boot transcript omitted] On a hunch, I built the kernel again from the same sources but starting with a clean compile directory. This time it worked. So it appears that the panic I got wasn't something inherent in the kernel, but rather was a build problem. I'm certain that I typed make depend before building the bad kernel. So I think there must be a missing dependency somewhere. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit number I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
On Wed, 28 Apr 1999, vortexia wrote: I cvsupped from 3.1-RELEASE today to 4.0-CURRENT and since then PCM sound has been screwed. Im using a crystal sound card, anyone having similar problems? Someone's not reading -current, obviously. Yes, we know that audio is broken; it's been broken since April 20th. 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: PCM
I have a question.I am subscribed to -current, but am wondering how much of -current applies to the Alpha port? I am also subscribed to freebsd-alpha too.FYI, I am running -current of a few days ago and it is running great on my alpha. William To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: pcm broken
For some reason, when I rebuilt the kernel after a cvsup this morning, sound will no longer work. It gives this kernel warning when I try to play sound: timeout flushing dbuf_out, chan 1 cnt 0xff00 flags 0x00c1 sound worked fine yesterday, before I cvsupped. Can anyone give me an idea as to what happened here? Any help would be appreciated. Thanks. Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: pcm broken
Ken, I can't offer you any help, just moral support :P - mine just broke too. Same message. Andrew. On Thu, 22 Apr 1999, Kenneth Wayne Culver wrote: Date: Thu, 22 Apr 1999 22:50:46 -0400 (EDT) From: Kenneth Wayne Culver culv...@wam.umd.edu To: freebsd-current@freebsd.org Subject: Re: pcm broken For some reason, when I rebuilt the kernel after a cvsup this morning, sound will no longer work. It gives this kernel warning when I try to play sound: timeout flushing dbuf_out, chan 1 cnt 0xff00 flags 0x00c1 sound worked fine yesterday, before I cvsupped. Can anyone give me an idea as to what happened here? Any help would be appreciated. Thanks. Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: pcm sound driver crashes at boot time.
Russell Cattelan wrote:
I haven't been able to track down exactly where this
is occuring, but disabling pcm allows eliminates the crash.
The build is current as of Sun 18th.
The one strange thing about this box, it has
two sounds cards. A build in Yamaha OPL-3 (really really crappy)
and Ensoniq AudioPCI 1371 (very hacked driver, So the problem may be my
fault).
But I guessing it has more to do with the newbus stuff.
Ok I finally tracked down what was going wrong, I'm not saying I found the
problem
of how to fix it correctly.
The cause:
pcmprobe gets called after es_pci_attach (which has setup the snddev_info
structure),
the first thing pcmprobe does is bzero that structure. Which of course cause a
page fault
the next time that structure is access. (by es_intr in this case)
The really QD fix was to just return from pcmprobe.
int
pcmprobe(struct isa_device * dev)
{
DEB(printf(pcmprobe dev:0x%x name:%s\n,dev,
(pcm_info[dev-id_unit]).name));
/* The AudioPCI probe stuff was done already */
if(!(strncmp ((pcm_info[dev-id_unit]).name,
ES1371,strlen(ES1371{
return 1;
}
bzero(pcm_info[dev-id_unit], sizeof(pcm_info[dev-id_unit]) );
return generic_snd_probe(dev, pcm_devslist, pcm) ? 1 : 0 ;
}
--
Russell Cattelan
catte...@thebarn.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
