[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