Re: [alsa-devel] [alsa-cvslog] alsa-kmirror: ALSA kernel mirror repository branch, master now at 9d46f4a919532c3f29a4ca1df3a4ce4686b11f37
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?
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
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.
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
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
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
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
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.
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
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.
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/showth...
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.
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/showth...
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
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
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.
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 */
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 .hgtagscan 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... :-(
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 .hgtagscan 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
participants (5)
-
"Martin Krüger" -
Martin Krüger
-
Pavel Hofman -
Takashi Iwai -
Thierry Vignaud