>
> It looks to me that something either needs to wake up the idle cpu when
> an rcu callback is scheduled on it (I couldnt figure out how to do
> that), or it should not be scheduled on a completely idle cpu as this
> cpu is already in a quiescent state.
While there are other possibilities, I'm
Maybe RCU_BARRIER is waiting for all RCU callback to complete but one or
more don't exists, since the module was unloaded.
On Fri, Feb 3, 2012 at 11:48 AM, Robert Beckett
wrote:
> Hello,
>
> Does anyone reading this list know much about the rcu subsystem?
>
> I have been debugging a problem with
Hello,
Does anyone reading this list know much about the rcu subsystem?
I have been debugging a problem with unmounting disks. Occasionally when
unmounting an ext4 filesystem, the whole system would freeze.
I traced this to it waiting for completion on an rcu_barrier.
After lots of debugging,
I think I managed to get ram_console working on the working kernel, it
gives this in kmsg:
<6>[1, swapper] [0.256378] ram_console: got buffer at 3a0,
size 4
<6>[1, swapper] [0.256408] ram_console: no valid data in buffer
(sig = 0x20008808)
<6>[1, swapper] [0.256561] console [ra
Good :-)
On Fri, Feb 3, 2012 at 3:23 PM, ajay wrote:
> thanks ! It works now!!
> On Feb 2, 2012 12:33 PM, "Chinmay V S" wrote:
>
>> AFAIK, input_sync() is always called after reporting input_report_xxx()
>> functions.
>> This way input events are flushed i.e reported to the userspace *
>> i
thanks ! It works now!!
On Feb 2, 2012 12:33 PM, "Chinmay V S" wrote:
> AFAIK, input_sync() is always called after reporting input_report_xxx()
> functions.
> This way input events are flushed i.e reported to the userspace *
> immediately* as they occur in the hardware.
> This i have done in
