On Fri, 2007-02-16 at 19:38 +0100, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Fri, 2007-02-16 at 19:25 +0100, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>> On Fri, 2007-02-16 at 18:58 +0100, Jan Kiszka wrote: > >>>> Jan Kiszka wrote: > >>>>> ... > >>>>> /me now watching what happens at 10 kHz... > >>>> Bad news are sometimes good news: > >>>> > >>>> # ./main > >>>> # rmmod xeno_native > >>>> # modprobe xeno_native > >>>> # ./main > >>>> > >>>>> [ 629.916921] Xenomai: stopping RTDM services. > >>>>> [ 632.954058] Xenomai: stopping native API services. > >>>>> [ 641.763276] Xenomai: starting native API services. > >>>>> [ 643.849294] BUG: unable to handle kernel paging request at virtual > >>>>> address c484eb58 > >>>>> [ 643.857099] printing eip: > >>>>> [ 643.859835] c013a173 > >>>>> [ 643.862050] *pde = 03fdb067 > >>>>> [ 643.864868] *pte = 00000000 > >>>>> [ 643.867696] Oops: 0000 [#1] > >>>>> [ 643.870517] PREEMPT > >>>>> [ 643.872747] Modules linked in: xeno_native 8139too eepro100 sd_mod > >>>>> scsi_mod > >>>>> [ 643.879873] CPU: 0 > >>>>> [ 643.879884] EIP: 0060:[<c013a173>] Not tainted VLI > >>>>> [ 643.879904] EFLAGS: 00013046 (2.6.19.3 #28) > >>>>> [ 643.891932] EIP is at xnheap_init_mapped+0x144/0x1a8 > >>> I've just found an issue which caused rt_queue_delete() to leave > >>> dandling mmapped segments when attempting to remove a busy queue (i.e. > >>> still bound to another descriptor in user-space). > >>> > >>> Could you resync with v2.3.x (or trunk) head revision and try again? > >>> TIA, > >>> > >> After resync and running main once: > >> > >>> [ 90.782016] Xenomai: stopping native API services. > >>> [ 90.987985] BUG: unable to handle kernel paging request at virtual > >>> address c4813808 > >>> [ 90.996022] printing eip: > >>> [ 90.998921] c01965d9 > >>> [ 91.001290] *pde = 03fd4067 > >>> [ 91.004267] *pte = 00000000 > >>> [ 91.007267] Oops: 0000 [#1] > >>> [ 91.010246] PREEMPT > >>> [ 91.012693] Modules linked in: xeno_native 8139too eepro100 sd_mod > >>> scsi_mod > >>> [ 91.020385] CPU: 0 > >>> [ 91.020430] EIP: 0060:[<c01965d9>] Not tainted VLI > >>> [ 91.020515] EFLAGS: 00010286 (2.6.19.3 #29) > >>> [ 91.032862] EIP is at remove_proc_entry+0x33/0x26a > >>> [ 91.037892] eax: 00000000 ebx: c484c620 ecx: ffffffff edx: > >>> c2c961e0 > >>> [ 91.044944] esi: 00000038 edi: c4813808 ebp: c1351f20 esp: > >>> c1351ef4 > >>> [ 91.051984] ds: 007b es: 007b ss: 0068 > >>> [ 91.056297] Process rmmod (pid: 906, ti=c1350000 task=c3422a70 > >>> task.ti=c1350000) > >>> [ 91.063761] Stack: 00002245 00000282 00000000 00000000 6f6e6578 > >>> c1351f20 c2c961e0 c4813808 > >>> [ 91.073076] c484c620 00000038 00000000 c1351f34 c01458f7 > >>> 00000000 00000000 6f6e6578 > >>> [ 91.082388] c1351f44 c013e20b c48f2e80 00000000 c1351f4c > >>> c0144163 c1351f58 c48e3055 > >>> [ 91.091724] Call Trace: > >>> [ 91.094659] [<c01458f7>] xnregistry_cleanup+0x34/0x10f > >>> [ 91.100310] [<c013e20b>] xnpod_shutdown+0x118/0x167 > >>> [ 91.105710] [<c0144163>] xncore_detach+0x1f/0x21 > >>> [ 91.110816] [<c48e3055>] cleanup_module+0x55/0x57 [xeno_native] > >>> [ 91.117352] [<c0130c53>] sys_delete_module+0x16a/0x193 > >>> [ 91.123008] [<c0102df6>] syscall_call+0x7/0xb > >>> [ 91.127878] [<b7e504c2>] 0xb7e504c2 > >>> [ 91.131770] ======================= > >>> [ 91.135540] Code: 20 e8 04 3c f7 ff 85 d2 89 55 ec 89 45 f0 75 13 8d > >>> 4d f0 8d 55 ec e8 16 ff ff ff 85 c0 0f 85 37 > >>> 02 00 00 8b 7d f0 31 c0 83 c9 ff <f2> ae f7 d1 49 81 3d 00 d2 2e c0 80 ae > >>> 2e c0 89 4d e4 75 07 b0 > >>> [ 91.159520] EIP: [<c01965d9>] remove_proc_entry+0x33/0x26a SS:ESP > >>> 0068:c1351ef4 > >> I'm going to re-check that my build was clean, but I think so. > >> > > > > Ok, it's not impossible that the initial fix caused a regression on the > > registry's /proc unexport code. I'm going to check that on my side too. > > > > Looks more like some unrelated, forgotten-to-rebuild RT module now. > Things run smoothly at the moment, I'm unable to reproduce any of the > earlier issues. >
Ok thanks, so far, no reproducible issue here too, but I will leave the test running for a few hours just in case. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
