From: Pravin <shi...@gm...> - 2007-03-14 06:49:39
|
Hi all, I am facing some problems in running UML in kernel-2.6.18 with CKRM patch. I also tried to run UML kernel without CKRM patch, but I get same problem. I have kernel-2.6.19 and kernel-2.6.20 running in UML mode but CKRM wont work with them. So, I need to run uml in kernel-2.6.18. I am able to compile this kernel in UML architecture. But problem comes when I execute it. Nothing is getting printed, and nothing is happening, not even error message is coming. It just waits there, and comes out after pressing "CTRL+C". When I run it using gdb, I got following error (gdb) b start_kernel Breakpoint 1 at 0x8049404: file init/main.c, line 461. (gdb) r Starting program: /home/pravin/projects/selinux/ckrm/plain_kernel/linux-2.6.18/linux Failed to read a valid object file image from memory. These problems also comes up with kernel 2.6.18 without CKRM patch. Is UML is not working properly with kernel 2.6.18 ? Can I know what is the problem and how to solve it. Thank you. -- Pravin Shinde |
From: Jeff D. <jd...@ad...> - 2007-03-16 02:39:52
|
On Wed, Mar 14, 2007 at 12:19:36PM +0530, Pravin wrote: > So, I need to run uml in kernel-2.6.18. Or you could bug the CKRM people to get up to speed. If something breaks in 2.6.18, but is fixed in current UML, I'm not going to be too excited about it. I'll tell you the fix if I recognize the problem, but in this case, I don't. > (gdb) r > Starting program: > /home/pravin/projects/selinux/ckrm/plain_kernel/linux-2.6.18/linux > Failed to read a valid object file image from memory. This is just bizarre. I would suspect something's up with gdb here. Jeff -- Work email - jdike at linux dot intel dot com |
From: Blaisorblade <bla...@ya...> - 2007-03-25 17:28:08
|
On mercoled=EC 14 marzo 2007, Pravin wrote: > Hi all, > I am facing some problems in running UML in kernel-2.6.18 with CKRM patch. > I also tried to run UML kernel without CKRM patch, but I get same problem. > I have kernel-2.6.19 and kernel-2.6.20 running in UML mode but CKRM > wont work with them. > > So, I need to run uml in kernel-2.6.18. Hmm, I published a 2.6.18 -bs patchset time ago with some bugfixes, and som= e=20 other were merged into -stable, so you may want to try these. CKRM will sti= ll=20 work with them (98 % sure). Also, with git you could look at the change history between 2.6.18 and 2.6.= 19,=20 even if that can be time-consuming. But I've given such a look and I found= =20 nothing of interest. Have you double-checked your compile-time options? > I am able to compile this kernel in UML architecture. But problem > comes when I execute it. > Nothing is getting printed, and nothing is happening, not even error > message is coming. > It just waits there, and comes out after pressing "CTRL+C". Looked at what's happening with strace? Tried starting UML and attaching to= it=20 with gdb (gdb works better this way, many times)? > When I run it using gdb, > I got following error > (gdb) b start_kernel > Breakpoint 1 at 0x8049404: file init/main.c, line 461. > (gdb) r > Starting program: > /home/pravin/projects/selinux/ckrm/plain_kernel/linux-2.6.18/linux > Failed to read a valid object file image from memory. > > These problems also comes up with kernel 2.6.18 without CKRM patch. > Is UML is not working properly with kernel 2.6.18 ? > Can I know what is the problem and how to solve it. > > Thank you. =2D-=20 Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade |
From: Pravin <shi...@gm...> - 2007-03-27 12:32:14
|
PiBIbW0sIEkgcHVibGlzaGVkIGEgMi42LjE4IC1icyBwYXRjaHNldCB0aW1lIGFnbyB3aXRoIHNv bWUgYnVnZml4ZXMsIGFuZCBzb21lCj4gb3RoZXIgd2VyZSBtZXJnZWQgaW50byAtc3RhYmxlLCBz byB5b3UgbWF5IHdhbnQgdG8gdHJ5IHRoZXNlLiBDS1JNIHdpbGwgc3RpbGwKPiB3b3JrIHdpdGgg dGhlbSAoOTggJSBzdXJlKS4KCkkgdHJpZWQgYm90aCBvZiB0aGUgZm9sbG93aW5nIHBhdGNoZXMg b24gdmFuaWxsYSAyLjYuMTgga2VybmVsLgooV2l0aG91dCBDS1JNIHBhdGNoKQpodHRwOi8vd3d3 LnVzZXItbW9kZS1saW51eC5vcmcvfmJsYWlzb3JibGFkZS9wYXRjaGVzL2d1ZXN0L3VtbC0yLjYu MTguMS1iYjIvdW1sLTIuNi4xOC4xLWJiMi5wYXRjaC5iejIKYW5kCmh0dHA6Ly93d3cudXNlci1t b2RlLWxpbnV4Lm9yZy9+YmxhaXNvcmJsYWRlL3BhdGNoZXMvZ3Vlc3QvdW1sLTIuNi4xOC1iYjEv dW1sLTIuNi4xOC1iYjEucGF0Y2guYnoyCgpCdXQgc3RpbGwgaXQgVU1MIGRpZG50IHdvcmtlZC4K SSB1c2VkIEdEQiB0byBsb2NhdGUgdGhlIHBvaW50IHdoZXJlIGl0IGlzIGZhaWxpbmcsIHNvIGkg Z290IGZvbGxvd2luZy4Ke3t7CihnZGIpIGJ0CiMwICBfX2NvbnN0X3VkZWxheSAodXNlY3M9NDI5 NTAwMCkgYXQgYXJjaC91bS9zeXMtaTM4Ni9kZWxheS5jOjM2CiMxICAweDA4MDZjODc4IGluIHBh bmljIChmbXQ9MHg4MDRlNzljICJcMjAz77+9XDAyNGg777+9XDAzNVxi77+977+9XDIyNiIpIGF0 Cmtlcm5lbC9wYW5pYy5jOjEzNwojMiAgMHgwODA0ZTc5YyBpbiBjaGVja19wdHJhY2UgKCkKIzMg IDB4MDgwNjM4NGIgaW4gb3NfZWFybHlfY2hlY2tzICgpIGF0IGluY2x1ZGUvbGludXgvdGltZXIu aDo0MQojNCAgMHgwODA1YzFjMyBpbiBsaW51eF9tYWluIChhcmdjPTEsIGFyZ3Y9MHhhZmRjM2Uy NCkgYXQKYXJjaC91bS9rZXJuZWwvdW1fYXJjaC5jOjM1MgojNSAgMHgwODA2MWZiMiBpbiBtYWlu ICgpIGF0IGluY2x1ZGUvbGludXgvdGltZXIuaDo0MQooZ2RiKQp9fX0KClNvLCB3aGF0IEkgY29u Y2x1ZGVkIGZyb20gdGhpcyB0aGF0LCBwYW5pYyBpcyBnZXR0aW5nIGNhbGxlZCBmcm9tCiJjaGVj a19wdHJhY2UiIGZ1bmN0aW9uLgoKVG8gZmluZCBvdXQgd2h5IGV4YWN0bHkgcGFuaWMgaXMgZ2V0 dGluZyBjYWxsZWQsIEkgYWRkZWQgZmV3IHByaW50ZgpzdGF0ZW1lbnRzIGluICJjaGVja19wdHJh Y2UiIGZ1bmN0aW9uIGluCiJhcmNoL3VtL29zLUxpbnV4L3N0YXJ0X3VwLmMiLgpJIG1hbmFnZWQg dG8gZmluZCBvdXQgdGhhdCBwYW5pYyBpcyBnZXR0aW5nIGNhbGxlZCBmcm9tCnt7ewppZighV0lG U1RPUFBFRChzdGF0dXMpIHx8IChXU1RPUFNJRyhzdGF0dXMpICE9IChTSUdUUkFQfDB4ODApKSkK ICAgICAgICAgICAgICAgICAgIHBhbmljKCJjaGVja19wdHJhY2UgOiBleHBlY3RlZCAoU0lHVFJB UHwweDgwKSwgIgogICAgICAgICAgICAgICAgICAgICJnb3Qgc3RhdHVzID0gJWQiLCBzdGF0dXMp Owp9fX0KSXQgd2FzIG5vdCBjYWxsaW5nIHBhbmljIGluIGZpcnN0IGl0ZXJhdGlvbiBidXQgaXQg d2FzIGNhbGxpbmcgaW4Kc2Vjb25kIGl0ZXJhdGlvbiBpbnNpZGUgd2hpbGUgbG9vcCwgd2l0aCBw YW5pYyBzdGF0ZW1lbnQgYXMKe3t7CmNoZWNrX3B0cmFjZSA6IGV4cGVjdGVkIChTSUdUUkFQfDB4 ODApLCBnb3Qgc3RhdHVzID0gMjU2Cn19fQpBdCBmaXJzdCBpdGVyYXRpb24sIHRoZSB2YWx1ZSBv ZiBzdGF0dXMgd2FzICIzNDE3NSIuCgpJIHN1cHBvc2UgdGhhdCBpdCBzaG91bGQgaGF2ZSBwYXNz ZWQgdGhlIGNvbmRpdGlvbiBpbiBmb2xsb3dpbmcgImlmCnN0YXRlbWVudCIgYW5kIHNob3VsZCBo YXZlIHRha2VuIGEgYnJlYWsgaW4gZmlyc3QgaXRlcmF0aW9uIG9ubHkuCi8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vCnN5c2NhbGwgPSBwdHJhY2UoUFRSQUNFX1BFRUtVU1IsIHBpZCwgUFRfU1lTQ0FMTF9O Ul9PRkZTRVQsMCk7CmlmKHN5c2NhbGwgPT0gX19OUl9nZXRwaWQpewogICAgICAgICAgICAgbiA9 IHB0cmFjZShQVFJBQ0VfUE9LRVVTUiwgcGlkLCBQVF9TWVNDQUxMX05SX09GRlNFVCwKX19OUl9n ZXRwcGlkKTsKICAgICAgICAgICAgaWYobiA8IDApCiAgICAgICAgICAgICAgICAgICAgICBwYW5p YygiY2hlY2tfcHRyYWNlIDogZmFpbGVkIHRvIG1vZGlmeSBzeXN0ZW0gIgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAiY2FsbCwgZXJybm8gPSAlZCIsIGVycm5vKTsKICAgICAgICAg ICBicmVhayA7Cn0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8KQnV0IHRoZSB2YWx1ZSBvZiBzeXNjYWxs IGluIGZpcnN0IGl0ZXJhdGlvbiB3YXMgMjUyIGJ1dCBpdCB3YXMKZXhwZWN0ZWQgdG8gYmUgMjAg KGkuZS4gIF9fTlJfZ2V0cGlkICkuClZhbHVlIDI1MiByZXByZXNlbnRlZCAiX19OUl9leGl0X2dy b3VwIgoKSSBhbSBub3QgYWJsZSB0byBwcm9jZWVkIGZ1cnRoZXIgZnJvbSB0aGlzIHBvaW50IGlu IGRlYnVnZ2luZyB0aGlzIHByb2JsZW0uCgo+IG5vdGhpbmcgb2YgaW50ZXJlc3QuIEhhdmUgeW91 IGRvdWJsZS1jaGVja2VkIHlvdXIgY29tcGlsZS10aW1lIG9wdGlvbnM/Cj4KPgo+IExvb2tlZCBh dCB3aGF0J3MgaGFwcGVuaW5nIHdpdGggc3RyYWNlPwpvbiB1c2luZyBzdHJhY2Ugb24gdW1sIGkg Z290IGZvbGxvd2luZy4gQnV0IEkgYW0gbm90IGFibGUgdG8gbWFrZSBhbnkKc2Vuc2Ugb3V0IG9m IGl0IDotKAp7e3sKcHJhdmluQG1pY3JvY29zbTp+L3Byb2plY3RzL3NlbGludXgvY2tybS9saW51 eC0yLjYuMTgkIHN0cmFjZSAtZiAuL2xpbnV4CmV4ZWN2ZSgiLi9saW51eCIsIFsiLi9saW51eCJd LCBbLyogMzEgdmFycyAqL10pID0gMAp1bmFtZSh7c3lzPSJMaW51eCIsIG5vZGU9Im1pY3JvY29z bSIsIC4uLn0pID0gMApicmsoMCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAw eDgyNzUwMDAKYWNjZXNzKCIvZXRjL2xkLnNvLm5vaHdjYXAiLCBGX09LKSAgICAgID0gLTEgRU5P RU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQptbWFwMihOVUxMLCA4MTkyLCBQUk9UX1JF QUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsCjApID0gMHhhN2Vm ZTAwMAphY2Nlc3MoIi9ldGMvbGQuc28ucHJlbG9hZCIsIFJfT0spICAgICAgPSAtMSBFTk9FTlQg KE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW4oIi9saWIvdGxzL2k2ODYvc3NlMi9jbW92 L2xpYnV0aWwuc28uMSIsIE9fUkRPTkxZKSA9IC0xIEVOT0VOVCAoTm8Kc3VjaCBmaWxlIG9yIGRp cmVjdG9yeSkKc3RhdDY0KCIvbGliL3Rscy9pNjg2L3NzZTIvY21vdiIsIDB4YWZkMGQ1NDgpID0g LTEgRU5PRU5UIChObyBzdWNoCmZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuKCIvbGliL3Rscy9pNjg2 L3NzZTIvbGlidXRpbC5zby4xIiwgT19SRE9OTFkpID0gLTEgRU5PRU5UIChObyBzdWNoCmZpbGUg b3IgZGlyZWN0b3J5KQpzdGF0NjQoIi9saWIvdGxzL2k2ODYvc3NlMiIsIDB4YWZkMGQ1NDgpID0g LTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuKCIvbGliL3Rscy9pNjg2 L2Ntb3YvbGlidXRpbC5zby4xIiwgT19SRE9OTFkpID0gMwpyZWFkKDMsICJcMTc3RUxGXDFcMVwx XDBcMFwwXDBcMFwwXDBcMFwwXDNcMFwzXDBcMVwwXDBcMFwyNjBcZlwwIi4uLiwgNTEyKSA9IDUx Mgpmc3RhdDY0KDMsIHtzdF9tb2RlPVNfSUZSRUd8MDY0NCwgc3Rfc2l6ZT05NjU2LCAuLi59KSA9 IDAKbW1hcDIoTlVMTCwgMTI0MzIsIFBST1RfUkVBRHxQUk9UX0VYRUMsIE1BUF9QUklWQVRFfE1B UF9ERU5ZV1JJVEUsIDMsCjApID0gMHhhN2VmYTAwMAptbWFwMigweGE3ZWZjMDAwLCA4MTkyLCBQ Uk9UX1JFQUR8UFJPVF9XUklURSwKTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJVEUs IDMsIDB4MSkgPSAweGE3ZWZjMDAwCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA9IDAKb3BlbigiL2xpYi90bHMvaTY4Ni9jbW92L2xpYmMuc28uNiIsIE9fUkRPTkxZKSA9 IDMKcmVhZCgzLCAiXDE3N0VMRlwxXDFcMVwwXDBcMFwwXDBcMFwwXDBcMFwzXDBcM1wwXDFcMFww XDBcMjQwT1wxIi4uLiwgNTEyKSA9IDUxMgpmc3RhdDY0KDMsIHtzdF9tb2RlPVNfSUZSRUd8MDY0 NCwgc3Rfc2l6ZT0xMjQxNTgwLCAuLi59KSA9IDAKbW1hcDIoTlVMTCwgMTI0NzM4OCwgUFJPVF9S RUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8TUFQX0RFTllXUklURSwKMywgMCkgPSAweGE3ZGM5 MDAwCm1tYXAyKDB4YTdlZjAwMDAsIDI4NjcyLCBQUk9UX1JFQUR8UFJPVF9XUklURSwKTUFQX1BS SVZBVEV8TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJVEUsIDMsIDB4MTI3KSA9IDB4YTdlZjAwMDAKbW1h cDIoMHhhN2VmNzAwMCwgMTAzOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxN QVBfRklYRUR8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHhhN2VmNzAwMApjbG9zZSgzKSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwCm1tYXAyKE5VTEwsIDQwOTYsIFBST1RfUkVB RHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwKMCkgPSAweGE3ZGM4 MDAwCm1tYXAyKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxN QVBfQU5PTllNT1VTLCAtMSwKMCkgPSAweGE3ZGM3MDAwCm1wcm90ZWN0KDB4YTdlZjAwMDAsIDIw NDgwLCBQUk9UX1JFQUQpICA9IDAKc2V0X3RocmVhZF9hcmVhKHtlbnRyeV9udW1iZXI6LTEgLT4g NiwgYmFzZV9hZGRyOjB4YTdkYzc2YzAsCmxpbWl0OjEwNDg1NzUsIHNlZ18zMmJpdDoxLCBjb250 ZW50czowLCByZWFkX2V4ZWNfb25seTowLApsaW1pdF9pbl9wYWdlczoxLCBzZWdfbm90X3ByZXNl bnQ6MCwgdXNlYWJsZToxfSkgPSAwCmdldHJsaW1pdChSTElNSVRfU1RBQ0ssIHtybGltX2N1cj04 MTkyKjEwMjQsIHJsaW1fbWF4PVJMSU1fSU5GSU5JVFl9KSA9IDAKYnJrKDApICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID0gMHg4Mjc1MDAwCmJyaygweDgyOTYwMDApICAgICAgICAg ICAgICAgICAgICAgICAgICA9IDB4ODI5NjAwMApydF9zaWdhY3Rpb24oU0lHSU5ULCB7MHg4MDYz NjRjLCBbXSwgU0FfTk9NQVNLfFNBX09ORVNIT1R9LCBOVUxMLCA4KSA9IDAKcnRfc2lncHJvY21h c2soU0lHX1VOQkxPQ0ssIFtJTlRdLCBOVUxMLCA4KSA9IDAKcnRfc2lnYWN0aW9uKFNJR1RFUk0s IHsweDgwNjM2NGMsIFtdLCBTQV9OT01BU0t8U0FfT05FU0hPVH0sIE5VTEwsIDgpID0gMApydF9z aWdwcm9jbWFzayhTSUdfVU5CTE9DSywgW1RFUk1dLCBOVUxMLCA4KSA9IDAKcnRfc2lnYWN0aW9u KFNJR0hVUCwgezB4ODA2MzY0YywgW10sIFNBX05PTUFTS3xTQV9PTkVTSE9UfSwgTlVMTCwgOCkg PSAwCnJ0X3NpZ3Byb2NtYXNrKFNJR19VTkJMT0NLLCBbSFVQXSwgTlVMTCwgOCkgPSAwCmZzdGF0 NjQoMSwge3N0X21vZGU9U19JRkNIUnwwNjIwLCBzdF9yZGV2PW1ha2VkZXYoMTM2LCAxKSwgLi4u fSkgPSAwCm1tYXAyKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFU RXxNQVBfQU5PTllNT1VTLCAtMSwKMCkgPSAweGE3ZGM2MDAwCm1tYXAyKE5VTEwsIDQwOTYsIFBS T1RfUkVBRHxQUk9UX1dSSVRFfFBST1RfRVhFQywKTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywg LTEsIDApID0gMHhhN2RjNTAwMApjbG9uZShQcm9jZXNzIDE4MjQ3IGF0dGFjaGVkCmNoaWxkX3N0 YWNrPTB4YTdkYzVmZDQsIGZsYWdzPXxTSUdDSExEKSA9IDE4MjQ3CltwaWQgMTgyNDZdIHdhaXRw aWQoMTgyNDcsIFByb2Nlc3MgMTgyNDYgc3VzcGVuZGVkCiA8dW5maW5pc2hlZCAuLi4+CltwaWQg MTgyNDddIGdldHBpZCgpICAgICAgICAgICAgICAgICAgICA9IDE4MjQ3CltwaWQgMTgyNDddIGdl dHBwaWQoKSAgICAgICAgICAgICAgICAgICA9IDE4MjQ2CltwaWQgMTgyNDddIHJ0X3NpZ3Byb2Nt YXNrKFNJR19CTE9DSywgW1dJTkNIXSwgW10sIDgpID0gMApbcGlkIDE4MjQ3XSBwdHJhY2UoUFRS QUNFX1RSQUNFTUUsIDAsIDAsIDApID0gLTEgRVBFUk0gKE9wZXJhdGlvbiBub3QgcGVybWl0dGVk KQpbcGlkIDE4MjQ3XSBkdXAoMikgICAgICAgICAgICAgICAgICAgICAgPSAzCltwaWQgMTgyNDdd IGZjbnRsNjQoMywgRl9HRVRGTCkgICAgICAgICA9IDB4MiAoZmxhZ3MgT19SRFdSKQpbcGlkIDE4 MjQ3XSBmc3RhdDY0KDMsIHtzdF9tb2RlPVNfSUZDSFJ8MDYyMCwgc3RfcmRldj1tYWtlZGV2KDEz NiwgMSksIC4uLn0pID0gMApbcGlkIDE4MjQ3XSBtbWFwMihOVUxMLCA0MDk2LCBQUk9UX1JFQUR8 UFJPVF9XUklURSwKTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHhhN2RjNDAw MApbcGlkIDE4MjQ3XSBfbGxzZWVrKDMsIDAsIDB4YTdkYzVhNTAsIFNFRUtfQ1VSKSA9IC0xIEVT UElQRSAoSWxsZWdhbCBzZWVrKQpbcGlkIDE4MjQ3XSB3cml0ZSgzLCAicHRyYWNlOiBPcGVyYXRp b24gbm90IHBlcm1pdHRlZFxuIiwgMzJwdHJhY2U6Ck9wZXJhdGlvbiBub3QgcGVybWl0dGVkCikg PSAzMgpbcGlkIDE4MjQ3XSBjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgPSAwCltwaWQgMTgy NDddIG11bm1hcCgweGE3ZGM0MDAwLCA0MDk2KSAgICA9IDAKW3BpZCAxODI0N10ga2lsbCgxODI0 NywgU0lHS0lMTCkgICAgICAgID0gMApbcGlkIDE4MjQ3XSArKysga2lsbGVkIGJ5IFNJR0tJTEwg KysrClByb2Nlc3MgMTgyNDYgcmVzdW1lZApQcm9jZXNzIDE4MjQ3IGRldGFjaGVkCjwuLi4gd2Fp dHBpZCByZXN1bWVkPiBbe1dJRlNJR05BTEVEKHMpICYmIFdURVJNU0lHKHMpID09IFNJR0tJTEx9 XSwKV1NUT1BQRUQpID0gMTgyNDcKLS0tIFNJR0NITEQgKENoaWxkIGV4aXRlZCkgQCAwICgwKSAt LS0KfX19CgpUaGFueAotLSAKIFByYXZpbiBTaGluZGUK |
From: Blaisorblade <bla...@ya...> - 2007-03-27 17:43:25
|
On marted=C3=AC 27 marzo 2007, Pravin wrote: > > Hmm, I published a 2.6.18 -bs patchset time ago with some bugfixes, and > > some other were merged into -stable, so you may want to try these. CKRM > > will still work with them (98 % sure). > I tried both of the following patches on vanilla 2.6.18 kernel. > (Without CKRM patch) > http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-b= b2 >/uml-2.6.18.1-bb2.patch.bz2 and > http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18-bb1= /u >ml-2.6.18-bb1.patch.bz2 > But still it UML didnt worked. > I used GDB to locate the point where it is failing, so i got following. > {{{ > (gdb) bt > #0 __const_udelay (usecs=3D4295000) at arch/um/sys-i386/delay.c:36 > #1 0x0806c878 in panic (fmt=3D0x804e79c "\203=EF=BF=BD\024h;=EF=BF=BD\03= 5\b=EF=BF=BD=EF=BF=BD\226") at > kernel/panic.c:137 > #2 0x0804e79c in check_ptrace () > #3 0x0806384b in os_early_checks () at include/linux/timer.h:41 > #4 0x0805c1c3 in linux_main (argc=3D1, argv=3D0xafdc3e24) at > arch/um/kernel/um_arch.c:352 > #5 0x08061fb2 in main () at include/linux/timer.h:41 > (gdb) > }}} > > So, what I concluded from this that, panic is getting called from > "check_ptrace" function. > > To find out why exactly panic is getting called, I added few printf > statements in "check_ptrace" function in > "arch/um/os-Linux/start_up.c". > I managed to find out that panic is getting called from > {{{ > if(!WIFSTOPPED(status) || (WSTOPSIG(status) !=3D (SIGTRAP|0x80))) > panic("check_ptrace : expected (SIGTRAP|0x80), " > "got status =3D %d", status); > }}} > It was not calling panic in first iteration but it was calling in > second iteration inside while loop, with panic statement as > {{{ > check_ptrace : expected (SIGTRAP|0x80), got status =3D 256 > }}} > At first iteration, the value of status was "34175". My program decodes it as SIGTRAP|0x80, which is correct. $ ./waitstatus 34175 WSTOPSIG(status) is 0x80|5 The signal is: Trace/breakpoint trap > I suppose that it should have passed the condition in following "if > statement" and should have taken a break in first iteration only. Yes. > /////////////////////////////////////////////////////////////////////////= // >// syscall =3D ptrace(PTRACE_PEEKUSR, pid, PT_SYSCALL_NR_OFFSET,0); > if(syscall =3D=3D __NR_getpid){ > n =3D ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET, > __NR_getppid); > if(n < 0) > panic("check_ptrace : failed to modify system " > "call, errno =3D %d", errno); > break ; > } > /////////////////////////////////////////////////////////////////////////= // >// But the value of syscall in first iteration was 252 but it was > expected to be 20 (i.e. __NR_getpid ). > Value 252 represented "__NR_exit_group" Hmm, there are some glibc which cache the result of getpid(), so we use=20 syscall(getpid). It seems this is happening again here, but it's strange. I= =20 looked in 2.6.18 source code and the bug had already been fixed. Can you test if 2.6.17 compiles for you and has this bug? Now, again, I need to know: =2D distribution =2D host kernel =2D glibc version used =2D whether the host processor/distro is a 64-bit one The only difference in source code between 2.6.18 and 2.6.19 which may be=20 related (but I have serious doubts, there shouldn't be different definition= s)=20 is this: diff --git a/arch/um/os-Linux/process.c b/arch/um/os-Linux/process.c index b98d3ca..c692a19 100644 =2D-- a/arch/um/os-Linux/process.c +++ b/arch/um/os-Linux/process.c @@ -7,10 +7,10 @@ #include <stdio.h> #include <errno.h> #include <signal.h> =2D#include <linux/unistd.h> #include <sys/mman.h> #include <sys/wait.h> #include <sys/mman.h> +#include <sys/syscall.h> #include "ptrace_user.h" #include "os.h" #include "user.h" > I am not able to proceed further from this point in debugging this proble= m. That's already a lot=20 > > nothing of interest. Have you double-checked your compile-time options? > > > > > > Looked at what's happening with strace? > > on using strace on uml i got following. But I am not able to make any > sense out of it :-( Argh, strace -f breaks UML, but would be what is needed, so strace is usele= ss. Btw, adding stderr=3D1 should make UML print its error message in such case= s. =2D-=20 Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade |
From: Pravin <shi...@gm...> - 2007-03-28 08:15:54
|
> Now, again, I need to know: > > - distribution > - host kernel I am running "Debian" on my machine. Its "2.6.18" and version #1 Fri Nov 10 16:55:51 IST 2006. > - glibc version used glibc version is 1.2.10 {{{ $glib-config --version 1.2.10 }}} > - whether the host processor/distro is a 64-bit one My machine is 32 bit. gcc version is {{{ $gcc --version gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) }}} > > Hmm, there are some glibc which cache the result of getpid(), so we use > syscall(getpid). It seems this is happening again here, but it's strange. I > looked in 2.6.18 source code and the bug had already been fixed. > I guess, I know the problem now... When I tried to compile vanilla kernel-2.6.18 with "make linux ARCH=um" gives following errors, and I had to do these modifications to make it compile. And one of the modification is about "getpid()". Here I am giving u the error, and what I did for that. {{{ arch/um/os-Linux/process.c:144: error: expected declaration specifiers or '...' before 'getpid' arch/um/os-Linux/process.c:146: warning: return type defaults to 'int' arch/um/os-Linux/process.c: In function '_syscall0': arch/um/os-Linux/process.c:147: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:152: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:158: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:173: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:183: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:197: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:207: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:242: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:254: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:274: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token arch/um/os-Linux/process.c:144: error: parameter name omitted arch/um/os-Linux/process.c:284: error: expected '{' at end of input make[1]: *** [arch/um/os-Linux/process.o] Error 1 }}} This error comes because "arch/um/os-Linux/process.c" has following statement {{{ inline _syscall0(pid_t, getpid) }}} And this statement is the one which is giving error. When I commented it, the compilation went ahead. Now, I can see that how this small modification of mine has created the problem. Can u tell me, what should I do with this statement so that I will get rid of above error ? ------------------------------------------------------------------------------ There were few other errors also which I came across in compilation process. Here I am giving all of them bellow... {{{ arch/um/os-Linux/skas/process.c: In function 'copy_context_skas0': arch/um/os-Linux/skas/process.c:328: error: 'PAGE_SHIFT' undeclared (first use in this function) arch/um/os-Linux/skas/process.c:328: error: (Each undeclared identifier is reported only once arch/um/os-Linux/skas/process.c:328: error: for each function it appears in.) arch/um/os-Linux/skas/process.c:560:2: warning: #warning need cpu pid in switch_mm_skas make[2]: *** [arch/um/os-Linux/skas/process.o] Error 1 }}} Here, I added {{{ #define PAGE_SHIFT 12 }}} in "arch/um/os-Linux/skas/process.c:328" I got this value of PAGE_SHIFT by doing some grepping. ---------------------------------------------------------------------------------- {{{ arch/um/os-Linux/sys-i386/tls.c:6: error: expected declaration specifiers or '...' before 'get_thread_area' arch/um/os-Linux/sys-i386/tls.c:6: error: expected declaration specifiers or '...' before 'u_info' arch/um/os-Linux/sys-i386/tls.c:6: warning: type defaults to 'int' in declaration of '_syscall1' arch/um/os-Linux/sys-i386/tls.c: In function 'check_host_supports_tls': arch/um/os-Linux/sys-i386/tls.c:20: warning: implicit declaration of function 'get_thread_area' make[2]: *** [arch/um/os-Linux/sys-i386/tls.o] Error 1 }}} This error is similar to the first error that I was getting, This time, It was for following line in "arch/um/os-Linux/sys-i386/tls.c" {{{ static _syscall1(int, get_thread_area, user_desc_t *, u_info); }}} So, I again commented this line also. ----------------------------------------------------------------------------------------- {{{ LD init/built-in.o LD .tmp_vmlinux1 arch/um/os-Linux/built-in.o: In function `check_host_supports_tls': (.text+0x3f27): undefined reference to `get_thread_area' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make: *** [.tmp_kallsyms1.S] Error 1 }}} Here, "get_thread_area" function name is wrong I suppose. After doing some grepping, i got "sys_get_thread_area" name for it. So, I modified "get_thread_area" with "sys_get_thread_area". ------------------------------------------------------------------------------------- After doing all above modifications, I got linux-2.6.18 compiling. But I guess my ad-hoc modifications has broken the UML working. Can I know which of above modifications are not proper. And how should I avoid them > > Btw, adding stderr=1 should make UML print its error message in such cases. Where I have to add stderr=1 ? in UML command-line parameter to UML ? > -- > Inform me of my mistakes, so I can add them to my list! > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > -- Pravin Shinde |
From: Blaisorblade <bla...@ya...> - 2007-03-28 18:31:49
|
On mercoled=EC 28 marzo 2007, Pravin wrote: > > Now, again, I need to know: > > > > - distribution > > - host kernel > > I am running "Debian" on my machine. Its "2.6.18" and version #1 Fri > Nov 10 16:55:51 IST 2006. > > > - glibc version used > > glibc version is 1.2.10 > {{{ > $glib-config --version > 1.2.10 > }}} That's not it, the right command to run is this: /lib/libc.so.6 glib is GTK and gnome-related, glibc is the base C library (Gnu LIBrary for= =20 C). > I guess, I know the problem now... > When I tried to compile vanilla kernel-2.6.18 with "make linux > ARCH=3Dum" gives following errors, and I had to do these modifications > to make it compile. And one of the modification is about "getpid()". This error is fixed in latest -stable tree for 2.6.18. I already suggested = you=20 to use that "in general". Get back a vanilla 2.6.18 tree and apply just this patch, all your errors=20 (except maybe the PAGE_SHIFT one, please report if you have problems) have= =20 been fixed: http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.18.8.bz2 > Here I am giving u the error, and what I did for that. > > This error comes because "arch/um/os-Linux/process.c" has following > statement {{{ > inline _syscall0(pid_t, getpid) > }}} > And this statement is the one which is giving error. > When I commented it, the compilation went ahead. > > Now, I can see that how this small modification of mine has created the > problem. Yes.... Grrrrr! > Can u tell me, what should I do with this statement so that I will=20 > get rid of above error ? > -------------------------------------------------------------------------= =2D- >--- There were few other errors also which I came across in compilation > process. Here I am giving all of them bellow... > {{{ > }}} > Here, I added > {{{ > #define PAGE_SHIFT 12 > }}} That's the correct value, but still 2.6.18- latest stable should compile=20 without changes (so please test it vanilla). > This error is similar to the first error that I was getting, > This time, It was for following line in "arch/um/os-Linux/sys-i386/tls.c" > {{{ > static _syscall1(int, get_thread_area, user_desc_t *, u_info); > }}} > So, I again commented this line also. This is fixed in -stable too. > Here, "get_thread_area" function name is wrong I suppose. No, this time simply glibc does not supply it (newer glibc's do), it is a=20 syscall which we call on the host. You are calling instead the guest=20 implementation, which uses indirectly the host syscall. If you call the function inside UML (i.e. if you use a recent glibc and are= =20 unlucky enough), with some luck, you might get in-kernel infinite recursion= =20 (and a crash thereof). man 2 get_thread_area on a recent system shows up even its manpage. > After doing some grepping, i got "sys_get_thread_area" name for it. > So, I modified "get_thread_area" with "sys_get_thread_area". Wrong change. > Where I have to add stderr=3D1 ? > in UML command-line parameter to UML ? Yes. Bye and hope all your problems are solved. =2D-=20 Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade |
From: Pravin <shi...@gm...> - 2007-03-29 11:58:08
|
Yes, finally it solved my all problems :-) Thanx.... On 3/29/07, Blaisorblade <bla...@ya...> wrote: > On mercoled=EC 28 marzo 2007, Pravin wrote: > > > Now, again, I need to know: > > > > > > - distribution > > > - host kernel > > > > I am running "Debian" on my machine. Its "2.6.18" and version #1 Fri > > Nov 10 16:55:51 IST 2006. > > > > > - glibc version used > > > > glibc version is 1.2.10 > > {{{ > > $glib-config --version > > 1.2.10 > > }}} > That's not it, the right command to run is this: > /lib/libc.so.6 > sorry, Here is correct version {{{ $ /lib/libc.so.6 GNU C Library stable release version 2.3.6, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19). Compiled on a Linux 2.6.18 system on 2006-11-04. }}} > > > -----------------------------------------------------------------------= ---- > >--- There were few other errors also which I came across in compilation > > process. Here I am giving all of them bellow... > > {{{ > > }}} > > Here, I added > > {{{ > > #define PAGE_SHIFT 12 > > }}} > > That's the correct value, but still 2.6.18- latest stable should compile > without changes (so please test it vanilla). > This PAGE_SHIFT error was still there, I added this value manually again. But there was no other error. No problem atall in compilation except PAGE_S= HIFT. > Bye and hope all your problems are solved. Yes, it solved all my problems.. Thanx again > -- > Inform me of my mistakes, so I can add them to my list! > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > --=20 Pravin Shinde |