Sebastian Smolorz wrote: > Jan Kiszka wrote: >> Sebastian Smolorz wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Jan Kiszka wrote: >>>>>>> Sebastian Smolorz wrote: >>>>>>>> Jan Kiszka wrote: >>>>>>>>> Are you tracing into vmalloc'ed memory? >>>>>>>> Yes, without CONFIG_IPIPE_TRACE_VMALLOC the system does not boot. >>>>>>> Hmm, makes me wonder of some laziness of the page mapping or a >>>>>>> missing lock-against-swapping causes this. Could you have a closer >>>>>>> look at the tracer code if we are lacking some magic for the vmalloc >>>>>>> trace buffer (compare to the xnheap code, e.g.)? >>>>>> This is a known issue, the ARM architecture lacks the set_pgdir >>>>>> function, needed in mm/vmalloc.c to workaround the lazy page mapping >>>>>> of vmalloced areas. >>>>> Would vmalloc+memset help to be safe for the remaining system runtime? >>>> Probably not, the vmalloced area is added only to the page table of the >>>> process that calls vmalloc, it is added to other processes table page >>>> only once they use it. >>> Are there any alternatives? Or do we have to live with this restriction? >> Try if smaller CONFIG_IPIPE_TRACE_SHIFT makes it boot without >> CONFIG_IPIPE_TRACE_VMALLOC. > > I already tried that but it didn't help. First with IPIPE_TRACE_SHIFT set to > 10 and after modifying Kconfig.debug with a value of 5. Booting impossible.
What about starting disabled and arming the tracer later via /proc/ipipe/trace/enable? This sounds like it's not a size issue (TRACE_SHIFT=5 is ridiculous small), rather some memory section is accessed too early. If it works we could postpone enabling to __ipipe_init_tracer by default (like it is done for TRACE_VMALLOC). I cannot imagine use cases for the tracer ATM that would benefit from early tracing. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
