On Tue, Jan 15, 2013 at 4:34 PM, David Daney wrote:
> On 01/15/2013 01:07 PM, Steven Rostedt wrote:
>>
>> On Tue, 2013-01-15 at 09:55 -0800, David Daney wrote:
>>
There's nothing that states what the ftrace caller must be. We can have
it do a proper stack update. That is, only at boot up
On 01/15/2013 01:07 PM, Steven Rostedt wrote:
On Tue, 2013-01-15 at 09:55 -0800, David Daney wrote:
There's nothing that states what the ftrace caller must be. We can have
it do a proper stack update. That is, only at boot up do we need to
handle the defined mcount. After that, those instructio
On Tue, 2013-01-15 at 12:53 -0500, Alan Cooper wrote:
> On Mon, Jan 14, 2013 at 10:40 PM, Steven Rostedt wrote:
> > On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote:
> >>
> >> I thought all CPUs were in stop_machine() when the modifications
> >> were done, so that there is no issue with
On Tue, 2013-01-15 at 09:55 -0800, David Daney wrote:
> > There's nothing that states what the ftrace caller must be. We can have
> > it do a proper stack update. That is, only at boot up do we need to
> > handle the defined mcount. After that, those instructions are just place
> > holders for our
On 01/14/2013 07:40 PM, Steven Rostedt wrote:
On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote:
I thought all CPUs were in stop_machine() when the modifications
were done, so that there is no issue with multi-word instruction
patching.
Am I wrong about this?
So really I think you c
On Mon, Jan 14, 2013 at 10:40 PM, Steven Rostedt wrote:
> On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote:
>>
>> I thought all CPUs were in stop_machine() when the modifications
>> were done, so that there is no issue with multi-word instruction
>> patching.
>>
>> Am I wrong about this
On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote:
>
> I thought all CPUs were in stop_machine() when the modifications
> were done, so that there is no issue with multi-word instruction
> patching.
>
> Am I wrong about this?
>
> So really I think you can do two NOP just as easily.
Th
On 01/14/2013 04:13 PM, Alan Cooper wrote:
On Mon, Jan 14, 2013 at 5:12 PM, David Daney wrote:
On 01/14/2013 01:10 PM, Alan Cooper wrote:
I already tried using "adddiu sp, sp, 8" and it caused the kernel to
randomly crash. After many hours of debugging the reason occurred to
me while in bed i
On Mon, Jan 14, 2013 at 5:12 PM, David Daney wrote:
> On 01/14/2013 01:10 PM, Alan Cooper wrote:
>>
>> I already tried using "adddiu sp, sp, 8" and it caused the kernel to
>> randomly crash. After many hours of debugging the reason occurred to
>> me while in bed in the middle of the night. The pro
On 01/14/2013 01:10 PM, Alan Cooper wrote:
I already tried using "adddiu sp, sp, 8" and it caused the kernel to
randomly crash. After many hours of debugging the reason occurred to
me while in bed in the middle of the night. The problem is that if we
get an interrupt between the add 8 and the add
I already tried using "adddiu sp, sp, 8" and it caused the kernel to
randomly crash. After many hours of debugging the reason occurred to
me while in bed in the middle of the night. The problem is that if we
get an interrupt between the add 8 and the add -8 instructions, we
trash the existing stack
On 01/11/2013 06:33 AM, Al Cooper wrote:
Function tracing is currently broken for all 32 bit MIPS platforms.
When tracing is enabled, the kernel immediately hangs on boot.
This is a result of commit b732d439cb43336cd6d7e804ecb2c81193ef63b0
that changes the kernel/trace/Kconfig file so that is no
12 matches
Mail list logo
