[PlanetCCRMA] Midi clock out problems with latest two rt-kernels (system hang)
Fernando Lopez-Lezcano
nando at ccrma.Stanford.EDU
Tue Aug 23 17:20:12 PDT 2016
On 08/23/2016 12:19 PM, Lassi Ylikojola wrote:
> Hi
Hi again,
> I did a 35 minutes run sending midi clock to ice1712 based terratec
> dmx6fire card and there were no problems
> using 4.6.5-200.rt10.1.fc23.ccrma.x86_64+rt kernel
>
> My settings were as mentioned previously and jack was set to 48000/64/3
> (4 ms). All other cards still blacklisted except dmx6fire used.
>
> The system did not crash and there were no xruns.
>
> I also tested 10 minutes with same settings midi clock out to hw midi
> sequencer and midi notes in to zynaddsubfx and everything worked.
>
> So at this point i would say that midi works with ice1712 based cards
> using the latest ccrma rt kernel.
>
> I also have a hoontech DSP24 card blacklisted but did not test that.
Very good news, thanks for testing and happy to hear it is working (I
also did a brief test in my desktop at home and it did not seem to
freeze with an ice1712 card in it).
Best,
-- Fernando
> On Mon, Aug 22, 2016 at 9:08 PM, Lassi Ylikojola
> <lassi.ylikojola at gmail.com <mailto:lassi.ylikojola at gmail.com>> wrote:
>
> 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
> <mailto: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
> <mailto: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
> <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://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://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/24682/>
> http://article.gmane.org/gmane.linux.alsa.devel/25323/
> <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 <mailto: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>
> <mailto: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
> <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>
> <mailto: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/
> <http://www.teuton.org/~gabriel/jack_midi_clock/> or
> https://github.com/x42/jack_midi_clock
> <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>
> <tel: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>
> <mailto:PlanetCCRMA at ccrma.stanford.edu
> <mailto:PlanetCCRMA at ccrma.stanford.edu>>
>
> https://cm-mail.stanford.edu/mailman/listinfo/planetccrma
> <https://cm-mail.stanford.edu/mailman/listinfo/planetccrma>
>
>
>
>
>
>
>
>
More information about the PlanetCCRMA
mailing list