Re: [alsa-cvslog] alsa-kmirror: ALSA kernel mirror repository branch, master now at 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37

Re: [alsa-cvslog] alsa-kmirror: ALSA kernel mirror repository branch, master now at 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37

[Thierry Vignaud]

noreply-git@alsa-project.org writes:

> Hello,
> 
> This is an automated email from the git hooks/update script, it was
> generated because a ref change was pushed to the repository.
> 
> Updating branch, master,
>        via  9d46f4a919532c3f29a4ca1df3a4ce4686b11f37 (commit)
>       from  fc5102d6c6520f48d39faf572881bc520c41aeb7 (commit)
> 
> - Log -----------------------------------------------------------------
> commit 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37
> Author:     Jaroslav Kysela <perex@perex.cz>
> AuthorDate: Tue May 20 13:25:35 2008 +0200
> Commit:     Jaroslav Kysela <perex@perex.cz>
> CommitDate: Tue May 20 13:25:35 2008 +0200
> 
>     removed .hgtags

can we make the log appears in subject instead of useless sha1 ID?

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

Pavel Hofman wrote:
>Clemens,
>
>Thanks a lot. After a few pointer fixes to make it compile your code 
>works flawlessly for both the generic as well as realtime ubuntu kernel.
>
>I am enclosing the functioning patch.
>
>Now I cannot feel any delay difference between usb and ice1724 midi 
>inputs. Well done, gentlemen, thank you all.

Hi, 

thanks a lot for taking care for that issue. 
I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:

sound/pci/Kconfig (modified by hand)
sound/pci/ice1712/ice1712.h (modified by hand)
sound/pci/ice1712/envy24ht.h (modified by hand)
sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)

I double-checked all the handmade changes, should be ok. 

Midi in via "amidi -p hw:0 -d" works now without problem, 
but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
it causes an immediate crash. 

That would not be a problem for me, but jackd probes all ports, and is unusable now.

Perhaps i forgot a patch, is the output working for you? 

My System: 
Amd64 @ 32Bit, 
Debian Sid,
Esi Juli@

Regards, 

Martin Krüger

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Pavel Hofman]

Martin Krüger wrote:
> Pavel Hofman wrote:
>> Clemens,
>>
>> Thanks a lot. After a few pointer fixes to make it compile your code 
>> works flawlessly for both the generic as well as realtime ubuntu kernel.
>>
>> I am enclosing the functioning patch.
>>
>> Now I cannot feel any delay difference between usb and ice1724 midi 
>> inputs. Well done, gentlemen, thank you all.
> 
> Hi, 
> 
> thanks a lot for taking care for that issue. 
> I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:
> 
> sound/pci/Kconfig (modified by hand)
> sound/pci/ice1712/ice1712.h (modified by hand)
> sound/pci/ice1712/envy24ht.h (modified by hand)
> sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)
> 
> I double-checked all the handmade changes, should be ok. 
> 
> Midi in via "amidi -p hw:0 -d" works now without problem, 
> but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
> it causes an immediate crash. 
> 
> That would not be a problem for me, but jackd probes all ports, and is unusable now.
> 
> Perhaps i forgot a patch, is the output working for you? 

Hello Martin,

I did check the MIDI output using command

amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000

Ubuntu Studio 7.10, both -generic and -rt kernel, Audiotrak Prodigy 192, 
the original patch (I assume the current git version is identical).

There was no MIDI device connected to the output as I have none.

I traced if MIDI-out on Juli goes through the Xilinx CPLD, and it seemed 
the MIDI lines go straight to the connectors, just as on my Prodigy 192. 
Unfortunately, I do not have Juli available any more to test the patch.

Please could you provide more details about the crash?

Thanks,

Pavel.

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

