Hello.
Jason Wessel wrote:
>>> If not can you provide me with a test case to see the problem?
>> Well, for example, with 2.6.18-rt7 kernel, stepping into
>> smp_processor_id() was blowing away U-Boot (!) on my PPC board (even
>> in PREEMPT_DESKTOP mode)... On x86, stepping past preempt_disable()
>> caused reboots.
> Sergei,
> Now that sounds more interesting. Perhaps you can elaborate on the
> configuration further, or provide the results of a test. I wonder if I
It was happening in PREEMPT_DESKTOP mode when stepping into
slab_irq_save() -- which contains cpu_processor_id() in this mode.
> have the same board I can try that test on? In theory it should already
> be fixed, after merging the code. On ppc boards I have seen this happen
> with evlog before where it can scramble the boot loader.
Looks like it's been fixed indeed. But still the session stalls in RT mode
-- here the macro looks different...
> For the x86 problem, which part of the kernel should I step through to
> try out the preempt_disable()? Are you using a low level single step,
> a source step in, step over, or finish frame? Certainly you cannot step
> through all parts of the kernel, but it would be good to understand
> where you cannot and why it would work by turning off DEBUG_PREEMPT.
This also seems to work now.
Thanks for unravelling this mystery (which we were too lazy to do :-).
> Jason.
WBR, Sergei
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
