More info on hard lock-ups with MIDI on envy24, x86_64 machine

More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hello again,

I swapped the M-Audio envy24 card for a SoundBlaster PCI EMU10K1 card 
and the problem went away - MIDI worked fine. I put the envy24 card 
back in and the problem came back. It only happens when applications 
make a MIDI connection to the ALSA sequencer, whether the MIDI dongle 
is attached or not. Audio-only applications don't cause the lock-ups.

Is this perhaps a bug in the envy24 driver that only affects x86_64 
machines? Or if other people have this combination working OK, could 
it be faulty hardware? Any clues would be appreciated.

Cheers

Daniel




Hello!

I discovered this reliably repeatable hard lock-up while attempting to 
use MIDI with 64 Studio, the Debian-based x86_64 distribution we are 
working on. The kernel is 2.6.12 (non-SMP, as I only have one CPU in 
this machine at the moment) with Ingo Molnar's realtime premption 
patches and ALSA base package 1.0.9b-2. The lockup happens when 
applications connect to the MIDI input of the soundcard - then the 
system bombs. The reset switch is all that will work. 

Using strace with seq24, the last two lines in the terminal are:

read (3, "#\n# ALSA library configuration "..., 4096) = 4096
read (3,

However, the lock-up is also repeatable with the 32-bit version of 
Mandrake 10.1 on the same hardware, which uses a fairly stock 2.6.8 
kernel.

Motherboard: Tyan Tiger K8W dual Opteron, 1GB RAM
CPU: Single Opteron 240
Card: M Audio Audiophile PCI

What can I do to help track this bug down? The hardware is otherwise 
rock-solid stable. Below I have included the output of lsmod and 
lspci when running 64 Studio.

Cheers

Daniel



daniel@64studio:~$ lsmod
Module                  Size  Used by
mga                    60160  1
drm                    71296  2 mga
ipv6                  272488  8
thermal                15184  0
fan                     5192  0
button                  7776  0
processor              24136  1 thermal
ac                      5576  0
battery                10568  0
realtime                6536  0
commoncap               8576  1 realtime
ehci_hcd               35592  0
uhci_hcd               34016  0
usbcore               130872  3 ehci_hcd,uhci_hcd
8139too                28544  0
8139cp                 23488  0
mii                     6336  2 8139too,8139cp
snd_ice1712            68896  2
snd_ice17xx_ak4xxx      4800  1 snd_ice1712
snd_ak4xxx_adda         7424  2 snd_ice1712,snd_ice17xx_ak4xxx
snd_cs8427             10176  1 snd_ice1712
snd_ac97_codec         88912  1 snd_ice1712
snd_pcm_oss            55648  0
snd_mixer_oss          19072  3 snd_pcm_oss
snd_pcm               100200  3 snd_ice1712,snd_ac97_codec,snd_pcm_oss
snd_page_alloc         10952  1 snd_pcm
snd_i2c                 6720  2 snd_ice1712,snd_cs8427
snd_mpu401_uart         9216  1 snd_ice1712
i2c_amd756              7684  0
hw_random               6048  0
i2c_amd8111             7040  0
i2c_core               25368  2 i2c_amd756,i2c_amd8111
amd64_agp              13164  1
agpgart                37132  2 drm,amd64_agp
pcspkr                  4368  0
tsdev                   9280  0
mousedev               13796  1
evdev                  11136  0
psmouse                29764  0
ide_cd                 43616  0
cdrom                  39656  1 ide_cd
snd_seq_dummy           4356  0
snd_seq_oss            36032  0
snd_seq_midi            9856  0
snd_rawmidi            28640  2 snd_mpu401_uart,snd_seq_midi
snd_seq_midi_event      9856  2 snd_seq_oss,snd_seq_midi
snd_seq                58880  9 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_m idi_event
snd_timer              26784  2 snd_pcm,snd_seq
snd_seq_device          9680  5 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmi di,snd_seq
snd                    59624  15 
snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97 
_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_i2c,snd_mpu401_uart,snd_seq_oss,snd 
_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore              12000  3 snd
genrtc                 11380  0
ext3                  129744  1
jbd                    65920  1 ext3
mbcache                11784  1 ext3
ide_disk               18368  3
ide_generic             1536  0 [permanent]
via82cxxx              12336  0 [permanent]
trm290                  5252  0 [permanent]
triflex                 4544  0 [permanent]
slc90e66                6528  0 [permanent]
sis5513                14928  0 [permanent]
siimage                12928  0 [permanent]
serverworks             9360  0 [permanent]
sc1200                  8192  0 [permanent]
rz1000                  3264  0 [permanent]
piix                   12164  0 [permanent]
pdc202xx_old           12160  0 [permanent]
opti621                 5316  0 [permanent]
ns87415                 4780  0 [permanent]
hpt366                 20672  0 [permanent]
hpt34x                  6208  0 [permanent]
generic                 5376  0 [permanent]
cy82c693                5184  0 [permanent]
cs5530                  5952  0 [permanent]
cs5520                  5568  0 [permanent]
cmd64x                 12492  0 [permanent]
atiixp                  6736  0 [permanent]
amd74xx                14064  0 [permanent]
alim15x3               11352  0 [permanent]
aec62xx                 8640  0 [permanent]
pdc202xx_new           10112  0 [permanent]
ide_core              144772  28 
ide_cd,ide_disk,ide_generic,via82cxxx,trm290,tr 
iflex,slc90e66,sis5513,siimage,serverworks,sc1200,rz1000,piix,pdc202xx_old,opti6 
21,ns87415,hpt366,hpt34x,generic,cy82c693,cs5530,cs5520,cmd64x,atiixp,amd74xx,al 
im15x3,aec62xx,pdc202xx_new
unix                   32248  352

daniel@64studio:~$ lspci
0000:00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-8151 System 
Controller (rev 14)
0000:00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP 
Bridge (rev 14)
0000:00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI 
(rev 07)
0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC 
(rev 05)
0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE 
(rev 03)
0000:00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 
(rev 02)
0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 
05)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:01:04.0 Multimedia audio controller: VIA Technologies Inc. 
ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
0000:01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
0000:01:0b.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 
1.1 Controller (rev 61)
0000:01:0b.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 
1.1 Controller (rev 61)
0000:01:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
0000:02:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 
AGP (rev 01)



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Lee Revell]