Pavel Hofman wrote:
> Martin Krüger wrote:
>   
>> Pavel Hofman wrote:
>>     
>> Hi, 
>>
>> thanks a lot for taking care for that issue. 
>> I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:
>>
>> sound/pci/Kconfig (modified by hand)
>> sound/pci/ice1712/ice1712.h (modified by hand)
>> sound/pci/ice1712/envy24ht.h (modified by hand)
>> sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)
>>
>> I double-checked all the handmade changes, should be ok. 
>>
>> Midi in via "amidi -p hw:0 -d" works now without problem, 
>> but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
>> it causes an immediate crash. 
>>
>> That would not be a problem for me, but jackd probes all ports, and is unusable now.
>>
>> Perhaps i forgot a patch, is the output working for you? 
>>     
>
> Hello Martin,
>
> I did check the MIDI output using command
>
> amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000
>
> Ubuntu Studio 7.10, both -generic and -rt kernel, Audiotrak Prodigy 192, 
> the original patch (I assume the current git version is identical).
>
> There was no MIDI device connected to the output as I have none.
>
> I traced if MIDI-out on Juli goes through the Xilinx CPLD, and it seemed 
> the MIDI lines go straight to the connectors, just as on my Prodigy 192. 
> Unfortunately, I do not have Juli available any more to test the patch.
>
> Please could you provide more details about the crash?
>
> Thanks,
>
> Pavel.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   
Hello Pavel,

i just compiled a new 2.6.25.4 kernel with realtime support. the kernel 
is from kernel.org, so without any patches except the realtime patch 
from the alsa wiki.

The alsa source i use is the actual daily snapshot, compiled with

./configure --with-isapnp=no --with-sequencer=yes --with-oss=no 
--with-debug=full --with-kconfig=ice1724
make
make install-modules

This version should have the patches applied, i think.

amidi -l gives the following output:
Dir Device    Name
IO  hw:0,0    ICE1724 MIDI
, and as written above, amidi -p hw:0 -d works without any problems.

The fault appears immediately after trying to write anything to the 
hw:0, this

amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000

also produces a complete freeze of the system.
No matter, if my keyboard is attached or not.

That was the first time i compiled alsa with the debugging enabled, and 
i am currently trying to find out how to use is to give you more 
information. Is there anything else i can help? I tried to trace myself 
through the source code, but my knowledge about the used api is very weak...

Thanks much for your help,
Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Takashi Iwai]

At Mon, 26 May 2008 12:54:32 +0200,
Martin Krüger wrote:
> 
> Pavel Hofman wrote:
> > Martin Krüger wrote:
> >   
> >> Pavel Hofman wrote:
> >>     
> >> Hi, 
> >>
> >> thanks a lot for taking care for that issue. 
> >> I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:
> >>
> >> sound/pci/Kconfig (modified by hand)
> >> sound/pci/ice1712/ice1712.h (modified by hand)
> >> sound/pci/ice1712/envy24ht.h (modified by hand)
> >> sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)
> >>
> >> I double-checked all the handmade changes, should be ok. 
> >>
> >> Midi in via "amidi -p hw:0 -d" works now without problem, 
> >> but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
> >> it causes an immediate crash. 
> >>
> >> That would not be a problem for me, but jackd probes all ports, and is unusable now.
> >>
> >> Perhaps i forgot a patch, is the output working for you? 
> >>     
> >
> > Hello Martin,
> >
> > I did check the MIDI output using command
> >
> > amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000
> >
> > Ubuntu Studio 7.10, both -generic and -rt kernel, Audiotrak Prodigy 192, 
> > the original patch (I assume the current git version is identical).
> >
> > There was no MIDI device connected to the output as I have none.
> >
> > I traced if MIDI-out on Juli goes through the Xilinx CPLD, and it seemed 
> > the MIDI lines go straight to the connectors, just as on my Prodigy 192. 
> > Unfortunately, I do not have Juli available any more to test the patch.
> >
> > Please could you provide more details about the crash?
> >
> > Thanks,
> >
> > Pavel.
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >   
> Hello Pavel,
> 
> i just compiled a new 2.6.25.4 kernel with realtime support. the kernel 
> is from kernel.org, so without any patches except the realtime patch 
> from the alsa wiki.

To be sure -- does 2.6.25.4 without realtime support work?


Takashi

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

