[alsa-devel] PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)
Takashi Iwai
tiwai at suse.de
Fri Jun 27 16:24:49 CEST 2008
At Fri, 27 Jun 2008 15:54:41 +0200,
Pavel Hofman wrote:
>
> Martin Krüger wrote:
> > Martin Krüger schrieb:
> >> Hi Pavel,
> >>
> >> sorry for the long break, i was really busy at studying.
> >>
> >> ---snip---
> >>
> >> Thanks a lot,
> >> Martin
> >> _______________________________________________
> >> Alsa-devel mailing list
> >> Alsa-devel at alsa-project.org
> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>
> >
> > Hi again,
> >
> > i did some other playing around this evening. (Debugging would be a word
> > much too big...)
> >
> > I commented out the logic stuff in the following subroutines of the
> > ice1724.c:
> >
> > - static int vt1724_midi_output_open(struct snd_rawmidi_substream *s)
> > - static int vt1724_midi_output_close(struct snd_rawmidi_substream *s)
> > - static void vt1724_midi_output_trigger(struct snd_rawmidi_substream
> > *s, int up)
> > - static void vt1724_midi_output_drain(struct snd_rawmidi_substream *s)
> >
> > The vt1724_enable_midi_irq(s, VT1724_IRQ_MPU_TX, 1) is killing my
> > kernel, i don't know why.
>
> So enabling the MPU TX interrupt causes lockup. Very similar to my
> experience with the previous version of the MIDI driver. Please put a
> debug line to snd_vt1724_interrupt, listing status bits for each
> interrupt. That was the place I experienced loops etc. In my case the
> flood eventually fooled the logging facility, but I could still read the
> first few logs.
>
>
> > On the input side everything works, so i am a bit confused. Again. ;-)
>
> I was also getting only TX interrupt floods, RX was OK.
If it's about TX, the patch below might stop lockup (but TX must be
still buggy)...
Takashi
---
diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c
index e596d77..b499328 100644
--- a/sound/pci/ice1712/ice1724.c
+++ b/sound/pci/ice1712/ice1724.c
@@ -382,23 +382,25 @@ static irqreturn_t snd_vt1724_interrupt(int irq, void *dev_id)
unsigned char status_mask =
VT1724_IRQ_MPU_RX | VT1724_IRQ_MPU_TX | VT1724_IRQ_MTPCM;
int handled = 0;
-#ifdef CONFIG_SND_DEBUG
int timeout = 0;
-#endif
while (1) {
status = inb(ICEREG1724(ice, IRQSTAT));
status &= status_mask;
if (status == 0)
break;
-#ifdef CONFIG_SND_DEBUG
if (++timeout > 10) {
- printk(KERN_ERR
- "ice1724: Too long irq loop, status = 0x%x\n",
- status);
+ status = inb(ICEREG1724(ice, IRQSTAT));
+ printk(KERN_ERR "ice1724: Too long irq loop, "
+ "status = 0x%x\n", status);
+ if (status & VT1724_IRQ_MPU_TX) {
+ printk(KERN_ERR "ice1724: Disabling MPU_TX\n");
+ outb(inb(ICEREG1724(ice, IRQMASK)) &
+ ~VT1724_IRQ_MPU_TX,
+ ICEREG1724(ice, IRQMASK));
+ }
break;
}
-#endif
handled = 1;
if (status & VT1724_IRQ_MPU_TX) {
spin_lock(&ice->reg_lock);
@@ -2410,8 +2412,10 @@ static int __devinit snd_vt1724_create(struct snd_card *card,
}
/* unmask used interrupts */
+#if 0 /* these are enabled/disabled dynamically */
mask = VT1724_IRQ_MPU_RX | VT1724_IRQ_MPU_TX;
outb(mask, ICEREG1724(ice, IRQMASK));
+#endif
/* don't handle FIFO overrun/underruns (just yet),
* since they cause machine lockups
*/
More information about the Alsa-devel
mailing list