From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45D5FA33.3030503@domain.hid> Date: Fri, 16 Feb 2007 19:38:43 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-help] fata: removing non-linked element... References: <45CC651C.6060402@domain.hid> <45CC68F3.1000003@domain.hid> <45D1C033.9010002@domain.hid> <45D1C61B.7030503@domain.hid> <1171376742.885.3.camel@domain.hid> <45D1CAFA.6050408@domain.hid> <1171385716.885.17.camel@domain.hid> <45D200C3.1030001@domain.hid> <1171393088.885.37.camel@domain.hid> <45D59F98.8020006@domain.hid> <45D5E493.4080405@domain.hid> <45D5F0AD.9010404@domain.hid> <1171649724.10479.12.camel@domain.hid> <45D5F71F.60509@domain.hid> <1171650868.10479.21.camel@domain.hid> In-Reply-To: <1171650868.10479.21.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig57AB6B6383FA3FE255DBDA97" Sender: jan.kiszka@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig57AB6B6383FA3FE255DBDA97 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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 virtu= al address c484eb58 >>>>> [ 643.857099] printing eip: >>>>> [ 643.859835] c013a173 >>>>> [ 643.862050] *pde =3D 03fdb067 >>>>> [ 643.864868] *pte =3D 00000000 >>>>> [ 643.867696] Oops: 0000 [#1] >>>>> [ 643.870517] PREEMPT >>>>> [ 643.872747] Modules linked in: xeno_native 8139too eepro100 sd_m= od scsi_mod >>>>> [ 643.879873] CPU: 0 >>>>> [ 643.879884] EIP: 0060:[] 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= =2E >>> 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 =3D 03fd4067 >>> [ 91.004267] *pte =3D 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:[] 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: c= 2c961e0 >>> [ 91.044944] esi: 00000038 edi: c4813808 ebp: c1351f20 esp: c= 1351ef4 >>> [ 91.051984] ds: 007b es: 007b ss: 0068 >>> [ 91.056297] Process rmmod (pid: 906, ti=3Dc1350000 task=3Dc3422a70= task.ti=3Dc1350000) >>> [ 91.063761] Stack: 00002245 00000282 00000000 00000000 6f6e6578 c1= 351f20 c2c961e0 c4813808 >>> [ 91.073076] c484c620 00000038 00000000 c1351f34 c01458f7 00= 000000 00000000 6f6e6578 >>> [ 91.082388] c1351f44 c013e20b c48f2e80 00000000 c1351f4c c0= 144163 c1351f58 c48e3055 >>> [ 91.091724] Call Trace: >>> [ 91.094659] [] xnregistry_cleanup+0x34/0x10f >>> [ 91.100310] [] xnpod_shutdown+0x118/0x167 >>> [ 91.105710] [] xncore_detach+0x1f/0x21 >>> [ 91.110816] [] cleanup_module+0x55/0x57 [xeno_native] >>> [ 91.117352] [] sys_delete_module+0x16a/0x193 >>> [ 91.123008] [] syscall_call+0x7/0xb >>> [ 91.127878] [] 0xb7e504c2 >>> [ 91.131770] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> [ 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 ae f7 d1 49 81 3d 00 d2 2e c0 8= 0 ae 2e c0 89 4d e4 75 07 b0 >>> [ 91.159520] EIP: [] remove_proc_entry+0x33/0x26a SS:ESP = 0068:c1351ef4 >> I'm going to re-check that my build was clean, but I think so. >> >=20 > 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.= >=20 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. --------------enig57AB6B6383FA3FE255DBDA97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1fozniDOoMHTA+kRAnPtAJ4kNqqdyzmkqH6ox6pmlMyac6PHAgCfWk0T 3dqG/PLlKOV3I9PwHjPIMVs= =27pf -----END PGP SIGNATURE----- --------------enig57AB6B6383FA3FE255DBDA97--