Takashi Iwai schrieb:
> At Mon, 26 May 2008 12:54:32 +0200,
> Martin Krüger wrote:
>   
>> Pavel Hofman wrote:
>>     
>>> Martin Krüger wrote:
>>>   
>>>       
>>>> Pavel Hofman wrote:
>>>>     
>>>> Hi, 
>>>>
>>>> thanks a lot for taking care for that issue. 
>>>> I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:
>>>>
>>>> sound/pci/Kconfig (modified by hand)
>>>> sound/pci/ice1712/ice1712.h (modified by hand)
>>>> sound/pci/ice1712/envy24ht.h (modified by hand)
>>>> sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)
>>>>
>>>> I double-checked all the handmade changes, should be ok. 
>>>>
>>>> Midi in via "amidi -p hw:0 -d" works now without problem, 
>>>> but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
>>>> it causes an immediate crash. 
>>>>
>>>> That would not be a problem for me, but jackd probes all ports, and is unusable now.
>>>>
>>>> Perhaps i forgot a patch, is the output working for you? 
>>>>     
>>>>         
>>> Hello Martin,
>>>
>>> I did check the MIDI output using command
>>>
>>> amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000
>>>
>>> Ubuntu Studio 7.10, both -generic and -rt kernel, Audiotrak Prodigy 192, 
>>> the original patch (I assume the current git version is identical).
>>>
>>> There was no MIDI device connected to the output as I have none.
>>>
>>> I traced if MIDI-out on Juli goes through the Xilinx CPLD, and it seemed 
>>> the MIDI lines go straight to the connectors, just as on my Prodigy 192. 
>>> Unfortunately, I do not have Juli available any more to test the patch.
>>>
>>> Please could you provide more details about the crash?
>>>
>>> Thanks,
>>>
>>> Pavel.
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>   
>>>       
>> Hello Pavel,
>>
>> i just compiled a new 2.6.25.4 kernel with realtime support. the kernel 
>> is from kernel.org, so without any patches except the realtime patch 
>> from the alsa wiki.
>>     
>
> To be sure -- does 2.6.25.4 without realtime support work?
>
>
> Takashi
>   
No. Not with an unpatched kernel set to "Preemptible Kernel (Low-Latency 
Desktop) PREEMPT_DESKTOP". I didn't test the lower preemption modes.

Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

Martin Krüger schrieb:
> Takashi Iwai schrieb:
>   
>> At Mon, 26 May 2008 12:54:32 +0200,
>> Martin Krüger wrote:
>>   
>>     
>>> Pavel Hofman wrote:
>>>     
>>>       
>>>> Martin Krüger wrote:
>>>>   
>>>>       
>>>>         
>>>>> Pavel Hofman wrote:
>>>>>     
>>>>> Hi, 
>>>>>
>>>>> thanks a lot for taking care for that issue. 
>>>>> I just tried it out by modifying the following files from the 2.6.26-rc3 kernel:
>>>>>
>>>>> sound/pci/Kconfig (modified by hand)
>>>>> sound/pci/ice1712/ice1712.h (modified by hand)
>>>>> sound/pci/ice1712/envy24ht.h (modified by hand)
>>>>> sound/pci/ice1712/ice1724.c (copied from the actual Git snapshot)
>>>>>
>>>>> I double-checked all the handmade changes, should be ok. 
>>>>>
>>>>> Midi in via "amidi -p hw:0 -d" works now without problem, 
>>>>> but when trying to write to the device, for example by "amidi -p hw:0 -s txdata.syx" 
>>>>> it causes an immediate crash. 
>>>>>
>>>>> That would not be a problem for me, but jackd probes all ports, and is unusable now.
>>>>>
>>>>> Perhaps i forgot a patch, is the output working for you? 
>>>>>     
>>>>>         
>>>>>           
>>>> Hello Martin,
>>>>
>>>> I did check the MIDI output using command
>>>>
>>>> amidi -p hw:0 -S F0411042110C000000000074FF0411042110C000000
>>>>
>>>> Ubuntu Studio 7.10, both -generic and -rt kernel, Audiotrak Prodigy 192, 
>>>> the original patch (I assume the current git version is identical).
>>>>
>>>> There was no MIDI device connected to the output as I have none.
>>>>
>>>> I traced if MIDI-out on Juli goes through the Xilinx CPLD, and it seemed 
>>>> the MIDI lines go straight to the connectors, just as on my Prodigy 192. 
>>>> Unfortunately, I do not have Juli available any more to test the patch.
>>>>
>>>> Please could you provide more details about the crash?
>>>>
>>>> Thanks,
>>>>
>>>> Pavel.
>>>> _______________________________________________
>>>> Alsa-devel mailing list
>>>> Alsa-devel@alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>   
>>>>       
>>>>         
>>> Hello Pavel,
>>>
>>> i just compiled a new 2.6.25.4 kernel with realtime support. the kernel 
>>> is from kernel.org, so without any patches except the realtime patch 
>>> from the alsa wiki.
>>>     
>>>       
>> To be sure -- does 2.6.25.4 without realtime support work?
>>
>>
>> Takashi
>>   
>>     
> No. Not with an unpatched kernel set to "Preemptible Kernel (Low-Latency 
> Desktop) PREEMPT_DESKTOP". I didn't test the lower preemption modes.
>
> Martin
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   
Hi,