On Thu, 2005-08-11 at 15:25 +0100, Daniel James wrote:
> Hello again,
> 
> I swapped the M-Audio envy24 card for a SoundBlaster PCI EMU10K1 card 
> and the problem went away - MIDI worked fine. I put the envy24 card 
> back in and the problem came back. It only happens when applications 
> make a MIDI connection to the ALSA sequencer, whether the MIDI dongle 
> is attached or not. Audio-only applications don't cause the lock-ups.
> 
> Is this perhaps a bug in the envy24 driver that only affects x86_64 
> machines? Or if other people have this combination working OK, could 
> it be faulty hardware? Any clues would be appreciated.

Sounds like a driver bug to me.

I guess you have tried to trigger the crash from a console as well as X,
and there's no Oops output?

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Lee,

> I guess you have tried to trigger the crash from a console as well
> as X

Not yet, but aconnect should take care of that...

> and there's no Oops output? 

I'll try to get some for you.
 
Cheers!

Daniel


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Lee,

> I guess you have tried to trigger the crash from a console as well
> as X

I've done that now. If I boot the system, switch to a console with 
ctrl-alt-f1 and run nothing but:

strace seq24

it starts to go wrong after: 

open ("/dev/snd/seq", O_RDWR)

There are a bunch of lines beginning with ioctl, then the killer blow 
is dealt by:

ioctl (3, CDROM_DEBUG or SNDRV_SEQ_IOCTL_SUBSCRIBE_PORT

(This is retyped from hand-written notes of course). The machine is 
then locked up solid - it's very reproducible too, same output every 
time. 

> and there's no Oops output? 

Nothing at all appears in the console or in /var/log/messages. Should 
I try increasing the log level or something like that?

Cheers!

Daniel


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Lee Revell]

