Hi, Small update: there's an mail-thread on Linux-Audio-User of somebody who seems to have a similar issue as this. The thread in question: http://linux-audio.4202.n7.nabble.com/Problems-with-real-time-kernel-thermal-throttling-and-cpu-freq-governors-td93209.html Note that the CPU the OP of that thread has is an i7, and they're using an older -rt kernel (3.14-2-rt-amd64). On a vanilla 3.14-2-amd64 all is reported to be fine (see forum post mentioned in first mail by OP, link: http://forums.debian.net/viewtopic.php?f=5&t=117613&p=554270#p554270 ) The OP of that thread mentions that the machine hangs, forcing a hard-reboot. I've been experiencing that too, but had not concidered that the issues might be one-and-the-same. What is the next step I can take to help this issue along? Cheers, -Harry On Fri, Sep 5, 2014 at 11:47 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Fri, 5 Sep 2014, Viresh Kumar wrote: > >> On 5 September 2014 17:36, Harry van Haaren <harryhaaren@xxxxxxxxx> wrote: >> > The down_read_trylock() fails, the other checks are fine. >> >> So my initial guess was correct :) >> >> > If i'm understanding correctly, the cpufreq_rwsem locks the module >> > from being unloaded during critical sections while writing to CPU >> > speed etc? >> >> Its not about changing speed, but its more of a lock for critical sections >> only.. So, yes its required.. >> >> > Would that mean that an un-matched pair of down_read() up_write() >> > could cause the failure of changing CPU speed? >> >> Probably yes, but why doesn't that happen without rt? > > I think Carsten had looked into this. > -- www.openavproductions.com -- 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
