Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >> >>> Jan Kiszka wrote: >>> >>>> Jan Kiszka wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> this is the preliminary, though already usable result of my recent >>>>> effort to extend the tool situation for Xenomai: A kgdb patch >>>>> series for >>>>> 2.6.15 on x86. It already works quite well but likely does not yet >>>>> catch >>>>> all fatal scenarios (e.g. page faults in the Xenomai domain). >>>>> >>>> >>>> >>>> And here comes another revision (prepare patch remains unmodified). >>>> >>>> It gets closer to what Philippe also just suggested in the original >>>> thread: hook KGDB into I-pipe in favour of registering a dedicated >>>> domain. The latter approach modifies the I-pipe state in a way which >>>> may >>>> blur the picture of I-pipe itself to the debugger. This revision hooks >>>> exception events into the I-pipe core so that they are delivered the >>>> normal way when the root domain is active, but get catched early for >>>> higher domains like Xenomai. I'm just not sure about the best way to >>>> handle the serial line IRQ. Philippe, do you see problems with current >>>> approach? Should we better hook into __ipipe_handle_irq (which would >>>> make things more complicated, I'm afraid)? >>>> >>> >>> The current approach works fine unless a runaway thread goes wild with >>> interrupts disabled (i.e. stall bit set) in the root stage or in any >>> higher priority domain regardless of the root domain state, in which >>> case the serial IRQ won't make it through the pipeline to KGDB. >> >> >> But catching this would mean to change the behaviour of ipipe regarding >> the highest priority domain from hard to soft masking of IRQs. Hmm, >> should be made at least optional to catch scenarios where this change >> makes bugs move (away...). >> >> Would be the easiest way to achieve this to register a dummy domain >> ahead of Xenomai (i.e. with higher prio)? > > This would be the theoretically "normal" way to do this, but this comes > with the undesirable side-effect of losing the hw masking of interrupts > for the Xenomai domain, since you stack another domain on top. > > Additionally, we would have to >> modify the IRQ pipeline in a way that, e.g., some flag makes an IRQ not >> only sticky but also "non-maskable" (I would make this also an option to >> avoid overhead for non-debugging scenarios). >> > > By non-maskable, you mean at PIC-level?
Nope, at software-level. I mean that such IRQs would always be passed down the pipeline, even through stalled domains. > >> Well, not yet an essential feature for me, because we still have the NMI >> watchdog and the option to spread breakpoints. But we should keep it in >> mind. >> >> >>>> In contrast to the first version, exceptions happening in the Xenomai >>>> domain now also get reported to KGDB. Debugging mostly works fine, I'm >>>> just facing unknown problems with intercepting and then continuing >>>> kernel-only RT threads. KGDB sometimes reports "E22" back in this case, >>>> but always locks up. Maybe it gets confused by the fact the there is no >>>> Linux task behind Xenomai kernel threads? I tested this by putting a >>>> breakpoint into xnpod_suspend_thread and running latency in mode 0 and >>>> 1. 0 works fine, 1 not. >>>> >>> >>> KGDB is relying on "current", so it's reading garbage over Xenomai's >>> kernel threads. >>> >> >> >> Attached is an improved version of the kgdb-ipipe.patch that copes with >> this situation by mapping invalid currents to init_task. Kernel threads >> are nicely debuggable now. =8) >> > > Ok, queued. > As an add-on patch like the tracer? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