On Thu, 2005-08-11 at 16:43 +0100, Daniel James wrote:
> Hi Lee,
> 
> > I guess you have tried to trigger the crash from a console as well
> > as X
> 
> I've done that now. If I boot the system, switch to a console with 
> ctrl-alt-f1 and run nothing but:
> 
> strace seq24
> 
> it starts to go wrong after: 
> 
> open ("/dev/snd/seq", O_RDWR)
> 
> There are a bunch of lines beginning with ioctl, then the killer blow 
> is dealt by:
> 
> ioctl (3, CDROM_DEBUG or SNDRV_SEQ_IOCTL_SUBSCRIBE_PORT
> 
> (This is retyped from hand-written notes of course). The machine is 
> then locked up solid - it's very reproducible too, same output every 
> time. 
> 
> > and there's no Oops output? 
> 
> Nothing at all appears in the console or in /var/log/messages. Should 
> I try increasing the log level or something like that?
> 

Try this (not even compile tested) patch.  Right now it looks like the
interrupt handler could loop forever if something weird happened.  Now
it will at least printk, and try to clear the interrupt pending
register.  This is shamelessly copied from the emu10k1 IRQ handler.

Index: alsa-kernel/pci/ice1712/ice1712.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ice1712/ice1712.c,v
retrieving revision 1.68
diff -u -r1.68 ice1712.c
--- alsa-kernel/pci/ice1712/ice1712.c	3 Aug 2005 12:40:11 -0000	1.68
+++ alsa-kernel/pci/ice1712/ice1712.c	11 Aug 2005 16:16:42 -0000
@@ -410,13 +410,14 @@
 static irqreturn_t snd_ice1712_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	ice1712_t *ice = dev_id;
-	unsigned char status;
+	unsigned char status, orig_status;
 	int handled = 0;
 
 	while (1) {
 		status = inb(ICEREG(ice, IRQSTAT));
 		if (status == 0)
 			break;
+		orig_status = status;
 		handled = 1;
 		if (status & ICE1712_IRQ_MPU1) {
 			if (ice->rmidi[0])
@@ -472,6 +473,20 @@
 				snd_pcm_period_elapsed(ice->playback_con_substream);
 			outb(ICE1712_IRQ_CONPBK, ICEREG(ice, IRQSTAT));
 		}
+		if (status) {
+			unsigned char bits;
+			snd_printk(KERN_ERR "ice1712: unhandled interrupt: 0x%08x\n", status);
+			bits = ICE1712_IRQ_MPU1 |
+			       ICE1712_IRQ_TIMER |
+			       ICE1712_IRQ_MPU2 |
+			       ICE1712_IRQ_PROPCM |
+			       ICE1712_IRQ_FM |
+			       ICE1712_IRQ_PBKDS |
+			       ICE1712_IRQ_CONCAP |
+			       ICE1712_IRQ_CONPBK;
+			outb(bits, ICEREG(ice, IRQSTAT));
+		}
+		outb(orig_status, ICEREG(ice, IRQSTAT));
 	}
 	return IRQ_RETVAL(handled);
 }




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Lee,

I apologise for the long delay in testing your patch. As our 
distribution is still quite new, we have still been sorting out our 
build environment and so on. Free is currently building a 2.6.13 
kernel package and we will test against that as soon as possible.

I also have a second Opteron test machine under construction that has 
an envy24 card (Delta 1010), so we'll be able to see if the lock-up 
is reproduced there too.

Cheers!

Daniel


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Lee,

We have now applied your patch to 2.6.13 and tried the test again. I 
get the same result, and there is still nothing relevant output 
to /var/log/messages

However, I am beginning to think that this may be a hardware fault or 
a problem specific to this motherboard or hardware combination. After 
a freeze-up triggered with strace seq24, I reboot and sometimes see 
this message from the BIOS (ie, before GRUB is loaded):

PCI IRQ ROUTING TABLE ERROR [02:00:00]

I don't know if this is the cause of the freeze-up, or just a 
consequence of it. A cold reboot makes the BIOS message go away.

To make sure this is a one-off problem, I'm going to build another 
Opteron machine and test ALSA with that.

Cheers!

Daniel


