On 14-04-19 10:42 AM, jordan wrote: > Hey Paul, > >> I've got some AMD kit that has just been freed up from winter >> heating duty - sometime later this week I should be able to try to >> reproduce what you have seen, and knowing it works w/o the above >> softirq patch monkeying around should be a good lead on this. > > That would be awesome! IIRC, Sebastian said that he didn't have said > h/w CPU kicking around to test with, at some point in my original > thread on this subject... and i just don't have the skill set required So I stuck the -rt patches onto 3.14.1 last night; made a defconfig and then enabled RT_FULL in the resulting .config and that booted right up on a 1090T six core phenom, which kind of surprised me. I should be able to dig up an athlon quad and see what it does... Paul. -- > [so i am very appreciative of anything you can do]. I don't know if > you caught it, but slavo also saw this thread, which led him to try > reverting those patches, which also allowed his arm platform to boot; > http://www.spinics.net/lists/linux-rt-users/msg11655.html ... > Eventually, after sorting out another issue he had [possible > mis-patching, KernelStack problem], slavo posted the same reverse-rt > timer code patch that i am using [applies after unified rt patch] that > works; http://pastebin.com/MYLqbmZw ... So this isn't just an AMD > problem [and i am not sure what amd cpus are affected, other than > 'positively' Phenom branded cpus - which are generally fairly decent > on -rt, in my use. likewise i am not sure what other ARM platforms are > affected - maybe someone else can speak up/take a look]. > > * Also, [i have had several users report this to me] NO_HZ_FULL on > 3.14-rt can be problematic / lead to serious instability. [on amd > Phenom anyway]. One person i know was getting lockups just by > connecting Pulseaudio to his USB soundcard, i even had one lockup > [nothing to do with PA]. Switching to periodic timers [old tick] fixed > everything for everyone. the newer no_hz_ code is still a little > dicey on -rt. > > anyway, give it a try, when you get a chance. In my own builds, for > now - i am good to go [as far as performance / stability]. But i > obviously had to; 1). revert the rt timer changes/commits, 2). switch > to preiodic timers ...which was enough for 3.14-rt to work okay, but > 3). Picked up the softirq-resurrect-threads.patch [IIRC, Steven > forward ported mingo's softirq split from 2.6.xx-rt to 3.2-rt or > 3.4-rt], but i grabbed it from Mike Galbraith's post; > http://www.spinics.net/lists/linux-rt-users/msg11204.html ~ I wish > this patch was in linux-rt/upstream. [actually, both]. > > now 3.14-rt is a happy camper ;) > > Jordan > >> Paul. >> -- >> >>> look at those patches again - and i am more than willing to test >>> subsequent revisions to see if we can get these troublesome AMD >>> machines to boot with them applied.. >>> >>> ...regarding nvidia on PREEMPT_RT_FULL / EXPORT_SYMBOL_GPL for >>> __rt_mutex_init - i notified nvidia of the problem [although, it is an >>> upstream linux problem]. Interestingly, this problem has already >>> cropped up during 3.0 development cycle on PREEMPT_RT_FULL - where the >>> __rt_mutex_init was changed to gpl-only symbol - only to be changed >>> back to SYMBOL_EXPORT shortly thereafter.... and yes, i realize >>> 'everybody hates nvidia' - but i have to imagine there might be an MIT >>> licensed out-of-tree module or two [or other gpl-compatible license] >>> that might rely on being able to use __rt_mutex_init and now can't... >>> meaning i doubt this is _just_ an nvidia problem :\ >>> >>> as it stands, one must either change nvidia's licenses to GPL [makeing >>> nvidia non-distibutable]... >>> >>> or change 'kernel/locking/rtmutex.c' ~ >>> EXPORT_SYMBOL_GPL(__rt_mutex_init) to EXPORT_SYMBOL(__rt_mutex_init) >>> >>> ...which obviously makes the kernel GPL-incompatible / non-distributable. >>> >>> I may hit LKML on this issue too, as something needs to happen here - >>> but i thought i would wait and see if i got a response from someone >>> here, first. [being as rt-devs have a little more direct contact with >>> Ingo / subsystem maintainers than i do [ and i am not even subbed to >>> that list]. >>> >>> Jordan >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