i just compiled a 2.6.25-3 with Preemption disabled and i still get the 
the same.

Midi in works, Midi out leads to a complete system freeze.
Is there a workaroud of disabling just Midi out? That would solve the 
bug for me, and would prevent other users from freezing their system...

Thanks for your help,
Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Pavel Hofman]

Martin Krüger wrote:
> Martin Krüger schrieb:
>> Takashi Iwai schrieb:
>>   
>>> At Mon, 26 May 2008 12:54:32 +0200,
>>> Martin Krüger wrote:
>>>   
>>>     
>>>> Pavel Hofman wrote:
>>>>     
>>>>       
>>>>> Martin Krüger wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>       
>>>>>         
>>>> Hello Pavel,
>>>>
>>>> i just compiled a new 2.6.25.4 kernel with realtime support. the kernel 
>>>> is from kernel.org, so without any patches except the realtime patch 
>>>> from the alsa wiki.
>>>>     
>>>>       
>>> To be sure -- does 2.6.25.4 without realtime support work?
>>>
>>>
>>> Takashi
>>>   
>>>     
>> No. Not with an unpatched kernel set to "Preemptible Kernel (Low-Latency 
>> Desktop) PREEMPT_DESKTOP". I didn't test the lower preemption modes.
>>
>> Martin
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>   
> Hi,
> 
> i just compiled a 2.6.25-3 with Preemption disabled and i still get the 
> the same.
> 
> Midi in works, Midi out leads to a complete system freeze.
> Is there a workaroud of disabling just Midi out? That would solve the 
> bug for me, and would prevent other users from freezing their system...
> 

Hi Martin,

I will try a newer kernel on my home Ubuntu 7.10.

We really need to find out what freezes your system. Is it a complete 
freeze, or just heavy overload?

Originally, I experienced a complete freeze caused by infinite loop in 
IRQ handler ice1724.c:snd_vt1724_interrupt. This loop is already avoided 
by the timeout variable. Do you run with  CONFIG_SND_DEBUG? Does dmesg 
list any of the "ice1724: Too long irq loop..." messages?

Later on, I experienced an IRQ flood, caused by intermittent throwing 
ICE1724 IRQ (MPU transmit). I could see the IRQxx "process" hogging the 
CPU in top. If that is the case, please add some debug statements to 
ice1724.c:snd_vt1724_interrupt and look which IRQ gets fired (variable 
status).

In any case, please make sure you are using the latest GIT version with 
all the patches, so that we all work on the same code.

Disabling MIDI OUT - I have not tested the following patch, perhaps it 
needs some changes:


diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c
index e596d77..13695de 100644
--- a/pci/ice1712/ice1724.c
+++ b/pci/ice1712/ice1724.c
@@ -2546,7 +2546,7 @@ static int __devinit snd_vt1724_probe(struct 
pci_dev *pci,
                 if (ice->eeprom.data[ICE_EEP2_SYSCONF] & 
VT1724_CFG_MPU401) {
                         struct snd_rawmidi *rmidi;

-                       err = snd_rawmidi_new(card, "MIDI", 0, 1, 1, 
&rmidi);
+                       err = snd_rawmidi_new(card, "MIDI", 0, 0, 1, 
&rmidi);
                         if (err < 0) {
                                 snd_card_free(card);
                                 return err;
@@ -2554,11 +2554,7 @@ static int __devinit snd_vt1724_probe(struct 
pci_dev *pci
                         ice->rmidi[0] = rmidi;
                         rmidi->private_data = ice;
                         strcpy(rmidi->name, "ICE1724 MIDI");
-                       rmidi->info_flags = SNDRV_RAWMIDI_INFO_OUTPUT |
-                                           SNDRV_RAWMIDI_INFO_INPUT |
-                                           SNDRV_RAWMIDI_INFO_DUPLEX;
-                       snd_rawmidi_set_ops(rmidi, 
SNDRV_RAWMIDI_STREAM_OUTPUT,
-                                           &vt1724_midi_output_ops);
+                       rmidi->info_flags = SNDRV_RAWMIDI_INFO_INPUT;
                         snd_rawmidi_set_ops(rmidi, 
SNDRV_RAWMIDI_STREAM_INPUT,
                                             &vt1724_midi_input_ops);






Regards,

Pavel.

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

["Martin Krüger"]

Pavel Hofman schrieb:
> Hi Martin,
>
> I will try a newer kernel on my home Ubuntu 7.10.
>
> We really need to find out what freezes your system. Is it a complete 
> freeze, or just heavy overload?
>
> Originally, I experienced a complete freeze caused by infinite loop in 
> IRQ handler ice1724.c:snd_vt1724_interrupt. This loop is already avoided 
> by the timeout variable. Do you run with  CONFIG_SND_DEBUG? Does dmesg 
> list any of the "ice1724: Too long irq loop..." messages?
>
> Later on, I experienced an IRQ flood, caused by intermittent throwing 
> ICE1724 IRQ (MPU transmit). I could see the IRQxx "process" hogging the 
> CPU in top. If that is the case, please add some debug statements to 
> ice1724.c:snd_vt1724_interrupt and look which IRQ gets fired (variable 
> status).
>
> In any case, please make sure you are using the latest GIT version with 
> all the patches, so that we all work on the same code.
>
> Disabling MIDI OUT - I have not tested the following patch, perhaps it 
> needs some changes:
>
>
> diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c
> index e596d77..13695de 100644
> --- a/pci/ice1712/ice1724.c
> +++ b/pci/ice1712/ice1724.c
> @@ -2546,7 +2546,7 @@ static int __devinit snd_vt1724_probe(struct 
> pci_dev *pci,
>                  if (ice->eeprom.data[ICE_EEP2_SYSCONF] & 
> VT1724_CFG_MPU401) {
>                          struct snd_rawmidi *rmidi;
>
> -                       err = snd_rawmidi_new(card, "MIDI", 0, 1, 1, 
> &rmidi);
> +                       err = snd_rawmidi_new(card, "MIDI", 0, 0, 1, 
> &rmidi);
>                          if (err < 0) {
>                                  snd_card_free(card);
>                                  return err;
> @@ -2554,11 +2554,7 @@ static int __devinit snd_vt1724_probe(struct 
> pci_dev *pci
>                          ice->rmidi[0] = rmidi;
>                          rmidi->private_data = ice;
>                          strcpy(rmidi->name, "ICE1724 MIDI");
> -                       rmidi->info_flags = SNDRV_RAWMIDI_INFO_OUTPUT |
> -                                           SNDRV_RAWMIDI_INFO_INPUT |
> -                                           SNDRV_RAWMIDI_INFO_DUPLEX;
> -                       snd_rawmidi_set_ops(rmidi, 
> SNDRV_RAWMIDI_STREAM_OUTPUT,
> -                                           &vt1724_midi_output_ops);
> +                       rmidi->info_flags = SNDRV_RAWMIDI_INFO_INPUT;
>                          snd_rawmidi_set_ops(rmidi, 
> SNDRV_RAWMIDI_STREAM_INPUT,
>                                              &vt1724_midi_input_ops);
>
>
>
>
>
>
> Regards,
>
> Pavel.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   

Hi Pavel,

now i'm confused. I just compiled the current daily snapshot with
"./configure --with-isapnp=no --with-sequencer=yes --with-oss=no 
--with-debug=verbose --with-cards=ice1724".

That should give as much debug messages as i need, as i understood. I 
get only one Message, telling me that ice1724 is using the defined 
eeprom. After using the midi output port, there is no more message in 
any log at all.

Due to this, it is really hard to understand the problem, for me it 
looks like a complete freeze. If i would get "just" a heavy overload, 
the numlock should still react within 10 minutes, and the cpu cooler 
should be louder. Both of this should also happen during an irq flood, 
if i understood that right.

Do you have any idea how to find out whats happening there? I will try 
your patch this evening.

Thanks a lot for your help,
regards,

Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Pavel Hofman]

Martin Krüger wrote:
> Pavel Hofman schrieb:
>> Hi Martin,
>>
...............
> 
> Hi Pavel,
> 
> now i'm confused. I just compiled the current daily snapshot with
> "./configure --with-isapnp=no --with-sequencer=yes --with-oss=no 
> --with-debug=verbose --with-cards=ice1724".
> 
> That should give as much debug messages as i need, as i understood. I 
> get only one Message, telling me that ice1724 is using the defined 
> eeprom. After using the midi output port, there is no more message in 
> any log at all.

That is OK, it means the loop-detection code does not kick in, i.e. 
there is no problem with clearing interrupt status bits.

> 
> Due to this, it is really hard to understand the problem, for me it 
> looks like a complete freeze. If i would get "just" a heavy overload, 
> the numlock should still react within 10 minutes, and the cpu cooler 
> should be louder. Both of this should also happen during an irq flood, 
> if i understood that right.

My IRQ flood loaded the PC heavily, but I could still switch windows and 
move mouse around, with long delays. Yours looks like a real freeze.

> 
> Do you have any idea how to find out whats happening there? 

I just add debug printk's to major code points all the way down to 
bottom functions. It takes many compiling and rebooting (after freezes). 
  Unfortunately I do not know of any other way to hunt the bug down.

Good luck,

Pavel.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Pavel Hofman]

Pavel Hofman wrote:
> 
> Martin Krüger wrote:
>> Pavel Hofman schrieb:
>>> Hi Martin,
>>>
> ...............
>> Hi Pavel,
>>
>> now i'm confused. I just compiled the current daily snapshot with
>> "./configure --with-isapnp=no --with-sequencer=yes --with-oss=no 
>> --with-debug=verbose --with-cards=ice1724".
>>
>> That should give as much debug messages as i need, as i understood. I 
>> get only one Message, telling me that ice1724 is using the defined 
>> eeprom. After using the midi output port, there is no more message in 
>> any log at all.
> 
> That is OK, it means the loop-detection code does not kick in, i.e. 
> there is no problem with clearing interrupt status bits.
> 
>> Due to this, it is really hard to understand the problem, for me it 
>> looks like a complete freeze. If i would get "just" a heavy overload, 
>> the numlock should still react within 10 minutes, and the cpu cooler 
>> should be louder. Both of this should also happen during an irq flood, 
>> if i understood that right.
> 
> My IRQ flood loaded the PC heavily, but I could still switch windows and 
> move mouse around, with long delays. Yours looks like a real freeze.
> 
>> Do you have any idea how to find out whats happening there? 
> 
> I just add debug printk's to major code points all the way down to 
> bottom functions. It takes many compiling and rebooting (after freezes). 
>   Unfortunately I do not know of any other way to hunt the bug down.


Ubuntu Studio 7.10 with kernel upgraded to 2.6.25 according to 
http://74.125.39.104/search?q=cache:0fDGNG0KRbwJ:forum.zackyfiles.com/showthread.php%3Fp%3D3351188+gutsy+2.6.25+package&hl=en&ct=clnk&cd=1 


Latest download of alsa from git, compiled by ./gitcompile.

Ancient Duron 1GHz, Audiotrak Prodigy 192

Both MIDI input (amidi -p hw:0 -d) and output (amidi -p hw:0 -S 
F0411042110C000000000074FF0411042110C0000000000\
74F7F0411042110C000000000074F7F0411042110C0F0411\
042110C000000000074FF0411042110C000000000074F7F0\
411042110C000000000074F7F0411042110C0)
work fine, no problems.

Regards,

Pavel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

Pavel Hofman schrieb:
> Pavel Hofman wrote:
>
> Ubuntu Studio 7.10 with kernel upgraded to 2.6.25 according to 
> http://74.125.39.104/search?q=cache:0fDGNG0KRbwJ:forum.zackyfiles.com/showthread.php%3Fp%3D3351188+gutsy+2.6.25+package&hl=en&ct=clnk&cd=1 
>
>
> Latest download of alsa from git, compiled by ./gitcompile.
>
> Ancient Duron 1GHz, Audiotrak Prodigy 192
>
> Both MIDI input (amidi -p hw:0 -d) and output (amidi -p hw:0 -S 
> F0411042110C000000000074FF0411042110C0000000000\
> 74F7F0411042110C000000000074F7F0411042110C0F0411\
> 042110C000000000074FF0411042110C000000000074F7F0\
> 411042110C000000000074F7F0411042110C0)
> work fine, no problems.
>
> Regards,
>
> Pavel.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   


Hi Pavel,

sorry for the long break, i was really busy at studying.

The problem still exists for me, and i tried to debug it a bit by adding 
printk's to the rawmidi module.
Unfortunatly, i am more confused at this problem than ever before.

I added printk("some text"); to the following subroutines:

- int snd_rawmidi_transmit
- snd_rawmidi_kernel_write1
- snd_rawmidi_kernel_write

As i read the source, these routines should be the ones who do all the 
midi output to the device. And the printk's should appear in the 
kern.log files.
Please tell me, if i am wrong here.
But none of the printk outputs appear in the logging. I added some 
outputs similar to the other ones to the Midi Input procedures, and 
everything works fine.

Does amidi write directly to the routines above? Or is there some Stuff 
between? I tried to read the amidi source, but my C/C++ knowledge is 
very poor, i am more on the java side of code...

Perhaps you have an idea where to start the debugging, to find that bug...

Thanks a lot,
Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Martin Krüger]

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@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.
On the input side everything works, so i am a bit confused. Again. ;-)

I will continue debugging, at all this seems to be a good starting point 
for me.

It would be glad, if you could help me some way.

Martin

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Pavel Hofman]

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@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.

Good luck,


Pavel.

Re: PATCH - MIDI on ice1724 - real-time kernel problem SOLVED(?)

[Takashi Iwai]

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@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
 	 */

can we make the log appears in subject instead of useless sha1 ID?

[Thierry Vignaud]

Thierry Vignaud <tvignaud@mandriva.com> writes:

> > This is an automated email from the git hooks/update script, it was
> > generated because a ref change was pushed to the repository.
> > 
> > Updating branch, master,
> >        via  9d46f4a919532c3f29a4ca1df3a4ce4686b11f37 (commit)
> >       from  fc5102d6c6520f48d39faf572881bc520c41aeb7 (commit)
> > 
> > - Log -----------------------------------------------------------------
> > commit 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37
> > Author:     Jaroslav Kysela <perex@perex.cz>
> > AuthorDate: Tue May 20 13:25:35 2008 +0200
> > Commit:     Jaroslav Kysela <perex@perex.cz>
> > CommitDate: Tue May 20 13:25:35 2008 +0200
> > 
> >     removed .hgtags
> 
> can we make the log appears in subject instead of useless sha1 ID?

I ask again if we could make the change log appears in subject instead
of useless sha1 ID?

Current commits mails are fare less readable than previous ones (when
using hg).  This is a regression... :-(

Re: can we make the log appears in subject instead of useless sha1 ID?

[Takashi Iwai]

At Wed, 18 Jun 2008 11:58:12 +0200,
Thierry Vignaud wrote:
> 
> Thierry Vignaud <tvignaud@mandriva.com> writes:
> 
> > > This is an automated email from the git hooks/update script, it was
> > > generated because a ref change was pushed to the repository.
> > > 
> > > Updating branch, master,
> > >        via  9d46f4a919532c3f29a4ca1df3a4ce4686b11f37 (commit)
> > >       from  fc5102d6c6520f48d39faf572881bc520c41aeb7 (commit)
> > > 
> > > - Log -----------------------------------------------------------------
> > > commit 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37
> > > Author:     Jaroslav Kysela <perex@perex.cz>
> > > AuthorDate: Tue May 20 13:25:35 2008 +0200
> > > Commit:     Jaroslav Kysela <perex@perex.cz>
> > > CommitDate: Tue May 20 13:25:35 2008 +0200
> > > 
> > >     removed .hgtags
> > 
> > can we make the log appears in subject instead of useless sha1 ID?
> 
> I ask again if we could make the change log appears in subject instead
> of useless sha1 ID?
> 
> Current commits mails are fare less readable than previous ones (when
> using hg).  This is a regression... :-(

Oh, SHA1 ID is often more useful :)

But, yes, the current mail is often just a crap.
Do you know of any good git-commit-mail-generating script?


Takashi