> On Thu, 2005-08-11 at 16:43 +0100, Daniel James wrote:
> > Hi Lee,
> >
> > > I guess you have tried to trigger the crash from a console as
> > > well as X
> >
> > I've done that now. If I boot the system, switch to a console
> > with ctrl-alt-f1 and run nothing but:
> >
> > strace seq24
> >
> > it starts to go wrong after:
> >
> > open ("/dev/snd/seq", O_RDWR)
> >
> > There are a bunch of lines beginning with ioctl, then the killer
> > blow is dealt by:
> >
> > ioctl (3, CDROM_DEBUG or SNDRV_SEQ_IOCTL_SUBSCRIBE_PORT
> >
> > (This is retyped from hand-written notes of course). The machine
> > is then locked up solid - it's very reproducible too, same output
> > every time.
> >
> > > and there's no Oops output?
> >
> > Nothing at all appears in the console or in /var/log/messages.
> > Should I try increasing the log level or something like that?
>
> Try this (not even compile tested) patch.  Right now it looks like
> the interrupt handler could loop forever if something weird
> happened.  Now it will at least printk, and try to clear the
> interrupt pending register.  This is shamelessly copied from the
> emu10k1 IRQ handler.
>
> Index: alsa-kernel/pci/ice1712/ice1712.c
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-kernel/pci/ice1712/ice1712.c,v
> retrieving revision 1.68
> diff -u -r1.68 ice1712.c
> --- alsa-kernel/pci/ice1712/ice1712.c	3 Aug 2005 12:40:11
> -0000	1.68 +++ alsa-kernel/pci/ice1712/ice1712.c	11 Aug 2005
> 16:16:42 -0000 @@ -410,13 +410,14 @@
>  static irqreturn_t snd_ice1712_interrupt(int irq, void *dev_id,
> struct pt_regs *regs) {
>  	ice1712_t *ice = dev_id;
> -	unsigned char status;
> +	unsigned char status, orig_status;
>  	int handled = 0;
>
>  	while (1) {
>  		status = inb(ICEREG(ice, IRQSTAT));
>  		if (status == 0)
>  			break;
> +		orig_status = status;
>  		handled = 1;
>  		if (status & ICE1712_IRQ_MPU1) {
>  			if (ice->rmidi[0])
> @@ -472,6 +473,20 @@
>  				snd_pcm_period_elapsed(ice->playback_con_substream);
>  			outb(ICE1712_IRQ_CONPBK, ICEREG(ice, IRQSTAT));
>  		}
> +		if (status) {
> +			unsigned char bits;
> +			snd_printk(KERN_ERR "ice1712: unhandled interrupt: 0x%08x\n",
> status); +			bits = ICE1712_IRQ_MPU1 |
> +			       ICE1712_IRQ_TIMER |
> +			       ICE1712_IRQ_MPU2 |
> +			       ICE1712_IRQ_PROPCM |
> +			       ICE1712_IRQ_FM |
> +			       ICE1712_IRQ_PBKDS |
> +			       ICE1712_IRQ_CONCAP |
> +			       ICE1712_IRQ_CONPBK;
> +			outb(bits, ICEREG(ice, IRQSTAT));
> +		}
> +		outb(orig_status, ICEREG(ice, IRQSTAT));
>  	}
>  	return IRQ_RETVAL(handled);
>  }



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Takashi Iwai]

At Wed, 14 Sep 2005 12:18:49 +0100,
Daniel James wrote:
> 
> Hi Lee,
> 
> We have now applied your patch to 2.6.13 and tried the test again. I 
> get the same result, and there is still nothing relevant output 
> to /var/log/messages
> 
> However, I am beginning to think that this may be a hardware fault or 
> a problem specific to this motherboard or hardware combination. After 
> a freeze-up triggered with strace seq24, I reboot and sometimes see 
> this message from the BIOS (ie, before GRUB is loaded):
> 
> PCI IRQ ROUTING TABLE ERROR [02:00:00]

This looks really bad.  Any change with ACPI boot options like
pci=noacpi or acpi=off?

Anyway, you can try the patch below, too.


Takashi


