abrt 1.0.6 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/jackd -R -dalsa -r44100 -p256 -n2 -D -Chw:M66,0 -Phw:M66,0 -Xseq -zs -H -M component: jack-audio-connection-kit executable: /usr/bin/jackd kernel: 2.6.31.12-174.2.19.fc12.x86_64 package: jack-audio-connection-kit-0.118.0-1.fc12 rating: 4 reason: Process was terminated by signal 6 (Aborted) release: Fedora release 12 (Constantine) comment ----- /etc/modprobe.d/* contains: alias snd-card-3 snd-mtpav options snd-mtpav index=3 id="MTPAV" port=0xec00 irq=10 install snd-rawmidi /sbin/modprobe --ignore-install snd-rawmidi && /sbin/modprobe snd-mtpav blacklist parport_pc blacklist parport blacklist ppdev blacklist lp Note, see http://ccrma-mail.stanford.edu/pipermail/planetccrma/2006-October/012637.html as to why the blacklist is needed, to prevent this issue w/ snd_mtpav: # gnulem-141-~> sudo modprobe snd-mtpav id="MTPAV" index=3 port=0xec00 irq=10 # FATAL: Error inserting snd_mtpav (/lib/modules/2.6.31.12-174.2.3.fc12.x86_64/kernel/sound/drivers/snd-mtpav.ko): No such device # /var/log/messages says: # > Jan 31 16:34:43 gnulem kernel: ALSA sound/drivers/mtpav.c:590: MTVAP port 0xec00 is busy # > Jan 31 16:34:43 gnulem kernel: snd_mtpav: probe of snd_mtpav failed with error -16 # Removing them allows snd-mtpav to bind the ports: # gnulem-144-~> sudo modprobe -r parport_pc # gnulem-145-~> sudo modprobe -r parport ppdev # gnulem-146-~> sudo modprobe snd-mtpav id="MTPAV" index=3 port=0xec00 irq=10 # now, /var/log/messages says: # > Jan 31 16:35:46 gnulem kernel: Motu MidiTimePiece on parallel port irq: 10 ioport: 0xec00 How to reproduce ----- 1. Run jack with a MOTU Midi TimePiece (parallel port version, see module snd-mtpav, which is where the bug lies). 2. Have the parallel port be at an unexpectred irq and address for a legacy parallel port 05:05.0 Parallel controller: Lava Computer mfg Inc Lava Parallel (rev 03) (prog-if 01 [BiDir]) Subsystem: Lava Computer mfg Inc Lava Parallel Flags: medium devsel, IRQ 10 I/O ports at ec00 [size=8] Kernel modules: parport_pc 3. Watch system become unstable or hang, and eventually jack coredumps with the above backtrace. However, like I mentioned, I believe the issue is snd-mtpav, which seems to require a "bidirectional legacy paralle port" at 0x378 and IRQ7. Module parport_pc resets the parallel port from IRQ 10 to 20 ## parport_pc 0000:05:05.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 ## parport0: PC-style at 0xec00, irq 20 [PCSPP,TRISTATE,EPP] However, loading parport_pc conflicts with MTPAV: ## ALSA sound/drivers/mtpav.c:590: MTVAP port 0xec00 is busy ## snd_mtpav: probe of snd_mtpav failed with error -16 Once "modprobe -r parport_pc parport" is done "modprobe snd_mtpav port=0xec00 irq=20" works: ## Motu MidiTimePiece on parallel port irq: 20 ioport: 0xec00 However, now, spurious MIDI input (that doesn't correspond to any physical key or controller events) occurs, as if the card were servicing interrupts and returning "noise". Prior, (at IRQ10) no MIDI input would occur at all no matter what controllers/keys operated). However, at IRQ 20, MIDI output works, despite the incoming MIDI "noise". IMHO, snd-mtpav isn't handling the interrupt remapping like parport_pc does: ## parport_pc 0000:05:05.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
Created attachment 395056 [details] File: backtrace
Also, there's a typo in the sourcecode http://www.openswan.net/download/openswan-ocf/klips-fsm/sound/drivers/mtpav.c "MTVAP" which can be noted in the output: # > Jan 31 16:34:43 gnulem kernel: ALSA sound/drivers/mtpav.c:590: MTVAP port 0xec00 is busy Per link above, Added author, hoping for guidance. Next step is to test same interface and cables on a computer with builtin legacy parallel port on motherboard. I believe the issues I'm having is because my Mobo (ASUS M4A78T-E) has no onboard legacy parallel port. which is where I run into trouble with interrupt handling (?) with add-on PCI parallel port cards. I have tried botha cheap "NetMos" single port PCI card, as well as a more expensive "Lava Computer" PCI card that claims you can change the IRQ and ioport address to legacy values. I also tried with two different parallel cables just to make sure I didn't have a rogue unidirectional parallel cable. I know at least one of the cables worked with windows and the MOTU MTPAV. In f12, MIDI output onm MTPAV works beautifully to all 8 channels. MIDI input doesn't ever reach the computer, other than w/ the parport_pc hack (modprobe and remove to force it to change IRQ to 20) which results in incoming MIDI noise. When I set snd-mtpav values based on "lspci -v" values, I can start jack & rosegarden and get the "row of LED's flashing in sequence" that indicates the device is working and initialized. 05:05.0 Parallel controller: Lava Computer mfg Inc Lava Parallel (rev 03) (prog-if 01 [BiDir]) Subsystem: Lava Computer mfg Inc Lava Parallel Flags: medium devsel, IRQ 10 I/O ports at ec00 [size=8] Kernel modules: parport_pc After I do "modprobe parport_pc", this changes: 05:05.0 Parallel controller: Lava Computer mfg Inc Lava Parallel (rev 03) (prog-if 01 [BiDir]) Subsystem: Lava Computer mfg Inc Lava Parallel Flags: medium devsel, IRQ 20 I/O ports at ec00 [size=8] Kernel modules: parport_pc
I tried the Motu Midi TimePiece (MTPAV) connected to a Mobo ASUS_M2N68-VM with a built-in parallel port under BIOS control. Using options snd-mtpav index=3 id="MTPAV" port=0x278 irq=5 options snd-mtpav index=3 id="MTPAV" port=0x378 irq=7 options snd-mtpav index=3 id="MTPAV" port=0x378 irq=5 All three resulted in the "spurious midi input" problem -- same behavior after I did the "parport hack" of modprobing and removing parport_pc for the purpose of moving it to IRQ20. One observation, I need to connect MIDI devices that don't send MIDI clock. Or use the MOTU LCD panel to tell it to filter MIDI clock before it reaches the computer. Seems like all the incoming MIDI data sent from say, a Yamaha DD-55 Digital Percussion, might end up "overflowing" the interrupts. Ongoing spurious MIDI input for minutes afterwards seems to be the result. Seems like snd-mtpav has bugs for MIDI input. It does, however, work for MIDI output.
The severity and priority of this bug is incorrect and inappropriate. This is more appropriate: "High Problem due to crashes, loss of data, severe memory, leak, etc."
Any movement on this issue? Also, please see comment 3/22 re incorrect priority, which should be "High."
It appears this bug is being ignored. Why are broken drivers like snd-mtpav shipped with Fedora and not maintained?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This was assigned to me accidentally.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.