Robin Gareus wrote: > Rui Nuno Capela wrote: >> Robin Gareus wrote: >>> Rui Nuno Capela wrote: >>>> Tim Goetze wrote: >>>>> [Tim Goetze] >>>>> >>>>>> [victor] >>>>>>> I was told to revert to 2.6.24.17 (not possible in my specific >>>>>>> case, but there you go), in this list. Or to join the tuner's list. >>>>>> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.3-rt2.bz2 >>>>>> >>>>>> >>>>>> worked for me. Applied cleanly and compiled well after turning off >>>>>> some RCU-related preemption options that caused compilation errors, >>>>>> but I was in no mood to find out the exact how and why. So far, it >>>>>> has collected a few hours of solid uptime too, but I haven't done >>>>>> any latency measuring. >>>>> Update: on my laptop, the patched 2.6.26.3 kernel boots into an >>>>> endless list of tracebacks on the console. On the main box, USB >>>>> MIDI input is only read as soon as a key is pressed on the USB >>>>> keyboard (the one with the letters, not the MIDI one ...). USB MIDI >>>>> out is broken, too. So it's back to the old version. >>>>> >>>> ah, it seems i'm not alone. >>> hehe , nice try. We won't let you go that easily ;) >>> >>>> i'm currently recovering myself from schock after returning from >>>> vacation and while trying 2.6.26.x-rt for the rentrĂ½e it all seemed >>>> to work fine except omg... midi timing is a wreck, specially wrt.alsa >>>> sequencer. event delivery is completely fubar. i mean, completely. >>>> true showstopper, whatever :( >>>> cacophony seems to be the right word to express what it is. >>>> however, didn't had the time to check whether NOHZ is at stake. i'm >>>> certainly going back to 2.6.25.x-rt where things are still sane and >>>> pleasant for a while. >>>> btw, having NOHZ=y (aka tickless kernel) has been the norm here, >>>> since its inception >>> CONFIG_NO_HZ=y - same norm here; with good results iff it works. >>> >> just tested 2.6.23.3-rt3 here with NO_HZ not set in my (old) pentium4 >> desktop. > >> it just confirmed that NO_HZ is not the culprit here. midi events are >> still being delivered *completely* out of time and the funny thing is it >> just gets somewhat better whenever you hit the pc-keyboard keys. >> however, it all gets back to badness once you stop pressing any key (eg. >> shift-key) > >> another funny thing goes that on a core2 duo T7200 laptop (x86_64) the >> same kernel config it runs all fine (NO_HZ=y) > > > http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock mentions TTY > drivers being a problem, actually "a long and difficult task".. >
ah. and more fun to the party: if the pc-keyboard is abused in way above said, to let midi delivery work miserably, it just stops working at all. you'll end with a dead pc-keyboard, something like its key-buffer gets fed up and can't get drained anymore. seeya -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