Index: alsa-kernel/pci/ice1712/ice1712.c
===================================================================
RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/ice1712/ice1712.c,v
retrieving revision 1.60
diff -u -r1.60 ice1712.c
--- alsa-kernel/pci/ice1712/ice1712.c	12 Sep 2005 10:27:50 -0000	1.60
+++ alsa-kernel/pci/ice1712/ice1712.c	14 Sep 2005 12:24:14 -0000
@@ -409,7 +409,10 @@
 
 	while (1) {
 		status = inb(ICEREG(ice, IRQSTAT));
-		if (status == 0)
+		if (! (status & (ICE1712_IRQ_MPU1 | ICE1712_IRQ_TIMER |
+				 ICE1712_IRQ_MPU2 | ICE1712_IRQ_PROPCM |
+				 ICE1712_IRQ_FM | ICE1712_IRQ_PBKDS |
+				 ICE1712_IRQ_CONCAP | ICE1712_IRQ_CONPBK)))
 			break;
 		handled = 1;
 		if (status & ICE1712_IRQ_MPU1) {


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Takashi,

> Any change with ACPI boot options like
> pci=noacpi or acpi=off?

Unfortunately it's no better, although I think that the kernel may be 
re-enabling ACPI by itself. Here is the output of /proc/interrupts:

           CPU0       
  0:      89261    IO-APIC-edge  timer
  1:       2003    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          0    IO-APIC-edge  rtc
 12:         97    IO-APIC-edge  i8042
 14:       2477    IO-APIC-edge  ide0
 15:         19    IO-APIC-edge  ide1
137:        674   IO-APIC-level  mga@pci:0000:02:00.0
145:        247   IO-APIC-level  eth0
153:          0   IO-APIC-level  ICE1712
NMI:         77 
LOC:      89235 
ERR:          0
MIS:          0

It could be because this is a dual-processor board with only one CPU 
in it. In /var/log/messages there is this:

Sep 14 14:16:05 64studio kernel: pnp: PnP ACPI: disabled
Sep 14 14:16:05 64studio kernel: PCI: Probing PCI hardware
Sep 14 14:16:05 64studio kernel: PCI: Probing PCI hardware (bus 00)
Sep 14 14:16:05 64studio kernel: PCI: Using IRQ router default 
[1022/746b] at 0000:00:07.3
Sep 14 14:16:05 64studio kernel: PCI->APIC IRQ transform: 0000:00:07.2
[D] -> IRQ 161
Sep 14 14:16:05 64studio kernel: PCI->APIC IRQ transform: 0000:02:00.0
[A] -> IRQ 137
Sep 14 14:16:05 64studio kernel: PCI->APIC IRQ transform: 0000:01:06.0
[A] -> IRQ 153
Sep 14 14:16:05 64studio kernel: PCI->APIC IRQ transform: 0000:01:08.0
[A] -> IRQ 145

> you can try the patch below, too.

Thanks! We'll give that a go.

Daniel


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Takashi,

> Anyway, you can try the patch below, too.

It's made no difference I'm afraid - and there are no clues 
in /var/log/messages that I can see. 

I'll test on a different machine and let you know what I find.

Cheers!

Daniel


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Takashi Iwai]

At Fri, 16 Sep 2005 13:52:48 +0100,
Daniel James wrote:
> 
> Hi Takashi,
> 
> > Anyway, you can try the patch below, too.
> 
> It's made no difference I'm afraid - and there are no clues 
> in /var/log/messages that I can see. 

The patch is to the lock up of the driver, not the ACPI stuff.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Takashi,

> > It's made no difference I'm afraid - and there are no clues
> > in /var/log/messages that I can see.
>
> The patch is to the lock up of the driver, not the ACPI stuff.

Other than running a MIDI program such as seq24 with strace, is there 
anything I can do to help diagnose this lock-up? Any logging options 
I should be enabling?

I have found on the Tyan site that they released a BIOS update for 
another one of their motherboards which was shipped with buggy IRQ 
routing. When we have our second Opteron test system running (which 
has an ASUS board) then we'll be able to confirm that it is a 
specific hardware problem.
 
Cheers!

Daniel


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Daniel James]

Hi Takashi, hi Lee,

I was unable to make any other progress with this bug, so I built a 
replica machine with a different motherboard, as I had begun to 
suspect a BIOS bug affecting PCI interrupts. Unfortunately, Tyan's 
support for BIOS updates seems to be very poor. 

I have put the tested M Audio Audiophile PCI sound card in the second 
test machine (identical configuration, Opteron 240, 1GB RAM except 
for motherboard, which is an ASUS SK8V. The Linux distribution 
installed is 64 Studio version 0.5.3 with kernel 2.6.13). MIDI 
appears to work perfectly in the second machine - at least I can get 
output from amsynth, and I can't reproduce the lock-up.

I therefore conclude that there is a motherboard/BIOS bug or a random 
hardware fault on this particular Tyan Tiger K8W S2875 board which 
causes the hard lock-ups when MIDI is used, but only
on an envy24 chipset card - it works fine with an EMU10K1 card such as 
a SoundBlaster Live. Weird, huh?

Thanks for all your help!

Daniel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: More info on hard lock-ups with MIDI on envy24, x86_64 machine

[Takashi Iwai]

At Mon, 5 Dec 2005 12:34:16 +0000,
Daniel James wrote:
> 
> Hi Takashi, hi Lee,
> 
> I was unable to make any other progress with this bug, so I built a 
> replica machine with a different motherboard, as I had begun to 
> suspect a BIOS bug affecting PCI interrupts. Unfortunately, Tyan's 
> support for BIOS updates seems to be very poor. 
> 
> I have put the tested M Audio Audiophile PCI sound card in the second 
> test machine (identical configuration, Opteron 240, 1GB RAM except 
> for motherboard, which is an ASUS SK8V. The Linux distribution 
> installed is 64 Studio version 0.5.3 with kernel 2.6.13). MIDI 
> appears to work perfectly in the second machine - at least I can get 
> output from amsynth, and I can't reproduce the lock-up.

Good to hear :)

> I therefore conclude that there is a motherboard/BIOS bug or a random 
> hardware fault on this particular Tyan Tiger K8W S2875 board which 
> causes the hard lock-ups when MIDI is used, but only
> on an envy24 chipset card - it works fine with an EMU10K1 card such as 
> a SoundBlaster Live. Weird, huh?

I believe the lockup is related likely with the irq stuff, and the
irq handling, especially routing, is pretty depending on the mobo
chipset.  But, still it's mysterious...


Thanks for reports, anyway.

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click