[PlanetCCRMA] Fwd: Midi clock out problems with latest two rt-kernels (system hang)
Lassi Ylikojola
lassi.ylikojola at gmail.com
Mon Aug 22 11:08:47 PDT 2016
Hi
4.6.5-200.rt10.1.fc23.ccrma.x86_64+rt seems to fix things for me somewhat.
I did 15min run midi clock out to ice1712 device and system is running ok.
I'll do a longer run later on.
Lassi
---------- Forwarded message ----------
From: Lassi Ylikojola <lassi.ylikojola at gmail.com>
Date: Fri, Jul 8, 2016 at 10:59 PM
Subject: Re: [PlanetCCRMA] Midi clock out problems with latest two
rt-kernels (system hang)
To: Fernando Lopez-Lezcano <nando at ccrma.stanford.edu>
Hi
Regarding ice1712 problem i found an interesting post saying there are
problems with rt-patches and maybe a fix from :
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-
November/012094.html
These might also be of interest:
http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000650.html
http://alsa-devel.alsa-project.narkive.com/XOZGNHsV/
crash-reboot-with-rawmidi-on-ice1712-dual-opteron
http://article.gmane.org/gmane.linux.alsa.devel/24682/
http://article.gmane.org/gmane.linux.alsa.devel/25323/
BR Lassi
On Tue, Jun 21, 2016 at 7:09 PM, Fernando Lopez-Lezcano <
nando at ccrma.stanford.edu> wrote:
> On 06/21/2016 02:33 AM, Lassi Ylikojola wrote:
>
>> Hi
>>
>
> Hi!,
>
> Tested last night on my system two 70 minutes runs with RT19, 48000/64/4
>> sending AND receiving midi/midi clock via usb midi interface(CH345) the
>> system was rock solid. No xruns no nothing. Everyhing worked. I'm not
>> sure but i think something was wrong with my initial tests. Non session
>> manager not shutting down all apps or something or some updates fixed
>> something.
>>
>> Anyway as soon as i pushed midi clock via ice1712 the system halted. It
>> took under a minute. So all points to ice1712 doing something wrong
>> with RT kernels at the moment.
>>
>
> Thanks for taking the time to retest this thoroughly! I will summarize and
> post to the lists and copy you. Hopefully someone will be able to spot the
> problem and come up with a fix.
>
> Best,
> -- Fernando
>
>
> On Mon, Jun 20, 2016 at 11:24 PM, Lassi Ylikojola
>> <lassi.ylikojola at gmail.com <mailto:lassi.ylikojola at gmail.com>> wrote:
>>
>> Hi
>>
>> I answered your questions and id some further testing today. Using
>> usb midi interface(CH345) and usb sound card(m-audio micro dac) i
>> think there are no crashes at least for ten minutes i tested.
>>
>> I blacklisted:
>> blacklist snd_hda_intel ( integrated card. This was blacklisted
>> before)
>> blacklist snd_ice1712
>> blacklist snd_ice17xx_ak4xxx
>>
>> And my lsmod |grep snd
>> snd_hrtimer 16384 2
>> snd_seq_dummy 16384 2
>> snd_seq_midi 16384 9
>> snd_seq_midi_event 16384 1 snd_seq_midi
>> snd_usb_audio 176128 16
>> snd_usbmidi_lib 36864 1 snd_usb_audio
>> snd_hwdep 16384 1 snd_usb_audio
>> snd_rawmidi 32768 2 snd_usbmidi_lib,snd_seq_midi
>> snd_seq 69632 79
>> snd_seq_midi_event,snd_seq_dummy,snd_seq_midi
>> snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi
>> snd_pcm 114688 2 snd_usb_audio
>> snd_timer 32768 3 snd_hrtimer,snd_pcm,snd_seq
>>
>>
>> So it seems it's related to those
>> modules(snd_ice1712,snd_ice17xx_ak4xxx) on my system. I think your
>> card M-Audio Delta 1010 card uses also ice1712. Some sort of
>> regression...
>>
>> I remembered seeing this thread from 2006:
>> 'Midi issues with 1.0.12 and ice1712'
>> http://www.spinics.net/linux/fedora/alsa-user/msg00346.html
>>
>> I tried the mentioned option to no avail:
>> "options seq seq_default_timer_device=0"
>>
>>
>> I also have a laptop on which i tested with the same usb midi
>> interface(CH345) and laptops internal pci intel sound card and no
>> problems on ten minute test.
>>
>> lsmod |grep snd
>> snd_hda_codec_idt 57344 1
>> snd_hda_codec_generic 69632 1 snd_hda_codec_idt
>> snd_hda_codec_hdmi 49152 1
>> snd_hda_intel 40960 11
>> snd_hda_codec 126976 4
>> snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_codec_
>> generic,snd_hda_intel
>> snd_hda_core 61440 5
>> snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_codec_
>> generic,snd_hda_codec,snd_hda_intel
>> snd_hwdep 16384 1 snd_hda_codec
>> snd_seq 69632 0
>> snd_seq_device 16384 1 snd_seq
>> snd_pcm 114688 4
>> snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
>> snd_timer 32768 2 snd_pcm,snd_seq
>> snd 77824 32
>> snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_idt,
>> snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_
>> intel,snd_seq_device
>> soundcore 16384 1 snd
>>
>> I try to do longer tests as soon as possible.
>>
>>
>> Lassi
>>
>>
>> On Mon, Jun 13, 2016 at 2:50 AM, Fernando Lopez-Lezcano
>> <nando at ccrma.stanford.edu <mailto:nando at ccrma.stanford.edu>> wrote:
>>
>> On 06/11/2016 02:07 PM, Lassi Ylikojola wrote:
>>
>> Hi
>>
>>
>> Hi,
>> Thanks for the report! I guess we should forward this to the rt
>> kernel mailing list.
>>
>> I tried a quick test here at home with rt19 but my system is
>> much simpler than yours. This is on an i7-3770K CPU and with one
>> M Audio Delta 1010 card (plus the motherboard HDA Intel and an
>> NVidia HDMI sound interface as well running nouveau).
>>
>> I started seq24, selected (in "Options") to send MIDI Clock to
>> the Delta 1010, then created some random notes (also routed to
>> the 1010) and pressed play. It plays for a while.
>>
>> It did hang after some time but I don't know what happened. But
>> I just managed to hang it again (instantly this time). Brought
>> up the pattern editor and clicked on "Select Output Bus" (which
>> by default was showing the Midi Through Port).
>>
>> But this is not repeatable. I just did it again (tried several
>> times) and it did not happen. A race condition, probably...
>> After a while I noticed that seq24 was not playing - I moved the
>> mouse and it moved the cursor a tiny bit and then the system was
>> again hung.
>>
>> Are you getting "instant hangs" or is this something that
>> happens randomly?
>>
>>
>> Sending midi to ice1712 card the system hangs within a minute.
>> Sending midi via usb midi interface and audio coming from ice1712
>> card hangs the system randomly.
>>
>>
>>
>> I presume also that after the cold reboot there is nothing left
>> in /var/log/messages that may be a clue? (an "Oops" or "BUG" - I
>> don't see anything in my test machine).
>>
>> #Disable SElinux
>> setenforce 0
>>
>>
>> Why are you doing this? I have never had to disable SElinux for
>> audio reasons. Were you getting errors from SElinux?
>>
>> I really don't remember why i use this in my config. I read about it
>> somewhere.
>>
>>
>> -- Fernando
>>
>>
>> clock send from jack clients(seq24, sequencer64,
>> jack_midi_clock from
>> http://www.teuton.org/~gabriel/jack_midi_clock/ or
>> https://github.com/x42/jack_midi_clock) to external devices
>> via midi out
>> interface.
>>
>> Sending midi clock to external devices via ice1712 based
>> cards hangs the
>> system and i have to cold reset the computer. I was able to
>> circumvent
>> this on rt 17 by sending midi clock via usb midi
>> interface(CH345).
>> However on rt19 this works also and the system does not hang
>> but the
>> clock is not send correctly. It lacks behind or it is out of
>> place(This
>> needs more tests with other clock sources).
>>
>> Tested kernels:
>>
>> 4.4.12-300.rt19.1.fc23.ccrma.x86_64+rt ice1712 based cards
>> midi out
>> hangs the system. Midi out via usb interface CH345 works but
>> not on
>> correct beat/time. I have to retest this with different
>> clock sources.
>>
>> 4.4.9-300.rt17.1.fc23.ccrma.x86_64+rt ice1712 based cards
>> midi out hangs
>> the system. Midi out via usb interface CH345 works.
>>
>> 4.4.4-301.rt11.1.fc23.ccrma.x86_64+rt is ok. I can send midi
>> clock from
>> ice1712 devices and system is stable.
>>
>> The system is stable with stock kernel also.
>>
>> So any help appreciated. I use rtirq and below some system
>> info.
>>
>>
>> System info:
>>
>> Scipt before every session:
>> # fedora chmod
>> chmod 666 /dev/snd/seq
>>
>> #wait 2 secs
>> sleep 2
>>
>> #load performance governor
>> modprobe cpufreq_performance
>>
>> #wait 1 sec
>> sleep 1
>>
>> #Set full speed for all processors
>> echo performance >
>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>> echo performance >
>> /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
>> echo performance >
>> /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
>> echo performance >
>> /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
>>
>>
>>
>> cat .jackdrc
>> /usr/bin/jackd -dalsa -r48000 -p64 -n4 -D -Chw:DMX6Fire
>> -Phw:DMX6Fire
>>
>> Tried different -p and -n options (-p128 -n2).
>>
>> cat /proc/asound/cards
>> 0 [A61 ]: USB-Audio - Axiom 61
>> M-Audio Axiom 61 at
>> usb-0000:00:1d.7-2.3, full speed
>> 1 [CH345 ]: USB-Audio - CH345
>> QinHeng CH345 at usb-0000:00:1a.2-2,
>> full speed
>> 2 [nanoPAD2 ]: USB-Audio - nanoPAD2
>> KORG INC. nanoPAD2 at
>> usb-0000:00:1d.7-2.4.4,
>> full speed
>> 3 [DSP24 ]: ICE1712 - Hoontech SoundTrack Audio
>> DSP24
>> Hoontech SoundTrack Audio DSP24 at
>> 0xec00, irq 16
>> 4 [DMX6Fire ]: ICE1712 - TerraTec DMX6Fire
>> TerraTec DMX6Fire at 0xe400, irq 17
>>
>>
>>
>> lsmod |grep midi
>> snd_seq_midi 16384 16
>> snd_seq_midi_event 16384 1 snd_seq_midi
>> snd_usbmidi_lib 36864 1 snd_usb_audio
>> snd_rawmidi 32768 3
>> snd_usbmidi_lib,snd_mpu401_uart,snd_seq_midi
>> snd_seq 69632 80
>> snd_seq_midi_event,snd_seq_dummy,snd_seq_midi
>> snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_
>> midi
>> snd 73728 47
>> snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_
>> timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,
>> snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427
>>
>>
>>
>> lsmod |grep 1712
>> snd_ice1712 77824 18
>> snd_cs8427 16384 1 snd_ice1712
>> snd_i2c 16384 2 snd_ice1712,snd_cs8427
>> snd_ice17xx_ak4xxx 16384 1 snd_ice1712
>> snd_ak4xxx_adda 20480 <tel:20480> 2
>>
>> snd_ice1712,snd_ice17xx_ak4xxx
>> snd_mpu401_uart 16384 1 snd_ice1712
>> snd_ac97_codec 131072 1 snd_ice1712
>> snd_pcm 114688 5
>> snd_ice1712,snd_usb_audio,snd_ac97_codec
>> snd 73728 47
>> snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_
>> timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,
>> snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427
>>
>>
>>
>> cat /proc/cpuinfo
>> processor: 0
>> vendor_id: GenuineIntel
>> cpu family: 6
>> model: 23
>> model name: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
>> stepping: 7
>> microcode: 0x70a
>> cpu MHz: 2499.000
>> cache size: 3072 KB
>> physical id: 0
>> siblings: 4
>> core id: 0
>> cpu cores: 4
>> apicid: 0
>> initial apicid: 0
>> fpu: yes
>> fpu_exception: yes
>> cpuid level: 10
>> wp: yes
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat
>> pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx lm
>> constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf
>> pni dtes64
>> monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1
>> lahf_lm
>> dtherm tpr_shadow vnmi flexpriority
>> bugs:
>> bogomips: 4999.64
>> clflush size: 64
>> cache_alignment: 64
>> address sizes: 36 bits physical, 48 bits virtual
>> power management:
>>
>>
>>
>> cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3
>> 0: 132 0 0 0 IO-APIC
>> 2-edge
>> timer
>> 1: 1 0 1 0 IO-APIC
>> 1-edge
>> i8042
>> 8: 0 0 0 1 IO-APIC
>> 8-edge
>> rtc0
>> 9: 0 0 0 0 IO-APIC
>> 9-fasteoi
>> acpi
>> 12: 0 2 1 1 IO-APIC
>> 12-edge
>> i8042
>> 16: 70849 70400 84763 74134 IO-APIC
>> 16-fasteoi
>> uhci_hcd:usb3, snd_ice1712
>> 17: 7682775 7678025 7665199 7669368 IO-APIC
>> 17-fasteoi
>> snd_ice1712, enp2s0
>> 18: 391807 398860 393361 405386 IO-APIC
>> 18-fasteoi
>> ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8
>> 19: 213063 213252 212895 213142 IO-APIC
>> 19-fasteoi
>> ata_piix, ata_piix, uhci_hcd:usb7, firewire_ohci
>> 21: 0 0 0 0 IO-APIC
>> 21-fasteoi
>> uhci_hcd:usb4
>> 23: 910884 913622 912322 912878 IO-APIC
>> 23-fasteoi
>> ehci_hcd:usb2, uhci_hcd:usb6
>> 27: 3989331 3982167 3990009 3981430 PCI-MSI
>> 524288-edge
>> nvkm
>> NMI: 11793 11536 11770 11499
>> Non-maskable interrupts
>> LOC: 25987631 29292447 20791378 19576474 Local
>> timer interrupts
>> SPU: 0 0 0 0 Spurious
>> interrupts
>> PMI: 11793 11536 11770 11499 Performance
>> monitoring interrupts
>> IWI: 1 2 0 0 IRQ work
>> interrupts
>> RTR: 0 0 0 0 APIC ICR
>> read retries
>> RES: 17114611 15588423 26439361 24596924
>> Rescheduling interrupts
>> CAL: 5808866 6203269 7499109 6750939 Function
>> call interrupts
>> TLB: 923613 903498 920749 891225 TLB
>> shootdowns
>> TRM: 0 0 0 0 Thermal
>> event interrupts
>> THR: 0 0 0 0 Threshold
>> APIC interrupts
>> DFR: 0 0 0 0 Deferred
>> Error APIC
>> interrupts
>> MCE: 0 0 0 0 Machine
>> check exceptions
>> MCP: 282 282 282 282 Machine
>> check polls
>> ERR: 0
>> MIS: 0
>> PIN: 0 0 0 0
>> Posted-interrupt
>> notification event
>> PIW: 0 0 0 0
>> Posted-interrupt
>> wakeup event
>>
>>
>> BR Lassi
>>
>>
>> _______________________________________________
>> PlanetCCRMA mailing list
>> PlanetCCRMA at ccrma.stanford.edu
>> <mailto:PlanetCCRMA at ccrma.stanford.edu>
>> https://cm-mail.stanford.edu/mailman/listinfo/planetccrma
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20160822/b1130811/attachment-0001.html>
More information about the PlanetCCRMA
mailing list