Re: Page fault in midi/sequencer.c
On Mon, Oct 22, 2018 at 11:00:41AM +0200, Hans Petter Selasky wrote: > On 10/20/18 6:56 PM, Peter Holm wrote: > > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > > > Hi, > > The following commits should fix the issues you experience: > > https://svnweb.freebsd.org/changeset/base/339581 > https://svnweb.freebsd.org/changeset/base/339582 > https://svnweb.freebsd.org/changeset/base/339583 > > --HPS Thank you for fixing this! -- Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Page fault in midi/sequencer.c
On 10/20/18 6:56 PM, Peter Holm wrote: I can trigger this on 13.0-CURRENT r339445 with a non-root test program: Hi, The following commits should fix the issues you experience: https://svnweb.freebsd.org/changeset/base/339581 https://svnweb.freebsd.org/changeset/base/339582 https://svnweb.freebsd.org/changeset/base/339583 --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Page fault in midi/sequencer.c
On 10/20/18 6:56 PM, Peter Holm wrote:
I can trigger this on 13.0-CURRENT r339445 with a non-root test program:
Calling uiomove() with the following non-sleepable locks held:
exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @
dev/sound/midi/sequencer.c:952
stack backtrace:
#0 0x80bfe263 at witness_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x80bf6a91 at uiomove_faultflag+0x71
#3 0x809439e6 at mseq_write+0x4c6
#4 0x80a4f725 at devfs_write_f+0x185
#5 0x80c02a87 at dofilewrite+0x97
#6 0x80c0287f at kern_pwritev+0x5f
#7 0x80c0277d at sys_pwrite+0x8d
#8 0x81070af7 at amd64_syscall+0x2a7
#9 0x8104a4ad at fast_syscall_common+0x101
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @
dev/sound/midi/sequencer.c:952
stack backtrace:
#0 0x80bfe263 at witness_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x810700d3 at trap_pfault+0x53
#3 0x8106f70a at trap+0x2ba
#4 0x81049bc5 at calltrap+0x8
#5 0x80bf6b42 at uiomove_faultflag+0x122
#6 0x809439e6 at mseq_write+0x4c6
#7 0x80a4f725 at devfs_write_f+0x185
#8 0x80c02a87 at dofilewrite+0x97
#9 0x80c0287f at kern_pwritev+0x5f
#10 0x80c0277d at sys_pwrite+0x8d
#11 0x81070af7 at amd64_syscall+0x2a7
#12 0x8104a4ad at fast_syscall_common+0x101
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x20ea6b
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8106d32d
stack pointer = 0x28:0xfe00a844a660
frame pointer = 0x28:0xfe00a844a660
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 2356 (xxx)
[ thread pid 2356 tid 100278 ]
Stopped at copyin_nosmap_erms+0xdd:movl(%rsi),%edx
db>
Hi,
Can you test the attached patch?
--HPS
Index: sys/dev/sound/midi/sequencer.c
===
--- sys/dev/sound/midi/sequencer.c (revision 339376)
+++ sys/dev/sound/midi/sequencer.c (working copy)
@@ -921,7 +921,9 @@
SEQ_DEBUG(8, printf("midiread: uiomove cc=%d\n", used));
MIDIQ_DEQ(scp->in_q, buf, used);
+ mtx_unlock(>seq_lock);
retval = uiomove(buf, used, uio);
+ mtx_lock(>seq_lock);
if (retval)
goto err1;
}
@@ -996,7 +998,9 @@
retval = ENXIO;
goto err0;
}
+ mtx_unlock(>seq_lock);
retval = uiomove(event, used, uio);
+ mtx_lock(>seq_lock);
if (retval)
goto err0;
@@ -1034,7 +1038,9 @@
SEQ_DEBUG(2,
printf("seq_write: SEQ_FULLSIZE flusing buffer.\n"));
while (uio->uio_resid > 0) {
+mtx_unlock(>seq_lock);
retval = uiomove(event, EV_SZ, uio);
+mtx_lock(>seq_lock);
if (retval)
goto err0;
@@ -1045,6 +1051,7 @@
}
retval = EINVAL;
if (ev_code >= 128) {
+ int error;
/*
* Some sort of an extended event. The size is eight
@@ -1054,7 +1061,10 @@
SEQ_DEBUG(2, printf("seq_write: invalid level two event %x.\n", ev_code));
goto err0;
}
- if (uiomove((caddr_t)[4], 4, uio)) {
+ mtx_unlock(>seq_lock);
+ error = uiomove((caddr_t)[4], 4, uio);
+ mtx_lock(>seq_lock);
+ if (error) {
SEQ_DEBUG(2,
printf("seq_write: user memory mangled?\n"));
goto err0;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Page fault in midi/sequencer.c
On Sun, Oct 21, 2018 at 12:59 AM Peter Holm wrote: > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > Calling uiomove() with the following non-sleepable locks held: > exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ > dev/sound/midi/sequencer.c:952 > stack backtrace: > #0 0x80bfe263 at witness_debugger+0x73 > #1 0x80bff1b8 at witness_warn+0x448 > #2 0x80bf6a91 at uiomove_faultflag+0x71 > #3 0x809439e6 at mseq_write+0x4c6 > #4 0x80a4f725 at devfs_write_f+0x185 > #5 0x80c02a87 at dofilewrite+0x97 > #6 0x80c0287f at kern_pwritev+0x5f > #7 0x80c0277d at sys_pwrite+0x8d > #8 0x81070af7 at amd64_syscall+0x2a7 > #9 0x8104a4ad at fast_syscall_common+0x101 > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ > dev/sound/midi/sequencer.c:952 > stack backtrace: > #0 0x80bfe263 at witness_debugger+0x73 > #1 0x80bff1b8 at witness_warn+0x448 > #2 0x810700d3 at trap_pfault+0x53 > #3 0x8106f70a at trap+0x2ba > #4 0x81049bc5 at calltrap+0x8 > #5 0x80bf6b42 at uiomove_faultflag+0x122 > #6 0x809439e6 at mseq_write+0x4c6 > #7 0x80a4f725 at devfs_write_f+0x185 > #8 0x80c02a87 at dofilewrite+0x97 > #9 0x80c0287f at kern_pwritev+0x5f > #10 0x80c0277d at sys_pwrite+0x8d > #11 0x81070af7 at amd64_syscall+0x2a7 > #12 0x8104a4ad at fast_syscall_common+0x101 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x20ea6b > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8106d32d > stack pointer = 0x28:0xfe00a844a660 > frame pointer = 0x28:0xfe00a844a660 > code segment = base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2356 (xxx) > [ thread pid 2356 tid 100278 ] > Stopped at copyin_nosmap_erms+0xdd:movl(%rsi),%edx > db> > > -- > Peter > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > It's a known fault in the oss implementation midi parsing code. The easiest route is to use something else to parse midi for the time being. OSS was ported over and many outstanding bugs are still laying around. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Page fault in midi/sequencer.c
I can trigger this on 13.0-CURRENT r339445 with a non-root test program: Calling uiomove() with the following non-sleepable locks held: exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ dev/sound/midi/sequencer.c:952 stack backtrace: #0 0x80bfe263 at witness_debugger+0x73 #1 0x80bff1b8 at witness_warn+0x448 #2 0x80bf6a91 at uiomove_faultflag+0x71 #3 0x809439e6 at mseq_write+0x4c6 #4 0x80a4f725 at devfs_write_f+0x185 #5 0x80c02a87 at dofilewrite+0x97 #6 0x80c0287f at kern_pwritev+0x5f #7 0x80c0277d at sys_pwrite+0x8d #8 0x81070af7 at amd64_syscall+0x2a7 #9 0x8104a4ad at fast_syscall_common+0x101 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ dev/sound/midi/sequencer.c:952 stack backtrace: #0 0x80bfe263 at witness_debugger+0x73 #1 0x80bff1b8 at witness_warn+0x448 #2 0x810700d3 at trap_pfault+0x53 #3 0x8106f70a at trap+0x2ba #4 0x81049bc5 at calltrap+0x8 #5 0x80bf6b42 at uiomove_faultflag+0x122 #6 0x809439e6 at mseq_write+0x4c6 #7 0x80a4f725 at devfs_write_f+0x185 #8 0x80c02a87 at dofilewrite+0x97 #9 0x80c0287f at kern_pwritev+0x5f #10 0x80c0277d at sys_pwrite+0x8d #11 0x81070af7 at amd64_syscall+0x2a7 #12 0x8104a4ad at fast_syscall_common+0x101 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x20ea6b fault code = supervisor read data, page not present instruction pointer = 0x20:0x8106d32d stack pointer = 0x28:0xfe00a844a660 frame pointer = 0x28:0xfe00a844a660 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2356 (xxx) [ thread pid 2356 tid 100278 ] Stopped at copyin_nosmap_erms+0xdd:movl(%rsi),%edx db> -- Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Corrected HEADS UP: the midi driver will be removed after 5.2-R
On Sat, 15 Nov 2003 22:42:44 +0900, Seigo Tanimura [EMAIL PROTECTED] said: tanimura Mathew Kanner has developed the new version of the midi framework, tanimura based on kobj(9) and buildable as a module. As the first step to tanimura replace the midi driver, the conventional one is removed from the tanimura kernel in a minute. tanimura Mathew will soon be starting a work to merge his driver. As we need some more time to define Mathew's driver, we have decided to postpone axing the old one until 5.2-R is released. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: the midi driver will be removed for a while
Mathew Kanner has developed the new version of the midi framework, based on kobj(9) and buildable as a module. As the first step to replace the midi driver, the conventional one is removed from the kernel in a minute. Mathew will soon be starting a work to merge his driver. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: the midi driver will be removed for a while
On Sat, Nov 15, 2003 at 10:42:44PM +0900, Seigo Tanimura wrote: Mathew Kanner has developed the new version of the midi framework, based on kobj(9) and buildable as a module. As the first step to replace the midi driver, the conventional one is removed from the kernel in a minute. Mathew will soon be starting a work to merge his driver. Please coordinate with re@ since the freeze will be beginning shortly. kris pgp0.pgp Description: PGP signature
kern/59233: patch to soundcard.h to include an ioctl and a constant for midi
Hello All, I'm sorry to be a pain, but I think it's important this PR be commited before any branch. http://www.freebsd.org/cgi/query-pr.cgi?pr=59233 It's vital to build current midi software and it has been in other OSes for a while. Thanks, --Mat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: midi problem, an isa device on a pci card
Hello,
I've recived no responses. Anyway, the following includes my
own solution to the question, lots of trial and error. I've found that
isahints was the closest exsting code to what I wanted.
As always, I would love to hear any comments.
How do I create isa devices from a pci device. Do I search up the
soundcard tree for the pci bus then search down for the isa bus, then
create_child(...mpushim)?
In pci device_attach:
isa=devclass_find(isa);
if( !isa ) {
device_printf(sc-dev,cmi midi error no devclass for isa\n);
goto err;
}
if (devclass_get_devices(isa, isalistp, isacountp) != 0 ) {
device_printf(sc-dev,cmi midi error fetching isa devices\n);
goto err;
}
if ( isacountp 1 ) {
device_printf(sc-dev,cmi midi no isa busses found\n);
goto err;
}
/*
* Be stupid and just pick the first isa bus
*/
sc-isadev = isalistp[0];
mpuisa=devclass_find(mpuisa);
if( !mpuisa ) {
device_printf(sc-dev,cmi: midi driver not found\n);
goto err;
}
i = devclass_find_free_unit(mpuisa,0);
sc-mpudev = BUS_ADD_CHILD(sc-isadev, 1, mpuisa, i);
[Needs to be done with BUS_ADD_CHILD, I tried with others, m' yo
they just don't work]
How do I tell the shim before the probe/attach what io region to look
at, do I fiddle with ivars (or some internal structure), do I mess with hints
via kenv(9) [Is there a kenv(9)? ]
[ Say, p-port=0x300, then following would set it to 0x300-0x302
and the same IRQ as the pci device ]
bus_set_resource(sc-mpudev, SYS_RES_IOPORT, 0, p-port, 2);
bus_set_resource(sc-mpudev, SYS_RES_IRQ, 0, rman_get_start(sc-irq), 1);
if( device_probe_and_attach(sc-mpudev) == 0 ) {
device_printf(sc-dev,added %s/%s\n,
device_get_nameunit(sc-isadev),
device_get_nameunit(sc-mpudev) );
return ;
}
Cheers,
--Mat
--
Brain: Are you pondering what I'm pondering?
Pinky: I think so Brain, but the Rockettes, it's mostly girls, isn't it?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
midi problem, an isa device on a pci card
Hello,
I've been fiddling with pci drivers in freebsd for a couple of
months and up to now everything has ok, I did a midi driver for es137x
which was relatively easy because the io was done on the pci bus. I
was very pleased that there were enough resources for a newbie like me
to dive into kernel hacking.
Now I want to do one for the cmi card, but it seems to offer
the midi device on the isa bus, as does a bunch of cards. I'm sure
they did this to confuse me.
Linux seems to be happy just inb,outb in their pci driver,
which seems uncool to me. Also since I can program the mpu to appear
to different locations I think the ISA bus driver can help determine
the best one to use...
Theory of Reality (mostly hand waving, as I've done no code yet)
Drivers:
cmi(pci), my pci sound, it's on board btw.
mpushim(isa), the mpu401 from the tree but hacked to receive
from the pci soundcard driver
How I think should work:
probe cmi,
attach cmi,
do {
enable mpu401 at port region,
probe attach mpushim
while ( ! mpushim attached )
done
Big question mark:
How do I create isa devices from a pci device. Do I search up the
soundcard tree for the pci bus then search down for the isa bus, then
create_child(...mpushim)?
How do I tell the shim before the probe/attach what io region to look
at, do I fiddle with ivars (or some internal structure), do I mess with hints
via kenv(9) [Is there a kenv(9)? ]
I think that these questions equally apply to joysticks.
Thanks,
--Mat
--
Brain: Are you pondering what I'm pondering?
Pinky: I think so, Brain, but if the plural of mouse is mice, wouldn't
the plural of spouse be spice?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIDI
David Schultz wrote: Thus spake Thanjee Neefam [EMAIL PROTECTED]: I was very happy when compiling my 5.0 kernel. For the first time device midi compiled without giving any errors. This abnormal excitement only led to misery when I discovered after rebooting that there still was no MIDI. Is MIDI going to be implemented soon? Who is working on it? Can I help them? (I am not a very good programmer, but I can hack pre existing code, and I am good at testing). MIDI is the ONLY thing stopping me from running FreeBSD exclusively. FYI, the non-free OSS driver supports MIDI: http://www.opensound.com/bsd.html Apparently even this is not complete, however: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1250661+0+archive/2003/freebsd-current/20030323.freebsd-current One interesting thing to note from that thread, is that Yuriy Tsibizov is into the development of this stuff, but does not have all the equipment needed to conduct testing. I don't know what hardware you have, but this is what he's been working on: http://chibis.persons.gfk.ru/audigy/ Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: MIDI
From: Peter Schultz [mailto:[EMAIL PROTECTED] One interesting thing to note from that thread, is that Yuriy Tsibizov is into the development of this stuff, but does not have all the equipment needed to conduct testing. I don't know what hardware you have, but this is what he's been working on: http://chibis.persons.gfk.ru/audigy/ No! I'm not a MIDI subsystem developer! The only thing I do is an attempt to add MIDI I/O to Live/Audigy cards. If MIDI subsystem is not compllete I'll stop this work. I'm going to do only card-specific drivers, not to fix possible broken in-kernel MIDI. Yuriy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
MIDI
Hello, I am not sure if this is most appropriate here, but there is no sound-dev-current mailing list. I was very happy when compiling my 5.0 kernel. For the first time device midi compiled without giving any errors. This abnormal excitement only led to misery when I discovered after rebooting that there still was no MIDI. Is MIDI going to be implemented soon? Who is working on it? Can I help them? (I am not a very good programmer, but I can hack pre existing code, and I am good at testing). MIDI is the ONLY thing stopping me from running FreeBSD exclusively. Also Gentoo is extremely unstable. I updated ports about 2 days ago and installed it. I don't know if this is a 5.0 issue or a ports issue. Cheers, Tim -- http://www.fastmail.fm - Send your email first class ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIDI
I'm interrested in using MIDI on FreeBSD, too, but I have to tell you, that - as far as I found out - there has been midi support some time ago, but it's not included in the system/kernel anymore. There's probably some hope although, I don't find it, but I remember someone stated that you can easily apply the netbsd midi code as a patch to the current kernel. 5.0RC2 works according to this source, but had system reboots, when kldloading the midi module. If you're interrested, maybee you have more luck searching, there aren't many articles about freebsd and midi on the net (especially newer ones). I'll keep on searching Friedemann Hello, I am not sure if this is most appropriate here, but there is no sound-dev-current mailing list. I was very happy when compiling my 5.0 kernel. For the first time device midi compiled without giving any errors. This abnormal excitement only led to misery when I discovered after rebooting that there still was no MIDI. Is MIDI going to be implemented soon? Who is working on it? Can I help them? (I am not a very good programmer, but I can hack pre existing code, and I am good at testing). MIDI is the ONLY thing stopping me from running FreeBSD exclusively. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIDI
Thus spake Thanjee Neefam [EMAIL PROTECTED]: I was very happy when compiling my 5.0 kernel. For the first time device midi compiled without giving any errors. This abnormal excitement only led to misery when I discovered after rebooting that there still was no MIDI. Is MIDI going to be implemented soon? Who is working on it? Can I help them? (I am not a very good programmer, but I can hack pre existing code, and I am good at testing). MIDI is the ONLY thing stopping me from running FreeBSD exclusively. FYI, the non-free OSS driver supports MIDI: http://www.opensound.com/bsd.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: MIDI on SB Live! ?
just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Yuriy Tsibizov, http://chibis.persons.gfk.ru/audigy/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: MIDI on SB Live! ?
Am Mo, 2003-03-24 um 07.47 schrieb Yuriy Tsibizov: just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Yuriy Tsibizov, http://chibis.persons.gfk.ru/audigy/ Your page says: 0. It works for SB Live! and Audigy. Not for Audigy2. and MIDI is on the TODO-list So, guess there is still some hope for SB Live! MIDI in the not-so-near future. :) Or are the differences between an EMU10K2 (as seen in the dmesg, I guess Audigy?) and EMU10K1 that big? Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: MIDI on SB Live! ?
From: Julian St. [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:26 PM just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Nobody. Our target for nearest future is Audigy/Audigy2 support. Your page says: 0. It works for SB Live! and Audigy. Not for Audigy2. and MIDI is on the TODO-list Yes, MIDI I/O is in my TODO list, but I'm not working on it now. So, guess there is still some hope for SB Live! MIDI in the not-so-near future. :) I can't promise that I start to code MIDI I/O in nearest future Mostly because I don't need it. I don't have any MIDI device at home or at work. Or are the differences between an EMU10K2 (as seen in the dmesg, I guess Audigy?) and EMU10K1 that big? EMU10K2=Audigy MIDI I/O should be almost the same between EMU10Kx cards... But I don't have any MIDI devices (other than AudigyDrive remote control, it should act as a MIDI controller on second MIDI port, AFAIK) to check it. Yuriy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: MIDI on SB Live! ?
Am Mo, 2003-03-24 um 14.02 schrieb Yuriy Tsibizov: MIDI I/O should be almost the same between EMU10Kx cards... But I don't have any MIDI devices (other than AudigyDrive remote control, it should act as a MIDI controller on second MIDI port, AFAIK) to check it. I have several devices to test it on. :) Perhaps until then I have learned enough (sound) driver hacking that I could adapt (with the help of some hardware documentation) your EMU10K2 MIDI code to EMU10K1 boards. It is a bit hard to get started though. Regards, Julian Stecklina signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Need ALSA [was: Re: MIDI on SB Live! ?]
[EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd certainly be more than willing to throw some money into a paypal account or whatever, and I think there are others who would too. OSS is so 20th century, lets get FreeBSD into 21st century sound architecture design. :-) If you're a developer seriously interested in this, lets talk. So much of FreeBSD development is sponsored by Universities and whatnot that we take it for granted. When stuff like ALSA doesn't get ported right away, I feel we need to realize our responsibility to contribute to the project as well. Sincerely, Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Need ALSA [was: Re: MIDI on SB Live! ?]
Hello, Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ Quote from this page: Known bugs - MIDI on SB live drive not working properly. Seems MIDI is not a great priority anymore. But I would certainly greet a new sound architecture. Broken MIDI is at least better than no MIDI. ;) [porting] I'd certainly be more than willing to throw some money into a paypal account or whatever, and I think there are others who would too. OSS is so 20th century, lets get FreeBSD into 21st century sound architecture design. :-) I would have no objections. If you're a developer seriously interested in this, lets talk. So much of FreeBSD development is sponsored by Universities and whatnot that we take it for granted. When stuff like ALSA doesn't get ported right away, I feel we need to realize our responsibility to contribute to the project as well. Uh... Ok, I have C experience, but my insight into FreeBSD and sound card programming (I remember some experiments with soundblasters in DOS times) is quite limited. Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
On Saturday 22 March 2003 14:52, Peter Schultz wrote: [EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux. This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already. -- Regards, Michael Nottebrock pgp0.pgp Description: signature
Re: MIDI on SB Live! ?
On Friday 21 March 2003 21:01, [EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? On and off, as far as I can tell. If you want MIDI right now, take a look at what 4Front Technologies offers in their commercial OSS package. -- Regards, Michael Nottebrock pgp0.pgp Description: signature
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
Michael Nottebrock wrote: On Saturday 22 March 2003 14:52, Peter Schultz wrote: [EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux. One could go either way with this. Leave it for after 1.0, or grab it now and help build it up for a better 2.0. Or I guess we could initiate the ABSDSA and have support for both ALSA and OSS. Wouldn't this be even more work though? This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already. OSS is on the outs. New applications that are ALSA only will soon be common, won't they? Newpcm is what, five years old? Whatever it is, it ain't new anymore. Of course, maybe I'm completely mistaken about the whole situation and all newpcm needs is a boost. What is the right answer? Does OS X have a completely proprietary sound arch? It would be nice to be able to work with what they've got too. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux. One could go either way with this. Leave it for after 1.0, or grab it now and help build it up for a better 2.0. Or I guess we could initiate the ABSDSA and have support for both ALSA and OSS. Wouldn't this be even more work though? porting alsa would gain very little and be a huge regression. This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already. OSS is on the outs. New applications that are ALSA only will soon be common, won't they? Newpcm is what, five years old? Whatever it is, it ain't new anymore. Of course, maybe I'm completely mistaken about the whole situation and all newpcm needs is a boost. you are completely mistaken. first, let me correct some of the factual inaccuracies that you are propounding: * newpcm is not even 4 years old yet. * alsa is in no way desireable- it is not a device abstraction system. every app must do userland resampling to play, say 44.1khz sound on a 48khz only chipset. given that it does not provide hardware abstraction, alsa's kernel components are far too complex. * alsa drivers are difficult to write- compare one to its corresponding newpcm driver. * newpcm has a much more advanced architecture than alsa, and is entirely different than oss. the fact that newpcm's dsp and mixer layers implement the oss api is incidental. newpcm v2, which may gain a better name, is under development. i originally hoped to have it ready for 5.0, but very poor health over the last year prevented this. instead, it will be targetted at 6.0 and probably backported to ~5.3+ once feature complete and demonstrably stable. i will not elaborate here on the features planned for v2, but replacing the api is one of them, although oss compatibility will be provided. there are a few people out there who know the plans, but they all know that i want them kept under wraps for now. with only two main developers, you should not expect v2 to be committed much before the end of this year. additional manpower would help, but don't volunteer if i'm going to have to spend time teaching you c, the kernel, kobj or the current design of newpcm. someone well versed in dsp techniques and acquainted with the mathematics of accoustics would be very helpful. money and/or hardware would be nice, but i at least am limited in speed by my body and nothing short of a few million dollars is likely to change that. the single greatest incentive to continue that the community could provide is to refrain from suggesting that newpcm be scrapped or replaced, especially by proponents who are not willing to do the code themselves, do not have a replacement working prior to their proposal, and/or have little to zero knowledge of sound hardware and the requirements of a top-flight audio infrastructure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
Peter Schultz wrote: Michael Nottebrock wrote: On Saturday 22 March 2003 14:52, Peter Schultz wrote: [EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ I think you wouldn't really do anyone a favour, including the ALSA folks, if you went and made a port right now. The ALSA project is still not at 1.00 status and still quite in-flux. One could go either way with this. Leave it for after 1.0, or grab it now and help build it up for a better 2.0. Or I guess we could initiate the ABSDSA and have support for both ALSA and OSS. Wouldn't this be even more work though? This can easily happen if we get behind a developer. ALSA has been sponsored by SuSE for the benefit of Linux, and there's no reason we can't pull together our resources to do the same for our OS. I'm sure someone will step forward to do the port if we have the cash for them to comfortably sit in front of their computer until the port is complete. I'd appreciate sponsoring somebody to work on our existing newpcm stuff and add the missing bits and pieces much more. Donating hardware (soundcards and MIDI-devices) would probably help very much already. OSS is on the outs. New applications that are ALSA only will soon be common, won't they? Alsa is condemned to driver + some silly user space daemon with naive signal filter anyway. So no problem here. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need ALSA [was: Re: MIDI on SB Live! ?]
On Saturday 22 March 2003 16:15, Peter Schultz wrote: OSS is on the outs. New applications that are ALSA only will soon be common, won't they? No. In fact, there is quite an explosion in multimedia middleware projects right now and people are having heated discussions in other places which one is the most promising. :) Don't expect many audio apps in the future to be talking directly to some API exported by a kernel. -- Regards, Michael Nottebrock pgp0.pgp Description: signature
Re: MIDI on SB Live! ?
On Mar 22, Michael Nottebrock wrote: On Friday 21 March 2003 21:01, [EMAIL PROTECTED] wrote: just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? On and off, as far as I can tell. If you want MIDI right now, take a look at what 4Front Technologies offers in their commercial OSS package. Hello Micheal and all, (this is reply targeted at the thread) In not sure about 4front compatability with -current. ALSA would require a complete rewrite to work for multiple platforms because they are intimate with the linux pci interface. IMHO, it would require a fork of their project. MIDI in FreeBSD is highly hackable. It took me only a couple of days to get midi working for an es173x, a made a small web page a few months ago, it was for 5.0-dp2 but would probably work with 5.0-R. As it is, midi can be a kld and all that is required for a particular card is basic IO. The emu10k should be easier than most because we already have code for a generic mpu401. Here are some web links, http://www.cnd.mcgill.ca/~mat/es137xmidi.html (my small es137x midi page, mostly derived from other sources) Nice references for midi hacking: from NetBSD (it's .se.netbsd because .netbsd seems to be down) http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/midi.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/midisyn.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/sequencer.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/pci/esa.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/pci/emuxki.c (oops, no midi for emu on netbsd) from ALSA: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/drivers/mpu401/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/pci/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/pci/emu10k1/ After all of this, the reality is, very few people care about midi for freebsd and it has been neglected for along time. We're lucky that the work done long ago still works. --Mat -- Brain: Pinky, are you pondering what I'm pondering? Pinky: I think so Brain, but pants with horizontal stripes make me look chubby. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MIDI on SB Live! ?
Hello, no luck here either: http://www.opensound.com/readme/README.SBLive.html - o EMU Wavetable MIDI synthesizer not yet supported The only thing that is (partially) working seems to be ALSA. Regards, Julian On 22-Mar-2003 Michael Nottebrock wrote: On Friday 21 March 2003 21:01, [EMAIL PROTECTED] wrote: Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? On and off, as far as I can tell. If you want MIDI right now, take a look at what 4Front Technologies offers in their commercial OSS package. -- Regards, Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
MIDI on SB Live! ?
Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Midi driver causes panic a la Driver Mistake...
Hello everybody, While the flamage rages on on cvs-all, I would like to report the second driver that does not pass the recently introduced warning-to-panic test because of driver mistake. It is the Midi driver (device midi and device seq) I have an SB 64 AWE ISA PnP card so I had these devices in my kernel config (GENERIC does not have them so only custom kernels are affected.) Card identified as: sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: SB 16 DSP 4.16 on sbc0 midi0 SB Midi interface on sbc0 featuring the following ddb trace: (sorry, transcribed by hand:-( Debugger panic make_dev midiinit mpu_attach mpusbc_attach device_probe_and_attach bus_generic_attach sbc_attach device_probe_and_attach isa_probe_children configure mi_startup begin and the WARNING is: (right after the midi0: line) WARNING: Driver mistake: repeat make_dev (dspr0.0) -CURRENT from today's make world. NB I think midi driver code may have other problems too... it doesn't seem to be heavily maintained these days. (PS Note to self: If this mail appears on the list, that means I have managed to route around my ISP's broken SMTP server.) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: midi causes panic on boot? (update)
Hello Jim, On Sun, Mar 25, 2001 at 07:20:04PM -0500, Jim Bloom wrote: I get a slightly different backtrace, but was able to use my palm pilot as the serial console. I have had this same problem for quit a while (about a month). I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last cvsup was within the past 24 hours and the kernel was built in a clean directory. Yes, same experience here. But I unfortunately did not have a serial console handy. Tanimura's commits on March 14th were supposed to help the situation, but they appearently haven't...:-( I can try to get more information if necessary. I am still trying to figure out how to get more. I am not good with ddb, and since the machine will not dump, gdb is not usable locally. (And again, no serial connection handy:-( 'show witness' and 'show mutex' come to mind as two more things I will try in ddb. trace _mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a mpu_uartmode(c0ecda00) at mpu_uartmode+0x63 mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25 mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19 device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at bus_generic_attach+0x16 sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at device_probe_and_attach+0x9a isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at isa_probe_children+0x143 configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39 mi_startup() at mi_startup+0x68 begin() at begin+0x29 Yes, I think we are looking at the same thing. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
Hello folks, I have tried it with today's -CURRENT, and as soon as I try to boot a kernel with the options (this has occured also earlier but wanted to make sure that I try today's sources first) device midi device seq (my sound card is a ISAPnP SB 64 AWE) I use device sbc too. the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's fixes, and yet this still happens. I do not have a serial console, so here a short trace output transcribed: _mtx_lock_sleep mpu_uartmode mpu_attach mprobe_attach device_probe_and_attach bus_generic_attach sbc_attach device_probe_and_attach isa_probe_children configure mi_startup() begin() At the point of panic not even the swap partition is available yet so the machine does not dump. How can I force it? I would like to offer any and all help to anyone wanting to debug this; I can reproduce the problem at will and luckily no FS corruption occurs because the panic is so early on boot.:-) Of course, as soon as I omit the midi part, the kernel boots fine, and the sound card works too. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
I get a slightly different backtrace, but was able to use my palm pilot as the
serial console. I have had this same problem for quit a while (about a month).
I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last
cvsup was within the past 24 hours and the kernel was built in a clean
directory.
I can try to get more information if necessary.
Jim Bloom
[EMAIL PROTECTED]
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1a0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8006
stack pointer = 0x10:0xc04e66dc
frame pointer = 0x10:0xc04e66db
trace
_mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a
mpu_uartmode(c0ecda00) at mpu_uartmode+0x63
mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25
mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19
device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a
bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at
bus_generic_attach+0x16
sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc
device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at
device_probe_and_attach+0x9a
isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at
isa_probe_children+0x143
configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39
mi_startup() at mi_startup+0x68
begin() at begin+0x29
db panic
panic: from debugger
Debugger("panic")
Stopped at _mtx_lock_sleep+0x29a: movl0x1a0(%edx),%eax
Szilveszter Adam wrote:
Hello folks,
I have tried it with today's -CURRENT, and as soon as I try to boot a
kernel with the options (this has occured also earlier but wanted to make
sure that I try today's sources first)
device midi
device seq
(my sound card is a ISAPnP SB 64 AWE)
I use device sbc too.
the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's
fixes, and yet this still happens. I do not have a serial console, so here
a short trace output transcribed:
_mtx_lock_sleep
mpu_uartmode
mpu_attach
mprobe_attach
device_probe_and_attach
bus_generic_attach
sbc_attach
device_probe_and_attach
isa_probe_children
configure
mi_startup()
begin()
At the point of panic not even the swap partition is available yet so the
machine does not dump. How can I force it?
I would like to offer any and all help to anyone wanting to debug this; I
can reproduce the problem at will and luckily no FS corruption occurs
because the panic is so early on boot.:-)
Of course, as soon as I omit the midi part, the kernel boots fine, and the
sound card works too.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
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: midi causes panic on boot? + entropy gatherer works fine
On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote: I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) Yup I'm seeing this too. SMP kernel, AWE64 PnP. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? + entropy gatherer works fine
On Wed, 14 Mar 2001 00:49:53 -0800, Alex Zepeda [EMAIL PROTECTED] said: Alex On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote: I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) Alex Yup I'm seeing this too. SMP kernel, AWE64 PnP. If the kernel attempts to probe mpu to die, my last commit should fix that. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
midi causes panic on boot? + entropy gatherer works fine
Hello everybody, I had been away for two weeks and after upgrading to the latest -CURRENT I noticed that leaving device midi (and maybe device seq, I did not test separately) in my kernel config file causes a Trap 12 with interrupts disabled on _mtx_lock_sleep+0x29a: movl 0x1a0(%edx),%eax quite early on boot. Dumping was not possible, my attempts at this were only honoured with a reboot. Although I never tested if the midi support actually does something but up until now I always had it in the kernel and it never caused problems. I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) BTW: the new entropy gatherer really works nice for me. Even with the usual set of debugging options, I did not notice any slowdown, more, I think the computer has become more responsive than it has been lately. Congrats to Mark and all, I just did not want to send an email separately for this!:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
midi panics
I'm getting fatal trap 12 with interrupts disabled related to the midi code during boot. Backtrace is: _mtx_lock_sleep+0x23a mpu_uartmode+0x3e mpu_attach+0x25 mpusbc_attach+0x19 device_probe_and_attach+0x9a bus_generic_attach+0x16 sbc_attach+0x3ad device_probe_and_attach+0x9a isa_probe_children+0x143 configure+0x39 mi_statup+0x68 begin+0x29 The problem DOES NOT HAPPEN when I have acpica in the kernel. With apm instead, though, it panics each and every time. Removing midi/seq from the kernel removes the problem. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi panics
On Tue, 27 Feb 2001 22:53:06 +0900, "Daniel C. Sobral" [EMAIL PROTECTED] said: Daniel I'm getting fatal trap 12 with interrupts disabled related to the midi Daniel code during boot. Daniel Backtrace is: Daniel _mtx_lock_sleep+0x23a Daniel mpu_uartmode+0x3e Daniel mpu_attach+0x25 mpu_uartmode() is called before init of scp-mtx. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MP-safe midi(4) and sequencer callout priority
The patch at http://people.FreeBSD.org/~tanimura/patches/midimutex.diff.gz makes midi(4) MP-safe. With this patch, my kernel with WITNESS and INVARIANTS plays my favorite midi tunes just fine, except that the callout used by the midi sequencer gets delayed under a heavy load. As the sequencer uses callout in order to wait until the next midi message is ready to be transmitted, the callout should run at PI_AV so that a tune will not sound messy. John, have you got any plan to modify the priority of a callout? Cameron, as pcm(4) interacts with few of the other subsystems in the kernel like midi(4), why don't you start making pcm(4) MP-safe? Multimedia devices should benefit very much from kernel execution in parallel. The only one thing to note is to not access a device in parallel to mess it up. We have to add a mutex to a device and share the mutex between the pcm part and the midi part of the driver. Could you please let me know when pcm(4) gets MP-safe, and we will see how we can share device mutexes between pcm(4) and midi(4). -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel hangs initializing Soundblaster AWE 64 midi driver
Hi, I'm tracking -CURRENT and build a kernel yesterday with the following options (edited): device sbc # Soundblaster Bridge-Code to pcm device pcm # PnP/PCI Sound Cards #device midi# Midi interfaces #device seq # Sequencer The corresponding hints are: none Without midi device, this is the relevant dmesg part: [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: SB16 DSP 4.16 on sbc0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources ed0 XXX: driver didn't initialize queue mtx lp0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable [...] and the kernel happily boots. Sound is usable as before. Now, adding midi (either alone or together with seq) produces the following messages: sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: SB16 DSP 4.16 on sbc0 midi0: SB Midi Interface on sbc0 midi1: SB OPL FM Synthesizer on sbc0 midi2: CTL0022 WaveTable Synthesizer at port 0x620-0x623 on isa0 exactly here, the system hangs completely. What I'm I missing? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCM and Midi.
Does anyone know when PCM will support midi? Thanks! Bob -- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Newmidi updated (CS461x, GUS, pcm+midi, etc)
After a long absense, newmidi now supports CS461x/428x PCI Audio and GUS midi, with some bug fix. Both pcm and midi on an ISA PnP/ PCI card now work(for SB/GUS/CS461x). Microtimeout and APIC timer patches are separated from newmidi. Please follow the document at: http://www.freebsd.org/~tanimura/newmidi/ to install newmidi. Thanks! Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
uh... [phaser.whistle.com] 536 man 9 finetimer No entry for finetimer in section 9 of the manual On Thu, 8 Jul 1999, Seigo Tanimura wrote: Another idea has come to my mind... pca(4) currently uses acquire_timer0(), which changes the timer frequency directly, breaking finetimer(9). I am considering to move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) comes to work again. Furthermore, we can get rid of acquire_timer0() and the related stuff in clkintr() to be much more simple than now. Any comments? Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: julian uh... julian [phaser.whistle.com] 536 man 9 finetimer julian No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: [EMAIL PROTECTED] finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999, Seigo Tanimura wrote: On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: julian uh... julian [phaser.whistle.com] 536 man 9 finetimer julian No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: [EMAIL PROTECTED] how do I read that? finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Call for Review: Voxware midi driver for serial ports
-Original Message- From: Seigo TANIMURA [mailto:tanim...@naklab.dnj.ynu.ac.jp] Sent: 02 May 1999 06:58 To: n...@jelal.kn-bremen.de Cc: tanim...@naklab.dnj.ynu.ac.jp; zin...@jan.ne.jp; freebsd-current@freebsd.org; freebsd-multime...@freebsd.org Subject: Re: Call for Review: Voxware midi driver for serial ports From: Juergen Lock n...@jelal.kn-bremen.de Subject: Re: Call for Review: Voxware midi driver for serial ports Date: Sun, 2 May 1999 02:15:00 +0200 Message-ID: 19990502021500.a3...@saturn.kn-bremen.de nox On Tue, Apr 20, 1999 at 10:27:35AM +0900, Seigo TANIMURA wrote: nox On Sun, 18 Apr 1999 22:15:05 +0200, noxJuergen Lock n...@jelal.kn-bremen.de said: nox nox Another bad news, I tried driving my SC-88 connected directly to a PC using nox Windows 95 and Portman PC/S driver, to find a miserable result. I saw no midi nox messages come properly, so Portman PC/S should be cooking the signals in some way... nox nox nox Or uses a higher speed than 38k4, can you check that? Hmm, or maybe nox nox i should just take my old Atari MSTe and use that as serial-midi nox nox interface... nox nox nox Bitrate 38.4k... I wish I had a long serial cable. The PC I had a test nox on the Portman driver is not in my room, and it is not a portable one. nox nox Atari, I have only heard the name. I played with an Acorn when I was a kiwi. nox nox Acorn, what CPU did it have again? :) Sorry, it was not mine, so I have no idea. I remember that Acone had a FM synthesizer in it, no midi interfaces. It sounded like a flat harpsichord, which was good at that time(in 1993, six years ago). The Acorn used a 6502. They went on to produce a box in the UK called the BBC Computer. It was *way* ahead of it's time, I still have it in the garage. Graphics resolutions that were better than the IBM PC that came later, 3 channel sound capability, the ability to add a second processor, an OS that was really neat. It was one nice piece of kit, ahh nostalgia. Paul Richards. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Call for Review: Voxware midi driver for serial ports
p...@originative.co.uk wrote in message ID a6d02246e1abd2119f5200c0f0303d10f...@octopus: The Acorn used a 6502. They went on to produce a box in the UK called the BBC Computer. It was *way* ahead of it's time, I still have it in the garage. Graphics resolutions that were better than the IBM PC that came later, 3 channel sound capability, the ability to add a second processor, an OS that was really neat. It was one nice piece of kit, ahh nostalgia. Hrm? If it was '93, it was more likely to be the Archimedes, which came out in '87 or '88. That used the ``ARM'' home-grown processor. In '93, it could have even been an ARM3. The ARM2 ran at a whopping 8MHz! (well, it was 12MHz I think, but after DRAM refresh (which paused the CPU, from memory) it was effectively 8MHz) Gary (who misses well-designed computers like the BBC B and Archimedes. Makes the PC look like a pile of components which fell into a case and somehow managed to work) -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Call for Review: Voxware midi driver for serial ports
From: Juergen Lock n...@jelal.kn-bremen.de Subject: Re: Call for Review: Voxware midi driver for serial ports Date: Sun, 2 May 1999 02:15:00 +0200 Message-ID: 19990502021500.a3...@saturn.kn-bremen.de nox On Tue, Apr 20, 1999 at 10:27:35AM +0900, Seigo TANIMURA wrote: nox On Sun, 18 Apr 1999 22:15:05 +0200, noxJuergen Lock n...@jelal.kn-bremen.de said: nox nox Another bad news, I tried driving my SC-88 connected directly to a PC using nox Windows 95 and Portman PC/S driver, to find a miserable result. I saw no midi nox messages come properly, so Portman PC/S should be cooking the signals in some way... nox nox nox Or uses a higher speed than 38k4, can you check that? Hmm, or maybe nox nox i should just take my old Atari MSTe and use that as serial-midi nox nox interface... nox nox nox Bitrate 38.4k... I wish I had a long serial cable. The PC I had a test nox on the Portman driver is not in my room, and it is not a portable one. nox nox Atari, I have only heard the name. I played with an Acorn when I was a kiwi. nox nox Acorn, what CPU did it have again? :) Sorry, it was not mine, so I have no idea. I remember that Acone had a FM synthesizer in it, no midi interfaces. It sounded like a flat harpsichord, which was good at that time(in 1993, six years ago). nox Anyway I now have restored the m68k-atari crosscompiler from tape and made nox a little /dev/midi - /dev/modem2 connection program. Well, it works! nox Now, does anyone know a sequencer program that has a tick display and nox that can record one track while playing back another? rosegarden can only nox do one thing at a time... Playing and recording simultaneously? I wish I knew one... nox Oh and i had to patch this to get my kernel to build: nox nox Index: i386/conf/files.i386 nox @@ -225,8 +225,10 @@ nox i386/isa/sound/uart6850.c optionaluartdevice-driver nox i386/isa/sound/uart16550.coptionaluartsio device-driver nox i386/isa/sound/midi_synth.c optionaluartdevice-driver nox +i386/isa/sound/midi_synth.c optionaluartsio device-driver nox i386/isa/sound/midi_synth.c optionalcss device-driver nox i386/isa/sound/midibuf.c optionaluartdevice-driver nox +i386/isa/sound/midibuf.c optionaluartsio device-driver nox i386/isa/sound/midibuf.c optionalcss device-driver nox i386/isa/sound/trix.c optionaltrixdevice-driver nox i386/isa/sound/adlib_card.c optionaltrixdevice-driver nox nox (the box has no sound card so these files were not compiled before.) Fixed the patch, thanks! Seigo TANIMURA |M2, Nakagawa Lab, Dept of Electronics CS =|Faculty of Engineering, Yokohama National Univ Powered by SIEMENS, |http://www.naklab.dnj.ynu.ac.jp/~tanimura/ FreeBSD 4.0-CURRENT |http://www.sakura.ne.jp/~tcarrot/ (25th Apr 1999) muesli.|tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com VoxWare Midi Driver for Serial Ports on FreeBSD: http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/ Seigo TANIMURA |M2, Nakagawa Lab, Dept of Electronics CS =|Faculty of Engineering, Yokohama National Univ Powered by SIEMENS, |http://www.naklab.dnj.ynu.ac.jp/~tanimura/ FreeBSD 4.0-CURRENT |http://www.sakura.ne.jp/~tcarrot/ (25th Apr 1999) muesli.|tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com VoxWare Midi Driver for Serial Ports on FreeBSD: http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
