From owner-lkcd@oss.sgi.com Tue Jul 3 08:25:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f63FP4c22725 for lkcd-outgoing; Tue, 3 Jul 2001 08:25:04 -0700 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f63FP1V22718 for ; Tue, 3 Jul 2001 08:25:01 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA99248 for ; Tue, 3 Jul 2001 17:24:53 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f63FOrn148836 for ; Tue, 3 Jul 2001 17:24:53 +0200 Importance: Normal Subject: To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Tue, 3 Jul 2001 17:23:49 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 03/07/2001 17:23:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello, this is just to inform you, that a couple of changes in lkcdutils were checked in today on sourceforge. A bunch of files were affected. For details see list below. For any comments about this stuff, feel free to contact me. Regards, Andreas 1. Enabled LFS for lcrash: - it is now possible to analyze dumps with size > 2GB Rules.make 2. All hex addresses are printed with leading '0x': - Adapted fprintf statements to new C-Standard using the "#"-character. lcrash/arch/alpha/lib/arch.c lcrash/arch/alpha/lib/trace.c lcrash/arch/i386/lib/arch.c lcrash/arch/i386/lib/trace.c lcrash/arch/ia64/lib/arch.c lcrash/arch/ia64/lib/trace.c lcrash/arch/s390/lib/arch.c lcrash/cmds/cmd_deftask.c lcrash/cmds/cmd_strace.c lcrash/cmds/cmd_vtop.c lcrash/struct.c lcrash/util.c 3. Removed compiler warnings: lcrash/arch/s390/cmds/cmd_s390dbf.c lcrash/include/arch-alpha/report.h lcrash/include/arch-i386/report.h lcrash/include/arch-ia64/report.h lcrash/include/arch-s390/report.h liballoc/alloc.c libklib/arch/s390/kl_get_ra.c libklib/include/klib.h librl/hist.c librl/rl.c 4. Bugfixes: lcrash/arch/i386/lib/dis.c lcrash/arch/s390/lib/s390-report.c lcrash/arch/s390/lib/s390-util.c lcrash/arch/s390/lib/trace.c lcrash/cmds/command.c lcrash/include/arch-s390/trace.h lcrash/vmdump.c libklib/arch/alpha/kl_kern.c libklib/arch/ia64/kl_kern.c libklib/arch/s390/kl_kern.c libklib/arch/i386/kl_kern.c libklib/kl_mem.c (fixes endless loop when high_memory is not initialized in dump) libklib/kl_memory.c (64 bit bugfix) libklib/kl_stabs.c (fixes sizeof typedefs) libklib/kl_stringtab.c (64 bit bugfix) 5. Moved lcrash/include/arch-xxx/dis-asm.h to lcrash/include/dis-asm.h - dis-asm.h is the same file for all architectures (file comes from libopcode) lcrash/arch/ia64/lib/dis.c lcrash/arch/alpha/lib/dis.c lcrash/include/arch-alpha/dis-asm.h (removed) lcrash/include/arch-ia64/dis-asm.h (removed) lcrash/include/arch-s390/dis-asm.h (removed) lcrash/include/dis-asm.h (new) -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Tue Jul 3 12:52:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f63Jq2Y30190 for lkcd-outgoing; Tue, 3 Jul 2001 12:52:02 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f63JpvV30186 for ; Tue, 3 Jul 2001 12:51:57 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f63Jljs15504 for ; Tue, 3 Jul 2001 12:47:45 -0700 Message-ID: <3B422273.C533490C@alacritech.com> Date: Tue, 03 Jul 2001 12:52:19 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: One more try ... Content-Type: multipart/mixed; boundary="------------AD3C6227F0BC505FF89CB050" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------AD3C6227F0BC505FF89CB050 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's the next attempt at the 2.4.4 LKCD patch. It seems that for whatever reason, my last patch sends haven't gone out, so I'm gziping the patch just in case it's a size constraint problem with the oss.sgi.com mail server. If you have received this patch already, I apologize for filling your mailbox. Let me know if you have any problems. This corrects a compilation problem with certain architectures in drivers/block/vmdump.c. If you have any feedback, please let me know as soon as possible. Thanks. --Matt --------------AD3C6227F0BC505FF89CB050 Content-Type: application/x-gzip; name="lkcd-2.4.4.NEW2.diff.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="lkcd-2.4.4.NEW2.diff.gz" H4sICAwiQjsAA2xrY2QtMi40LjQuTkVXMi5kaWZmAOw8aXPbSK6f5V+B8TgJZd2XDzlORbHl RBv5eJKdeVOTKRZFUlKveQ0POZ6Z/PcFupsUJVG0M8d7tVubmZKobjS6gUYDaAC0waZTqFxp kQ8Wc6IvtXNXj2zTCbWQuU7tzHWmbBb5ZnVuWp4AqVr3upELt1OpVJ6BrnDhM+h5PjTr0Djo NlvdRhOf642dUqn03LkKl64D/4gsABzb6nYa3U5dIHn7FirN40a7fAAl/o3Y377dAQDDdV6F EDmG6Qeh5hjwMNdCCOcsANvUnABcHzTfBMcNQYN703dMC+aajk9l+GcUhEBYLFNbmMAQJMTP AAxzqkVWCAvNikzoDy+qO7BT+ihG674WzMGIbC/YKZ1dX10M3qufLs/vLm92SgA/sHAez5OC BNPRJpZplGHB/DDSLFye7fqP8MAsCyYmhzINCF1cvEmIqAEXsmC6CYFn6mzKsJ85UDNDvRY8 BjpnXm1hE2QV4JaI1izLfQhg6vqEw3ODsDLVmIUsBs3RrMcAYdwpsgIRhKYtl/iQWrRhTqLZ jDkzXItrBdWd0g5IyoPI81w/JOzEFJgwR/OZGeyAZMO7wdXF5a2KfcRVAlH6X0w9Col2oO0Z Muee/7hwfVsLi0BrJoT4g+O12MTnSAl8x1iX6Uvt3pwyHJ+SqbgtJatx01IuD6Fx1G0cdhvH mXKZDMiVwcbRAYkgfR1yASwIptXug0c7qFooTszRrcgwa2Idumt7iLU6h88IvLB5K4w576u2 5vHmamh7+/hUKhCfw0cPiad2w2cLFOuaPtd8xOQErmXiGBWlM5xYVR1igAUzTLfm+a6NUKro y0JgI5Fz2u+NTsO3a/sV2zX4SH7c2i2ksdRstyWpE9cNuyBJwPFv95TL3sd+Ec4uhr3349Pd PUU8FSF+Uj/2R1f9YXEXKmd4CvV5bU/pjc4+FGuEDI9URaLr0hAuQnej3u3g+grlwmFhzdaY U3XFMy0WdQb+5EOCaGIwH0/gH0KxZPQKMijsKcNzImA4uPqYUPOh3zvPRUf8LFQqqIH8sDLz 3UhsbIGWNOqrF4NhHxFJxnaEGut0yo2GEKJCxU0xdk+5uizGv+F3mPmmB5UFvPqsSHEyPhc/ //5Z+Vx19/bEI/yk3T38DHH756ozi7uGvfGHn0bDn88Hn4uvEF1AJ/hNSgZj1cb50RWk3ce/ qy6K5Vs2hZ+gMt3og59PSF05XHgL9mITIEF8wmGmjNQJHhYk7j7oIrW+LRCLU6MFNrYpoBtx E5yA5UAlQJ0V2BUpP/Rc5NxsNevEzVbzoHzMmbmztjfd1d/61gMat0u1etkbofTy7Tg7W4r0 pnBD5fzudqxe9s4+DK76p6925Rp3X0FFh8qGrKwuB9lRWmfaxh7oWxZXenpxe8rN6Brlb3D1 Hlc6QwmdBHJde/u4mr3XCcuEaHdTP7bN+wymrM67Mt+GTueaQbO8uSbnqaKVS+nmrP6Urs/q Ltyi3Sa930C9T0q/22xn6v3Mwbk2oHXQ4BKHX0IxokwDV48WvLrUZkynszX6Be3p46vYMF72 3g/O1PGP49H/7JQE6Fga0w1fAXTN0ybMYiFawQSD9DCSmYbmTNMf49Fc84BmGL4ZLMf0hjcf euqw/7539qM6vu2NbtXe+fmoPx4jnrxtkFYty9huh8rekjUgbpAvzAnAMTQa3dZRt954amPW UeSbaDLNpUZsoHfA/EJsrriTfwbQPQWOUhX22iUThB2VR/RWqBMdU/8RpTT0NY+0F5pUHRmK T24wVdFlovPr/yI+VY6Ka//Sn0ci3ThhSwhTwGbosGFDYIYRdXiIUDcJMbNN3o7Ke+769LxO FXz/nP0VmPV8tkug3N2VMHxzLzWfdgY3t9Hs1g+fubkxhvyjd0TOSIm+GnW+vd+bDtIJtf3E Ax1+VM/7n9TB1eB2dA77tR34SrvMnBBUlVQb6Vv8+J5N8dIwXTtepRhGIN4BT5uZKgtUX7OV yKE9QSfcctE79qZOcQd+w90KQj/SQ3LoUVkGoSp/7wP/afonz9kLIS1P7IUEyt0LCVO4nUfi oB0BbkQHL2XZnu92DPnnjHsxjdg7/D4216/FusLwsTp/s9lumJaW3RPYnmq5+j11ltY75emg cemR6AbUZnTeNG8NJ/VEms4PHvZwx6vJ/a5WLDsp8F08o6Fbne+SL4SSkSEY5hfcSQcWLjNA 2afVqNPI0ekaq+LJLCrkR8N+GeTue6Hqm7MA9osniTSh60Pjd8Bg92owdx84iLI+gj7LsCpt +/6x2uhwgeMnoc4vIq1GQ7o9hYKPJ8h3Toiq9PrHZDQKno9Cf6/snt3cwQsDdst4B/YNlXgu 1ZPrq8xQiny1mQwoEHCAhKB8u56SIgvi72SaF4Hywih24UUALyzjs4Pz6ZHv405V3qDHZad+ eszgPCuD6fuIFC8mK8wRzBDUnwjaG0exy9foSOIf5mSmlAZHgAe+kOAP576pGdWppSFrfz9F mLshvH4NB60cUvn2mvzmaipyZ4t8kbQcQboVmHw8BQsY7pOygkS9vD6/G/aLiAxBlE15wY1E l3mjPXs2JCmRoYTZhotLZKEyHrwf999/ItK/Ps+uy9P0hLKJoXK1TQxU+AEl9dzUodWgAFC9 jv9D4/jg+Gl1k6DI1Tf1ch3VTfnwiHa8VNvfKaGC7SEyFpp6SPENGSTRQeHoixDzlYdDKPKA 16lUSKZKKDiaZrUVO1J4BSYcmhg3eeyiPQtDOK/CyJ0wvII7oDxq9wj9FieduIIylOkix3Tm eo8+m81DWngdbgmET1yGgaNXAXqWBRwgwM0NTH9hGnwdQB81ug1I0m7nJsxd914snhbMQzLY Kle6FkcKXdQqwT0PdqH7TBEwjoc8JprXeeR+A2grJFL4xdZQA4q40zpS20RpdFhglzkuhAhM wOttiAKPAyl8NjGBYGYidhVhP+FxzIflYMHp2qZWF7ebLH0/zW5emoGNLtvmzcQ/8oZDlIOF 5jOKNQV8ctnIT9wcVYLpq2gk1HC95SS1CVeabXbRb+AgehyslMCK2PILlLIuJJFMTj534wWU iK1puO2oaD38zWOKCUu4L7Jtgs217htzbdPEcDWxU/ot1lzLIVWEV226lKhOZE9w+lPg6qk3 vpSXkqu7y3f90cmWsfKimh72qT8aD66vnhgofwbsVxMH05c73SSoyLldwD3T8eRw3iExjLym AFBxYsMjF2nkGhpe4hjXp5xioULJ7fIeFYVb5v3iy/VJ+Go4fJnACwpF0kKQ4MK8yOWt8rUY a178FMZVGJjS120S8uCjMsqSjjvP0EIhGlIqmCNinsTbREK0LHXG0Yh/qUFZ8rMyvTAjBvmv UjTWGKXwPihl7U1YFMxa5dXLNc6Wt2+r3NfnsY087hV2DbCB4Yb/ujxNpPyk4kkuVDLkTf87 eGkme7xkVfgqQC1EcBoqMq4RTbQIxNqYd9wXK6UXESE7D9p4ztAR1SxVaEGVX64lE1FSJVFc FmOnaztxeOadFeKusWGpJGSAX8nc+uIKiSnqiNhvJ5EvRco4v9ZLNxYf0d2MSY+JRu4/SXO2 r8FaRwc8wrs9gLAJsu5lbEIkN5pmE9C/aHZybzQZ4/Pvlk1KKpXoq82dyl8tZrnpqHKfolrv rq9vB6g40bODQhwW3VMGV+Pb3nCo3vRuPxRrInb7axIdtRdbQba0V13LOOGRpa2TpJIIOfOk oLZ0xTOVts60DJbnTLQE2tqTIgq9jxVmwpttnCBgWvvt9c35YJRLEJKwArp9SQlbv0AtQLeu RnudULdsOgFy80XGjX7X0AMMUVOfyKCf/JknJZUC+ps4TzUeW8Xfe4qIk476w35vvDYkm9jd NRp26Ub2l2DOYtjmbEgtzwfWJhGzjG76B14RKCL84Xp8K6LC/ElGhinw+xb2XkNlsJxI+m5P 6o8UYdvP9xJouw5ZwvDI8D80B6AFddQCh93mAV5UjjtPaJEUhufFH49EXAS19V4DKonXLvwp 2dFcdjCbrDHXhKKvteyjXRI6kve0sSfOUMtlgaehD6FMLM25J7/JxyXjfcBHg4LKHPV4MlCi pG0WOEVX59txwvc8hgJ3eI3BJT7CnJLoGl7tg9C1EyyB7jMvlKkvurGX8OLeTEIweGlcnbUC gUb3FLqY3JtCDfMIXqyd2uv6Fc8YKaRl+/KRVA46SfHQzsbQEh+6bF8+8qHinKfn3lS7yfTp M9VOqdeVBWSMj9eQHt9Jj5er4EqzSaoyoQ8bPRKVldlX5ttQ3sl0KfXYWVXSOyWepystJ0y4 go1iws7KhNTYXsHD1eOf1rE5CmJ7qmi1O1MpLHM96cKVI9QFXZTQfKfiuXmio3q5TcHqerkT C7tI3ZxThQXc21Srodfup75pJimb8/67O0oXDYfXZ/93SSXTMWzTifLY/VRKKAsok/VZCSEK HKEz12h3W51um+cM6ts34K/LB8mMja1TBsYOfZ++AvrUvYgZ9IvpeNtwDUqy0OQbmaMCjl9m eNI5mSSBs54QEsmfhX10kEoe/Vk8K/mjQpIrYkfNzjF9u0Q1FU8YYSqnFKeSHgOVqEuG66xi 2NoazfTjEL8mFMCw3XsaadhMDXTN4Rx5WnyCzLDjBkSe4HAAbsXpLtBokdQ0Wt1264ljuzI8 /+TWeW6DvmSFRhxQonvw1IqCuRpaE9VFTeYHsJYXQsmxteA+idLYdpIQsu0ycZf+rY5ZaDyy vy0cTSEtF20iouaGlorZJib4kePgvbharcLwh7G4nK3iZR5TaTErKQhERynGfeiB7kYenmV3 CkrocpR4+VuYRhFtMN6HH0Gfm7qo04B9GXxvoWdTohi8vCcVeJKNR2W+k7TT3aiAekzJCbEj TWNJU8CJwtkpseCZBhJkMTT9aH1SCoyLappUmlGJKYTTmPHwkp5U10EpMLHPK8LpKdQpEr+8 uorwvVi1sn3gdwnWVZLiEDwNX45WGpRYyMippAdLTtlx/UqrLu6d7UbsFBXwfyFkto1k2fZJ 0rDQsGGhbeeqhp4X01U83pwrCXvK8FJgiMlJ8WB9TCLAWUMk4bEI/WAKry8kleIYPAIxuBkA MpFC0gLo7OYuAG06RceRot1CYrZmmSjDhCjW1z+4+tQbDs57t331dvhO/dQ/u70epclYHZgQ kTNO0IJDZfZolVzaMxRSPGtzOmQUErqPKGBDURoK2xkuuk7iKPLDhsrARMpEkqrNM6OldqsV J6lE7g+SLJpvBni6jMgyFUpO47RP6QDOVMMV1a2UFXCdCsmqYHDG8Y9F81SKJs2xIeUn8ijF dIuo6io349FlGPXHZx/6lNpKsVKkp7K24YmB8R5Q3gpqQsN06p3yMZQ6IiDDDwTxTEdvKcmU KaQpVOKDypFf3Q2HZWiU8ZifSHgnslWuW06hcSLTulkJf2KsDJ3xqBovjl2qnbKsMKYJORCP DELvZnAm9J6q6hZTZOIyoHSDKoKHBCLaVTQATMmi91kGk66fTxtNAfWE4RRAf8p4ShS5BrTT IdlfFjiSfGftCdVtvGMhl1Hku8zZopAL6VzKdfaZWLgWmmU8uRtSvyreUjSfhIr1Aa4KNYI+ p/lB8eaPAUv2fHBepOt4QBpPAFnujHcTsMyxkGAkiyPiv6ATpXlMZ4YausSCn65GKg4Y/7yt NiTN9W2lIRkwefufLuugIp3GMb/x4O7Xn7f7z6sLOeZ1Icdb6kKkY5pVAEIG3s/skbm9nKKQ 9S6K5n9r/YnHnLj+hAsxr7DoHMblItKJM1Btq8kzD12o6FP/9DMK9W/4Xx2VEHwtZz2RRdls hq8nf3vVCZlrmVMenN+iyebyix4XpYAqmiXOBRlxZnsWm4pM3A0eRhbZfOhFHeoXQPfWB9e/ 13w3ctBPS+y/JnIWeAyosBd9gRm95CGCPo0m6fNm47DcFPqcaqZkOTvlFyduYApFSVvAa4BU vNooLw3Gdem99CKzCy2K8PvvT5VgbFbE5FSzlDKqWbrwot62vvBClrhWBQ1p/csU/4mly4IV kbpUZOFG5d+7woTvR+Rk7siW+hPu+7T5/al9gBY8rk5KmHl1OYAftFCfG+5MOlMoesPrs493 N6j3SY2+MMrLLHBXVA+h53LC8WQzOj2DFC0I5lEYALpseGtAJH+LFBXy5Ch75wure7/KkHPJ kN0NOcBxeductdHbUAv4QrL1hczNLyRnNEAz5oRKvAFLoVBeOnj953xfikUhQzCetnFbS5Ky gPKs3B8rSMrE8Jx6pOPOM+qRCPs3lCOd+aZGhyKpPtooPQpmLKk5Wqs7ahwfH8OYWQx3D96j xUYnJZDVR9uKj/5bBPWfVwS1WYkQoKFWPVyMLior00UJY36JxzX3BzdUXYOXLeEDjHpUhIBm nkI0nhbQa3nI3hl/iRPQxUWXLavWYH2y7FKmZYHBnNfHuPH1toyuRkiKO8P9vxj1LvvqzfXg 6pa/A6NyhCqSGfvcqqrs8tIgd4Gnt628eGEGXrEM+K2jEV928QZsr6N9oNYu7J7OdlHLzrXK G6obMplHBjath5+a7q+aTajjrXUl/xbVaBS4jCWLryLRiciiGpIrohbbWYqXxbmVycnAy+cw H+16ceNWlgcJy7csQywBJBIJmC3jKNA5ePhi0njiqA4lYh3UNzzYCmjauHJ6pPTZg/lKqLKI J1ldw0zFPkUR3MuXoHxH3Sp1i8Zi7PzFZFJrFWmlUNDKPbgoaumgBI1vLnf7b93Wf2Ddlm2L y/MWTyzpzvTBkt61vwfQ6HSbTwUZlmNz/a52gweX6Ct+ffarCKhtcbgp/pJ6i2c9XUNdjl9M okQy1cNEBOr5g4XXTFdbGsNOtqfDtIN2XvJ6pXuDyyu93/aW49rY/D+2cCheUj5s/7+85CgG 9zUfvRBxrUv+9gCqq18ihm4jfHrf+66YDB308BT0e6Phj+rNCF2DjzGWWzoASCu96Yt+YUVz jIr5RbhrPKDB1S7pKSWw3Id1lCIhf3Z5879nH96v48RLsfh7CTJRlodigFzJkYgn8+sZQJnS sZ4dp6pJkhHo8PfAGjK/niMj35Zf538mgH9mvm9JGDdft6QXMXWPpZLaM3QA6eeUiU/U3tGE cs6p8anXJqlZPgYUWaXnRZh+GfPvm2L1VU1b0+cLk3o9nqVfJvHRv5ra/J3vJB0fyDc6U9l9 kYkvcFzLdz4pIS/mj7P9MlUfOTJcx58fmGMQX4nkuAZRCN37/lV/NDgrQuk0tUTmSlKeIYpb cvXrEHlCKHP1f1QCn5Grbx4dckV1lMRpl/oXCnRrVBg6PfUTYPB6JQmBLaVSMSfjRvZTEzm7 eRSGpCEM94FHqKDOL6SO+5DcUUR45jtWREXjIHBkpvOlvJNRPjkjPSzCKnHeLMCJKCdYBteT r7M9vVdbUwSbMHn7lX539A/t2LNSBK1DMt0l+jpYSxLQa5tMazUz3uZMmJb/pue3vDo69YIH TfZIu8+b0KnEe+0Ujyxdctaa/v5oPR8vX0Tmx58/An9xI3kD9KD9r/a+tL2J7Fj4s/gVDfcF JCwbyYAH7IGJwYbxHS/ES5i5hEdPW2pjxdqmWxrjJPz3t9az9WlZBpLc5I6fZLC7+9TZaj9V ddCrvvasufooTACtqTb0L/SYv7/b+/Bl+Z+OM924d/+dvegaJhJNSL2XELPmmG1QFDDWmpRI s5Tocu+fdUSBymGqnJClrnNxbV/PIqo9rJGP5jGJL/SwxiAs4mFday/iYQXo/1gP6+rK4y9w j6aDtItZWd3zmHu0DuKZXKQ3aS+OUTAti/EsBxsUoxPR0syzQQb2ZY+roZFR+Wb/JHnzdnfl d7/qP9Cv+u/iiaPwJh4GbMSVk2iJZ8Ep20DA23PxMQHk+h1qlBeOv8q4iidjkom6u9qrBjsi CON/0pfPiVUaWOKeKGYkvl03xe++p/8zvictRHeKR4hRAzj+hSOj4h8EoeWt79ZX29HQ8orm 8w2PJ1zFTexezwDTIjSHm3uNGthfedlG0092Dw7e0jeD8XhS+dXbo1X6aFKsZkWvj0XZvO9E savhN2qdVoD6eYsgfYoP6dXbP3a2NumL7uTXNM/Tq8rvXu0cHeHHCZqY3W4fbd7rdjemhMS/ qNzdG6sfFc2D3V1df/ykpHu0V5942scRlhhN856Kyf+9R7p0lCojwpPdrzzSVUCPv175GU3z /ulMVi0fD5OjNzswmZd7zWTv1W6TqoRyZP3KV54mey3bpXHOaUrN99Ir0D/weKaXXuFJDBdq BYGCwYoUhDvoT6eDjGoXcEdIxegSUCD/d5QutKe5pmxUgxK/c+xVtaLG6xJ9ZeL4Sm/yjEJU b6D4VYQXgtUfaoOL+xrK0OaVt6oYASotnYpBExZEO7oqutP4ovXHp7OzigGko3gTCaQsbyhu WxzWGIPa42MD2h/FsWA2LUagA0XfnQNtDTPVwTWQe4jqzX+xVY9/1NPmaUOUnaRer6eN7+un jcYP8Ms6/uK4WLBIDGWXFqg6HR+ebBPbOUsxExHpTXwFbvQBfgV/zEbOH2rqyyAIUBtIwzR6 vbl7ZFvpX0Ezepy0cFwosLDKB6qT8ivGlYIG1cKwrboU3JCCHEDAT7FQh+vd6HR2d46Pd7c7 2/tbO5v7jYQOpL1nTTeY4SVIdOcxj4x7e7v5Zrtz9OPO62P7187/bJs/9jaPfjJ/HLx+fbRN H8JEPrtFdI5nVPq6WLdyCakEtNhkmZii6LMhVxSOhWdsBXHd6djqto5iiz/pYDgG1pUOLtOr gs2RvD9EFRepGGDk074pm2KG0Blkv2WYcYwN0uF4NiLWnp2d4UmT0bcZoZPifDwb9BhvMFQW 7KBgFH6JFpoQVuAWlUDrb+skuLg4xuKOxpdlSA4PPkUmfyqB8tRs3czD+2l9aq3DP1tjTVtp wi+6qCtJnTxe+wf7241Y2za2fYt+J15unb87J5EqjiFLErsMTn6oJg1WVucNNI1x93nfdVhY ZHn7MDqwVRzYO4LkDUwsaSRdNKTVPePgzUrlwLhTdLxFu3x8oy7xTwzBqOzNG5N2fnK0vRXt /OlinXsEwqZc5QCk3HudB9yk0TYTTD1umPFs7u7G8QKR6pg1koss4zwYASg5iEknPZtmeQfU JOafoDZVjkWJHBR8PkUZLYOik88mU1DURXNOLLJu7Rwdnrw9bsRR/lgWR2iZyulrIQMYbzug eDwFxhq5HV615eTyPENls4raQWfMhhMEVTmdJFGgSZZ2z91tAco9Q39Kfyq3ADAhzAFVQSLM MUzGmVrw/cHVHFh4AQIPicYCAHSgouaCcCMvtvTWQQH8Hut9AGv/+cOGgHn4gBVArMpAiq/v hjA/XGQt5inYcEcl4OgTdSHFwCK4CxzVVMfngQnApV3ScrUBw5B0HDM6Fps0LArqAG0ohPmQ 8UR2b3Z2Bu0RSaV4VuO2M1lklA7qSYk0ZCkbwejE+c+g+Wv/xwMX4Ohz0is2BJzBVzwZJpL0 sY8G7oErqGAHOWeC2WJ4Hr2kQl5GACPiVY9OwIE4KirB4csFwfVHeBz6kSbwnFWhDQPuEktF cAycMI2m/yeDA6XCq17mlvTbcIfnKgYuRy0Nr+xhDZ5sGMTLu+fL5iAiAtQhiwtSwAUD6Xdv dPIa1y1PL5OdhwfGBvRHR/orGgcU2tD3CxyqExhth14/71D0g/SJJVya8nuvp791J/rbYGOB Copm68YXYBeX9qyb4pbxSojQxyn8UFpj6oiPTIFy/a7kJJXDrzDAEi1dgBZlAbQVaAkLt2UL 0O1KwMnSgCnbEXNDxJj+uWHwmKWbq/mUweHoHpwOLoi03n+IjA25CbMicj4xmXXTQXc2EAeK A+7Ljo39VbQOqRBwzGWN7SPflH2+1tXrNEm4pvbCRxTx8bv9F310n+Oia/ewD2QDlT59IOVT yCLqAFLDYMJvqLKKX8LQfuEH8lHeW4Z5fVMQ+9JGlp3/edA0LaSrJHDeM4XBlDtMe0YyeK78 Q/hA+BDQby+dpoZR8tcqmS21CTuKgubBIdNvyngf0NFDE2TqWQfNmTO0ySjDHO2bJmMtGJFN WRMcgjjt8dUgQzd9jWEh/T4nkcJHNvj30vOkoMPpszr82Uzu3MVsJTskOgcHKNAQP1/W5vRs +TmOSFPO8cn3PC45Z8eBcXawBNTQJ1i+QY8TWnTMzjWDqAl3RUDkBL7GSyAjT5a0Sz1Zghbx syWaBFfRDNbZ2UDWy79oB6OgfUrjgxUX/1gJaZaT+3k7S5tIJy+CY2xiGo+l0Wj4cM5VXbAG QSOgAuk5ESR70LinT1oNdz15A6tXNEBcX71ZmDj8ZotSSdDZ/ypy8cf2n0Y3/uwWJaAFd3l+ Z9+apOJa+T+PZECHiJNJaJNZk5GcBNJbf7ogtWA//wgKwQLQ0xx+qbuWpoQUBGWJuWdfarut momg4b8pXYR76bt5vnpDI719Y2KQ8FrleYbbOTpvcdEH3f83EDQDwC800y4xUKGYpF22TfVb KbxDXWEiU7+gb+oyKE5jCpXq5WXdnPDN0hK3c15xPhOF5tZp954rbTY6nY/ZtIM6IpF0/c3r t3p9leZPyXovb+8f7G3v2fwoPPDr4OFlB/1odcZZpXSeDfSDZxKyisZ53uCq4jigB3VBJ26w nLSpUtX9P4/uK/bGvhCMNXXT0RPoRI24eALsajaYSlwNhkHb76guuI4Eo5bd+Vr25FGGvu1r qGMFxvMJFJ/1eLj+I4xtkNlaO5dUMomOufDYyg8PfKj47zn7+agz66lLTA0eLo4EG1rQigAS U3xVeD2ngjnNKNgpm8p5MzYmZ4NGnvMhmrkArZCwig7dZPn+g/Uq8o8/FhAV0IJLpQJgOuXG c2Qh7EKjCLgXB4wfTzBJ84JjsnAli6aEjPGWT8furnthY+VNgN945MkD+oeZNvEKY5UZ/jBB XsBkryjNRlbyADjdpEr5mQDm41+KU9TR8gsS73//e6J/D9NPyGHxCYGD36AFTr6OfS+/OOtM xgUyg9s0PiVF/liwv+Yxb9spt3D5OH+ODQ1rMLfFsLjgSUkVhf5ZHZkCUXW3mUyWlhqmwIJh Bq83T3aPTeEEKczQpSpzOK9uQMW12imI2Qu3AXS5tEQPPruC6cXzxFslBcBT8RdwWYSaARDw JGf5LWtCmAo0Mh2CZSKbEwdE4z00/WDW090pUHBpCTfkbLYqlWIci2HjzAmLyNq327VbA0Oj opkaMWR8nK+Lbx0d48YP0butJT/MmW9EyotWEvTmbMjC+xHZTB+zuI2ulP+txT7ZxumYN1H3 zdtMdxOrkdIbSwnLk/pkJmiOmNpM7K6L6AWps1hHITIroeqiBLgijz9b/alVrTupzh2E1Iq/ O7VilTUzSs/Bo1ngv3T8CeKC/IFpMaYz6KYb7XmGh7NF/3SQOSGTxJ9RCdPA0cuMQmD6o2Tn cOfnQO9Cr9ij1Y7yXDNcMQcHvQ5eyaiK9Ci7ZMbrxEnin3kfWbtVHIjGZh1qxBb8c6wV1Z3l ndOraabRs8g2HyQ7Ytizf5EPrc7TCRHbOLmjQ7qDfw3S/CMddaVyWIgAxCWAY2rS9dFdLMWQ 6scot1BESsIkDWJ2Ri7PFQJAntzaJaoXeV9Gjw+Yx+aUdoXzZUQi0ZCrvlHTOVFZS56prtr7 vP+B0cxbF4+KhWLo9fNk9ckTg64kDfqAxI+AEJ3+LSbTeQg/Yjyuwf68v+wvLVk+5z8zNkHw nEYuz3UWzsTKEwpmZKaU2LHXKwCQikid2AkRNCHBYH3cFXqB6qM+nrdAsSUyixRfpuqFql4q Ham3h+EQZT3JYrPjmzv46Ojt8CvG7z1uxx/br4NFdka0+pUj8lZo3qvP/ir+jc5edBlbIlkX XMZ/3qAr1639TYdgFwfLe54lhgKUX+FPSKva2qVOpSkGwwSpvMqA8nthTmTe6ktkjnZj8j4R rEjCGJFW4ni4KDTXMprGCTK6ZPMIMY495cF5WoLdsAj5RAit/FWJy/t4ukBvDkLEH392VMIo 8Vwz9W87mOh821/UBU+sAvFjSO+JI+nksl+tlrGRzL6mCmeW3mpiD1CbUt9maiP+Bv1hf8oH oa5mZs9KwebNpt0VjvJhjW5HCvJyhfBTdpw5xrer4aE6l04TCg0E27s/xUcpzGEy6JOWAw8v 8Yv8spOnlx3yzVGUjTcc6KLAap/wHHu+TEdBC65bJVOWU/xiCnpVGBt3Cs3g/W9ZF1r1CVqa fByPe8lkgL4xBiSrwyUl0PgedVEPve9C0qrbvKbkEKCUQOwVOr26TK/YteGdP7tHzw4wjNia fRxoPlDOoSAUTqK+Bk4T4iWG/Tga0xn/GNcUvnAHBs2b3MybLbpoZqBOXo6arouKb/wjN1Wg WxfsdBDV2kM5ToRW/blWw2qcpCL3x6zGkn/Sc2fWTt//tHOAcU2dIyo/ffShyYsyyuUXWGpC SHFiIEcIEZbO72E1bOywxLv1pRK3Kc5kwgL2Nv/74FD93o0P6pzAjtBHWK8PyK8OdldFi/d7 O/seBOYF33+fvMSqmWT+dF7uHB81khcvyiE6twK7Vzre2T/GxfBciWhAS3GJH+xMTBSXcc3I MyeuiFyTMjU10f88ivCKdVgpvspRzA7qD2vJ3ebSWsbJuLxNldsb3ghPs6uxVJnHavPqKOfN WV6mGUjxOgx9Q+9AE8twJIVbN6s0o8i64Y1ktFaLzWoERid5twfZ2TSh9GwcUziplj8dzDmZ OuabxKtxJigPWFBUfbfXjHrD8QoToUvuBsOF5WJEd0AXGrbGpvT/VOEQ4zQ1eJHUA1LCRvWw FeDEM+NIN30t3NJbKGb5HEtMJr3AI0sW2cow/cTb5VKgjJafLyu1hyMKXnv9enROLFc7HvNo btv+bvOrL8EXKk1Xu4NoY31j1+AO3hLl5A6J1DmlBPAx81XmhjLCsdzEKhMA9lGJPAraRUrB mbCgCkOzpVRgXd/3P2g3o5ytUjPoSz+mGV3DGuFG4JmRO3Lj3eHO8TZV9r9ng+aaejQGjLtZ inFsbJR3D1EEw+loDYZYETcrVAKRd94TVWZLcTjfG83vmi31QDBs2Iq7vdt3tLSFx93IjeZs qfZ326fHL+i7B9wVGSEvtuIWrLkLt8xuwwFhWBmMR3xi0zwdFcCwc0pinGLo9LKV4WPlryUm tfQcoTh6ZV3WokK1THs9Po1z1crNXg/0JHLxufkHLEIqj0INKP9cc5gNMRGrGUSAPZiCHAZ2 zHpFpF7Iz1jDt1w5ZXP37Y+bKJO9kEVTMS6otug4pIPjVnYUqmpvY5RB7ySHscbOUXgv1XH0 njTu1XFiQLrvZYIfaC85vnvSxa/eG3cp+aH4iOc37JhJBn8rF4ikUeArdGxOCGhvstKb6DNq odGBAky+4BongtCHm+/sG2FGZkBRn6Z2wMn6kgTWJPbUn2qwJ/rLKWNozG1D7EiSHdAEiiID JboZvhXs5pZgS6CiLW9WjHfTP9P4cefNj3vbe0Kxb2FxfoSB7WVDWBshVpoGQjwizZ0Uc4yK PQWthWvV9Jjr7Bz+kapFAeo0pUmeYbxuiu2Ei5M3GmtOaXIm1aTKeuvcgizV32TrLmBtOnyf T33STH7a67w8ONl/td0hPqrEXZOaOLZO+U1xneSdi+WCc8G5eb1d0SUyl8H4UlMlaBI6hzK+ 8fdhtDsFEGmwu9VUwzAdjp43O5N0B1ma28agE5EY4nWE8QALqAu9NNGksCf3xC8FcX13v56d 0BS0vLo+NMA8SDIa1f9sYkaCRCNXn8upBpCpmbX1TNBIvnegivMgQnqvDvbeHm4fHW1vbTif OFezW7dB6Tp2GoJEtFPnpWvE3XSKZMky0jCK516PTpZr7qXhzOI4JkIbUshc+ZuN+NBgA10s IjxwVuBeuAIOJigcZ/EtQt1gnrSmQcSSbrpd6lI4hQ7BjxNwJ/N1Y2BsLI0gWGn72sgd3u2V 3jnVyiM6Yj3OU0Urj+zmVMM5mfTUJnGr4BCzn2AdnLyP7yP33Jeke6kfDUfCbAEqyjW/Go5V DsP0OvbLHB8cJKf9j47ZGLnsHqzDpRCl3aD3BpqREXUu1OfKi7aOWHlKOciswdXu8KvCO8WL qXRVFoPpxJuta2wGuz/EOq8dMR6FlXCN1/2TvZfbhxGEkeuN9es/bR8e7RzsV3/vVstRfYAz ias/Rst/sdHIVjiMrrR/kVZEXxEFJfzOi5+2f0S+lPSvzlQuKuQ/6cMxBqFRcstZL72q3wta 4hvmfJr1fnJ8tI/177f3jw9/gV23aeThm2TtiSNxA1Zyrx70JBkwGDdEwZlNOowMOHjdT5dZ sR+HndPCLtrnaNzLFu/U+fqrepV6aYt1aj/+qj6FPhbr0378VX1i9VfAj8X6tB9/VZ+98TDt jxbfU+/7WM/ChA17F0Z63XjM92AiRIWkIy+El+4DR9nd3re8U0NJA+6+gnXNYixy82gvZEzz QAQsE1uX2Oa89tcyOZZEZfXJ1n9jbfOKPNnsnTVSj+8YuHatzWjo+9hC44umDs8XzY0qOeUW OIvnWLrSi4ySqny0e8FgpWZnYK8YiXldFTon1jqi5lSm7l8Tti2g/OMNysXkRBCOwBflzW6o sWioJzdzWRV2Mmpc3ZFMG08xKeOHu85GR4UBjef3hTgS9BXaAXYrSgaBEczx7ICSBhxv24yw nBICVCttZi3o8hJ0HnrZ6jRTVaHLjnnTenP33eYvR47TU+s3TK1e0ZQbZMmXUadiJez+LW43 KlxqEbcJX5tDkW4D6U9uoyXPUTo1NqvvOdyIw7cYxpYmASg7QiNEED0gTs5SAG8iMh2nY9s1 ioh+qa9vQJVYp3iY5hdRyqR7XNNi6iAxf6vuRfdwCT65hmydvub5FMtOPUEy8QFgpzIM3vjA y+ZZ7a1PrQo/2/b+VoQ16HEbRvJ9A9M+Rl+TZsxsv5FpXz4Uxm1AAlRU8kqERnBtDmKI7w3N CPzbw4u3WY4mp1tKQgxx2n+JD71MB3TolI9nH8+DciteMRY6eKeg5NI5R31GMf1U4c7G+zcq USwc9U3MXJOklcn5uLKCVul83LrFMboTfrE61+24RHWG4IpSZQ5bjvToUlSq3FrvhGhXsAPq 2VrISLNUfN+BuLKy4pSknZXcCrraXGkkBzSlAgFlfuizr+s4nhSZ9YYinX8rHsczoqufJC0F w03s1JpeXVXj9mQ7VLxdUkqpwhdruc4paIBcvkfIUwv80F0pWBSRihqSj8YVTdcLJmAWrnax MW9LmWT8Hf3GOo05ZmcQFOOMOjefgzPC24A/ck7Tdd9M6Bxdk8lA7TmokAyfhuof3+NZNJ7D jHLzUA5HxekHHN2y33r/jIvykujGgrGOi9c/xjIUek9GbILznRsnarLDPOtM7hD7jertYFZU mATOR+WyAi8iZ4/UQfnoNrortet0jVqUumoBZrBX3qKGkJa6t0LSqlUSV0heZnEolgQ7YPcv c0jc00tBTJ2nKx0lMDTLNXJTT3rw3Kbs2QSCzPEm8y4lD6SS67i8LIU8uVkHD3U6yBaxYpbq gUD6l0ZRwTzKMzwsYaVEW+ouWPlsVHO8ql5W0BKHtkuLGOPDHIcigEcnatTGDkYqaz0ERdll glivaxMLgEk8lDakSRGD1KJ+ysQ68MeIyoXhydhwzDXFtR1GRVD+KMdDoPycO7sVafjQ4Njt um4rXtP83ZlNZLmG/VfiqIOkW5Xs3+BoGUnnYGkJTTV+WbtcuVPG3+tYZO1GTFI401/wjNGu Pi48VoZP/LX3j94CHlJmIeq9qNXK9qU77DwbjkDYFV6KcK3keAjxOswCLrkeQj1WFr3mDTQO SGe1HFkzf1oqYrBObkzMxIA+D4VkLYyQ94PEArCK4Rrq7wsyxSLvWI9ETWDhXI5zLHRXIDFe 4JVGfXvzaoxaHHPHSKLrFKc/j17TFZeXyt7VVAkI5yu0pmuQMKAZVgqxLmisNMrNSGdxpL4W l6/F3SRE2muQ9HqRHOV2lfuWfaKbGqKCOWR5lQwvYHefb2Dd62U/rvG2zc/M+qOsCe57wNO+ go/7VJtzDhzdDOx+NugVHBFNnB3t5ZydXxy4jKHNRYVF6YaNg7zvnnPJRuuaGecX/jUL3qRu atsZz6BvypE7wKiyXgwjCltCUd964EpuUsrNozHPZgAAzIv6FAHJdYsLCQXHQ1PUeWCmyxlf DEKBL+OeRkk6XUnROH3oFwGkcofUJ92wS9Op038JX4ppH1AX8xsySupMyCuH5UOLhOSX3Oxh mFi4DkZ1CmJFODUCxkx1nEEb5AnOiy9xr4eKl2285R/6x780q2EjnYG0SAs1lwCj+fxxzKFO 6O9LR1cG22O2oAYSUrlfwwH5aJ3KvxYm/UGC2CWbgqAztxI2gFUxOjv7rw8SMut1DBx23fp0 91Py/m7xAQOWME7pbo+MOeZNOCCO1IT/4vmOCWRvxm8Zq9UiN+RtOCngtVaQ1l3jeoX5lPwz rGgaD41EDdrKggFDDEk49GoYFn+L47PeoYTnqsywSqjekiPxvno1SDLfF5kibVxvQf0066aY ULzz6OmalBksGGTKZy/SCEaJelcuaSHIOShABFZSIGT9yUO80hlL3kqjUzQckAWw/4CJUq5U v91Ikj3KhEHXk/YiA+AvNanEXMKeFlqwonshLWhEBdfZJW8OMUc/8JiYFZsqiV8AlU7ApWbw yi0bwHZzP1NJRLmr7DmcNH6i7HiyhOlj4s9P1wLz7uAC82mmkiR+uL25u/sLUOBoLLGHunTW 8AHJ8w5pi9pgJd7C5COhoflJurB70DQx5pipDeI2pzwGvT9dv9aL0zugqXUsMpjdVndR+D0F F8Usv3FuTMPRFedYgQLIUo7i7UZng36XvUD6JbD401l/0FOrjvYIYLlIiyxY7TLMF8JZ0/Q5 HZ+may6HF1zWz1ELZbmCAkt700BkDJsHEs59q6/6EvnINfLVF8lXXCUfu0zeuU4+chIqN8vX aqIdLXy7fK3qfvnwCGs+4NJ18yYUpOb4TAN/KW+SMDXrMnXcUQH2xL04ZYqU7mTdancC1VEt lQUUUjK+Q29rpaoZtuuP+sU5xrCDpEP+YJkD1nGDPutSLZHSM35ohD1EoWrjFfv1LS/Nh+rR OlXT+2fKSzgFUMqfZ71AOat7xW/BrIH1uHcPvRtlp69TKT3wxZP43t7bPnyT3DmksRCRj1BS FxkQeK9wJLbXJc9mSLetBIN5kLRbLdHgJWoE0JQEcX3/ZNfN3IroeKrxkNpPl86Fet6tuTel sS650D1piNMzRg5nC+hOBirG/5JZqKu6k8LFBzXYZHXl0crPCdYUGZPVjNWZxRXedBn8NEX1 w7MBABVJJzYtUApIKAPKfDAoJnz2pJ0dbr7rvNk+frmzv+VAEsmq2ZxXIClGvXLVJ1oRNiP4 OjrRtrjgXlDALUhAoEcdqu6MSlOfI9SCQrz4H+cxF42aUpH3W1oUKs9HeGuJZPAZQ8QUAKJG dN9KnqGZlZjKd7ZCXA3zh8RcZUOVOgGwWE+G51meYTM56BxuvTvUcouzUQmMGd7b48PO9uFh neAaB8bOkfMwQkbvNg/3d/bfEKXccZBwHSUVMhSapYt+d4sEL8NFXsUEFhs2j2qBDMgCaHB6 pZmpY/Xxa2ozp2y5xZWIJR51do5e7v7E08Ljmh5VBV9+0YP9BgNt+UW/M4R/bzZjd5Z9rr/k j8DyZ6w2hBvnrPb8eVprjac2GmugPAx8PEjqLbzyZ5w3SpOt3+aE2XlzzdEAaXDpsVp9we+B /dKXeO1NqIWWVmr+UmkSrEqf+jD9C3Cpu70mzwrQ1+JLjROCr987FqWxpb4Gp8CmFyrUmzOI 1tzi8jXTvQYbMKVtuK9wGJgOxK+wfgGIK/hw89WrvYOtbe9bPjBsec+wGmlaejrGbCeUKIaT fMzTU/FHT+1JPUVGoOZYR2Tpnz2U2wOY1cu5mlNi/B7+t3xG6EKLRkXbuy691CeEtkIDytOh gWolPQsfErdOVr1TuaBJ7skRboVxv9p8ZXXRcDbLPU3CNp5BMPfVqUjSVxCUa6CXy6mahj4q mPpP4r3ky4dmlJcyzk2yFfst6nQ+TSdcMGA3XMmMyg5K67V7ycZLzonxg+SR4LtTiNNGIQRw LeDWl3BpHU2j5LC1PCvqrrqGk1GdUG9Jb1Fu2aauK8aySK7u8rIUF+s5NjeqZb6js3lLynRN pRKEg6SyXXgYUIBIGEroCeUFcyfofmMAeLBfcBkvPeGki6JHWTo9h2E05YpDLuqgtIPrxu2V Q1hO5tb/YhVvLHse3HfR8KjXqTGGhyXoQ1EVzeA8faMprX72b7nOwJ3kmk33oDUCt/W32WYu ZBAcAUjslgmYELWK2AYqWj4lqgpiPrtbSu5yIZjfl5K6paLlivYNZ7IR6nQ1Pp5SWs4ELY0W WbGeTaHDVebb9MPMbPUBZtdhGIWTTu5zhxcvEnsFXYOSzAE0xpCV1sVgB9ZjnAz6xZTT0IMk WbwME4srUjxFasIK3eaovmQ9LU3kvjEBn63wzSAbfQQaKh/nuR+Ncls5fN40FaFc5XiSA8GN Z4VRIc6IbLJPGMDdW1BUeCqtord942NzUSg6I4322HbGa7FoPWd5mO+NUaNqBYhqq4/m6FT4 tRMy7OjDER1ZL6Yqi2z3EiP3yhY7RLdWSZDVA0A6XMYAXuow5pUVCHqlihUhfYetNxTZ3RfU knD/tiXae6A0bYTk/uLFc6yBEDYOqivowGi3CAkolxRvQbOZz05Fcb6DUKP9XT5oT2DKJwBc etVXaZHRZr11OgtAvVV7sotG18PRd2rnuoaCH9RWTjMU9ywokSe727eW+N/O5snxj6AY3yld QPy93qkM0raLITUfs5VRNn1BHF8ab20fvTrceXu8c7Bfv8PXG//EpTRe0W2N5Nip7/70agt0 BLpBmp1okmwlLg00TuA/Hb40Tn1seDbF3ZiLjkLXxSL314eHmORzF2UdT3/c9AjHVdDLYJWR 4Ej4S/EsTGW8yK5wzy/1CMPqEczaCok/cmD5Jyhsuug4e9b7bCSAB88vxaX3WTImAFBABFkG ek1Vu8seDfrCyYigM6zyUmlyJCD7X7N87EUJegkHFAZbivxvaHZT+D2nCkTbkAvWYnhsVFq6 n+kS90tufwOD7wo16zz7ddbPs54oz+4lTdaycLIi53dXigGqEvc20LFLF5OLkHEuFFNHMF7L hYJnKpe4OnDxMjHMZiQIfOUAcfn6HazlzmwCWMFRZ+f11o5xyRhdHpu74hv/BiF7OaJg5eMf d446TEPhEapfA3o94ZHhzjtrYovK82eRwNztlydHvwQBJOJY7fXiExO2xoY5Tuxw+83f4d/D kzcH+O+7k6NDYdM0vdJh1dwxqzcgHLtWwnfngBFz1WvemjfVmkxRarNbrLgn/Wy435gbQvBD e13IVO3I0g0iXmt7HQU2dy6nMO3LF1ZshLsxqN4MdoH/K/aDe7ZbEtsTgy7OECo/jm3g3B0c xDcwyEKGr0Traa+5D2+2r2WgN95ZA8Lf3O5kzu76gRL/km32h/AN99tF338IfnQnFQjiT2nD /b6MKvj0hrgyB/7NsaYEzCqlZlsLTKGXdALrODGhzu5liuip0j0sv/SDQjYiqmepb9YWSfx2 00l62h8AYtF9zMWUVRrtLmy5h1eZXJUklbn3hLz705LTJTzNvVZb5kAz8i3OJqKpBhoVWvF5 38t5k6Odb25ZBl2pM6hXocGUXH9f5tdkeiqrOWJvLEzJN6Pjqq9DtnZ9szLxf44bG/DgLFne T2d5MkCj5iHbLsVDPBRELMt/Xenyq5XBRbcXfX9reXl5TvPa67yfvM5Ok+RZ0m6vP2qtr64m q61W+9bS0tJ1sGt7YKD992yQJNDm0fqT9vqTFjf+wx+S5dV2cy1Zgv9+l/zhD7eS/5Lrd5Lv eTQM4/xF+c3FaY+O+aIvf52Np+l4UuDLpfAlL2u0HUaioZUafcmERK9o6M9aOPRn7Wa7TWO3 0ucwEwbFpJtUnpcn9qqYiotUKK7xfvc+Ff/iqJs7tCgilUxz5g6JNBjfX6ewCzTFAF0O0Pc8 GV+SV+4M0SaRsAsE1aE3HXiDtJY4YvStNuGJ4Kzbj5/itNtPHjefBdN+ifaBTDgG3AN9AONg vlZxg4x+yPzWZYFOl0dXo25yMhpSPevifHz5tkv/HKfFRUG/7WXDZDD+SPTaWn6aTLfzYXKx M8AKmoNBOtg1ewTrtEURVWjg3t+8j+KEwufP6RarHp/iU4yWHM4fTcDC49X8XCZEQR9MnVlO B5Pz1GCeSzLVXzlEWf1R7R0MbCvrJo/aIMTXWy34X9J+tvYsJM05IOYSaKvZgt1urhGOq19D HCcS6kOCA+1H9qp0jYAs7K1Zr0jhw1KSIAfRfWN8N3X13XzsrwCfbNgm48kV5yO2nz17lhyB oAXun7zJ08l5v1s0k51RdwUPWjhrsaDEifw38Skk4lig65LJm+KO9nyMQd9qo6tPJTElJ+wc 3IwwLcnDNTv2OPXSuoiCx9TzKEOHDl4/7nRfCDTlL7AnDycU5wbcJUxKsT/oI8ZbwiQ43P0x M6Wh9O2N0Dq2aKESatr61IOR4f+BJ1EnVONEvfhBJyV4fukSgrcaDFoLnoQQedAGqY7U07we lj3piGfptahu697tPbqwsDTx+iFUIx3rQroOKg7+H4M2cqlpr+yoqqjgMb2aZLj3cr7QCYdY cO6kM20DyFtPoOnZqP/rjIwSWBnUCOkrzzmrYNQl5G12WIdmI9JxsOZjOZWmnsIO8EKjUgcC IAabbAaFqGHOGoPPIZz3p3wnMZbTXqg7p6iNcVWZSGRTiAP3eBOZl4ljJn2ucpWKiQdMNGet sHBTaHnqQaO1tDV1JHvKy99w2maSofG5jNz0vOJa9mSBe9nD696T2H3veKrw9Ze3WwaAt+ZJ kDdYXov//PnWUv1vN/g+DkJ/1eUPb3efbCwMAuZbv3MKmPz/HrWa+P+7rTsJxvnmd2DxJ41G BSgHxLXdVY/is7N2zA2tku/Jk6iu7wr1/qOna9dqGN5HFQqG980X6Rc+hEXUiydrv6sXv6sX i6kX7WDQv6sXv6sX13VXpV5gOhXubN9NzjJaQBRUFigVlGtzQxD9yT9fk/gCRaJKj/hqNSKS fRUZQpgOEwHvZwZ+sehM1x5fLzrdj6pEp/vNl4lOD8JCovPZ76Lzd9G5mOh8FAz6d9H5u+i8 rrtQdDpdqlkO62XYe5XseoCw5Mk3EH7BxPMR5ZmKMYiCQ+OOzgaz4jwvFts7BOMNbnJWXA+2 2mMAzT1wp8WEUt++BqbC+HfXAb5MXPtHODEp6n8REdT+BzeW0kHzRUR0+/GT/ygZLUtRUGkV GyDsSjhKHnGm4kvpiIT+UulsTvOS8EeEclzyOLpDvD93MljODWaKXDQiu3/aOXh58tqIWZba pxnME4cgh0bK7nFEkiUxTCfI2swQlHmnnnZjym55fWooufysPabs3NXH3KUAKh2wmx/b5zQd 9dK8F5t1qdNAQWl9Sp+2n7Xa3z1aaz89W32UGTWlLFu10wi83Z0/bdP7EF7XwBv0f8sWgBco PK1Pj11coEFVKTxReKY0fCLjawNr8OGRdZJwuflEsgJKi8zRFZRFB8wIq0GmhYNwpX4PN9+5 43I9HhjZkF5KJcmRvRwJbw2onIe9C0fgrbrwCBbV7TGX4lyzLljFyxuft85OVeMxlkE8mw2k MkB0XVB7wwsg8d/EVwxxqdCjm6rrnwOTr0wFHG9UWPbGG1XLHRWsFXaHLVO6wRa3gooHUeGd yCy5pmrVLsgtjC6lUnJc9aphRL03Pm8XXECYTCPwOYEkCu9E9zO6Cw68pgB7iDWADMSyyYDE 5sJ7WgkPl88rfxyDZ8sT6Pq1HHhyuRcVn5XyMKIFCap4cfQVBsgixgd+jxrW1K1nyKU6Wakn KRWaHyRTkiR8nKXFFZUzKbLhKcYBnMmlydYoxQWREHw9Z8LMjRBSSjbtoD81twtTJZYCu+gL uq89XoamDx+t4j/iWgrhgEwXnlYsYg+RLVT7ShOoSjctmz61BW2eKleZZ+vUvtzIqYRf5Rfk oH1vnHXiFqn0+MM1gG2QWHTsqWh7DhUl9cc/NZOn8P/22k98Dfo1fZh7i+JdAJFOzq+Kftdm TM/fPZvnHB7BctHEL4KGjX1/KRei/BJg0NQDZdGJ2RDdZq77pbKEAnbmrqO59Mw3/RzR3sQE vPQ3kBQUTkzQqOhG+BPcQPPe1yM+eB1QtZ1xuUaJZwLjR0B5Fjw+8MDsb79L5FYdzN/Esh9e ThzQNBIHjDbtiiAdchdc4E/zkN2yflqVSjVtvbXHV24QwARsVkwfPs8GoM3OMKOIL2z2vHf9 kc1RCgBg/v4wvTrNKMGxl17BQDi86gqTk4U1Zsn7tScfgGxExNxO5m9CcLkVNt5Y4HO9aWrR 7+WSqEU/F2626OcSNLjo5/ZKJWlhcUQlEWCbV5itfrC7hVmb8HtHEA6sdcSo5xpjy+tMfwQ/ D4KLziIOCab8CiHOd0GURPgY72PQQnSqERXFuNsnExiwkkSu4R9yKWQoGLWqA/lX+qMylYmI J5UhZWfjGZZG+0+R+CwdtBxzFBcss7TFneMs2FxLUi2JI3DKzHbiixc2iuqCRbC8gb3StAYR rI4aH3PFolyOsmFQkdHMDe3vSLGJTsdxlVEZJOMnk6tcN8qvbXpi4DPzchG4/QKOLzMUX+El rLSeFSyCA7RdeIwdczqlTAepLBfd3mzaHzDiTdLuBSkVWPG4350N0hyWdyCVUaiYJwx9iNo6 VQR1AfcZhE90tMdsSDQ92VqBhDgcBCoqZ3/k7xOKh43I88k0L/4ae4F3kHfGeY80y9Jbcsop O47CJWo4759Nq99K2nZIAfRyyAwu/tK5PSkATOFr9v1nuyzTEBOucX8CW8DVJ3PZD+gP33ku T//VDZydQcNF3Jyr37leTndEZadk/VUD27eA3w+TvXGegoFen/5laByZaAWHrE9/Svnf6gVN B2kX04m6574zdGs2HF4lHMDPNSmNC1PziMlViFHhbHizW2J8xrWGs2K6kghhZu4nAd1wcZdT LoPBxJYgTWIFLyqwwoQ1SgdXf0WLtySQikSpGV1e/HolOTGF6ahPAuJ2rCxADWlu10zyFCu/ JnRx7EXJ6Vxw8WqulE3TZ83tbJB96p9KxbZ8fEpmDw65oCrQ44H1SzOboqR7yj3HJRAi7HGx GRrXm/2T5M3bXeUUxg3s8GHjB3afmfvK/USMdDYd47lDNLtjOIw+5nOK6Cuj3M7NFVnSvCqD 1yhmh1dOYlU0BwDoCNWyCMny45Ba+Sll3GxO8gRoqv14HUjucSuaceO2mZ9os0aJNmsViTan g3jSyzlI/Y/RN+TEvmmCDdaiBM0s+m46vbLJNe3V7yjNZPVps02xgckFFgYhu35AmVMdyhxO NCfEEZ1KoeyPkCrfeYbezQwL8wdaEJqVTanezoogwUGcwLoyhPJUZ+AOkFv3/A4rgHyfF8AA UTgFYgVBiDogFtcGGyalVgSH2M1gPL4o0An1EEb9cIg0DzQpHhZmSFPmH0rpzCaPmAMM0wnB OpMbZUBkeFPEovNUjv1XvMhMqyvS6Hn2Ok2CUoyxsiV0dL/g6tFKmKLO+LG0YnUHF9153T9P 7qltTooSbQ/l5GjtuL2jzuHWwf7uL7BjrBtpHW7g08MU2/Jz3dl+N+uwKfP4AycePXm6ihjx 5NkjSTzSnQd2wucWWa8uEUV/PDk43sR8ox5mgpHO1jkHHlt344Ui7VgGNzRVlItVOEhWozKM ndPZx4Ke20Spg6Odn6l0MjJlKtoFMgP3EoTByf7O652fOc+oxCHEN3tRXA0Due6/cfiE/6LM KlafRFlF0Gwut3hMaw3/jXOL4fCvYK3Hs+TixG1SZa9uyjLOgRBm/V6cneSV2XpnlPyHc1l7 jHNZe9J8SnNxFHosxgHb1OkNU1v5ijR92MO8KZgqebg7W7jjrsaPGakVbZ1Pi0mfi5LSqw7+ STmGvm3hldoNLIv6g16YuNyYZ2EkRBNOgN3ewZacjR3dSjiDVpqxStQBlDgdD0D4Zp8m43za IYWj8ycxM2kVHz1+hMv46PGaMuTtn98eHB53jn7Ze3mwW+cEbgwI+S3rdsCwGKafcCzRr2bI ROi7ovMXoIg+SNOFm+h3fIjEmJPUS6pUw162SJqMmEtgDwFbMaEmfl9O3AN2EH2J9mHlyzAc oiLYMdo2CHd0WZX/fRkbSsMJazoDSlAJGbk3g1Ma5RgtWG+8fg4b5nO4FYGPcit5U+ZW8oLY zgFgHiBRe3X9yVPgPGQIVHArt1klt2o/abZXMSe12X4S5Vej8RTLL+dxRQZ2O54NrMnHN2FX Zo1Zl8H0EnhBtjgRMwAFcht1xYdg7mhCvYavW6Y9cel/NjodpKMLRK5irKn8Pvt41dnsbNE2 x5jJF3ARrnoH8OSNriBXTtM7a8xTVDU2RHUDfttuA8P9rrnaot0AORlOgVByqWbaoyehA4Pp j+r3IqCpIJPWGI+nDCd//3tcmktRoUbIFPH2kYTuHinwgqtiOp64sn751vKXDa8in9lzD/El 2aVFb7n3nphCCN6OOfWT3OdzIdY+O0qPqssJdVAuNw8v/lZJ91hztBele3lTpnt5YbWUVtJ+ ur66tg4MYI6Wos3m0v2TVcpFx39YJSTSKVEcgrIlMMq3f5g9Kvv6TAV7N/tcK6QL3A7VXHnA f9MfG/Yjz7WOVR2byYMR9AP/TJzPEItIZCQPpsOJKLyPeHaP28jdKNUeAWD1HPaXYnt0y3W6 kxk8xZfLL8xFOkRhFRM1uOXMUFDr43g6lrqDPD/UBHr9Ag++egEyCRIBEMP16g1K8ycoDgD3 E+UT37XIxPuuvSa7V/H9uqNnH5lP0KdvPtEc/pcnb+rVNFg1q3Vnb/UGguQzjPL/A+UyzRth HwEA --------------AD3C6227F0BC505FF89CB050-- From owner-lkcd@oss.sgi.com Fri Jul 6 05:59:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66Cx4X26631 for lkcd-outgoing; Fri, 6 Jul 2001 05:59:04 -0700 Received: from XCHANGESERVER.storigen.com ([65.193.106.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66Cx2V26625 for ; Fri, 6 Jul 2001 05:59:02 -0700 Received: by XCHANGESERVER.storigen.com with Internet Mail Service (5.5.2653.19) id <3MLGTJ6D>; Fri, 6 Jul 2001 08:59:01 -0400 Message-ID: <88D2015B3AF7BF4B91272EC25A9FE097691CA0@XCHANGESERVER.storigen.com> From: Tony Dziedzic To: "'lkcd@oss.sgi.com'" Subject: Minor bug in lcrash (kl_savedump.c) Date: Fri, 6 Jul 2001 08:59:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1061B.6D368DE0" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1061B.6D368DE0 Content-Type: text/plain; charset="iso-8859-1" We ran into an interesting error with lcrash when saving a crash dump. While copying the crash dump lcrash ran into an error and displayed the message "Error: dump flags in dumpdev page index invalid". On each subsequent reboot lcrash would again attempt to copy the crash dump, and would also encounter the same error. Each attempt would write some number of blocks and increment the bounds file contents, resulting in a continual series of less-than-useful crash dump files. In this particular error __kl_dump_retrieve returns a status of 0 (line 247 of kl_savedump.c), which prevents the caller (kl_dump_retrieve) from erasing the dump. Every other failure case returns a status of 1, which seems more appropriate. It's probably advisable to modify this line to return a status of 1 to be consistent and to allow the crash dump to be erased. FYI, Tony Dziedzic Storigen Systems ------_=_NextPart_001_01C1061B.6D368DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minor bug in lcrash (kl_savedump.c)

We ran into an interesting error with = lcrash when saving a crash dump.  While copying the crash dump = lcrash ran into an error and displayed the message "Error: dump = flags in dumpdev page index invalid".  On each subsequent = reboot lcrash would again attempt to copy the crash dump, and would = also encounter the same error.  Each attempt would write some = number of blocks and increment the bounds file contents, resulting in a = continual series of less-than-useful crash dump files.

In this particular error = __kl_dump_retrieve returns a status of 0 (line 247 of kl_savedump.c), = which prevents the caller (kl_dump_retrieve) from erasing the = dump.  Every other failure case returns a status of 1, which seems = more appropriate.  It's probably advisable to modify this line to = return a status of 1 to be consistent and to allow the crash dump to be = erased.

FYI,
Tony Dziedzic
Storigen Systems

------_=_NextPart_001_01C1061B.6D368DE0-- From owner-lkcd@oss.sgi.com Fri Jul 6 14:56:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66LuqQ18571 for lkcd-outgoing; Fri, 6 Jul 2001 14:56:52 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66LupV18568 for ; Fri, 6 Jul 2001 14:56:51 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f66Lqes10867; Fri, 6 Jul 2001 14:52:40 -0700 Message-ID: <3B463440.8756286@alacritech.com> Date: Fri, 06 Jul 2001 14:57:20 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tony Dziedzic CC: "'lkcd@oss.sgi.com'" Subject: Re: Minor bug in lcrash (kl_savedump.c) References: <88D2015B3AF7BF4B91272EC25A9FE097691CA0@XCHANGESERVER.storigen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk > Tony Dziedzic wrote: > > We ran into an interesting error with lcrash when saving a crash dump. > While copying the crash dump lcrash ran into an error and displayed the > message "Error: dump flags in dumpdev page index invalid". On each > subsequent reboot lcrash would again attempt to copy the crash dump, and > would also encounter the same error. Each attempt would write some number > of blocks and increment the bounds file contents, resulting in a continual > series of less-than-useful crash dump files. > > In this particular error __kl_dump_retrieve returns a status of 0 (line 247 > of kl_savedump.c), which prevents the caller (kl_dump_retrieve) from erasing > the dump. Every other failure case returns a status of 1, which seems more > appropriate. It's probably advisable to modify this line to return a status > of 1 to be consistent and to allow the crash dump to be erased. Corrected. If you're using the CVS tree, grab the latest copy from there. Thanks, Tony. :) --Matt > FYI, > Tony Dziedzic > Storigen Systems From owner-lkcd@oss.sgi.com Sat Jul 7 10:31:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67HVFt30576 for lkcd-outgoing; Sat, 7 Jul 2001 10:31:15 -0700 Received: from socal.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67HVDV30573 for ; Sat, 7 Jul 2001 10:31:13 -0700 Received: from eswssol002.elsegundoca.ncr.com (eswssol002 [141.206.1.4]) by socal.sandiegoca.ncr.com (8.9.3+Sun/8.9.2) with ESMTP id KAA21795 for ; Sat, 7 Jul 2001 10:31:04 -0700 (PDT) Received: (from kim@localhost) by eswssol002.elsegundoca.ncr.com (8.9.3+Sun/8.9.2) id KAA13670 for lkcd@oss.sgi.com; Sat, 7 Jul 2001 10:31:07 -0700 (PDT) Date: Sat, 7 Jul 2001 10:31:07 -0700 From: Moo Kim To: lkcd@oss.sgi.com Subject: how to apply kernel patch for both lkcd and kdb ? Message-ID: <20010707103107.G16108@mailbox.ElSegundoCA.NCR.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, I am interested in installing both kdb and lkcd on linux box running RedHat 7.1, kernel 2.4.2. Has anyone done this ? I know I might have to upgrade kernel to 2.4.4 in order to apply the patch. The question is which order I need to apply the kernel patch ? I think the patch assumes to apply on the clean kernel source. Anyone has any suggestion on this ? Thanks in advance, Moo Kim Moo.Kim@NCR.COM NCR Corporation ph: 858-485-2233 fax: 858-485-2032 From owner-lkcd@oss.sgi.com Sun Jul 8 05:50:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f68Cocb22647 for lkcd-outgoing; Sun, 8 Jul 2001 05:50:38 -0700 Received: from exg.allot.com (exg.allot.com [199.203.223.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f68CoaV22637 for ; Sun, 8 Jul 2001 05:50:36 -0700 Received: from allot.com (FELIX [172.16.1.37]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NDT7ZKM0; Sun, 8 Jul 2001 15:54:30 +0200 Message-ID: <3B4858E5.2BD748A7@allot.com> Date: Sun, 08 Jul 2001 15:58:13 +0300 From: Felix Radensky Organization: Allot Communications Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: libsial: compilation failure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, I'm trying to compile lkcdutils-1.0.7 on Slackware 8.0 (gcc-2.95.3, bison-1.28). Compilation fails on file sial.y yacc -psial -v -t -d sial.y sial.y:76: type clash (`' `t') on default action sial.y:125: invalid input: ; make[1]: *** [sial.tab.h] Error 1 Please help. Thanks in advance. Felix. From owner-lkcd@oss.sgi.com Sun Jul 8 20:23:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f693NaH13663 for lkcd-outgoing; Sun, 8 Jul 2001 20:23:36 -0700 Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f693NMV13638 for ; Sun, 8 Jul 2001 20:23:26 -0700 Received: from f02n16e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id NAA162554 for ; Mon, 9 Jul 2001 13:19:53 +1000 From: rbharata@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n16e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f693Maa65912 for ; Mon, 9 Jul 2001 13:22:36 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A84.001287FA ; Mon, 9 Jul 2001 13:22:24 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: Moo Kim cc: lkcd@oss.sgi.com Message-ID: Date: Sun, 8 Jul 2001 22:14:08 -0500 Subject: Re: how to apply kernel patch for both lkcd and kdb ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk Yes, 2.4.4 would be the right kernel since latest lkcd is available on this. Apply kdb patch first(as it has more files than lkcd) and then lkcd patch. If this the order, I have seen that only some 4 hunks fail, which can be easily fixed manually. Note: The same should also work for 2.4.2 kernel. Regards, Bharata. Bharata. B. Rao IBM Linux Technology Center, IBM Software Labs, India. E-mail : rbharata@in.ibm.com Phone : 91-80-5262355, Extn : 3962 Moo Kim on 07/07/2001 01:31:07 PM Please respond to Moo Kim To: lkcd@oss.sgi.com cc: (bcc: Bharata B Rao/India/IBM) Subject: how to apply kernel patch for both lkcd and kdb ? Hi, I am interested in installing both kdb and lkcd on linux box running RedHat 7.1, kernel 2.4.2. Has anyone done this ? I know I might have to upgrade kernel to 2.4.4 in order to apply the patch. The question is which order I need to apply the kernel patch ? I think the patch assumes to apply on the clean kernel source. Anyone has any suggestion on this ? Thanks in advance, Moo Kim Moo.Kim@NCR.COM NCR Corporation ph: 858-485-2233 fax: 858-485-2032 From owner-lkcd@oss.sgi.com Mon Jul 9 00:29:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f697Tp500856 for lkcd-outgoing; Mon, 9 Jul 2001 00:29:51 -0700 Received: from nakedeye.aparity.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f697TnV00853 for ; Mon, 9 Jul 2001 00:29:49 -0700 Received: from alacritech.com (w033.z064001165.sjc-ca.dsl.cnc.net [64.1.165.33]) by nakedeye.aparity.com (8.11.2/8.11.2) with ESMTP id f697Vbn28772; Mon, 9 Jul 2001 00:31:38 -0700 Message-ID: <3B495A6D.CAA1B5AE@alacritech.com> Date: Mon, 09 Jul 2001 00:17:01 -0700 From: "Matt D. Robinson" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Felix Radensky CC: lkcd@oss.sgi.com Subject: Re: libsial: compilation failure References: <3B4858E5.2BD748A7@allot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, Felix: yacc != bison (at least, on my system) ... I assume you aren't using Berkeley's yacc? You are correct -- bison fails, but yacc doesn't. If you need a quick fix, use Berkeley's yacc. In the meantime, I'll take a look at how to fix this. (I have RH on a build system, which has byacc-1.9-18) --Matt Felix Radensky wrote: > > Hi, > > I'm trying to compile lkcdutils-1.0.7 on Slackware 8.0 (gcc-2.95.3, > bison-1.28). > Compilation fails on file sial.y > > yacc -psial -v -t -d sial.y > sial.y:76: type clash (`' `t') on default action > sial.y:125: invalid input: ; > make[1]: *** [sial.tab.h] Error 1 > > Please help. > > Thanks in advance. > > Felix. From owner-lkcd@oss.sgi.com Mon Jul 9 06:17:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f69DHb423183 for lkcd-outgoing; Mon, 9 Jul 2001 06:17:37 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f69DHaV23172 for ; Mon, 9 Jul 2001 06:17:36 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA06386 for ; Mon, 9 Jul 2001 06:14:59 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id GAA36897; Mon, 9 Jul 2001 06:17:25 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id GAA38358; Mon, 9 Jul 2001 06:16:58 -0700 (PDT) Message-ID: <3B49AB93.E88B5E3E@sgi.com> Date: Mon, 09 Jul 2001 09:03:15 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "Matt D. Robinson" CC: Felix Radensky , lkcd@oss.sgi.com Subject: Re: libsial: compilation failure References: <3B4858E5.2BD748A7@allot.com> <3B495A6D.CAA1B5AE@alacritech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk That's right Matt. I just checked in a sial.y that takes care of the type clash and the empty action. It should compile fine on Slackware now. Is Slackware symblink'ing yacc to bison ? cvs diff sial.y diff -r1.3 sial.y 75c75 < | ctype_decl ';' --- > | ctype_decl ';' { ; } 123,124d122 < ; < "Matt D. Robinson" wrote: > > Hi, Felix: > > yacc != bison (at least, on my system) ... I assume you aren't > using Berkeley's yacc? You are correct -- bison fails, but > yacc doesn't. If you need a quick fix, use Berkeley's yacc. > In the meantime, I'll take a look at how to fix this. > > (I have RH on a build system, which has byacc-1.9-18) > > --Matt > > Felix Radensky wrote: > > > > Hi, > > > > I'm trying to compile lkcdutils-1.0.7 on Slackware 8.0 (gcc-2.95.3, > > bison-1.28). > > Compilation fails on file sial.y > > > > yacc -psial -v -t -d sial.y > > sial.y:76: type clash (`' `t') on default action > > sial.y:125: invalid input: ; > > make[1]: *** [sial.tab.h] Error 1 > > > > Please help. > > > > Thanks in advance. > > > > Felix. -- Luc From owner-lkcd@oss.sgi.com Mon Jul 9 07:25:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f69EPqq30511 for lkcd-outgoing; Mon, 9 Jul 2001 07:25:52 -0700 Received: from nakedeye.aparity.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f69EPpV30506 for ; Mon, 9 Jul 2001 07:25:51 -0700 Received: from alacritech.com (w033.z064001165.sjc-ca.dsl.cnc.net [64.1.165.33]) by nakedeye.aparity.com (8.11.2/8.11.2) with ESMTP id f69ERdn29431; Mon, 9 Jul 2001 07:27:40 -0700 Message-ID: <3B49BBE2.8E1CE7E8@alacritech.com> Date: Mon, 09 Jul 2001 07:12:50 -0700 From: "Matt D. Robinson" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luc Chouinard CC: Felix Radensky , lkcd@oss.sgi.com Subject: Re: libsial: compilation failure References: <3B4858E5.2BD748A7@allot.com> <3B495A6D.CAA1B5AE@alacritech.com> <3B49AB93.E88B5E3E@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Thanks for jumping in there and fixing this, Luc. :) --Matt Luc Chouinard wrote: > > That's right Matt. > > I just checked in a sial.y that takes care of the type clash and the > empty action. > It should compile fine on Slackware now. Is Slackware symblink'ing yacc > to bison ? > > cvs diff sial.y > > diff -r1.3 sial.y > 75c75 > < | ctype_decl ';' > --- > > | ctype_decl ';' { ; } > 123,124d122 > < ; > < > > "Matt D. Robinson" wrote: > > > > Hi, Felix: > > > > yacc != bison (at least, on my system) ... I assume you aren't > > using Berkeley's yacc? You are correct -- bison fails, but > > yacc doesn't. If you need a quick fix, use Berkeley's yacc. > > In the meantime, I'll take a look at how to fix this. > > > > (I have RH on a build system, which has byacc-1.9-18) > > > > --Matt > > > > Felix Radensky wrote: > > > > > > Hi, > > > > > > I'm trying to compile lkcdutils-1.0.7 on Slackware 8.0 (gcc-2.95.3, > > > bison-1.28). > > > Compilation fails on file sial.y > > > > > > yacc -psial -v -t -d sial.y > > > sial.y:76: type clash (`' `t') on default action > > > sial.y:125: invalid input: ; > > > make[1]: *** [sial.tab.h] Error 1 > > > > > > Please help. > > > > > > Thanks in advance. > > > > > > Felix. > > -- > Luc From owner-lkcd@oss.sgi.com Mon Jul 9 08:33:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f69FXZF03198 for lkcd-outgoing; Mon, 9 Jul 2001 08:33:35 -0700 Received: from socal.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f69FXXV03194 for ; Mon, 9 Jul 2001 08:33:33 -0700 Received: from eswssol002.elsegundoca.ncr.com (eswssol002 [141.206.1.4]) by socal.sandiegoca.ncr.com (8.9.3+Sun/8.9.2) with ESMTP id IAA27021; Mon, 9 Jul 2001 08:33:24 -0700 (PDT) Received: (from kim@localhost) by eswssol002.elsegundoca.ncr.com (8.9.3+Sun/8.9.2) id IAA28465; Mon, 9 Jul 2001 08:33:21 -0700 (PDT) Date: Mon, 9 Jul 2001 08:33:21 -0700 From: Moo Kim To: rbharata@in.ibm.com Cc: Moo Kim , lkcd@oss.sgi.com Subject: Re: how to apply kernel patch for both lkcd and kdb ? Message-ID: <20010709083321.C26721@mailbox.ElSegundoCA.NCR.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rbharata@in.ibm.com on Sun, Jul 08, 2001 at 10:14:08PM -0500 Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, How can I get a latest snapshot of lkcd from sourceforge.net ? I am not versed with cvs. I followed the steps in the Anonymous CVS Access WEB page: cvs -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd login cvs -z3 -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co modulename I was able to login fine, but I am now stuck in step #2. What do I specify for 'modulename' ? I tried lkcd, 2.4, lkcdutils, and they all failed with connection refused message. I am not sure whether the connection refused message is caused by improper modulename or anonymous ftp server is just busy. [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co 2.4 usw-pr-cvs.sourceforge.net: Connection refused cvs [checkout aborted]: end of file from server (consult above messages if any) [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co lkcdutils usw-pr-cvs.sourceforge.net: Connection refused cvs [checkout aborted]: end of file from server (consult above messages if any) Thanks, Moo On Sun, Jul 08, 2001 at 10:14:08PM -0500, rbharata@in.ibm.com wrote: > > > Yes, 2.4.4 would be the right kernel since latest lkcd is available on > this. Apply kdb patch first(as it has more files than lkcd) and then lkcd > patch. If this the order, I have seen that only some 4 hunks fail, which > can be easily fixed manually. > > Note: The same should also work for 2.4.2 kernel. > > Regards, > Bharata. > > Bharata. B. Rao > IBM Linux Technology Center, > IBM Software Labs, India. > > E-mail : rbharata@in.ibm.com > Phone : 91-80-5262355, Extn : 3962 > > > Moo Kim on 07/07/2001 01:31:07 PM > > Please respond to Moo Kim > > To: lkcd@oss.sgi.com > cc: (bcc: Bharata B Rao/India/IBM) > Subject: how to apply kernel patch for both lkcd and kdb ? > > > > > > Hi, > > I am interested in installing both kdb and lkcd on linux > box running RedHat 7.1, kernel 2.4.2. Has anyone done > this ? I know I might have to upgrade kernel to 2.4.4 > in order to apply the patch. The question is which order > I need to apply the kernel patch ? I think the patch > assumes to apply on the clean kernel source. Anyone > has any suggestion on this ? > > Thanks in advance, > > Moo Kim Moo.Kim@NCR.COM > NCR Corporation > ph: 858-485-2233 fax: 858-485-2032 > From owner-lkcd@oss.sgi.com Mon Jul 9 13:46:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f69KkeM16742 for lkcd-outgoing; Mon, 9 Jul 2001 13:46:40 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f69KkcV16735 for ; Mon, 9 Jul 2001 13:46:38 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f69KgQs29609; Mon, 9 Jul 2001 13:42:26 -0700 Message-ID: <3B4A1850.81ACE51@alacritech.com> Date: Mon, 09 Jul 2001 13:47:12 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Moo Kim CC: rbharata@in.ibm.com, lkcd@oss.sgi.com Subject: Re: how to apply kernel patch for both lkcd and kdb ? References: <20010709083321.C26721@mailbox.ElSegundoCA.NCR.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Try '.' for 'modulename'. So 'co .'. --Matt Moo Kim wrote: > > Hi, > > How can I get a latest snapshot of lkcd from sourceforge.net ? > I am not versed with cvs. > > I followed the steps in the Anonymous CVS Access WEB page: > > cvs -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd login > > cvs -z3 -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd > co modulename > > I was able to login fine, but I am now stuck in step #2. What do I > specify for 'modulename' ? I tried lkcd, 2.4, lkcdutils, and > they all failed with connection refused message. I am not sure > whether the connection refused message is caused by improper modulename > or anonymous ftp server is just busy. > > [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co 2.4 > usw-pr-cvs.sourceforge.net: Connection refused > cvs [checkout aborted]: end of file from server (consult above messages if any) > [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co lkcdutils > usw-pr-cvs.sourceforge.net: Connection refused > cvs [checkout aborted]: end of file from server (consult above messages if any) > > Thanks, > > Moo > > On Sun, Jul 08, 2001 at 10:14:08PM -0500, rbharata@in.ibm.com wrote: > > > > > > Yes, 2.4.4 would be the right kernel since latest lkcd is available on > > this. Apply kdb patch first(as it has more files than lkcd) and then lkcd > > patch. If this the order, I have seen that only some 4 hunks fail, which > > can be easily fixed manually. > > > > Note: The same should also work for 2.4.2 kernel. > > > > Regards, > > Bharata. > > > > Bharata. B. Rao > > IBM Linux Technology Center, > > IBM Software Labs, India. > > > > E-mail : rbharata@in.ibm.com > > Phone : 91-80-5262355, Extn : 3962 > > > > > > Moo Kim on 07/07/2001 01:31:07 PM > > > > Please respond to Moo Kim > > > > To: lkcd@oss.sgi.com > > cc: (bcc: Bharata B Rao/India/IBM) > > Subject: how to apply kernel patch for both lkcd and kdb ? > > > > > > > > > > > > Hi, > > > > I am interested in installing both kdb and lkcd on linux > > box running RedHat 7.1, kernel 2.4.2. Has anyone done > > this ? I know I might have to upgrade kernel to 2.4.4 > > in order to apply the patch. The question is which order > > I need to apply the kernel patch ? I think the patch > > assumes to apply on the clean kernel source. Anyone > > has any suggestion on this ? > > > > Thanks in advance, > > > > Moo Kim Moo.Kim@NCR.COM > > NCR Corporation > > ph: 858-485-2233 fax: 858-485-2032 > > From owner-lkcd@oss.sgi.com Tue Jul 10 15:55:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AMt0Q31369 for lkcd-outgoing; Tue, 10 Jul 2001 15:55:00 -0700 Received: from socal.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AMsvV31356 for ; Tue, 10 Jul 2001 15:54:57 -0700 Received: from eswssol002.elsegundoca.ncr.com (eswssol002 [141.206.1.4]) by socal.sandiegoca.ncr.com (8.9.3+Sun/8.9.2) with ESMTP id PAA04881; Tue, 10 Jul 2001 15:54:47 -0700 (PDT) Received: (from kim@localhost) by eswssol002.elsegundoca.ncr.com (8.9.3+Sun/8.9.2) id PAA19250; Tue, 10 Jul 2001 15:54:46 -0700 (PDT) Date: Tue, 10 Jul 2001 15:54:46 -0700 From: Moo Kim To: "Matt D. Robinson" Cc: Moo Kim , rbharata@in.ibm.com, lkcd@oss.sgi.com Subject: Re: how to apply kernel patch for both lkcd and kdb ? Message-ID: <20010710155446.C18259@mailbox.ElSegundoCA.NCR.COM> References: <20010709083321.C26721@mailbox.ElSegundoCA.NCR.COM> <3B4A1850.81ACE51@alacritech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B4A1850.81ACE51@alacritech.com>; from yakker@alacritech.com on Mon, Jul 09, 2001 at 01:47:12PM -0700 Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi Matt, Your suggstion of '.' worked fine. Thanks again, Moo On Mon, Jul 09, 2001 at 01:47:12PM -0700, Matt D. Robinson wrote: > Try '.' for 'modulename'. So 'co .'. > > --Matt > > Moo Kim wrote: > > > > Hi, > > > > How can I get a latest snapshot of lkcd from sourceforge.net ? > > I am not versed with cvs. > > > > I followed the steps in the Anonymous CVS Access WEB page: > > > > cvs -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd login > > > > cvs -z3 -d:pserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd > > co modulename > > > > I was able to login fine, but I am now stuck in step #2. What do I > > specify for 'modulename' ? I tried lkcd, 2.4, lkcdutils, and > > they all failed with connection refused message. I am not sure > > whether the connection refused message is caused by improper modulename > > or anonymous ftp server is just busy. > > > > [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co 2.4 > > usw-pr-cvs.sourceforge.net: Connection refused > > cvs [checkout aborted]: end of file from server (consult above messages if any) > > [root@kimlx cvs]# cvs -z3 -dpserver:anonymous@cvs.lkcd.sourceforge.net:/cvsroot/lkcd co lkcdutils > > usw-pr-cvs.sourceforge.net: Connection refused > > cvs [checkout aborted]: end of file from server (consult above messages if any) > > > > Thanks, > > > > Moo > > > > On Sun, Jul 08, 2001 at 10:14:08PM -0500, rbharata@in.ibm.com wrote: > > > > > > > > > Yes, 2.4.4 would be the right kernel since latest lkcd is available on > > > this. Apply kdb patch first(as it has more files than lkcd) and then lkcd > > > patch. If this the order, I have seen that only some 4 hunks fail, which > > > can be easily fixed manually. > > > > > > Note: The same should also work for 2.4.2 kernel. > > > > > > Regards, > > > Bharata. > > > > > > Bharata. B. Rao > > > IBM Linux Technology Center, > > > IBM Software Labs, India. > > > > > > E-mail : rbharata@in.ibm.com > > > Phone : 91-80-5262355, Extn : 3962 > > > > > > > > > Moo Kim on 07/07/2001 01:31:07 PM > > > > > > Please respond to Moo Kim > > > > > > To: lkcd@oss.sgi.com > > > cc: (bcc: Bharata B Rao/India/IBM) > > > Subject: how to apply kernel patch for both lkcd and kdb ? > > > > > > > > > > > > > > > > > > Hi, > > > > > > I am interested in installing both kdb and lkcd on linux > > > box running RedHat 7.1, kernel 2.4.2. Has anyone done > > > this ? I know I might have to upgrade kernel to 2.4.4 > > > in order to apply the patch. The question is which order > > > I need to apply the kernel patch ? I think the patch > > > assumes to apply on the clean kernel source. Anyone > > > has any suggestion on this ? > > > > > > Thanks in advance, > > > > > > Moo Kim Moo.Kim@NCR.COM > > > NCR Corporation > > > ph: 858-485-2233 fax: 858-485-2032 > > > From owner-lkcd@oss.sgi.com Wed Jul 11 10:24:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BHOBM14246 for lkcd-outgoing; Wed, 11 Jul 2001 10:24:11 -0700 Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BHO9V14243 for ; Wed, 11 Jul 2001 10:24:09 -0700 Received: by esply02.cnt.com with Internet Mail Service (5.5.2650.21) id <3XASWN24>; Wed, 11 Jul 2001 12:28:13 -0500 Message-ID: <1139BB776563D011BFB600805FC1048FC1B352@eswb01.cnt.com> From: Jeff Goldszer To: "'lkcd@oss.sgi.com'" Cc: Harold Stevenson , Marco DelToro , "'tjm@sgi.com'" Subject: Lkcd crashes when a crash is detected. Date: Wed, 11 Jul 2001 12:24:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lkcd@oss.sgi.com Precedence: bulk I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). I got you email address from the following URL http://www.oss.sgi.com/projects/lkcd/download/doc/linuxworld2000/LKCD.html Problem: the crash dump facility is crashing after a crash is detected. Crash dump: Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel paging request at virtual address 0ec4e430 printing eip: c0108fb3 *pde = 00000000 Oops: 0002 CPU: 1471744 EIP: 0010:[] EFLAGS: 00010006 eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 ds: 0018 es: 0018 ss: 0018 Process erred (pid: 1835619449, stackpage=c349f000) Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 00000016 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 ffffff00 c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 c349e000 Call Trace: [] [] [] [] [] [] [] [] Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 Dumping to device 0x341 [ide0(3,65)] ... Writing dump header ...<1>Unable to handle kernel paging request at virtual addr ess 423b1045 printing eip: c012a373 *pde = 00000000 Particulars: * My development machine is a Pentium 133 with two ide drives. * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an i586) * Using lkcdutils-1.0-7 for i386 * kernel patch lkcd-2.4.3.diff * /dev/vmdump is linked to /dev/hdb1 * /dev/hdb1 is the swap partition currently used by the development machine. [root@mill /root]# swapon -s Filename Type Size Used Priority /dev/hdb1 partition 133016 16 -1 * Could not use patch which modified rc.sysinit. I modified the /etc/rc.sysinit to look like this. Note this is only a portion of the rc.sysinit. # Mount all other filesystems (except for NFS and /proc, which is already # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs if [ -x /sbin/vmdump ] ; then action "Configuring system for crash dumps" /sbin/vmdump config fi if [ -x /sbin/vmdump ] ; then action "Saving crash dump (if one exists)" /sbin/vmdump save fi if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a fi Pertinent Question: * Is my dump device set up correctly? * If necessary how to I properly setup /etc/fstab to use a swap partition that is a file? Can Linux use a swap partition file and lkcd use /dev/hdb1? Jeff Goldszer Senior Software Engineer Computer Network Technologies 65C Commodore Lane West Babylon NY, 11704 Phone: 631-321-5118 FAX: 631-321-5119 From owner-lkcd@oss.sgi.com Wed Jul 11 10:55:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BHt4615594 for lkcd-outgoing; Wed, 11 Jul 2001 10:55:04 -0700 Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BHswV15590 for ; Wed, 11 Jul 2001 10:54:58 -0700 Received: by esply02.cnt.com with Internet Mail Service (5.5.2650.21) id <3XASWNT0>; Wed, 11 Jul 2001 12:59:04 -0500 Message-ID: <1139BB776563D011BFB600805FC1048FC1B358@eswb01.cnt.com> From: Jeff Goldszer To: "'lkcd@oss.sgi.com'" Subject: FW: Lkcd crashes when a crash is detected. Date: Wed, 11 Jul 2001 12:54:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lkcd@oss.sgi.com Precedence: bulk Forgot to mention the OS is configured for SMP. Jeff Goldszer Senior Software Engineer Computer Network Technologies 65C Commodore Lane West Babylon NY, 11704 Phone: 631-321-5118 FAX: 631-321-5119 -----Original Message----- From: Jeff Goldszer Sent: Wednesday, July 11, 2001 1:24 PM To: 'lkcd@oss.sgi.com' Cc: Harold Stevenson; Marco DelToro; 'tjm@sgi.com' Subject: Lkcd crashes when a crash is detected. I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). Problem: the crash dump facility is crashing after a crash is detected. Crash dump: Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel paging request at virtual address 0ec4e430 printing eip: c0108fb3 *pde = 00000000 Oops: 0002 CPU: 1471744 EIP: 0010:[] EFLAGS: 00010006 eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 ds: 0018 es: 0018 ss: 0018 Process erred (pid: 1835619449, stackpage=c349f000) Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 00000016 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 ffffff00 c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 c349e000 Call Trace: [] [] [] [] [] [] [] [] Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 Dumping to device 0x341 [ide0(3,65)] ... Writing dump header ...<1>Unable to handle kernel paging request at virtual addr ess 423b1045 printing eip: c012a373 *pde = 00000000 Particulars: * My development machine is a Pentium 133 with two ide drives. * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an i586) * Using lkcdutils-1.0-7 for i386 * kernel patch lkcd-2.4.3.diff * /dev/vmdump is linked to /dev/hdb1 * /dev/hdb1 is the swap partition currently used by the development machine. [root@mill /root]# swapon -s Filename Type Size Used Priority /dev/hdb1 partition 133016 16 -1 * Could not use patch which modified rc.sysinit. I modified the /etc/rc.sysinit to look like this. Note this is only a portion of the rc.sysinit. # Mount all other filesystems (except for NFS and /proc, which is already # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs if [ -x /sbin/vmdump ] ; then action "Configuring system for crash dumps" /sbin/vmdump config fi if [ -x /sbin/vmdump ] ; then action "Saving crash dump (if one exists)" /sbin/vmdump save fi if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a fi Pertinent Question: * Is my dump device set up correctly? * If necessary how to I properly setup /etc/fstab to use a swap partition that is a file? Can Linux use a swap partition file and lkcd use /dev/hdb1? Jeff Goldszer Senior Software Engineer Computer Network Technologies 65C Commodore Lane West Babylon NY, 11704 Phone: 631-321-5118 FAX: 631-321-5119 From owner-lkcd@oss.sgi.com Wed Jul 11 13:19:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BKJ6g19867 for lkcd-outgoing; Wed, 11 Jul 2001 13:19:06 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BKJ0V19862 for ; Wed, 11 Jul 2001 13:19:00 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6BKEus00434; Wed, 11 Jul 2001 13:14:56 -0700 Message-ID: <3B4CB4E2.13CC5787@alacritech.com> Date: Wed, 11 Jul 2001 13:19:46 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Goldszer CC: "'lkcd@oss.sgi.com'" Subject: Re: FW: Lkcd crashes when a crash is detected. References: <1139BB776563D011BFB600805FC1048FC1B358@eswb01.cnt.com> Content-Type: multipart/mixed; boundary="------------54807A0F5FF113195BBEAABE" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------54807A0F5FF113195BBEAABE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey, Jeff. Try the following patch (instead of the patch you are currently using), and let me know if you get the same results. Also, _before_ you upgrade, use 'lcrash' on the system and determine what function is at c0108fb3 and c012a373. I don't think you're dying in the LKCD code, but somewhere along the way in writing out the pages of memory. We've made some changes to the way in which SMP systems are dealt with. Let's just say that leaving smp_send_stop() out is a _bad_ thing, while leaving it in isn't so hot, either. This is a test patch -- not for production systems. You also need to modify /etc/sysconfig/vmdump and change your DUMP_LEVEL from 4 to 8. Also, can you duplicate this problem, or were you testing the dump process on your machine? --Matt Jeff Goldszer wrote: > > Forgot to mention the OS is configured for SMP. > > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 > > -----Original Message----- > From: Jeff Goldszer > Sent: Wednesday, July 11, 2001 1:24 PM > To: 'lkcd@oss.sgi.com' > Cc: Harold Stevenson; Marco DelToro; 'tjm@sgi.com' > Subject: Lkcd crashes when a crash is detected. > > I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). > > Problem: the crash dump facility is crashing after a crash is detected. > > Crash dump: > Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel > paging request at virtual address 0ec4e430 > printing eip: c0108fb3 > *pde = 00000000 > Oops: 0002 > CPU: 1471744 > EIP: 0010:[] > EFLAGS: 00010006 > eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 > esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 > ds: 0018 es: 0018 ss: 0018 > Process erred (pid: 1835619449, stackpage=c349f000) > Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 > 00000016 > 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 > ffffff00 > c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 > c349e000 > Call Trace: [] [] [] [] [] > [ 0107334>] [] > [] > > Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 > Dumping to device 0x341 [ide0(3,65)] ... > Writing dump header ...<1>Unable to handle kernel paging request at virtual > addr > ess 423b1045 > printing eip: > c012a373 > *pde = 00000000 > > Particulars: > > * My development machine is a Pentium 133 with two ide drives. > * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an > i586) > * Using lkcdutils-1.0-7 for i386 > * kernel patch lkcd-2.4.3.diff > * /dev/vmdump is linked to /dev/hdb1 > * /dev/hdb1 is the swap partition currently used by the development > machine. > > [root@mill /root]# swapon -s > Filename Type Size Used Priority > /dev/hdb1 partition 133016 16 -1 > > * Could not use patch which modified rc.sysinit. I modified the > /etc/rc.sysinit to look like this. Note this is only a portion of the > rc.sysinit. > > # Mount all other filesystems (except for NFS and /proc, which is already > # mounted). Contrary to standard usage, > # filesystems are NOT unmounted in single user mode. > action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs > > if [ -x /sbin/vmdump ] ; then > action "Configuring system for crash dumps" /sbin/vmdump config > fi > > if [ -x /sbin/vmdump ] ; then > action "Saving crash dump (if one exists)" /sbin/vmdump save > fi > > if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then > action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a > fi > > Pertinent Question: > * Is my dump device set up correctly? > * If necessary how to I properly setup /etc/fstab to use a swap > partition that is a file? Can Linux use a swap partition file and lkcd use > /dev/hdb1? > > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 --------------54807A0F5FF113195BBEAABE Content-Type: application/x-gzip; name="lkcd-latest.diff.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="lkcd-latest.diff.gz" H4sICHa0TDsAA05FVzQuZGlmZgDsPGt320aun+VfgbpuQlnvl2PLTU8UW07UyI+V7fT2JDk8 FElJXPNVkpLjtvnvC2CGFClRstN2997du2mPRM1gMAMMBsAAoA1rMoHKhTYPwLbc+efaqafP HdONtMjy3NqJ506s6TwwqzPT9gVI1b7Tja1wO5VK5QnoCmeBBT0/gGYdGgfdZqvbaOJzvbFT KpWeOlfhZjaHH+c2QAfq9W79sNs5FEhevYJK86jRLh9Aib8R+6tXOwBgeO7zCOauYQZhpLkG 3M+0CKKZFYJjam4IXgBaYILrRaDBnRm4pg0zTcenMvx9HkZAWGxTW5hgIUiEnyEY5kSb2xEs NHtuQn94Vt2BndI7MVoPtHAGxtzxw53SyeXF2eCN+v789Pb8aqcE8JMVzeJ5UpBgutrYNo0y LKwgmms2Ls/xgge4t2wbxiZDmQZEHi7eJETUgAtZWLoJoW/q1sTCfsuFmhnptfAh1Jl5tYVD kFWAGyJas23vPoSJFxAO3wujykSzbGQxaK5mP4QI402QFYggMh25xPvUog1zPJ9OLXeKa/Hs sLpT2gFJeTj3fS+ICDsxBcaWqwWWGe6AZMPrwcXZ+Y2KfcRVAlH6n019HhHtQNsztNw7/nHm BY4WFYHWTAjxB+O1rXHASAl8x1iV6XPtzpxYOD4lU3FbSlbjpqVcvoDGYbfxots4ypXLZMBW GWwcHpAI0tcLFsCCYFrtLnxwwqqN4mS5uj03zJpYh+45PmKtzuAjAi8cboVr5n3V0XxurkaO v49PpQLxOXrwkXhqNwJrgWJd02dagJjc0LNNHKOidEZju6pDDLCwDNOr+YHnIJQq+vIQOEjk jPZ7rdMInNp+xfEMHsnHrd1CGkvNdluSOva8qAuSBBz/ak85773rF+HkbNh7c/1yd08RT0WI n9R3/dFFf1jchcoJnkJ9VttTeqOTt8UaIcMjVZHoujSEReh21LsZXF6gXLhWVHM0y6164pkW izoDf/KQcD42rABP4B9CsWR0BhkU9pThKREwHFy8S6h52++dbkVH/CxUKqiBgqgyDby52NgC LWnUV88Gwz4ikoztCDXW6ZQbDSFEhYqXYuyecnFejH/D7zANTB8qC3j+UZHiZHwsfvz9o/Kx 6u3tiUf4oN3ef4K4/WPVncZdw9712w+j4afTwcfic0QX0gn+ISWDsWpjfnQFaXfx76qHYvnK msAHqEzW+uDTMakrl4W34CzWARLExwwzsUid4GFB4u7CLlIbOAKxODVa6GCbAroRN8Ex2C5U QtRZoVOR8kPPReZmq1knbraaB+UjZubOyt50s7/1jQc0bpdq9bw3Qunl7Tg5WYr0unBD5fT2 5lo97528HVz0Xz7flWvcfQ4VHSprspJdDrKjtMq0tT3QNyyu9Pji9pSr0SXK3+DiDa50ihI6 DuW69vZxNXvfJywTot1N/dg07xOYkp03M9+aTmfNoNn+TJPzVNHKpXRzXn9K1+d1F27QbpPe b6DeJ6XfbbZz9X7+4G02oHXQYInDL6EYUaaB1aMNz8+1qaXT2Rr9gvb04XlsGM97bwYn6vXP 16O/7ZQE6LU0pmu+Auiar40t24rQCiYYpIeRzDQ0p5r+EI9mzQOaYQRmuBzTG1697anD/pve yc/q9U1vdKP2Tk9H/etrxLNtG6RVyzO2m6Hyt2QFiA3ymTkGOIJGo9s67NYbj23MKortJppM c6kRG+gdMD8Tmyve+O8hdF8Co1SFvfbIBGFH5QG9FepExzR4QCmNAs0n7YUmVUeG4pMXTlR0 mej8Br+IT5VRsfYv/Xkk0o0TtoQwhdYUHTZsCM1oTh0+ItRNQmw5Jrej8p55AT2vUgXfPmV/ BWZ9O9sl0NbdlTC8uedaANCkzW00u/UXT9zcGMP2o3dIzkiJvhp13t5vTRfphNp+4oEO36mn /ffq4GJwMzqF/doOfKFdttwIVJVUG+lb/PjWmuClYbJyvEoxjEC8A742NVUrVAPNUeYu7Qk6 4baH3rE/cYs78BvuVhgFcz0ihx6VZRip8vc+8E8zOH7KXghpeWQvJNDWvZAwzEk+aIeAG9HB S1m+57sdw3Iv8E7X7qTOGXsxjdg7/DY219+LdUXRQ3X2w3q7Ydpafk/o+Krt6XfUWVrtlKeD xqVHohtQm9J50/wVnNQz13Q+eNjDjleT/a5WLDsp8F08o5FXne2SL4SSkSMY5mfcSRcWnmWA sk+rUSdzV6drrIons6iQHw37ZZC770dqYE5D2C8eJ9KErg+N3wHDulPDmXfPIMrqCPosQ1ba 9oMjtdFhgeOT0DgUbg9S05FO5P2MVLXSwAmhgEJf0OdBgMyp/BDNAlMzqhNbQ/S/v0SY2yF8 /z0ctHhxufQWmESTb2+mIqkr4lLLQOsTVNmhmT9ePb88vR32EQ2eTmWdW0gGOoxr7fnzIDEJ B+NzWTA8XJwVKdeDN9f9N++J6C9Ps2pSlh45ajHU1rMWAxV+wn06NXVoNSj8QZqrDo2jg6PH D1uCYuW0oW1sLk9bvVzHw4aSy6Jbqu3j7X4feojNikw9ouu9jBHooDD+IsSM5WgAXbzxNpGK SFQJBaNpVluxH4E3QMKhiXHjhy6q8yiC0yqMPLzth54LyoN2h9CvcNKxJ0hDJ7rImE48/yGw prOIVl6HGwLhicswcPUqQM+2gQFC3N3QDBamwesA+qiRMyxJu5mZMPO8O7F4WjBHJLBVrnQl jBJ5eKjCO471oPdIASDGQw4Dzes+sNkELUMiRR8cDRWACLusInVMFEfXCp0y40KI0AS83UWW izdHh6JHYxMIZipCN3PsJzyueb8cLDhdW1dqwrnPU3eT/OalFlzrchxuJv6RMxihHCy0wKJQ S8iTy0Y+cjPUBmagoo5Uo9WW49QmXGiO2UWzySB6HKuTwIrY8jOUsi4kgTwmn71YASVCSxpu O6pYH39zSC1hCZviTROsr3XfmGnrGpb1xE7pt1hpLYdUEV51yCdX3bkzxulfAqun3vW59Mkv bs9f90fHG8bKe1p62Pv+6HpwefHIQPkztH41cTB9eZN1gorM7QLumY4nh3mHxFjkNISAmhMb HlikkWtod4hjrFCZYqFDyevwHxSFDdN+8dnqJLwahi8TeEGhQFIEElyYGrm8LF+LserFzwC9 MzR+bFtKXzZJyH2AyihPOm59Q4uEaEipsFwR8iPeJhKi5akzRiP+pQblyU9memFHDHLfpGis MErhPijl7U1UFMzK8urZCmfLm7dV7uvT2EYOZ4ZdA2ywcMN/XZ4mUn5S8ST3CRnxpf9dvDOS KV6yKnoeohYiOA0VGWtEEy0CsTbmHbsipfQi5sjOgzaeM/TDNFsVWlDlu6VkIkqqJIplUTxv Iw7PvJsh7hIblkpCxreV3K0vZkhMUUfEfj2JvBQp43yrlV4cPqK3FZMeE43c/6M0h4jR1U1V hNgz1J/iVc3NCHolsdtiGO20xydfhuhzaVmZgvr+6GrRDs+d3MWOuCe1FLYsbF83EnGP3n3e grOzPGm9+a6c1To84PDx5ujEOsiqE7cOkVyXmk12vzpbr0sbxm++uDYpY1WirzZ767/alu2l Q9Z9Cpm9vry8GaBZ6qOfX4hjrnvK4OL6pjccqle9m7fFmggM/5qEXp3FRpAN7VXPNo45bLVx klSGYss8KagNXfFMpY0zLSPxWyZaAm3sSRGFvl2GmfDDJk4QMK395vLqdDDaShCSkAHdvKSE rZ+hFqLTXKO9TqhbNh0D3Z9EOo9+19C/jtAOHsuIovy5TUoqBfTmcZ5qPLaKv/cUEYQd9Yf9 3vXKkHxid1do2EVq/xrMeQxbnw2p5WRjbTy3bKOb/oE3MAo3v728vhEhZ36SYWeKKr+Cve+h MlhOJD3jR/VHirDN53sJtFmHLGE47PwjKkdoQb3V7bzoNg/wHnjUeUSLpDE8Kbh5KIIuaAv3 GlBJ7kTCW5UdzWWH5ZCvw5pQ9LWWfbRLQkdyTxt74vS3XBb4GnpoytjW3DvySgNcMt62AtT9 aCpRjycDJUraZoFTdHW+Hid8ywEauMVLIi7xAWaUoddAx0uX5yRYQj2w/Ejm1SgUUmoelJtJ fAfv5NlZKxBqdAuka9+dKdQwhwdj7dRe1a94xkghLduXj6Ry0AWNh3bWhpZ46LJ9+chDxTlP z72udpPp02eqnVKvmQXkjI/XkB7fSY+Xq2Cl2SRVmdCHjT6JSmb2zHxryjuZLqUeO1klvVPi JGBpOWHCFWwUE3YyE1JjO4OH1eOf1rFbFMTmPFS2O1cpLBNJ6aqYQ9QF3UbnEafiqUmow3q5 TZHwerkTC7vIC51S+QbcOVQIotfuJoFpJvmg0/7rW8pFDYeXJ/+6jJXpGo7pzrex+7F8Ux5Q Luvzsk0Ul0NnrtHutjrdNick6ps34K9LNsl0kKNTeseJgoC+QvrU/bll0C9Lx7ucZ1AGhyZf S0sVcPwyfZRO+CTZodVsk8gsLZzDg1Rm6s/iySSnCkkiyjpsdo7o2yOqqTLDiFIJqzhP9RCq RF0yXLcqhqOt0Ew/XuDXmMJDjndHIw3HUkNdc5kjj4tPmBvVXYPYJjihCMWiFae7QKNFUtNo ddutR45tdng2ktvuNlupk1vnxAl9yfKPOFxHUYaJPQ9namSPVQ81WRDCStIJJcfRwrskBuY4 SbbJccrEXfqXHbPQOG2wKc5PAUMPbSKiZkNLlXJjE4K56+JdtFqtwvCna3E5y+K1fEulxWTy G4iO8pf70APdm/t4lvEyq0Qeo8Sr9cI0imiDXSt6AH1m6qIIBPZlVqOFnk2JkhvynlTgDB7H vL6RtNPdqIB6TNmSu0CariVNIROFs6Pf4PumgQTZFpp+tD4pBcaimiaVZlRiCuFlzHh4Rk+q 56IUmNjnF+HlS6gXKVqUXF1FXkSsWtk88JsEa5akOMNBw5ejlQZlbChJJg+yF6iWoRSL6cGS U05cHNOqi3tnuxE7RQX8XwiZ4yBZjnOcNCw0bFhom7mqoedl6Soeb+ZKwp4yPBMYYnJSPFgd kwhw3hBJeCxCP5nC64tIpbgGByIGVwNAJlLAXwCdXN2GoE0m6DhSLkFIzCYKCI2KKFbXP7h4 3xsOTns3ffVm+Fp93z+5uRylycgOTIjYMk7QgkNlWi5LLu0ZCimetRkdMgq43c0pHEYBFQqK Gh66TuIo8mFDZWAiZce8r21Ou5barST7JxKLLB681MAM8XQZc9tUKPON0z6mA5iphidKZynn 4rkVklXB4JzjH4vmSymaNMealB/LoxTTLWLWWW7Go8sw6l+fvO1T4jDFSpH9y9uGRwbGe0Bp QagJDdOpd0j7dlrNuICTWKajs5TkIRVSFCqxQWXcF7fDYRkaZTzlxxLenTsqq5aX0DimlDEx UAYgOTbJFbZL9VKWZcqEmYE4vgq9q8GJ0G+qqtuWOMCGFVLSRhUhWAIR7SoqegZ5kh2kW+Xj tlBAPWIPBdCfsokxim2uVKdDIr0siiSxzeM11Xq8tiIWPWSzzHGj7AqhW4prvqgvPButLR7I NWHOSq2UuEeh4mOOq8KDrs9oflD82UNoJVs8OC3SLTskRSaAbG/K3QQsE1MkB8niiPjP6Btp vqVbhhp5xIIPFyMVB1x/eooMbConyYHZtv9xKcg5qiQq7Gkc8UUGd7/+tN3fWEtSr6fc6COu JTnaUEsi/c28ohGy20Fuj0yIbikkWe2iFMjX1qz4lhvXrLAQc3l450VcYiJ9MwO1sZo8c0RC RVf5wycU6t/wvzoqF/hSznsiQ7HeDF+O/+mVKmSFZSJ+cHqDlpjlFx0pyptVNFucC7LNluPb 1kSkL6/wMFpzh4ee1aF+BnQdvfeCOy3w5i66X4lZ10SiB48BFQOjiZ/SiyEiliMMXBNFIi5v IVZzfZCKNxPlmWGxirxj3egHeGDulN3vwi58V2/bnz+6u0xeGcwgQKNU/zzBf0J/y7IbkWRV ZI1J5d+1DIbZMnc3MCa3SIY9iDbfQtokqgeyfihh48X5AH7SIn1meFPpkuBODy9P3t1eoZol rfWdUV5mqrvMbrL/x4wnn8XpGeTLDBDO5lEI6Pig741Itnj0hexGZNd4Kte4+5WbUti6LXkb s2leAV9ItqqQu1mFgiRc5O8iJWbYchOVZy5eeplPy20s5Gzk4yZgY51THtA2I/DHqpxyMWTN QKvVbRyuFzl1Wk8ociL0X1HjdBKYGklxUtK0Vs8UTq2kkGmlmKlxdHQE15Zt4fbBG7RoaMRD WdK0qaLpv5VV/3mVVTmpfjRkqo+L0UUpZzp9fs13V1xzf3BFJTt4yRA2ctSjygY0gxSZ8LUw FOn0Kb8YCegCokuTm/RfmSy/PmqZV59x0Y0X3+rKaIoj0rQ57vHZqHfeV68uBxc3/F6JyghV JDP2SVVV2eV6I2+Bx7etfPedGfrFMuC3jvZ22cUN2F5HhU6tXdh9Od1FNTvTKj9QMZJp+RQv SWnpR6f7q2YT+nhjKcS/RYkbxetiyeJVJDoRWVRDcsVlfTNL8TI1s3M5GfrbOcyjPT9u3Mjy MGH5hmWIJYBEIgHzZRwFegseXkwaTxzMoPyji/qGY4yAto2V0wNlje7N50KVzTm36BlmKuQn KuuePQPlG+pWqVs0FmNvLSaTWqtIK0VAMvfEoijQgxI0vrqG7r/FYP8pxWBCnNOxpAzpP5KN 40j0CoxQ0/emjBnJeBDTQ9GEFOX8ursp1LspEtukf7SlQ2QuTOQGRRkIZx1ZeOHdpzBwsE91 yG1QpbUlA5H4L+Jfzw69Ms+xO7OjXU6mE+OkmZ964mXxFYs9TosgZxj4zVNvAuTuUm4hdjhi Jw4BiB4draEoFwPS1tnF8uvirudWkC/B3I+shRCeeJNTyZSdUs4WiFpOGuI8yC2VAVJWHnIq 4J2M/+3DiDMXYgXIzW66U1QGzanKdy04nyikVPyPdgNv8WQoQpQ12ibXu0/schwuZW0TT1LQ bVML1DEeS45JPlvJJRynQJNYIpl4qKd68kOLiVlM4OQKVEOLtA/rRH2qohSodKUPVe+umOJF jABpUo6PiyCVtsJik1kkUU0gUj3+nyyljBe7HiFel6uVMHFmbDaCWfr/UqPpOCKituH+mXTn 3jyT3pU/LNLodJuPRR6XY7cGnNsNjjjTV/we/heRLNgQgyA9kXodcDU1S11uUExCx1ITWSIs /fTBIlZA7xXSGOt4c+pbO2hvK1TJdK9xOdP7da9Lr47d+ldbXoi/dvCi/b/ytrQY3NcCvHqJ 4FPyR0zQR/tlbqHMw/s3vW+KydBBD01/vzca/qxejfA+9C7GckMHAK0U/ckAvAxX0PxWzM/S alKUk31NUjpKaHv3qyhF8c3J+dX/nLx9s4rTCn4Rf3hFJsW3oRggV7ZIxKO1NDlAudKRVwlD MoL7TC+UNmQtzRYZ+bpaGv57I/yZ++I2YVx/b5ve6NZ9K1XAMkX1Rz8nlvhERT0fU31Janzq /Wtqlo8hpVvoeRGl3+r+502Rfefb0fTZwqRenytylgU76CtMnH+09+1fTWTZwj/Hv6Lkfmoi ARNAVGidQUGb2zwcHmP3tV21iqSQGpJUuioRmRn/9+/s13nVqRDUmTszt1mrW6iqs89r7332 +2DxCB16U3JquBXJQ1E3DYRlksch+Ib6l8geDsuZjtiGj79fZaM+rCtMWeKNCene7BzsHO2+ akWLz60hZjlPZQ5UrInL8b+YhYQmsOarMDAYl/N4Y9XKZ155+gQZ1VPtvDH8l+WVTJ3gnc0o i35wznX1ZHGxNcO7DudnQv75i+lkAhyin1+NSBKsCoCkiN7NSA1VEuPz5xD2AL6/+Pjk8K1S RBXzVWCmqR01gc0yiCoJBImQmVm856UaAkQGtJW+wNnCN+9irUex+s2snbQdgl+1l7UeRTmy MPLlCRzqi6vaveFmhmfJ6kogYVwv2uxk8ttkp5+Py6uE37BEgI+Ujj1RVK2IGWw+3qN/vHMP 23OtA2QM+GvEQh8nma8jRTxZ0T4442d7f6//YSO6V0b3Bn3y/kiuuTodh9af46xvPHEtIiaT +a69Nf+OvjcJ0Qpm2d+PkHlSvoQ6uCHPAYU6vYjgqMvOYxZoCjVJSjUVhxs7xG4mzHo/T+Cj WaT5lX6eEIRKMnv3ccXP83QuN4+C/o9186wsr32FjyYZJD3IN+1dhHw0TXVcop/mNu3ZO5OV UZlPi14aQWQwGDyKVGn/pZoVljlEXe/NwWn05u2eqHG/O3f+Ec6dfxd3AIYW0jDURlxbKeRg hktIJyknecGGbgW5uYCNitIymmt/1TjHk0h2V3qVQGMAoY3g8vI5skrfvFFO8dC0zQa/G8D/ rxjA/wVMeP/Jljap33kGYSJBdT/8hSUBhD/wkmY6T9T5HUyaqWk+2x70mIpfspbvqJtSu+to a7/VUNpmUdVI5ZO9Q6UHwTeDPB/XfvX2eAU/GpcradnPoJal8x0Jiq0GfCO6eA2on7cR0ufw kF69/VO8vYVf9Ma/JUWh9r3uu1e7x8fwcQQKda+XgYZ/0+6GRLzwF7W7e2vhrqa5u7vdZxvd J9UInpWn67ZsdwyVmZOi7zt8/vWidjBahkcEwTvfGLUjgNa+XbQcTYrsbMqrVuTD6PjNrprM y/12tP9qr43OQMoZWv7GgCGnZbcyzhlNsfl+cq2kO/DA95NrcLZTfWt1XBMnz6Dm7mQySLHm DXUEVGw7Hv/viLRgI+CTLSSfspU99KpeDKZ1Cb7SocyVN0WKUfq3EKtrIqzLq8SXtee3n1Sh zaoKWDMCEAnjmkEjFgQ7ui57k/CiZfnZ9LxmAMko3IRjyasbCtsWhpVDuk54bIr2R2EsmE7K kZJfgu8uFG0NU9FwpODlEITH/1K/gfSs/mgm7bOW+CubzWbS+qF51mr9Qf2yAb9YZiMoLoZ5 8yUIpidHpzvIds4TyLEGeiOofTvADL5Sf0xH1h9iSOFBIKCuIg3d6PXW3rFpJX95zfAxOLjv LMKBBdWhQFjnXyG0XklQHQjNbXKhJi7kpAj4KRR4Av84j7gZx3u7Jyd7O/HOwfbu1kErwpgj 51nbjld7qU506zGNjHp7u/VmJz7+cff1iflr93929B/7W8c/6T8OX78+3sEP1US+2MXXTqZ4 Y0C5Yc4loBKlI0RLyBRZW/C5InMs8CiWyHUnudEcLLUBI0gGw1yxrmSgBNWSlL0iG4ICAVSs YBSTTJfb0kOIB+mnFGopQINkmE9HyNrT83Pwq2lthhA6Ki/y6aBPeAPZAkrL9EYROaW9cEJw cQGLBHJtgUyC7mSAdISRE8si2pAdgaKY/BnnCmGzDS+yhX86nzsb6h+ljnBCXlv9Iou6HDXR nHhweLDTCrXtQtu3YNWj5Zb523PiU8UyE+CJXQXHP1jLDC6koA3UjWH3ad9lWFCbfucoOLAV GNg7hOQMjO0UQLpgphDjl4U3y7UDo07BrBnscu1WXcKfEGVX25szJun89HhnO9j50/k6dwiE FOXaAbCm16QBt3G07QiKKrT0eLb29sJ4AUh1QhLJZZqObdWRs6ujODmfpEUMYU/IP5XYVDsW IXIl4JPPqBIEZdZIIev27vHR6duTVhjlT3hxmJbxFhIp0aLG2/UoHnzeUFo8plVbiq4uUhA2 66hdyYzpcAygaqcTRQI0SpPehb0tinLPwVqVTfjyFCKEGaBqSIQ4hs6lFftINrieAQvujaEh 4VgUABkoi7nqcEMfAfcWwwH8HioZKdb+84dNBvPoIQmAGJZ3XjHy6B+KWgvZYTbtUTE4/EQM dCGwAO4SRjWR8TlgPHBJD6VcaUAwOCNRj46OTRwWhrAoaciH+YjwhHdven6u2gOSctHF1l1r ssAoLdTj0prAUja90bFrhUDT1+6PA87D0ecoV2wyOI2v4AdHknSxDwfugCuxFBGavrzZQgQ2 vsQCkPoABsSrHx2DU8dRWQsOXs4JLhuBi/cjTuA5iUKbGtwVFMGhMGdmGm33TwIXcYSkVL20 S8Fu2sOzBQObo1aGV7Vfe082NeIVvQtjJwsAtcjiEgVwxkD83Rkdv4Z1K5KraPfRodYB3dGh /ArKAQZyZG5hXDGxg+7Qz4oYYz24TyhO1ebf+335rTeW3wabc1Te1VuXXyq9uLJnEPV6xbTM hz5M4Q+VNWZwxIHGPUDc91rI/CD4zjQ4LenOKOw46feRNpqtKjg3HM2E4qM3U6ZHzmfFL9wJ sk+aQtwgch/0azWHIONBBAD9m3k86Z32BBkcb4hSoGNWcvjwlD83NfXQmWrLW1VwMLqHZ4NL JOj3HwJjAx5GDBBNXkTcvWTQmw7YbGOB+zoHvLuKxgzmAw65IaB94JuqHd+Y760mEV2AMLfb KTz+QP8h23v4y4DR2/uwzMDLAvsoM1IfozJX6f0hV7hC1S5W1Knm53+Dxa/cGr7mCxfhMYc5 hRztiZJfuA3vJP3zsK1bcFdRKOAfQgBiYiL6iPPcCEmfGapiRBBirTk+fe1FsqO/sB40DQ6o us3jfYgeqrYSDs5j0MvO2xLjDopamwhBacNtXhMYghUJr3YT4h0IFjCi53g2kmcP/l58HpUY w3DeVH+2o4V7kHdrhoThEgqKagifL0lzfLb0HEYkVUHgyQ80Lg7HgIFxnHTDfAIVdsQv0sFo DCrrhk2oKwTCgRoNWgIeebQoXYoDUrUIuyBxElRG2ltnawNJwfiqHQyCdomX/G82/hEnb1fr r9B2VjYRXUiMY6Qra9OrFs3Ih2vLYFAmpuVRAfccMZI9bN2XJxjjrteTNrB+RT3EdeW0uYnD bTYvlXid/UuRizu2/zS6cWc3LwHNucuzO/veJBVWL/55JKPEkjCZ+Mql0X3R2sG9ZZM5qQX6 +UdQCORGTQr1S9NWmTnyxKvLTz27p7bdqh0xGv6b0oW/l6696ps3NNDbdyYGjooWnqe5nSVG l5eZUmI+qYNmoPAL9M0rCI4ox0mPlGz5lmujYVcQ7ZyV+E2TB9VykuDkZ2lJNsd/s7hI7axX lHuLVfGauHvPhTZbcfwxncQgI5JW9Ob1W7m+UHJ9eb2Xdg4O93f2TS4veC5j8MLGYBBsEs4K pdNsVD/gXOFV1Apai67VgAE9bDI6UYOlqIvFBB/8Onog2Bv6gjFWXxwCJk0ruMjGE5C4BxMO v4LodfMdXowhI4FYc3u+hj05lCFvs/q0PVIJ0JVGTisH139UY+NUVgxausKqduivA/+bG0X6 SPDf8VqQzzbti21P545i/Tq1oSWuiEJiDMPzr2cWMGcpxsSlE3acQ2O0mkjCAHkD9QWYJceH xHiT8fsPfoqsOxZ1VKgWVM1aAUZ3PTjEJZJJwiGoFwuMGxgxToqSQvdgJcs2RxbSlk9ye9ed 6MLqJqjfaOTRQ/yHmDbyCq3oaf4wBl5AZC8oTUpW9FBxunGd8DNWmA9/CU5hR0sv8Hj/+98j +XuYfAYOC08QnPpNtYDJN6HvpRfn8TgvgRncxfEJKdLHjP0Nh3mbTqmFzcfpc2ioWYO+KY2O C5oUl/zJzpvAFJCqe+1ovLjY0tWANDN4vXW6d4KAsG86WHpYCBTm1fOouNE4U8fspd1Adbm4 iA++2AfTi+eRs0oCgKbiLuASH2oagMeTrOU3rAlgCtDAdBCWDoCPLBCt96rpB72e9k4pAReX cJOdzHUZMHko1JESXgwiS9921ybM3wTPEzVCTkFebLCTACz82rTRvyv1pLTzOnDKs1Ti9WZt yNz7EdhMF7OojayU+63BPt7GSU6bKPvmbKa9ifVI6YylguVRczxlNAdMbUdm1/noVafOfB35 yCyEKovi4Qo//mLkp0697CQytxd5zYb7xByrJJlhVhX4mBX/RT+uOi7QxJiUOTrT23ZQ8Dl4 mcvsbJBakbW6koLEF1+lGMuTjaLdo92fPbkLDG2rK7HwXD1cVgcHfbC5FiJIj9IrYrxWOC38 WWTA2o3ggDQ2jbERafDPoWJAb1rEZ9eTVIKsgW0+jHZZsSeTJXnfLpIxElseLciQFuCvQVJ8 RJ9dwl5PAMAmARhTO0KbGkS1JvIxnFtwRHKeKw5ieo5W1GUEgIb1xhWIF0XGo4cHxGMLzJaD +RIi4dFQiLzRkDlh5WGaqaza+yL7QGjmrItDxUwx+Pp5tPL4sUZXPA0yhcSrihCt/g0mo2OH HhEeN9T+vL/KFhcNn3OfaZ3Ae44j5+cyC2ti1Ql5M9JTiszYmzUAUETETsyEEBqToLc+9gq9 APFRHs9aoNAS6UUKL1P9QtUvlYzU2UN/iLyeqLGZ8c0cfHD0Zvg143ced8OPzdfeIlsjWvnG ETkrNOvVF3cV/4ZOJFnGDp+scy7jP2/QtevW/a5DMIsDlZnPI00Bwq/gx6dVaW1Tp9AUgSGC FF6lQbm9ECfSb+UlMEezMUWGBMsnYYhIa3HcXxScaxVNwwQZXLJZhBjGnurgHCnBbFiAfAKE Vv2qwuVdPJ2jNwshwo+/WCJhkHhumPr3HUxwvt2v6oImVoP4IaR3jiPu5CqrF8tISSZbU40x Sy6eMj7ZNtdim5jQxUE2zCbkW7UlM+N+VTpvOuktU7gSSXS7XEuJLnE4I8OZpXzbEh6Ic8kk whhHpXtnEyof1Z+OBxlKOerhFXxRXMVFchWjbQ7DhZzhqC5KqNysnkPPV8nIa0E1FnnKHI5Q TpRc5Qf5nalm6v2ntKdaZQgtiT7meT8aD8A2RoB4dagSCCjfox7IoQ9sSHIxAq0pGgQwcxR6 VZ1eXyXXZNpwXNq2N9sCBqFn048DSRsrKKYF42LE1kDZZLTEaj+Oc648lkH0qG3CgOZtaubM Fkw0UyVOXo3atomKrrxFM5UnW5dkdGDR2kE5K2FKyc+NBhR5RhE5y0mMRfukY85snL3/afcQ ArTiY7wh4PhDmxZlVPAvaqkRIdmIARzBR1gMCVCrYYKgOXAv48sSdAUvHWmwv/Xfh0di9259 EOMEdAQ2wmZzgHZ1pXfVtHi/v3vgQCBe8MMP0UsoyYzqT/xy9+S4Fb14UY01uuPpvdzx7sEJ LIZjSgQFmmuC/MHMRIejadMMP7MCpNA0yVMTFf3XUYBXbKiVoruMWe3A/qDu6V0qA6mNjEs7 eLlGyxnhWXqd80UgcCGIGMppc5aWcAZcaBVi+MA6IJXWrBqPlRkF1g0ujcS1mm9WI6V0onV7 kJ5PIszihzH5k+q404HkmYmlvnHgHSUM04AZRcV2e8OoNy2rMBI6J6EQXLVchOgW6FLi70iV /p86HCKcxgYvoqZHStCo6bdSOPFMG9J1X3O3dBaKWD4FRaNKz/BQkwW2Mkw+03bZFMijpedL Qu3+iLzXTr8OnSPLlY5zGs1d099devU1+IJlVBsL+ci2jd2AO3CRn5UExafOGdYJyImvEjfk EeZ8FTlPQLGPWuQR0DZSMs74dXAImqmAo9b1ffZBuhkVpJXqQV+5wdlgGpZQPQRPjNw6N94d 7Z7sYFm9+yb6ry2uMcW425VgzdZmdfcARSAuENdgCOXb01JOILTOO0eV3lIYzg9a8rthSx0Q BFttxb3+3QWpfeJwNzSjWVsq/d116fEr+u4r7gqMkBZbcEutuQ23ym79AUGkmhoP28QmRTIq FcMuMBtzAjHgS+YMz4W/VpjU4nOAYsmVTV6LGtHSxChaYuVWv6/kJDTx2YkUdITUukI1KNev OUyHkFHW9iLAHk7UOazYMckVdmoQG7N/hnrzf/+7/3hr7+2PW3AmO1GQutCfVxnYMkh77lYy FIpob4KtldyJBmMJx8M4Zaw57Dxp3W/CxBTpvucJfsC9JD/OJ4BOdAG/VSsWY1fwCqyXWE+0 0R8v98fyDFtIVCED4y+o3g1j7dHWO/OGOY420gYNl9IBFW7glLU28qBsIkGiYBSnIrPU1keB KNpVx31ZQiRi23/LKEwtlcIA0jS/WdYmTNdx8ePumx/3d/aZLN+qxflRDWw/Haq1YYrEaQDE YxTPUfqGGN4zJZpQxaI+sZbdoz9hvS6FH21uUqQQXZxAO2bVaHKGemCSSor1wtL+BrVAdfQT b92lWpuY7lVrjtvRT/vxy8PTg1c7MTJLoeAGV0aSpLnbIzQeajYqM2J5zvFmt6ZL4CCD/EoS O3ASMocqvtH3fmw+RglJaL4RR/1YHIr11zsTYblc01gJPnjW0Dqq8Sg6b3LsdBv0BuOeR6bI iOva9MVBglOQCz/koQbmQOLRiJBn0kgiIBpQz/UQgWnrWRvzA47kBwsqWwgCpPfqcP/t0c7x 8c72pvUJT8UxFpnYAUVWZggcf4+de0E5TSf5I1o03NIP1bnfR/dxgzMuLT5GgQ/SEOPiqt9s hoemNtDGIsQDawXu+ytgYYLAsRbfINQt5olr6oUlyaabpa7ETMgQ3GAAezLfNgbCxsoIvJU2 r/XhQru93L/AOoZIRySsOfJmrV9uRmWk03FfFA+7IhIy+zHURCoyqpuiTUO1R3ilH4k5giwD LNA2uzKSkQD9ZEAyvpwcHkZn2UdLN7RxUvJiWtGij9J2sHwLdMWAzOYLbdVF2wCsPMOMaRLT Ggv0qnRcdSG5rU4t0J04s7U1Sm/3h1CDN2YNkVkJ1d89ON1/uXMUQBi+Zl6+/vPO0fHu4UH9 93blJJEHKO+5/mNQ7+cbDW+Fxegq+xdohfQVEFD875wgafNH4EtOVosnfGEs/Ykf5hBphkkx 5/3kunnfawlviPNJjv7pyfEBXMiyc3By9IvadZP07r+J1h9bJ67HSu43vZ44cwaCgzACs40e R4+DN900m2Xzsd85Luy8fY7yfjp/p9bX39Qr186br1Pz8Tf1yfQxX5/m42/qEyrzKvyYr0/z 8Tf12c+HSTaaf0+d70M9MxPW7J0Z6U3j0d8rFSF4SFrnBfPSA8VR9nYODO+UeFGPuy9DjbsQ i9w63vcZ0ywQHsuE1hW2Oav9jUyOTqKq+GRqAZK0eY3majLB6lOPLr25ca31aPD70ELDi7YM zz2aW3XnVLhyWt3phUpJXR7bfW+wXL/V01f0iXlTRUIroDog5tQWGrghNptBuT4MqiUH4yJ3 QMTCm9lQrdFgT3aetQjsqNTYsiOqNo5gUsUPe521jKoGlM/uC3DE68vXA8xWVBQCfTCHUwAq EnC4bTvAcioIUC+06bXA27TAQujk1uNMRYSuWt916629d1u/HFuWTak2MTFyRZtv8kZbRhNL q5CNt7zbqrGbBcwmctEPODi4P74VHM1DyUTrrK55cDMM32AYaZoIoGrtDBBB0AscnScKvA67 tCyLXVspQvrFvr4DVUI982FSXAYpE+/ZTsqJhcT0rdgQbQ/StHKDkE+2Vl+zDIdVyx0jGdsA oFMeBm28Z2VztPbO506NnW3nYDvAGsSnBuF630G1D9HXuB1S22+l2lc9v7ANQICCSk652ACu zUAMtr2BGgF/O3jxNi1A5bQLX7AijvvPQaBXyQA9S0U+/XjhFYdxSsegdx0jjyvOjOYUA/ex Hp8J6m/Vopg/6tuouToTK2UnuLCCTsUJbmzfEMKpfjEy193wiWoNwT5KhTlsW6dHD0NPidHZ cdg17AB7Nhoy0GzGlQcE4vLyslWeeFoxK8hqU12UQqEpFhao8kOXfd3E8bjgsDMU7vx78Tia Ed5FyLknEFNiptZ2qsBqsyfpoWzt4sJPNbZYw3XOlARIxYaYPKUcEd5jAyUcsQQj2mjso+nm g0kxC1u62Jy1pUQy7o5+Z5lG+9IJBAYyg8xNzm5CeBPVh8bpfKwJnUJoUh6ocXYyyZDLU/74 ARzO4GwZFfohe0DZ6Kc4umG/zeycCjTj0Q3lbS0Tr+ur0hR6n0esI/CtOz8avMM065QvtfyE 1YEg9cnP9CZ/OK/Ai4CDETuo+meDu9K4SdZoBKmr4WEGWeUNajBpiXnLJ61GLXH55KUXBwNG oAMy/xKHhD29YsSUedqnI0d/poWEZ4qnB/w2VcsmXbCYgycH6kBzQuPSEpcdpWYxOHViYItQ 30vkQEX6V1pQgWTJc3CWkFAiLWUXzPmsRXO4SpBX0BCHtEvKEOODRIbSg4ceNWxjBsN1wB4p QdlmglBdbAvKlXHQkzTESSGDlBKEwsRi9ccoljsd+QpF3Q5CHzBJlIIe4PycObtlbvhI49jd pmzrfSUrPTk32So3sP9aHLWQdLuW/WscrSLpDCytoKkEKUuXywtV/L2JRTZuxSSZM/0Frx7V qw8LD7cERO7au643j4dUWYhYLxqNqn5pD7tIhyN12JVOHnCjYnjw8dpP9a2YHnw5lhe94Qw0 DEhmtRRYM3dacsRAVd/QMRMC+tw/JBt+GLwbCeaBFQyXeH73IBMsctx6eNR4Gs5VXkBZvhKI 8RKum8rMVeAharHUHX0S3SQ4/Tp6jXcuXwl7F1XFI5xvkJpuQEKPZkgohCqmofontyOd+ZH6 Rly+EXcjH2lvQNKbj+Qgt6vdt/Qz3toRPJh9llfL8Dx29+UW2v2MKyOO6ZVVS7MdQZ1BcPS9 enta4uXCdtQ4WHNGXmA4mk0yjOL7iGQH6dXwVxIt/DbN0skCKVFt60Zi20Rg3y486+qJfk7h 5RhJ7VzqcYXYQviJOFNzWYaWVdUoiEPQsKn2cZmbe6JBElF4uJTS1S0YjpL3JUARgTuF5+Sh W0gQSyZin6b6G8dn6r9xP8sJ3DEMSQYpZlbiOhdQjLSM8HzhW1gMk7npquxb37wR2I1Z92oM mMHa+1BaxoiskAt7nOs97N3xhmhZNOh2HTLR6Er8xCcIzHmWDvr6Ihz8fMbqBnbG3TXeSrNd OAqspGctU8b19iXTgMvFpmS3sLzeTtk+xVg7dPfg3YDaaVWW9awBUDsj3tnfOXoTLRzhWEAe VHhwrw8FLvNRnxRA4mdOl8Qihlid3hvMw6jb6TAPYb8V7AP4kptw57J1ONyEYXKTnI1bO/RM s3UYsnelEPCWkqIIREm04hjs6g20x5hNgQIjmOEKsqlT0gOkRZQ1hio75USpEYpjYN1aY/HN i8sAysukbmsyEofDnWqgs7A7z/pAOMeY6JzRrs2hwqEtFlTL36qRGn6QFyUuqf3AcvGK5xMP nBUYZt/xF64Oe8eN1gl/qUnP5CGoMxHVR9K81ajB7vUxpxhF4PvJ6FrjU8iII2G+WFVciy4U E4NVpkudnMQpJpzrhNBJzLDpbvfg9WGE9jgZAyVFdD7f+xy9v1d+gEhDCDBUxGiIEAZEcdTq /+CY1WkmbT8k8pgKOTQCl4tuWgUaGh2v6EKDyqIWEzSskoaoTasc02tKiXqSjE8kvjlSy2Z3 KLDyHYjmVPxdrRLopegBeCDmSBSpH7AwyG1sM1/zLO0lkO6/u/p0nbG3JJAJOU25kRolKEwF J20BbWJkl1pJhpBm40dpOcbK2tzoDDR+MMOS4Y/ObXTqZOAIivYxTw1ODumFB0BfSsoXt2iD NM/lZHqX3AJHVFI5bzTDIvtx0wKQHZCNIXLrLGPoCpcmX6b32nx0OwNxRba0V9mxFEvgU9Vi bAjTxcSfn657dpnDS8h246MuOtrZ2tv7RVHgKOegYVk6Y7FQvP0d0Ba2gYLfpc4WBAvRZ+7C 7EFbZ4BAHQUlPxSYZVQmrk1D7fgjtfNRrFSs2CCD3m2x8/rfY1RgyGSTF9qmM7qmDEiludE5 goGyo/NB1iPzrXyppMCzaTboizkG90jBspEWZDMxqEA2H8wap0/FMnC6MjnBZfkc1EcjGEtv kiYASS2KhAvXXBOj2zWO4vhTDgmIgzSOm7z342l5MYju3Ut7n38d0aNh/mkQwaNy3K550/us 3nTk8Tgfy+NfRwx3I1p4/nEhCoYwKMCUSMdqTXh8NLKIoepPjchG6I932fq+59mAcbg2YB3D 1bCcHZ6jgzaJmZrxdVh2ZA97wubXKkVyd7xujQVP5xMTwxyaJFrNfDdJrY7ot8tGWXkBGSbq pAP+YJgDVFlUfTa5likmT/2h5fcQhCqNl83X9lk+nk4qqgXZw4zYEhT8bxI357vsEfZ0Sotj jQKvPsE7L14SC7GFQxQ4yMMITVaWV5d/jqDiTY7mHiiCzj6cts3gJgkcv46UqaaKaqNuAVyQ Y3DgzFMi65icptLZ0da7+M3Oycvdg20LEp8skmt8rTjlqF+tSYYrQoIq3anJ0gaVg/TKC3rp MfgoxiLqIDRkFFrplYmG/1mPqaTZBO9SuCMly4piBJcDcX6pFkB1eSpshNcaFSkI8pGuy2jq FzYgu43tLGRhwU4UWKh2RPOszrAdHcZH2++OpBjodFQBo4f39uQo3jk6aiJcbXnbPbYeBrSv d1tHB7sHb5AKFiwk3ABODQSFs7TR714ZwV3eQKskEoaGTaOaIz+3VOxwci1507k4pyTxnhIK 7dJfyBKO493jl3s/0bTAz9jH4vtLL/pqv/O+epTFQ/Xv7WZszzKj6mDuCAx/glpYsHHWas+e p9FWaGqjXDI81MDzQdTswM1aedGqTLZ5l9K5Z821AAG8RYXxGs05v1daO34Jt0v5UlhlpWYv laRoC/dtDpO/KC51r9+mWSn0NfjSoHT1m/eOjpLQUt+AU+lEqFAuqEFas+9waOjuJUqGKG3T fgXDgDw2egXVNVrRffXh1qtX+4fbO8635OnuOM+gVm5SeZpDLh4YIjQn+VgkZ+xImZgQEwzp AcmpCciSnT/iSzqI1bND2CqAfx/+X3Vu29CC4fzmwl4nZw+gLeOAimSooRoDER0+aKWxaj5Y dTXaaFcfwVZok57JphfbAKVh3ZcSAdqkrdRdsYaj0YYRlCr0V4v96oYuKujqZGx2pzu+8I4L OEYlS5D09iYGVqBrVg3YjrPTozKDktsEnFT4RSvU4WG0yvhulYnd1D4JD64B3PkaLi2jaVU8 DYZnBS26N3AyrGLrLOkdTIrcknWFICzOJF9a4tJ3fUvn1FeJaFNa+w4XkZtwnRILSXm7wItV qiNhyDFTmLVOnYCFmgBAREpJRebENY+33Y/SZHKhhtHmm0Sp5IjQDqwbtRcOYTiZXZ2O7Kk5 77l3rUzLoV6rAh54+cCGICKaxnn8RhKu3dz0ahWMheiGTXegtTx/y/fZZiqz4fmuOOhQR/qw WIVsAwQtlxJFBNGf3atkJdoQ9O+LUdNQ0VJN+5Y12QB12hIfTSmppjBXRgusWJyq4Ing+bbd +EhTG4PYtR//YxU7cLnDixeRuemxhSUQFGgIfqysi8YOqBY6HmTlhIokeCnccOcslP7EQKBE x8PazUF8SftSOMt+oyOVO/6bQTr6qGio6oe2PxoVpq79rGkKQtnC8bhQBJdPSy1CnCPZpJ8h 86A/51HhiLSC3uaNi81lKegMNNon3RFun8P1nBZ+NQIIdxYtgEVbeTRDpoKvrVh3Sx4OyMhy /1v1yLbvCrPvKLKs4lYlHS8dTQGJqciGeinDmFX0wusV66n49O233hRkt19gS8T9u4Zo7yuh adMn9xcvnkOFDr+xV/tDBoa7hUiASdBw2aBJ2bfq3dNVn5KmEvZ6VS3gVBjYFWmB0ab9DbSF g9wqPZlFw1sY8TvRc21FwY3GrObHsnlSCZGnezt3FunfeOv05EclGC9U7vn+Qa4uV6dtD2LB PqbLo3TyAjk+N97eOX51tPv2ZPfwoLlAt4j/RIVeXuGlqGjYaO799GpbyQh4UTsZkThLkP2H oJyo/8V0N6PYmMBpS91Eciuab7rAi6ds0wXHxGL5K32IuG4ytDmzsA7eD9vPapkK+qlaZSA4 PPzZSQ85uJfpNez5lZjwjRxBrK3kwDkLlutBINVFxtk31ld9Ajjw3EJxcm0sYYICqhCBlwFf Y035qkUDv3D9zFlgqSSrVyH7X9Mid8JbnUwZjN+upKy0JC3P/55yXIJt0ARpMDw0KrlYwvjF +ZJFpfBdg2RdpL9NsyLttxwvOM7ZaBZWOu/s7irBa3XHvYnQ7Smdy74rRnQ+MYTCPXRw8Ez4 rmTbZAe+8OcMgS7EQC7fXICbBohNKFZwHO++3t7VJhkty0Nz+/iGv9UhezXCKPuTH3ePY6Ih 34XoVijfiGhksPPWmpgrD+izQET5zsvT41+8yCf2x/f74YkxWyPFHCZ2tPPm7+rfo9M3h/Dv u9PjI2bTOL2Ks2bmmMUa4I9d7mmw5wChnvVr3pk11QZPkW8OMFhxn/vZtL/R99fAh+Yym4no kZX7bZzW5rIUaG5dnaLbV69T2fR3Y1C/GeTr/d/YD+rZbEloTzS6WEOo/Ti0gTN3cBDeQC99 Xn3FUk933X54u32tAr31zmoQ7ub2xjN21w0U+F/ZZncI33G/bfT9h+BHb1yDIO6UNu3vq6gC T2+JKzPg3x5rKsCMUKq3tYTaD3Kpqjac6Bh9+/ZQsFTJHlZfukERmwHRs9I3SYt4/PaScXKW DRRi4bXn5YREGunOb7kPF+1cV04qfSsPWvcnFaOL7828UVqmUCa0LU7HLKl6EhVo8UXmJGuy a+e7a5ZeV2IM6tdIMBXT39fZNYmeqmIO6xtzU/Lt6Ljua5+t3dysSvxfwsqGenAeLR0k0yIa gFLziHSX8hE4BQHLit+We/RqeXDZ6wff31laWprRvPG6yKLX6VkUPYu63Y3VzsbKSrTS6XTv LC4u3gS7cXIxjf57Ooiix1Gns9F5uvH4KTX+4x+jpZVuez1aVP9/Ev3xj3ei/+LLoaIfaDQE 4+JF9c3lWR/dfMGXv03zSZKPS3i56L+kZQ22g0gs0FKDL4mQ8BUO/VkHhv6s2+52cezm9DlK mUER6Ua1YZaRucio5pofDPh90HuAVeso6mQBF4VPJd2cuEPEDfIHGxh2AKqYQpdDsD2P8yu0 yp0D2kQcdgCgYnwTqzdAa5F1jL6VJjQRmHV37SlMu/t4rf3Mm/ZL0A94wiHgDuhDNQ7iazX3 G8mHxG9tFmh1eXw96kWnoyFWWy8v8qu3PfznJCkvS/xtPx1Gg/wj0mtn6Wk02SmG0eXuAOq7 DgbJYE/vkVqnbYwoAgX3wdYDOE4w7+MC71jrkxcfY5TYOX88VhoereaXKiEy+kDO11IyGF8k GvNskqn/yiLK+o8a79TAttNetNpVh/gGEFgn6j5bf+aT5gwQMwm00+6o3W6vI46LXYMNJxzq ggcH6I9kVenpA7I0d7q9QoEPCp2qcxDMN9p20xTbzcdsWfHJlmmSj68pkbb77NkzSFPIFPeP 3hTJ+CLrle1od9RbBkcLpduWmPFTfGKbQsSGBbwfHK0p9mgvcggr9mPXI10rxczBTmWUWlJU bGafcoaNich7jD2PUjDoJMW13X3J0IS/qD15NMY4L8Vd/Gwq8wM2YrjDjsOP7R89UxxKZq5A l7EFK+xg087nvhoZ/Kd4EnaCxXnEiu91UoHn1txBeCveoKVSjw+RBq2R6lgszRt+vZ6YLUuv WXTbcO6WkoVVSxMufIMV/KGgqW2govDyXEkjV5KvTYaqmtIzk+txCnvP/oXYH2JJSb/WtDUg Zz0VTU9H2W9TVErUyoBEiF85xlkBIyYhZ7P9AkqbgY69Nc/ZK409+R3AdVuVDhhACDbqDAJR wnwlOYVCGB9M6MZsKPY+V3dWNSZtqtKRuLqCDOzxFjAvHceL8lztKpVjBxhLzlIa5LbQisSB hmtpikFx2p+TIWC1VX9i6y9V5MbnXOsYJVu2CmJkkXvXbFtjBJyHgTZooW4GPgKvQlRX5aky JOjJz3YgU6QwALjTkYOcleY1/8+vdxabf7vF92EQ8qssv1d5Wu373CDUfJsLZwqT/99qpw3/ 3essRBDnWiyoxR+3WjWgLBA3dlc/ii/W2hE3NEK+c54EZX37UM9Wn67fKGE4H9UIGM43XyVf uBDmES8er/8uXvwuXswnXnS9Qf8uXvwuXtzUXZ14AelEsLOZnZykpYAgqNQTKjDX5JYgsvE/ X5L4CkGiTo74ZjEikH0UGIKfDhIA72bGffXRmayv3Xx02h/VHZ32N193dDoQ5jo6n/1+dP5+ dM53dK56g/796Pz96LypO//otLoUtVytl2bvdWfXQ4DFT77D4edNvBhhniUrg3BwSNzR+WBa XhTlfHsHYJzBjc/Lm8HWWwxUcwfcWTmmshbfAFNg/LvLAF93XLsunNAp6n4ROKjdD259SnvN 5zmiu2uP/6POaF6KEot3mABh+4TD5BFrKu4pHTihv/Z01t68yP/hQzl88liyQ7g/ezJQh1DN FLho4Oz+affw5elrfczSqX2WqnnCENhpJOweRsRZEsNkDKxND0GYd+JIN7penNOnhJLzz/oa FnVZWaMuGVDFwa5/TJ+TZNRPin5o1pVOPQGl8zl52n3W6T5ZXe8+PV9ZTbWYUj1bpdMAvL3d P+/gex9eT8MbZJ/SOeB5Ak/n85qNCzioOoEnCE/faRDx+LqKNbjwUDuJ6J6EiLMCKotM0RWY RaeYEZQxTUoL4Sr9Hm29s8dlWzwgsiG54hKoI3OrF1x3UTsPc4kTw1ux4SEsLG2lb3O6YV2g /JwzPmedrXLcOdTvPJ8OODM+uC4gvcH1pPBv5AqGsFRg0U3E9E+Byde6AowzKij74oyqY49K rRV0By0TvF8ZtgKramHhmcAsqRhw3S7wHaE2pWJyXP2qQUS9Mz5nF2xAkEzD8CmBJAjvVPYz uAsWvDYDewQ1cDTEqsoAxGbDe1oLD5bPqdsdgmeqWsn6dSx4fCsdVk3m8igsBTGqOHH0NQrI PMoHfA8S1sQuxEk1Zkmox1PKVz/wTIki/3GalNdYzqNMh2cQB3DOV3obpRQWhEPwxc8EmRs+ pAR12kE20Xdfc8k8BTxjdF9fW1JNH62uwD9sWvLhqDOdeVo5jz6EulDjG1WgOtm0qvo05tR5 6kxljq7T+HolpxZ+nV2QgvadcTaRWyTc4x9uAGyCxIJjT1jas6goaq791I6eqv+66z9RucUb +tAXboW7UEQ6vrgus57JmJ69eybP2XfBUrXPr4IGjV17KVVQ/RpgqqkDyqATsaFsZO2XnCUY sDNzHfVtfa7qZx3tbUjASz6pkwLDiREaFt3wf7yrk967csQHpwOsNpNXa5Q4KjB8pCjPgIcH DpiDnXcRXwcF+ZtQ9sPJiVM0DcShRpv0+CDl8nFUA1PykO3Kl1KVSSRtuW7KFW6w1IvSWSF9 +CIdKGl2ChlFdJ24Y73LRiZHyQMA+fvD5PosxQTHfnKtBkLhVdeQnMysMY3erz/+oMiGj5i7 0exN8G5lg8abc3wuV6TN+z3fbjbv58zN5v2cgwbn/dzcBcYtDI7ISaSwzSlM1jzc24asTfV7 zAintHXAqOcSY0vrjH94Pw+9G/oCBgmi/JpDnC4xqRzhOVwkIoXYRCIqy7yXoQqssBKPXM0/ +DZT/2CUqg5oX8lGVSrjIx5FhoSMjedQGuw/5cSn00HqiAdxwTBLU5U8zIL1fTr1J3EATpXZ jt3jhZSiJmORWl5PX2kbhUitjigfM49FvtVnU6MioZkd2h9zsYk4tkxlWAZJ28n4DuLN6muT nujZzJxcBGo/h+FLD8UVeBErjWUFiuAo2i4dxg45nVymA0WWy15/OskGhHjjpHeJQgWU6s56 00FSqOUdcGUULGaphj4EaR0rYtqAMwLhEh3uMSkSbedsrUFCGA4AZZEzG7n7BMfDZuD5eFKU fw29OLuepHFe9FGyrLxFo5yw4yBcpIaL7HxS/5bTtn0KwJdDYnDhl9a1Xx5gDF8z77+YZZn4 mHCD+VOxBVh9VJfdgH7/nWPydF/dwtjpNZzHzLnyxLZy2iOqGiWbr1rQvqP4/TDaz4tEKejN yV+G2pAJWrDP+uSnkv8tVtBkkPQgnah34RpDt6fD4XVEAfxUk1GbMCWPGE2FEBVOijeZJfJz KsKdlpPliAkztT/x6IaKu5xRGQwitghoEip4YYEVIqxRMrj+K2i8lQOpjISaweRFr5ejU12Y DvtEIHbHwgJEkZYq7kWCNbPxxuPLitG5pPLIVIsZp0+S2/kg/ZydccW2Ij9DtQeGXGKh9Hxg 7NLEpjDpHnPPYQmYCPtUbAbH9ebgNHrzdk84hTYDW3xY24HtZ+zY9xMxkukkB79DMLtjOAw+ Jj9F8JUWbmfmiixKXpXGazhmh9dWYlUwB0DREYhlAZKlxz610lPMuNkaF5Giqe7axsrqxlon mHFjt5mdaLOOiTbrNYk2Z4Nw0suFOvU/Bt+gEfu2CTZQwlxJZsF3k8m1Sa7prjzBNJOVp+0u xgZGl1AYBPX6AWZOxZg5HElOiHV0CoWSPYKrXBcpWDdTuCPAk4JArWxzfXASBBEO4ATUlUGU xzoDC4rcehcLJABSOXoFQx2FE0Ws6iAEGRCKSysdJsFWCAfZzSDPL0swQj1So340BJpXNMkW FmJIE+IfQunEJo+JAwyTMcI656uQ1JHhTBHKmuONBb/BDXxSXRFHT7OXaSKUMofKlqqjByVV TxbCZHHGjaVlrdu7odHp/nl0X3RzFJRwezAnR2rH7R/HR9uHB3u/qB0j2UjqUCs+PUygLT2X nc16aUyqzNoHSjx6/HQFMOLxs1VOPJKdV+yE/BZpv8kRRX86PTzZgnyjPmSCocwWXyge27Tj hQLt6AxuSaooFauwkKyBZRjjs+nHEp+bRKnD492fsXQwMGUs2qXODNhLdRicHuy+3v2Z8owq HIJts5fl9dA71903Fp9wX1RZxcrjIKvwms3kFmu41ur/YW4xHP5VaevhLLkwcetU2evbsowL RQjTrB9mJ0Vttt45Jv/BXNbXYC7rj9tPcS6WQA/FONQ2xf1hYipfoaSv9rBoM6ZyHu7uNuy4 LfFDRmpNW+tTuD0Fi5Liqxj+xBxDV7dwbmjwNIvmw76fuNyapWFESBNWgN3+4Tb7xo7vRJRB y81IJIoVSpzlA3X4pp/HeTGJUeCI/8xqJq7i6toqLOPq2row5J2f3x4encTHv+y/PNxrUgI3 BIR8SnuxUiyGyWcYS/CrKTAR/K6M/6IoIlOn6dxN5DtyIhHmRM2KKNUyt4SiJMPqktKHFFvR oSZuX1bcA3QQfAn6Ye1LPxyiJtgx2NYLd7RZlft9FRsqw/GvAlEogSVk+EIZSmlkN5q33nBv IjQsZnArBB/kVvymyq34RWNfyauHCvMUEnVXFM/ZeNxFRaCGW0kzl1utdTdWVw236j5ud1cg J7XdfRzkV6N8AuWXi7Ago3Y7nA0syce3YVd6jUmWgfQS9QJ1cSRmBVSR26jHNgR9uRjINXRP OO6JTf/T0dkgGV0CcpW5pPK77ONVvBVv4zaHmMlXcBGqeqfg8RtZQaqcJrei6Kcgamyy6Kb4 bberGO6TdpdOD3VO+lNAlFyqXoexhJdhlHBVWjnJx/DdEhPBkgKj+wPLQ6wGn42a9wNDwQJO cpVNbYqxY7GhC9cr69CxruIIgYl1nQhduMBZYavekf18ZneNL5aQIuJthB1UbxVSL/5WS6dQ I7QfpFN+U6VTfmGkik7Ufbqxsr6hCHaGVCHNZkoVj1cwdxz+IREOUb1CIQDKlKyo3lahN7Bq m9PXO9nZ4lLRnOHGWCPlIf2Nf2yajxxTOFRhbEcPR6of9c/Y+gyQDFl89HAyHLOAukqzW+sC N8LUeAAA1W7IvgntwYwW98ZT9RReLr3QF78ARdRNVOOWNUNGrY/5JOc6gTQ/OLn7WQmOqr6H TIxECojmUs0WpuUjFAuA/YnQ9ZMOqmRPuuu8ezXfb1hy8bH+BGzw+hPJuX95+qZZXwOgblYb 1t7KjQHRFzXK/w/L4IC5rycBAA== --------------54807A0F5FF113195BBEAABE-- From owner-lkcd@oss.sgi.com Wed Jul 11 22:50:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6C5oAD05490 for lkcd-outgoing; Wed, 11 Jul 2001 22:50:10 -0700 Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6C5o7V05486 for ; Wed, 11 Jul 2001 22:50:07 -0700 Received: by esply02.cnt.com with Internet Mail Service (5.5.2650.21) id <3XLADDQS>; Thu, 12 Jul 2001 00:50:02 -0500 Message-ID: <1139BB776563D011BFB600805FC1048FC1B35C@eswb01.cnt.com> From: Jeff Goldszer To: "'Matt D. Robinson'" Cc: "'lkcd@oss.sgi.com'" Subject: RE: FW: Lkcd crashes when a crash is detected. Date: Thu, 12 Jul 2001 00:50:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lkcd@oss.sgi.com Precedence: bulk Matt, Thank you for the quick response. I will try the patch. I am pretty sure that I can reproduce the problem. Hard for me to say because I was not sure is if lkcd was failing because of a configuration issue. I have to do more testing to let you know. I will only do the testing further testing with the new patch unless told otherwise. I "hacked" many kinds of combinations of lkcd setup. Swap space linked to raw character character devices ( Comments found in /etc/sysconfig/vmdump ), Deciding what a swap partition was ( could it be a file or was is just a partition that was run with mkswap? Did swapon on have to be run on the partition for it to be used? Could a pre existing swap partitions be used? ) I wasn't sure how to set up LKCD until I stumble on to older documentation (Original SCSI documentation) and the mail listing. Existing swap space can be used by lkcd, The swap partition has to be mounted using swapon or fstab. I assume the swap partition can not be a file. Jeff Goldszer Senior Software Engineer Computer Network Technologies 65C Commodore Lane West Babylon NY, 11704 Phone: 631-321-5118 FAX: 631-321-5119 -----Original Message----- From: Matt D. Robinson [mailto:yakker@alacritech.com] Sent: Wednesday, July 11, 2001 4:20 PM To: Jeff Goldszer Cc: 'lkcd@oss.sgi.com' Subject: Re: FW: Lkcd crashes when a crash is detected. << File: lkcd-latest.diff.gz >> Hey, Jeff. Try the following patch (instead of the patch you are currently using), and let me know if you get the same results. Also, _before_ you upgrade, use 'lcrash' on the system and determine what function is at c0108fb3 and c012a373. I don't think you're dying in the LKCD code, but somewhere along the way in writing out the pages of memory. We've made some changes to the way in which SMP systems are dealt with. Let's just say that leaving smp_send_stop() out is a _bad_ thing, while leaving it in isn't so hot, either. This is a test patch -- not for production systems. You also need to modify /etc/sysconfig/vmdump and change your DUMP_LEVEL from 4 to 8. Also, can you duplicate this problem, or were you testing the dump process on your machine? --Matt Jeff Goldszer wrote: > > Forgot to mention the OS is configured for SMP. > > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 > > -----Original Message----- > From: Jeff Goldszer > Sent: Wednesday, July 11, 2001 1:24 PM > To: 'lkcd@oss.sgi.com' > Cc: Harold Stevenson; Marco DelToro; 'tjm@sgi.com' > Subject: Lkcd crashes when a crash is detected. > > I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). > > Problem: the crash dump facility is crashing after a crash is detected. > > Crash dump: > Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel > paging request at virtual address 0ec4e430 > printing eip: c0108fb3 > *pde = 00000000 > Oops: 0002 > CPU: 1471744 > EIP: 0010:[] > EFLAGS: 00010006 > eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 > esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 > ds: 0018 es: 0018 ss: 0018 > Process erred (pid: 1835619449, stackpage=c349f000) > Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 > 00000016 > 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 > ffffff00 > c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 > c349e000 > Call Trace: [] [] [] [] [] > [ 0107334>] [] > [] > > Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 > Dumping to device 0x341 [ide0(3,65)] ... > Writing dump header ...<1>Unable to handle kernel paging request at virtual > addr > ess 423b1045 > printing eip: > c012a373 > *pde = 00000000 > > Particulars: > > * My development machine is a Pentium 133 with two ide drives. > * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an > i586) > * Using lkcdutils-1.0-7 for i386 > * kernel patch lkcd-2.4.3.diff > * /dev/vmdump is linked to /dev/hdb1 > * /dev/hdb1 is the swap partition currently used by the development > machine. > > [root@mill /root]# swapon -s > Filename Type Size Used Priority > /dev/hdb1 partition 133016 16 -1 > > * Could not use patch which modified rc.sysinit. I modified the > /etc/rc.sysinit to look like this. Note this is only a portion of the > rc.sysinit. > > # Mount all other filesystems (except for NFS and /proc, which is already > # mounted). Contrary to standard usage, > # filesystems are NOT unmounted in single user mode. > action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs > > if [ -x /sbin/vmdump ] ; then > action "Configuring system for crash dumps" /sbin/vmdump config > fi > > if [ -x /sbin/vmdump ] ; then > action "Saving crash dump (if one exists)" /sbin/vmdump save > fi > > if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then > action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a > fi > > Pertinent Question: > * Is my dump device set up correctly? > * If necessary how to I properly setup /etc/fstab to use a swap > partition that is a file? Can Linux use a swap partition file and lkcd use > /dev/hdb1? > > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 From owner-lkcd@oss.sgi.com Thu Jul 12 00:43:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6C7hD908845 for lkcd-outgoing; Thu, 12 Jul 2001 00:43:13 -0700 Received: from nakedeye.aparity.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6C7h9V08841 for ; Thu, 12 Jul 2001 00:43:09 -0700 Received: from alacritech.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by nakedeye.aparity.com (8.11.2/8.11.2) with ESMTP id f6C7jQn03567; Thu, 12 Jul 2001 00:45:26 -0700 Message-ID: <3B4D51FD.5FCC3C64@alacritech.com> Date: Thu, 12 Jul 2001 00:30:05 -0700 From: "Matt D. Robinson" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Goldszer CC: "'lkcd@oss.sgi.com'" Subject: Re: FW: Lkcd crashes when a crash is detected. References: <1139BB776563D011BFB600805FC1048FC1B35C@eswb01.cnt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Jeff Goldszer wrote: > > Matt, > > Thank you for the quick response. I will try the patch. I am pretty sure > that I can reproduce the problem. Hard for me to say because I was not sure > is if lkcd was failing because of a configuration issue. I have to do more > testing to let you know. I will only do the testing further testing with the > new patch unless told otherwise. Okee, sounds good. Again, if you use 'lkcd' and disassemble the addresses (from the original kernel) that I mentioned in my previous E-mail, we can determine what the PC (eip) instruction was that the crash occurred at. If it is dump_??*() anything, it's an LKCD issue. Otherwise, it's because of something else while writing out the pages. > I "hacked" many kinds of combinations of lkcd setup. Swap space linked to > raw character character devices ( Comments found in /etc/sysconfig/vmdump ), > Deciding what a swap partition was ( could it be a file or was is just a > partition that was run with mkswap? Did swapon on have to be run on the > partition for it to be used? Could a pre existing swap partitions be used? > ) Pre-existing swap spaces can be used. You don't have to use 'swapon' to activate the swap partition, as long as the swap header exists. The best thing to do is to link /dev/vmdump to /dev/sdb1 (I think that's the right swap device in your case), and you're all set. You normally don't have to set it up by yourself, if you've got your swap partitions configured in your /etc/fstab -- the 'vmdump' script creates the link to the first swap device for you automatically. > I wasn't sure how to set up LKCD until I stumble on to older documentation > (Original SCSI documentation) and the mail listing. > Existing swap space can be used by lkcd, The swap partition has to be > mounted using swapon or fstab. I assume the swap partition can not be a > file. The swap partition cannot be a file. :) I'm pretty sure you don't have to have it mounted, but you do have to make sure the swap header is on the partition (done by mkswap). BTW, your dump device doesn't have to be SCSI anymore -- you can use IDE if you want. > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 Let me know what results you get, Jeff. Thanks. --Matt > -----Original Message----- > From: Matt D. Robinson [mailto:yakker@alacritech.com] > Sent: Wednesday, July 11, 2001 4:20 PM > To: Jeff Goldszer > Cc: 'lkcd@oss.sgi.com' > Subject: Re: FW: Lkcd crashes when a crash is detected. > > << File: lkcd-latest.diff.gz >> Hey, Jeff. Try the following patch > (instead of the patch > you are currently using), and let me know if you get the > same results. Also, _before_ you upgrade, use 'lcrash' on > the system and determine what function is at c0108fb3 and > c012a373. I don't think you're dying in the LKCD code, > but somewhere along the way in writing out the pages of > memory. > > We've made some changes to the way in which SMP systems are > dealt with. Let's just say that leaving smp_send_stop() out > is a _bad_ thing, while leaving it in isn't so hot, either. > > This is a test patch -- not for production systems. You > also need to modify /etc/sysconfig/vmdump and change your > DUMP_LEVEL from 4 to 8. > > Also, can you duplicate this problem, or were you testing > the dump process on your machine? > > --Matt > > Jeff Goldszer wrote: > > > > Forgot to mention the OS is configured for SMP. > > > > Jeff Goldszer > > Senior Software Engineer > > Computer Network Technologies > > 65C Commodore Lane > > West Babylon NY, 11704 > > Phone: 631-321-5118 > > FAX: 631-321-5119 > > > > -----Original Message----- > > From: Jeff Goldszer > > Sent: Wednesday, July 11, 2001 1:24 PM > > To: 'lkcd@oss.sgi.com' > > Cc: Harold Stevenson; Marco DelToro; 'tjm@sgi.com' > > Subject: Lkcd crashes when a crash is detected. > > > > I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). > > > > Problem: the crash dump facility is crashing after a crash is detected. > > > > Crash dump: > > Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel > > paging request at virtual address 0ec4e430 > > printing eip: c0108fb3 > > *pde = 00000000 > > Oops: 0002 > > CPU: 1471744 > > EIP: 0010:[] > > EFLAGS: 00010006 > > eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 > > esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 > > ds: 0018 es: 0018 ss: 0018 > > Process erred (pid: 1835619449, stackpage=c349f000) > > Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 > > 00000016 > > 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 > > ffffff00 > > c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 > > c349e000 > > Call Trace: [] [] [] [] > [] > > [ > 0107334>] [] > > [] > > > > Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 > > Dumping to device 0x341 [ide0(3,65)] ... > > Writing dump header ...<1>Unable to handle kernel paging request at > virtual > > addr > > ess 423b1045 > > printing eip: > > c012a373 > > *pde = 00000000 > > > > Particulars: > > > > * My development machine is a Pentium 133 with two ide drives. > > * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an > > i586) > > * Using lkcdutils-1.0-7 for i386 > > * kernel patch lkcd-2.4.3.diff > > * /dev/vmdump is linked to /dev/hdb1 > > * /dev/hdb1 is the swap partition currently used by the development > > machine. > > > > [root@mill /root]# swapon -s > > Filename Type Size Used Priority > > /dev/hdb1 partition 133016 16 -1 > > > > * Could not use patch which modified rc.sysinit. I modified the > > /etc/rc.sysinit to look like this. Note this is only a portion of the > > rc.sysinit. > > > > # Mount all other filesystems (except for NFS and /proc, which is already > > # mounted). Contrary to standard usage, > > # filesystems are NOT unmounted in single user mode. > > action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs > > > > if [ -x /sbin/vmdump ] ; then > > action "Configuring system for crash dumps" /sbin/vmdump config > > fi > > > > if [ -x /sbin/vmdump ] ; then > > action "Saving crash dump (if one exists)" /sbin/vmdump save > > fi > > > > if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then > > action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a > > fi > > > > Pertinent Question: > > * Is my dump device set up correctly? > > * If necessary how to I properly setup /etc/fstab to use a swap > > partition that is a file? Can Linux use a swap partition file and lkcd use > > /dev/hdb1? > > > > Jeff Goldszer > > Senior Software Engineer > > Computer Network Technologies > > 65C Commodore Lane > > West Babylon NY, 11704 > > Phone: 631-321-5118 > > FAX: 631-321-5119 From owner-lkcd@oss.sgi.com Thu Jul 12 04:27:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CBRGC16041 for lkcd-outgoing; Thu, 12 Jul 2001 04:27:16 -0700 Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CBR1V16033 for ; Thu, 12 Jul 2001 04:27:02 -0700 Received: from ecvwall11.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id f6CLjlL19709 for ; Thu, 12 Jul 2001 16:45:47 -0500 (GMT) Received: from ecvwall11.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GGCYDQ00.9BE for ; Thu, 12 Jul 2001 16:55:02 +0530 Received: from sangs ([192.168.225.52]) by platinum.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GGCYF300.606 for ; Thu, 12 Jul 2001 16:55:51 +0530 Message-ID: <003801c10ac6$caaca900$34e1a8c0@wipro.com> Reply-To: "Sriram A.S" From: "Sriram A.S" To: Subject: lkcd on mips Date: Thu, 12 Jul 2001 17:05:45 +0530 Organization: Wipro Technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-lkcd@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I'm new to linux. And I want to build lkcd on a MIPS architecture. Has anybody ported lkcd to MIPS?. Or can somebody please give me some pointers?. Thanks Sriram --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-lkcd@oss.sgi.com Thu Jul 12 10:07:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CH72A25360 for lkcd-outgoing; Thu, 12 Jul 2001 10:07:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CH6oV25353 for ; Thu, 12 Jul 2001 10:06:50 -0700 Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02863 for ; Thu, 12 Jul 2001 09:14:21 -0700 (PDT) mail_from (Jeff_Goldszer@cnt.com) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id <3Y6JRXJZ>; Thu, 12 Jul 2001 11:12:41 -0500 Message-ID: <1139BB776563D011BFB600805FC1048FC1B35F@eswb01.cnt.com> From: Jeff Goldszer To: "'Matt D. Robinson'" Cc: "'lkcd@oss.sgi.com'" , Harold Stevenson , Marco DelToro Subject: RE: FW: Lkcd crashes when a crash is detected. Date: Thu, 12 Jul 2001 11:12:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This what happened when I used the new patch. Unable to handle kernel NULL pointer dereference at virtual address 0000001b printing eip: c0110ce2 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] EFLAGS: 00010286 eax: 0000001b ebx: c3448000 ecx: c3448000 edx: ffffffe0 esi: 0000001b edi: c0110c80 ebp: ffffffff esp: c3448008 ds: 0018 es: 0018 ss: 0018 Process (pid: 0, stackpage=c3447000) Stack: ffffffff c3448000 c3448000 00000001 ffffffff 00030001 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff c3b7a03c ffffffff ffffffff ffffffff ffffffff ffffffff 00000085 ffffffff ffffffff ffffffff Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 83 28 01 0f 88 3f eb 0e 00 56 55 e8 bd 2a 01 00 89 c2 85 Dumping to device 0x341 [ide0(3,65)] on CPU 0 ... Writing dump header ...kernel BUG at sched.c:539! LILO The file in the patch failed to update. I am using the standard 2.4.3 with no additional patches. Fortunately it was ia64 platform issue. patching file arch/ia64/kernel/Makefile Hunk #1 FAILED at 13. 1 out of 1 hunk FAILED -- saving rejects to file arch/ia64/kernel/Makefile.rej [root@mill linux]# gzip -cd /usr/jeffo/lkcd/*latest* | patch -p1 patching file Documentation/Configure.help Hunk #1 succeeded at 2876 (offset -38 lines). patching file Makefile patching file arch/alpha/config.in Hunk #1 succeeded at 359 (offset -2 lines). patching file arch/alpha/kernel/Makefile patching file arch/alpha/kernel/setup.c patching file arch/alpha/kernel/traps.c patching file arch/alpha/kernel/vmdump.c patching file arch/i386/boot/Makefile patching file arch/i386/boot/install.sh patching file arch/i386/config.in Hunk #1 succeeded at 366 (offset -14 lines). patching file arch/i386/kernel/Makefile patching file arch/i386/kernel/smp.c patching file arch/i386/kernel/smpboot.c patching file arch/i386/kernel/traps.c patching file arch/i386/kernel/vmdump.c patching file arch/i386/mm/init.c Hunk #1 succeeded at 418 (offset 3 lines). patching file arch/ia64/config.in Hunk #1 succeeded at 249 (offset -25 lines). patching file arch/ia64/kernel/Makefile Hunk #1 FAILED at 13. 1 out of 1 hunk FAILED -- saving rejects to file arch/ia64/kernel/Makefile.rej patching file arch/ia64/kernel/smp.c Hunk #1 succeeded at 284 with fuzz 2 (offset -3 lines). patching file arch/ia64/kernel/traps.c Hunk #1 succeeded at 39 (offset 2 lines). Hunk #2 succeeded at 93 (offset 21 lines). patching file arch/ia64/kernel/vmdump.c patching file drivers/block/Makefile patching file drivers/block/vmdump.c patching file drivers/char/sysrq.c patching file include/asm-alpha/vmdump.h patching file include/asm-i386/vmdump.h patching file include/asm-ia64/vmdump.h patching file include/linux/vmdump.h patching file init/kerntypes.c patching file init/main.c Hunk #1 succeeded at 26 with fuzz 2. Hunk #2 succeeded at 127 (offset -1 lines). Hunk #3 succeeded at 604 (offset 11 lines). patching file kernel/ksyms.c Hunk #2 succeeded at 63 (offset -2 lines). Hunk #3 succeeded at 348 (offset 2 lines). patching file kernel/panic.c patching file kernel/sched.c -----Original Message----- From: Matt D. Robinson [mailto:yakker@alacritech.com] Sent: Thursday, July 12, 2001 3:30 AM To: Jeff Goldszer Cc: 'lkcd@oss.sgi.com' Subject: Re: FW: Lkcd crashes when a crash is detected. Jeff Goldszer wrote: > > Matt, > > Thank you for the quick response. I will try the patch. I am pretty sure > that I can reproduce the problem. Hard for me to say because I was not sure > is if lkcd was failing because of a configuration issue. I have to do more > testing to let you know. I will only do the testing further testing with the > new patch unless told otherwise. Okee, sounds good. Again, if you use 'lkcd' and disassemble the addresses (from the original kernel) that I mentioned in my previous E-mail, we can determine what the PC (eip) instruction was that the crash occurred at. If it is dump_??*() anything, it's an LKCD issue. Otherwise, it's because of something else while writing out the pages. > I "hacked" many kinds of combinations of lkcd setup. Swap space linked to > raw character character devices ( Comments found in /etc/sysconfig/vmdump ), > Deciding what a swap partition was ( could it be a file or was is just a > partition that was run with mkswap? Did swapon on have to be run on the > partition for it to be used? Could a pre existing swap partitions be used? > ) Pre-existing swap spaces can be used. You don't have to use 'swapon' to activate the swap partition, as long as the swap header exists. The best thing to do is to link /dev/vmdump to /dev/sdb1 (I think that's the right swap device in your case), and you're all set. You normally don't have to set it up by yourself, if you've got your swap partitions configured in your /etc/fstab -- the 'vmdump' script creates the link to the first swap device for you automatically. > I wasn't sure how to set up LKCD until I stumble on to older documentation > (Original SCSI documentation) and the mail listing. > Existing swap space can be used by lkcd, The swap partition has to be > mounted using swapon or fstab. I assume the swap partition can not be a > file. The swap partition cannot be a file. :) I'm pretty sure you don't have to have it mounted, but you do have to make sure the swap header is on the partition (done by mkswap). BTW, your dump device doesn't have to be SCSI anymore -- you can use IDE if you want. > Jeff Goldszer > Senior Software Engineer > Computer Network Technologies > 65C Commodore Lane > West Babylon NY, 11704 > Phone: 631-321-5118 > FAX: 631-321-5119 Let me know what results you get, Jeff. Thanks. --Matt > -----Original Message----- > From: Matt D. Robinson [mailto:yakker@alacritech.com] > Sent: Wednesday, July 11, 2001 4:20 PM > To: Jeff Goldszer > Cc: 'lkcd@oss.sgi.com' > Subject: Re: FW: Lkcd crashes when a crash is detected. > > << File: lkcd-latest.diff.gz >> Hey, Jeff. Try the following patch > (instead of the patch > you are currently using), and let me know if you get the > same results. Also, _before_ you upgrade, use 'lcrash' on > the system and determine what function is at c0108fb3 and > c012a373. I don't think you're dying in the LKCD code, > but somewhere along the way in writing out the pages of > memory. > > We've made some changes to the way in which SMP systems are > dealt with. Let's just say that leaving smp_send_stop() out > is a _bad_ thing, while leaving it in isn't so hot, either. > > This is a test patch -- not for production systems. You > also need to modify /etc/sysconfig/vmdump and change your > DUMP_LEVEL from 4 to 8. > > Also, can you duplicate this problem, or were you testing > the dump process on your machine? > > --Matt > > Jeff Goldszer wrote: > > > > Forgot to mention the OS is configured for SMP. > > > > Jeff Goldszer > > Senior Software Engineer > > Computer Network Technologies > > 65C Commodore Lane > > West Babylon NY, 11704 > > Phone: 631-321-5118 > > FAX: 631-321-5119 > > > > -----Original Message----- > > From: Jeff Goldszer > > Sent: Wednesday, July 11, 2001 1:24 PM > > To: 'lkcd@oss.sgi.com' > > Cc: Harold Stevenson; Marco DelToro; 'tjm@sgi.com' > > Subject: Lkcd crashes when a crash is detected. > > > > I am trying to trouble shoot a crash using lkcd (Linux Kernel Crash Dump). > > > > Problem: the crash dump facility is crashing after a crash is detected. > > > > Crash dump: > > Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel > > paging request at virtual address 0ec4e430 > > printing eip: c0108fb3 > > *pde = 00000000 > > Oops: 0002 > > CPU: 1471744 > > EIP: 0010:[] > > EFLAGS: 00010006 > > eax: 13a66000 ebx: 00000000 ecx: 00000016 edx: 00000018 > > esi: c0297800 edi: 00000000 ebp: c029c906 esp: c349feb8 > > ds: 0018 es: 0018 ss: 0018 > > Process erred (pid: 1835619449, stackpage=c349f000) > > Stack: 00167500 00000000 00000030 c029c937 c029c906 c01072b0 00000000 > > 00000016 > > 00000010 00000030 c029c937 c029c906 00000000 00000018 00000018 > > ffffff00 > > c0114891 00000010 00000282 00000282 00000000 c029c936 00000033 > > c349e000 > > Call Trace: [] [] [] [] > [] > > [ > 0107334>] [] > > [] > > > > Code: ff 04 85 30 64 2b c0 f0 fe 8b 10 78 29 c0 0f 88 5d 64 0f 00 > > Dumping to device 0x341 [ide0(3,65)] ... > > Writing dump header ...<1>Unable to handle kernel paging request at > virtual > > addr > > ess 423b1045 > > printing eip: > > c012a373 > > *pde = 00000000 > > > > Particulars: > > > > * My development machine is a Pentium 133 with two ide drives. > > * The OS: Red Hat Linux release 7.0.91 (Wolverine Kernel 2.4.3 on an > > i586) > > * Using lkcdutils-1.0-7 for i386 > > * kernel patch lkcd-2.4.3.diff > > * /dev/vmdump is linked to /dev/hdb1 > > * /dev/hdb1 is the swap partition currently used by the development > > machine. > > > > [root@mill /root]# swapon -s > > Filename Type Size Used Priority > > /dev/hdb1 partition 133016 16 -1 > > > > * Could not use patch which modified rc.sysinit. I modified the > > /etc/rc.sysinit to look like this. Note this is only a portion of the > > rc.sysinit. > > > > # Mount all other filesystems (except for NFS and /proc, which is already > > # mounted). Contrary to standard usage, > > # filesystems are NOT unmounted in single user mode. > > action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs > > > > if [ -x /sbin/vmdump ] ; then > > action "Configuring system for crash dumps" /sbin/vmdump config > > fi > > > > if [ -x /sbin/vmdump ] ; then > > action "Saving crash dump (if one exists)" /sbin/vmdump save > > fi > > > > if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then > > action $"Checking filesystem quotas: " /sbin/quotacheck -v -R -a > > fi > > > > Pertinent Question: > > * Is my dump device set up correctly? > > * If necessary how to I properly setup /etc/fstab to use a swap > > partition that is a file? Can Linux use a swap partition file and lkcd use > > /dev/hdb1? > > > > Jeff Goldszer > > Senior Software Engineer > > Computer Network Technologies > > 65C Commodore Lane > > West Babylon NY, 11704 > > Phone: 631-321-5118 > > FAX: 631-321-5119 From owner-lkcd@oss.sgi.com Thu Jul 12 18:22:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6D1MSt05851 for lkcd-outgoing; Thu, 12 Jul 2001 18:22:28 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6D1MRV05847 for ; Thu, 12 Jul 2001 18:22:27 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6D1IMs11156; Thu, 12 Jul 2001 18:18:22 -0700 Message-ID: <3B4E4D74.8E94D884@alacritech.com> Date: Thu, 12 Jul 2001 18:23:00 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Sriram A.S" CC: lkcd@oss.sgi.com Subject: Re: lkcd on mips References: <003801c10ac6$caaca900$34e1a8c0@wipro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk "Sriram A.S" wrote: > > Hi, > > I'm new to linux. And I want to build lkcd on a MIPS architecture. > Has anybody ported lkcd to MIPS?. Or can somebody please give > me some pointers?. > > Thanks > Sriram Hi, Sriram. We haven't ported it to MIPS, surprisingly, so it is an outstanding project to take on. Both Tom and I have a lot of experience in dealing with MIPS from the past, but our focus was initially x86. Is this something that people need? Tom, what's the likelihood of using some of of the 'icrash' code in 'lcrash'? Not necessarily directly, but some of it could be useful ('dis', etc.) --Matt From owner-lkcd@oss.sgi.com Fri Jul 13 07:36:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DEacd15514 for lkcd-outgoing; Fri, 13 Jul 2001 07:36:38 -0700 Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DEaYV15499 for ; Fri, 13 Jul 2001 07:36:34 -0700 Received: from f02n15e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id AAA128002; Sat, 14 Jul 2001 00:32:45 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6DEZWc25398; Sat, 14 Jul 2001 00:35:32 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A88.00503164 ; Sat, 14 Jul 2001 00:35:55 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: "Matt D. Robinson" , lkcd@oss.sgi.com Message-ID: Date: Fri, 13 Jul 2001 18:50:01 +0530 Subject: Crash Dump : Non-disruptive dumps vs standalone dumps Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello, Here are a few thoughts on some of the crash dump requirements that we've been looking into. In a broad sense, these requirements appear to address two different aspects of dump which come into play in very different situations. This makes it possible to try to tackle each of these independently, which simplifies our job a little. (a) One of these applies to panic type dumps, which can occur when the system is in a damaged state, and a reboot is necessary (where it may not even be safe to continue running/using parts of the OS, due to the risk of corruption or further damage). Addressing the extreme end of spectrum for this would involve some kind of a "standalone dump capability". (I'll send out a separate note discussing some prevailing design options/possibilities for achieving this in a separate note). In such a situation, we don't need to bother about disruption to the system as loss of information or in-progress work (e.g through forced resets of devices) is acceptable, because the system cannot continue as is anyhow. (b) The other, which the rest of this note is dedicated to, applies to situations where a dump needs to be taken (preferably as an accurate snapshot of the state at an event or point of execution), but where the basic OS is expected to continue running after the dump is taken, and where it is desirable that it indeed do so. This is what we refer to as "Non-disruptive dump support". A key assumption we make is that, in this situation, it is all right, in principle, to depend on the basic OS infrastructure, in order to take the dump. Of course these are two extreme possibilities in terms of how much we can rely on the OS, and it is perhaps the shades of grey in between that occur in reality, but if we can address these two ends we would have a lot of ground covered. If we could achieve both in one shot, it would be great, but maybe to start with even solving these independently in a nice manner would be good progress. Does this sound reasonable ? Now, a little about (b): Non-disruptive dumps: --------------------------------- In an ideal world, this would mean being able to take an *accurate* snapshot dump of the system (probably selective sections of it, along the lines of OS/2 process dump, i.e. flexible dump) *without disrupting* the operation of the system - i.e. have the system continue normally after the dump is taken. This is something that we expect to help with serviceability of live/remote customer systems - the dump could be sent over for analysis of problems that are non-fatal in terms of system availability, but require a visibility into kernel data structures and system state to resolve. For example, rather than have a person on-site running a kernel debugger to examine the system, use dprobes to gather data about the history of a certain situation that is recreateable only on the customer site and then trigger a dump, and let the system continue to run. In this situation the malfunctioning is not crippling and does not affect the integrity of the system. >From a requirements perspective, we do need to clearly establish why we need this to be an accurate snapshot, rather than what the livedump capability in lcrash (i.e. the ability to generate a crash dump from the running kernel memory core) already gives us. The example above is indicative, but there may be tradeoff between accuracy --- and --- non-disruption, it would be good to have some inputs to help understand where to position ourselves there. To appreciate this tradeoff consider the fact that at the instant when the dump is triggered, the system may be in a state where the i/o layer/driver/the device where the dump is to be stored is not prepared to immediately accept dump commands (e.g there could be some i/os in flight or DMA's in progress, or even if we have a dedicated dump device, it still may be possible for the bus to be in an intermediate state; besides locks might have just been held, interrupt servicing in progress etc - think of the problems crash dump has been having - and think of what could happen if we wanted network dumps). A certain amount of quiescing (I use this term here for the want of a better word) may be required to get to a state when it is safe to dump (even if we attempt to switch to a software path that is independent of the current OS state, we may have the h/w state to think of). However, during this quiescing, the system state could or rather would change, affecting accuracy. And then, of course, during the process of dumping, if we go via the block i/o path, system state is changing as we are dumping. If we could predict exactly which parts of memory would change, we could perhaps save that off in a reserved area, but that could get kind of messy or too tied to the implementation. Another point here is that if we do freeze the system while the dump is going on, we also need to understand the consequences of such a freeze when we want to resume normalcy (there would be some amount of disruption - perhaps some thinking along the lines of power management suspension handling could give us some clues). Actually, if the added effort/complexity for effecting a memory snapshot mechanism seems worthwhile, then we could design a way to achieve both of these (well, almost) with some extra complexity and some extra memory space. It is possible that such a scheme (i.e. the interesting possibility of implementing a snapshot memory feature through page/segment protections and copy-on-write mechanisms (think of the way snapshotting for block devices/lvm/filesystems happens) may even turn out to be useful outside of just crash dump. But at the same I realise that it may be a little intrusive and an added complexity in the dump path. It also requires extra memory to save modified state - though the lesser the drift during a quiesce, the lesser this would be. However, one question at the moment is if it is worth it from a user's point of view and where the priority for this lies. A practical compromise in the form of a partial quiesce which essentially involves locks to ensure consistent dump data (e.g. for the subset of state being dumped as with flexible dump options) is another possibility , in addition to providing an option to run on as is, even if data is in an inconsistent state at the point of dump. This also means that when we (eventually) have customized snapshots involving a small portion of memory, the amount of drift would be reduced (e.g if we aren't dumping memory that changes during the dump i/o path). However this has to be worked out further. In any case, the steps may be something like this: 1. Send an IPI to other CPUs to get them to capture their register state (i.e. save it in a memory area). 2. Quiesce (to the minimal extent necessary for the following to work without disrupting the system). 3. Set things up for i/o to dump device to work (e.g change IRQ affinity settings, make device ready etc). This may involve waiting till the setup is done. Also before changing anything on the system, save associated state so we can restore these back to original settings after we are done. 4. Perform actual dumping. Wait for completion. 5. Restore the settings changed just for dump (i.e. get system ready to continue normal operation) 6. Release the system (i.e. let it continue) Does this capture the overall process correctly ? Each of these steps may involve some alternatives which may differ depending on the degree/strictness of accuracy required, and resources available. I'd like to discuss them in some detail in separate notes. (Just to have multiple threads of discussion going on and to keep the overall view separate from the details of how we work out the elements). Some of the recent work that's been happening, in terms of blocking scheduling and stopping other processors would fit in under these points. Regards Suparna Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Fri Jul 13 14:36:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DLadt28891 for lkcd-outgoing; Fri, 13 Jul 2001 14:36:39 -0700 Received: from socal.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DLaZV28886 for ; Fri, 13 Jul 2001 14:36:36 -0700 Received: from eswssol002.elsegundoca.ncr.com (eswssol002 [141.206.1.4]) by socal.sandiegoca.ncr.com (8.9.3+Sun/8.9.2) with ESMTP id OAA23078; Fri, 13 Jul 2001 14:36:27 -0700 (PDT) Received: (from kim@localhost) by eswssol002.elsegundoca.ncr.com (8.9.3+Sun/8.9.2) id OAA11666; Fri, 13 Jul 2001 14:36:28 -0700 (PDT) Date: Fri, 13 Jul 2001 14:36:27 -0700 From: Moo Kim To: bsuparna@in.ibm.com Cc: "Matt D. Robinson" , lkcd@oss.sgi.com Subject: Re: Crash Dump : Non-disruptive dumps vs standalone dumps Message-ID: <20010713143627.O17383@mailbox.ElSegundoCA.NCR.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bsuparna@in.ibm.com on Fri, Jul 13, 2001 at 06:50:01PM +0530 Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello Suparna, I think the idea of capturing crash dumps on a live system seem to quite attractive to end-users (e.g. customer) since it implies there is no system down time or unavailble. From my limited exposure/experience in NCR supporting Teradata DBMS product on SVR4 MPRAS system, developers were time to time requested to dial-in to the customer system (typically MPP system) to diagnoze the performance or system slow down/hung related problems. We often explictly request for customer or site personnel to force the particular node in question, out of X node in MPP system, to panic to capture the crash dump for post-mortem analysis. Each node is typically configured to 4/2/1 GB of memory. SVR4 MPRAS also has the utility to take a memory dump on a live system and we could not use it at all because: 1. The utility basically writes the entire memory to a flat file and often there is no system disk space that could handle 4/2/1 GB of data. 2. The utility takes a long time to finish (several hours) because it is an user-level application. 3. Lastly I don't know whether utility quieses the system or not, but I was told that it may not take a clean snapshot of the memory that there is a small chance that live crash dump file may not contain the information one is after. Please note that this email is not to discourage any of your proposal below, but to share my limited experience. Aside from this, I am more eager to see the basic functionality of lkcd being integrated into the main linux source tree or standard linux distribution as part of RAS (Reliability, Availability, Supportability) feature to Linux soon since being able to reliably save the panic dump and identify/debug any software problem (e.g. post-mortem analysis) have been recognized by management as one of key RAS features for supporting Teradata RDBMS product at NCR. Thanks, Moo Kim Moo.Kim@NCR.COM NCR Corporation On Fri, Jul 13, 2001 at 06:50:01PM +0530, bsuparna@in.ibm.com wrote: > > Hello, > > Here are a few thoughts on some of the crash dump requirements that we've > been looking into. > > In a broad sense, these requirements appear to address two different > aspects of dump which come into play in very different situations. This > makes it possible to try to tackle each of these independently, which > simplifies our job a little. > > (a) One of these applies to panic type dumps, which can occur when the > system is in a damaged state, and a reboot is necessary (where it may not > even be safe to continue running/using parts of the OS, due to the risk of > corruption or further damage). Addressing the extreme end of spectrum for > this would involve some kind of a "standalone dump capability". (I'll send > out a separate note discussing some prevailing design options/possibilities > for achieving this in a separate note). In such a situation, we don't need > to bother about disruption to the system as loss of information or > in-progress work (e.g through forced resets of devices) is acceptable, > because the system cannot continue as is anyhow. > > (b) The other, which the rest of this note is dedicated to, applies to > situations where a dump needs to be taken (preferably as an accurate > snapshot of the state at an event or point of execution), but where the > basic OS is expected to continue running after the dump is taken, and where > it is desirable that it indeed do so. This is what we refer to as > "Non-disruptive dump support". A key assumption we make is that, in this > situation, it is all right, in principle, to depend on the basic OS > infrastructure, in order to take the dump. > > Of course these are two extreme possibilities in terms of how much we can > rely on the OS, and it is perhaps the shades of grey in between that occur > in reality, but if we can address these two ends we would have a lot of > ground covered. > If we could achieve both in one shot, it would be great, but maybe to start > with even solving these independently in a nice manner would be good > progress. > > Does this sound reasonable ? > > > Now, a little about (b): > > Non-disruptive dumps: > --------------------------------- > > In an ideal world, this would mean being able to take an *accurate* > snapshot dump of the system (probably selective sections of it, along the > lines of OS/2 process dump, i.e. flexible dump) *without disrupting* the > operation of the system - i.e. have the system continue normally after the > dump is taken. > > This is something that we expect to help with serviceability of live/remote > customer systems - the dump could be sent over for analysis of problems > that are non-fatal in terms of system availability, but require a > visibility into kernel data structures and system state to resolve. For > example, rather than have a person on-site running a kernel debugger to > examine the system, use dprobes to gather data about the history of a > certain situation that is recreateable only on the customer site and then > trigger a dump, and let the system continue to run. In this situation the > malfunctioning is not crippling and does not affect the integrity of the > system. > > From a requirements perspective, we do need to clearly establish why we > need this to be an accurate snapshot, rather than what the livedump > capability in lcrash (i.e. the ability to generate a crash dump from the > running kernel memory core) already gives us. The example above is > indicative, but there may be tradeoff between accuracy --- and --- > non-disruption, it would be good to have some inputs to help understand > where to position ourselves there. > > To appreciate this tradeoff consider the fact that at the instant when the > dump is triggered, the system may be in a state where the i/o > layer/driver/the device where the dump is to be stored is not prepared to > immediately accept dump commands (e.g there could be some i/os in flight or > DMA's in progress, or even if we have a dedicated dump device, it still may > be possible for the bus to be in an intermediate state; besides locks might > have just been held, interrupt servicing in progress etc - think of the > problems crash dump has been having - and think of what could happen if we > wanted network dumps). A certain amount of quiescing (I use this term here > for the want of a better word) may be required to get to a state when it is > safe to dump (even if we attempt to switch to a software path that is > independent of the current OS state, we may have the h/w state to think > of). However, during this quiescing, the system state could or rather would > change, affecting accuracy. And then, of course, during the process of > dumping, if we go via the block i/o path, system state is changing as we > are dumping. If we could predict exactly which parts of memory would > change, we could perhaps save that off in a reserved area, but that could > get kind of messy or too tied to the implementation. > > Another point here is that if we do freeze the system while the dump is > going on, we also need to understand the consequences of such a freeze when > we want to resume normalcy (there would be some amount of disruption - > perhaps some thinking along the lines of power management suspension > handling could give us some clues). > > Actually, if the added effort/complexity for effecting a memory snapshot > mechanism seems worthwhile, then we could design a way to achieve both of > these (well, almost) with some extra complexity and some extra memory > space. It is possible that such a scheme (i.e. the interesting possibility > of implementing a snapshot memory feature through page/segment protections > and copy-on-write mechanisms (think of the way snapshotting for block > devices/lvm/filesystems happens) may even turn out to be useful outside of > just crash dump. But at the same I realise that it may be a little > intrusive and an added complexity in the dump path. It also requires extra > memory to save modified state - though the lesser the drift during a > quiesce, the lesser this would be. > However, one question at the moment is if it is worth it from a user's > point of view and where the priority for this lies. > > A practical compromise in the form of a partial quiesce which essentially > involves locks to ensure consistent dump data (e.g. for the subset of state > being dumped as with flexible dump options) is another possibility , in > addition to providing an option to run on as is, even if data is in an > inconsistent state at the point of dump. This also means that when we > (eventually) have customized snapshots involving a small portion of memory, > the amount of drift would be reduced (e.g if we aren't dumping memory that > changes during the dump i/o path). However this has to be worked out > further. > > In any case, the steps may be something like this: > 1. Send an IPI to other CPUs to get them to capture their register > state (i.e. save it in a memory area). > 2. Quiesce (to the minimal extent necessary for the following to work > without disrupting the system). > 3. Set things up for i/o to dump device to work (e.g change IRQ > affinity settings, make device ready etc). This may involve waiting till > the setup is done. Also before changing anything on the system, save > associated state so we can restore these back to original settings after we > are done. > 4. Perform actual dumping. Wait for completion. > 5. Restore the settings changed just for dump (i.e. get system ready > to continue normal operation) > 6. Release the system (i.e. let it continue) > > Does this capture the overall process correctly ? > > Each of these steps may involve some alternatives which may differ > depending on the degree/strictness of accuracy required, and resources > available. > I'd like to discuss them in some detail in separate notes. (Just to have > multiple threads of discussion going on and to keep the overall view > separate from the details of how we work out the elements). Some of the > recent work that's been happening, in terms of blocking scheduling and > stopping other processors would fit in under these points. > > > Regards > Suparna > > > > Suparna Bhattacharya > IBM Software Lab, India > E-mail : bsuparna@in.ibm.com > Phone : 91-80-5267117, Extn : 2525 > > From owner-lkcd@oss.sgi.com Fri Jul 13 21:50:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6E4o6r20251 for lkcd-outgoing; Fri, 13 Jul 2001 21:50:06 -0700 Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6E4o3V20245 for ; Fri, 13 Jul 2001 21:50:03 -0700 Received: from f02n15e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id OAA282490 for ; Sat, 14 Jul 2001 14:46:16 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6E4n3c19864 for ; Sat, 14 Jul 2001 14:49:03 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A89.001A73DF ; Sat, 14 Jul 2001 14:48:55 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: lkcd@oss.sgi.com Message-ID: Date: Sat, 14 Jul 2001 10:04:52 +0530 Subject: Standalone/minimal system dependent dump capability (reliably getting dumps on damaged/hung systems) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk This note covers some preliminary thoughts on ways to reliably get dumps generated from a system that has crashed/is damaged / hung, so that a reboot is necessary. We'd really like to get to work out a nice way for doing this on Linux that can handle various kinds of environments (architecture, firmware and device h/w) neatly and with minimal work, and any ideas on that are welcome. Standalone dumps: ----------------------------- In the ideal world this would mean being able to take an *accurate* snapshot dump of the system state without relying on the functioning of any portion of the OS (*zero-system dependence*), and without executing anything that could potentially worsen the system damage. In some ways this might actually be a more critical requirement today, as it comes into play for panic style dumps, where the system is damaged, where a dump may be the only way to figure out what went wrong. Here the system would be brought down (any further execution has a potential for causing corruption of persistent data, which is unacceptable), so it is OK to take drastic reset type actions that could result in loss of data. >From a requirements perspective we need to characterise the extent of damage that we must be able to tolerate and what information/data must be dumped. We listed some of the possibilities that we were aware of : 1. Having a special raw driver dump interface registered by dump devices Issue: Range of devices / adapters to be supported on Linux 2. Make use of firmware/bios capabilities to trigger the dump (should be possible for configuations that can be booted from as long as the capabilities provided for boot extend to support for write operations) Issue: Range of architectures to be supported and the need to check on the kind of firmware support we need there Issue: Potential loopholes or special cases to be handled on a case to case basis ( there have been some tricky problems along this route encountered with OS/2 standalone dump; e.g. some special case problems with reseting adapters which disabled their bios support had to be addressed and a few troublesome issues for certain h/w) 3. Reset (without clearing memory) to effect a soft boot of a reliable linux kernel (built for this purpose with the necessary drivers for the dump device), which performs the actual dumping to disk (before the reset, save /mark the memory areas that could be overwritten during the process) (Mission-critical mcore approach) Issue: On systems where firmware support for a reset without clearing memory is not available, as on many x86 systems, the reset, including reset of the devices etc, has to be affected in software (e.g mcore has had occasional problems with video resets; from what I've heard from some people who've tried it, the bootimg capability which it relies on may not have matured sufficiently to be considered as a reliable option for production systems) Issue: Can't capture entire physical memory state in the dump because of the memory that gets used by the dump kernel (preloaded code plus dynamic space during the softboot) (mcore reuses some of the user memory pages to save the dump pages to make this space available) It may be worthwhile to find out if BIOS extension standards could be worked out to help with this (I hear of some attempts in this area), because that would be the ideal way to solve this problem. Perhaps an extension to soft reset without clearing memory coupled with a way to save register/system state in some place, or in the longer run a way to dump memory to disk (sort of, but not quite the way it happens with hibernation on some systems). For example (2) seems to the way Linux 390 achieves standalone dumps today, because of the h/w / firmware support existing in that environment, so as general direction such a standard interface from memory dump to disk would be nice to have. The390 capability of saving register status is a useful h/w mechanism in the same context. Having a raw device driver interface has its merits too as it is sort of intermediate between (2) and (3), but there is the issue of getting all the device drivers (which isn't small on Linux) to support this interface. Should we try to get inputs from hard disk driver maintainers about the kind of effort this entails for each driver and the acceptability of such an approach ? Maybe, in a hybrid solution, one could think of using (1) if the dump device has registered a raw dumping interface, and if it doesn't then moving to (3), i.e. the dormant kernel approach, maybe if even that fails (e.g if there are memory limitations or some other restrictions; Ques: How would we know that ?) then take up (2) as a last ditch effort only for limited h/w set ? Or should we try (2) first and then (3) ? Obviously, none of the options seem to be perfect. So, enough of rambling :-) As you can see, the floor is open for discussion ! Regards Suparna Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Mon Jul 16 03:58:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GAw8r20904 for lkcd-outgoing; Mon, 16 Jul 2001 03:58:08 -0700 Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GAvxV20885 for ; Mon, 16 Jul 2001 03:57:59 -0700 Received: from f02n15e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id UAA80432; Mon, 16 Jul 2001 20:54:06 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6GAvOp15850; Mon, 16 Jul 2001 20:57:24 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A8B.003C23D9 ; Mon, 16 Jul 2001 20:56:53 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: Moo Kim cc: "Matt D. Robinson" , lkcd@oss.sgi.com Message-ID: Date: Mon, 16 Jul 2001 16:06:38 +0530 Subject: Re: Crash Dump : Non-disruptive dumps vs standalone dumps Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello Moo Kim, Thank you for sharing your experiences with us. Its good to hear that this would be a useful feature to have. Let's hope that we can come up with at least a best effort solution which addresses some of the difficulties you've observed. One of the enhancements that we are also looking at somewhere down the line along the direction of non-disruptive dumps is an increased flexibility in customizing the kind of data to dump. This feature should make it possible to bring down the sizes of the dumps considerably by focussing on the relevant subset of the system data that is of interest for a particular kind of problem. And yes, of course, like many others who subscribe to this list, we too are seriously interested in seeing RAS support in Linux become a standard feature rather than remain confined to isolated patches. One of the areas in this regard is interoperability between/coexistence of different RAS facilities. Specifically on the subject of these discussions on crash dump, I guess an important design consideration that we have to consciously carry at the back of our minds for any of these extensions is to look for minimally intrusive approaches of achieving our goals, so that it is easier to integrate with the kernel when the time comes. Regards Suparna >Hello Suparna, > >I think the idea of capturing crash dumps on a live system seem >to quite attractive to end-users (e.g. customer) since it >implies there is no system down time or unavailble. From >my limited exposure/experience in NCR supporting Teradata >DBMS product on SVR4 MPRAS system, developers were time >to time requested to dial-in to the customer system (typically >MPP system) to diagnoze the performance or system slow >down/hung related problems. We often explictly request >for customer or site personnel to force the particular node >in question, out of X node in MPP system, to panic to capture >the crash dump for post-mortem analysis. Each node is >typically configured to 4/2/1 GB of memory. SVR4 MPRAS >also has the utility to take a memory dump on a live system >and we could not use it at all because: > >1. The utility basically writes the entire memory to > a flat file and often there is no system disk space > that could handle 4/2/1 GB of data. > >2. The utility takes a long time to finish (several hours) > because it is an user-level application. > >3. Lastly I don't know whether utility quieses the system > or not, but I was told that it may not take a clean > snapshot of the memory that there is a small chance > that live crash dump file may not contain the > information one is after. > >Please note that this email is not to discourage any of your >proposal below, but to share my limited experience. Aside >from this, I am more eager to see the basic functionality of >lkcd being integrated into the main linux source tree or >standard linux distribution as part of RAS (Reliability, >Availability, Supportability) feature to Linux soon since >being able to reliably save the panic dump and identify/debug >any software problem (e.g. post-mortem analysis) have been >recognized by management as one of key RAS features for >supporting Teradata RDBMS product at NCR. > >Thanks, Moo Kim Moo.Kim@NCR.COM NCR Corporation Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Mon Jul 16 13:02:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GK2Me24202 for lkcd-outgoing; Mon, 16 Jul 2001 13:02:22 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GK2MV24199 for ; Mon, 16 Jul 2001 13:02:22 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id NAA14575 for ; Mon, 16 Jul 2001 13:02:16 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 13:02:16 -0700 Message-ID: From: Hiro Sugawara To: lkcd@oss.sgi.com Subject: Compiling on SunOS Date: Mon, 16 Jul 2001 13:02:10 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi! I am porting LKCD to our embedded PPC Linux with SunOS 5 as the host. With modified gdbserver as an agent, lcrash can now show ps, backtrace process stack, disassemble the code, and do other things on a live kernel. One big problem is that the lex and yacc files do not compile well on SunOS. I work around this problem by using Linux to produce *.c files from the source and then copying those files by hand. Does anybody have encountered (and hopefully solved) this problem? hiro From owner-lkcd@oss.sgi.com Mon Jul 16 13:21:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKLen25748 for lkcd-outgoing; Mon, 16 Jul 2001 13:21:40 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKLcV25745 for ; Mon, 16 Jul 2001 13:21:38 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA21537 for ; Mon, 16 Jul 2001 13:21:29 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA60832; Mon, 16 Jul 2001 13:21:28 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id NAA46220; Mon, 16 Jul 2001 13:21:22 -0700 (PDT) Message-ID: <3B5349C1.DE76E607@sgi.com> Date: Mon, 16 Jul 2001 16:08:33 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Hiro Sugawara CC: lkcd@oss.sgi.com Subject: Re: Compiling on SunOS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hiro, I did a checkin last week on sourceforge to fix a problem with using the bison parser instead of yacc. Make sure you cvs/update with the latest. If you are running with the latest, then send me the error messages that you get I'll check it out. Let me know, Hiro Sugawara wrote: > > Hi! > > I am porting LKCD to our embedded PPC Linux with SunOS 5 as the > host. With modified gdbserver as an agent, lcrash can now show > ps, backtrace process stack, disassemble the code, and do other > things on a live kernel. > > One big problem is that the lex and yacc files do not compile > well on SunOS. I work around this problem by using Linux to > produce *.c files from the source and then copying those files > by hand. > > Does anybody have encountered (and hopefully solved) this > problem? > > hiro -- Luc From owner-lkcd@oss.sgi.com Mon Jul 16 16:44:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GNive03213 for lkcd-outgoing; Mon, 16 Jul 2001 16:44:57 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GNiuV03210 for ; Mon, 16 Jul 2001 16:44:56 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6GNexs03216; Mon, 16 Jul 2001 16:40:59 -0700 Message-ID: <3B537CA8.3E4419A3@alacritech.com> Date: Mon, 16 Jul 2001 16:45:44 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Luc Chouinard CC: Hiro Sugawara , lkcd@oss.sgi.com Subject: Re: Compiling on SunOS References: <3B5349C1.DE76E607@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk To take this a step further, what lex/yacc revision are you using? And is this an RPM-based user-land, and if so, which RPMs? If this is as simple as changing 'yacc' to 'bison', that's easy, but if you're using the same lex/yacc revision that is commonly used on x86 RH systems, then we've got a whole other problem to solve. --Matt Luc Chouinard wrote: > > Hiro, I did a checkin last week on sourceforge to fix a problem with > using the bison parser instead of yacc. Make sure you cvs/update with > the latest. If you are running with the latest, then send me the error > messages that you get I'll check it out. > > Let me know, > > Hiro Sugawara wrote: > > > > Hi! > > > > I am porting LKCD to our embedded PPC Linux with SunOS 5 as the > > host. With modified gdbserver as an agent, lcrash can now show > > ps, backtrace process stack, disassemble the code, and do other > > things on a live kernel. > > > > One big problem is that the lex and yacc files do not compile > > well on SunOS. I work around this problem by using Linux to > > produce *.c files from the source and then copying those files > > by hand. > > > > Does anybody have encountered (and hopefully solved) this > > problem? > > > > hiro > > -- > Luc From owner-lkcd@oss.sgi.com Mon Jul 16 16:55:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GNtwS03418 for lkcd-outgoing; Mon, 16 Jul 2001 16:55:58 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GNtuV03415 for ; Mon, 16 Jul 2001 16:55:56 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04684; Mon, 16 Jul 2001 16:55:46 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 16:55:46 -0700 Message-ID: From: Hiro Sugawara To: "'Matt D. Robinson'" , Luc Chouinard Cc: Hiro Sugawara , lkcd@oss.sgi.com Subject: RE: Compiling on SunOS Date: Mon, 16 Jul 2001 16:55:45 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Thanks for the kind responses. I used the yacc and lex that came with my SunOS 5.8, then tried bison 1.28 and flex 2.5.4, and none worked well. I think the exact problems were both in compilation and linking, but I only vaguely remember. I will post the exact symptom(s) as soon as I have time to reproduce the trouble (and I will have to do it anyway). Regards, hiro > -----Original Message----- > From: Matt D. Robinson [mailto:yakker@alacritech.com] > Sent: Monday, July 16, 2001 16:46 > To: Luc Chouinard > Cc: Hiro Sugawara; lkcd@oss.sgi.com > Subject: Re: Compiling on SunOS > > > To take this a step further, what lex/yacc revision are you using? > And is this an RPM-based user-land, and if so, which RPMs? > > If this is as simple as changing 'yacc' to 'bison', that's easy, > but if you're using the same lex/yacc revision that is commonly > used on x86 RH systems, then we've got a whole other problem to > solve. > > --Matt > > Luc Chouinard wrote: > > > > Hiro, I did a checkin last week on sourceforge to fix a problem with > > using the bison parser instead of yacc. Make sure you > cvs/update with > > the latest. If you are running with the latest, then send > me the error > > messages that you get I'll check it out. > > > > Let me know, > > > > Hiro Sugawara wrote: > > > > > > Hi! > > > > > > I am porting LKCD to our embedded PPC Linux with SunOS 5 as the > > > host. With modified gdbserver as an agent, lcrash can now show > > > ps, backtrace process stack, disassemble the code, and do other > > > things on a live kernel. > > > > > > One big problem is that the lex and yacc files do not compile > > > well on SunOS. I work around this problem by using Linux to > > > produce *.c files from the source and then copying those files > > > by hand. > > > > > > Does anybody have encountered (and hopefully solved) this > > > problem? > > > > > > hiro > > > > -- > > Luc > From owner-lkcd@oss.sgi.com Mon Jul 16 18:45:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H1jWI05433 for lkcd-outgoing; Mon, 16 Jul 2001 18:45:32 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H1jSV05429 for ; Mon, 16 Jul 2001 18:45:28 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA10882; Mon, 16 Jul 2001 18:43:29 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 18:43:29 -0700 Message-ID: From: Hiro Sugawara To: Hiro Sugawara , "'Matt D. Robinson'" , "'Luc Chouinard'" Cc: "'lkcd@oss.sgi.com'" Subject: RE: Compiling on SunOS Date: Mon, 16 Jul 2001 18:43:27 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Okay, here's the complete log of my experiments (4 cases): =============================== SunOS 5.8's native lex and yacc SunOS' lex does not accept -P =============================== lex -Psialpp -t /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.l > ./lex.sialpp.c lex: illegal option -- P Usage: lex [-ewctvnVY] [-Q(y/n)] [file] =============================== flex 2.5.4 and SunOS 5.8's native yacc Files compile, but linker fails =============================== yacc -psial -v -t -d /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y conflicts: 255 shift/reduce, 18 reduce/reduce cat ./y.tab.c | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > ./sial.tab.c cat ./y.tab.h | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > ./sial.tab.h ... yacc -psialpp -v -t -d /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y conflicts: 23 shift/reduce cat ./y.tab.c | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > ./sialpp.tab.c cat ./y.tab.h | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > ./sialpp.tab.h gcc -gstabs -I. -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c ./sialpp.tab.c gcc -gstabs -I. -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c ./sial.tab.c flex -L -Psial -t /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.l > ./lex.sial.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c ./lex.sial.c flex -Psialpp -t /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.l > ./lex.sialpp.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c ./lex.sialpp.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -o mkbaseop /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/mkbaseop.c ./mkbaseop > baseops.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c baseops.c ar ccurl libsial.a sial_util.o sial_node.o sial_var.o sial_func.o sial_str.o sial_op.o sial_num.o sial_stat.o sial_builtin.o sial_type.o sial_case.o sial_api.o sial_member.o sial_alloc.o sial_define.o sial_input.o sial_print.o sialpp.tab.o sial.tab.o lex.sial.o lex.sialpp.o baseops.o make[1]: Leaving directory `/users/home11/hsugawar/springboard/tools/obj/sparc-sun-solaris/powerpc-linu x/lkcdutils/libsial' ... gcc -o lcrash -L. -L./../libklib -L./../liballoc -L./../librl -L./../libsial main.o util.o eval.o report.o stabs.o struct.o vmdump.o sial.o -lcmds -larch -lalloc -lrl -lklib -lncurses -lopcodes -lbfd -liberty -ldl -lsial ./../libsial/libsial.a(sial.tab.o)(.data+0x0): multiple definition of `yys' ./../libsial/libsial.a(sialpp.tab.o)(.data+0x0): first defined here ./../libsial/libsial.a(sial.tab.o)(.data+0x4): multiple definition of `yyv' ./../libsial/libsial.a(sialpp.tab.o)(.data+0x4): first defined here ./../libsial/libsial.a(sial.tab.o)(.data+0xc): multiple definition of `yytoks' ./../libsial/libsial.a(sialpp.tab.o)(.data+0xc): first defined here /usr/gnu/sparc-sun-solaris2.7/bin/ld: Warning: size of symbol `yytoks' changed from 208 to 808 in sial.tab.o ./../libsial/libsial.a(sial.tab.o): In function `sial_toctype': /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y:423: multiple definition of `yyreds' ./../libsial/libsial.a(sialpp.tab.o):/usr/ccs/bin/yaccpar:136: first defined here /usr/gnu/sparc-sun-solaris2.7/bin/ld: Warning: size of symbol `yyreds' changed from 116 to 740 in sial.tab.o collect2: ld returned 1 exit status make[1]: *** [lcrash] Error 1 ==================================== flex 2.5.4 + bison 1.28 sial.y compiles, but sialpp.y fails ==================================== bison -psial -v -t -d /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y -o ./y.tab.c /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y contains 253 shift/reduce conflicts and 20 reduce/reduce conflicts. cat ./y.tab.c | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > ./sial.tab.c cat ./y.tab.h | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > ./sial.tab.h ... bison -psialpp -v -t -d /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y -o ./y.tab.c /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y contains 23 shift/reduce conflicts. cat ./y.tab.c | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > ./sialpp.tab.c cat ./y.tab.h | sed -f /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > ./sialpp.tab.h gcc -gstabs -I. -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c ./sialpp.tab.c /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y: In function `sial_getppnode': /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: `yyval' undeclared (first use in this function) /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: (Each undeclared identifier is reported only once /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: for each function it appears in.) make[1]: *** [sialpp.tab.o] Error 1 ==================================== Linux' lex/yacc output files copied Everything looks good ==================================== gcc -gstabs -I. -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c ./sialpp.tab.c gcc -gstabs -I. -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c ./sial.tab.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c ./lex.sial.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c ./lex.sialpp.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -o mkbaseop /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/mkbaseop.c ./mkbaseop > baseops.c gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c baseops.c hiro > -----Original Message----- > From: Hiro Sugawara > Sent: Monday, July 16, 2001 16:56 > To: 'Matt D. Robinson'; Luc Chouinard > Cc: Hiro Sugawara; lkcd@oss.sgi.com > Subject: RE: Compiling on SunOS > > > Thanks for the kind responses. > > I used the yacc and lex that came with my SunOS 5.8, then > tried bison 1.28 and flex 2.5.4, and none worked well. > I think the exact problems were both in compilation and > linking, but I only vaguely remember. > > I will post the exact symptom(s) as soon as I have time to > reproduce the trouble (and I will have to do it anyway). > > Regards, > hiro > > > -----Original Message----- > > From: Matt D. Robinson [mailto:yakker@alacritech.com] > > Sent: Monday, July 16, 2001 16:46 > > To: Luc Chouinard > > Cc: Hiro Sugawara; lkcd@oss.sgi.com > > Subject: Re: Compiling on SunOS > > > > > > To take this a step further, what lex/yacc revision are you using? > > And is this an RPM-based user-land, and if so, which RPMs? > > > > If this is as simple as changing 'yacc' to 'bison', that's easy, > > but if you're using the same lex/yacc revision that is commonly > > used on x86 RH systems, then we've got a whole other problem to > > solve. > > > > --Matt > > > > Luc Chouinard wrote: > > > > > > Hiro, I did a checkin last week on sourceforge to fix a > problem with > > > using the bison parser instead of yacc. Make sure you > > cvs/update with > > > the latest. If you are running with the latest, then send > > me the error > > > messages that you get I'll check it out. > > > > > > Let me know, > > > > > > Hiro Sugawara wrote: > > > > > > > > Hi! > > > > > > > > I am porting LKCD to our embedded PPC Linux with SunOS 5 as the > > > > host. With modified gdbserver as an agent, lcrash can now show > > > > ps, backtrace process stack, disassemble the code, and do other > > > > things on a live kernel. > > > > > > > > One big problem is that the lex and yacc files do not compile > > > > well on SunOS. I work around this problem by using Linux to > > > > produce *.c files from the source and then copying those files > > > > by hand. > > > > > > > > Does anybody have encountered (and hopefully solved) this > > > > problem? > > > > > > > > hiro > > > > > > -- > > > Luc > > > From owner-lkcd@oss.sgi.com Mon Jul 16 18:51:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H1p6m05567 for lkcd-outgoing; Mon, 16 Jul 2001 18:51:06 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H1p5V05563 for ; Mon, 16 Jul 2001 18:51:05 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA11087 for ; Mon, 16 Jul 2001 18:49:07 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 18:49:07 -0700 Message-ID: From: Hiro Sugawara To: "'lkcd@oss.sgi.com'" Subject: Module support Date: Mon, 16 Jul 2001 18:49:06 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Has anyone tried to make lcrash support modules. If no one has, I guess I have to reverse-engineer the query_modules system call. Am I correct? Since most of our proprietary kernel code (device drivers) is in module, LKCD is not very useful with module support... hiro From owner-lkcd@oss.sgi.com Mon Jul 16 19:38:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H2cKS06574 for lkcd-outgoing; Mon, 16 Jul 2001 19:38:20 -0700 Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H2cJV06571 for ; Mon, 16 Jul 2001 19:38:19 -0700 Received: from m7.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id LAA21737 for ; Tue, 17 Jul 2001 11:36:20 +0900 (JST) (envelope-from j-kondo@pst.fujitsu.com) Received: from meow.aoi.pst.fujitsu.com by m7.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id LAA32376 for ; Tue, 17 Jul 2001 11:36:19 +0900 (envelope-from j-kondo@pst.fujitsu.com) Received: from localhost (really [127.0.0.1]) by meow.aoi.pst.fujitsu.com via smail with esmtp id (Debian Smail3.2.0.102) for ; Tue, 17 Jul 2001 11:36:18 +0900 (JST) To: lkcd@oss.sgi.com Subject: Re: Module support From: KONDO Jyunji Reply-To: j-kondo@pst.fujitsu.com In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010717113618I.j-kondo@pst.fujitsu.com> Date: Tue, 17 Jul 2001 11:36:18 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 19 Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, hiro. > Has anyone tried to make lcrash support modules. If no one has, > I guess I have to reverse-engineer the query_modules system call. > Am I correct? We are trying to do that by extending lcrash and using ksymoops. > Since most of our proprietary kernel code (device drivers) is > in module, LKCD is not very useful with module support... I agree... At the moment, we are fixing our ideas and we'll be post it to this group soon. Please wait a moment. Jyunji Kondo From owner-lkcd@oss.sgi.com Mon Jul 16 20:02:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H32xw07044 for lkcd-outgoing; Mon, 16 Jul 2001 20:02:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H32wV07038 for ; Mon, 16 Jul 2001 20:02:58 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05643 for ; Mon, 16 Jul 2001 20:00:29 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id UAA59422; Mon, 16 Jul 2001 20:02:42 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id UAA46799; Mon, 16 Jul 2001 20:02:18 -0700 (PDT) Message-ID: <3B53A7B9.B6BFB0B2@sgi.com> Date: Mon, 16 Jul 2001 22:49:29 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: j-kondo@pst.fujitsu.com CC: lkcd@oss.sgi.com Subject: Re: Module support References: <20010717113618I.j-kondo@pst.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Jyunji, Andreas Herrmann has been doing some work on a feature like this one for lcrash. I'm not sure how complete Andreas's work is at this time. I know there was also some legal issues involved in releasing that work to the group. Andreas, any status ? KONDO Jyunji wrote: > > Hi, hiro. > > > Has anyone tried to make lcrash support modules. If no one has, > > I guess I have to reverse-engineer the query_modules system call. > > Am I correct? > > We are trying to do that by extending lcrash and using ksymoops. > > > Since most of our proprietary kernel code (device drivers) is > > in module, LKCD is not very useful with module support... > > I agree... > > At the moment, we are fixing our ideas and we'll be post it to this > group soon. > Please wait a moment. > > Jyunji Kondo -- Luc From owner-lkcd@oss.sgi.com Mon Jul 16 20:06:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H36EZ07130 for lkcd-outgoing; Mon, 16 Jul 2001 20:06:14 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H36BV07126 for ; Mon, 16 Jul 2001 20:06:11 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07956 for ; Mon, 16 Jul 2001 20:03:42 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id UAA68956; Mon, 16 Jul 2001 20:06:00 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id UAA46793; Mon, 16 Jul 2001 20:05:35 -0700 (PDT) Message-ID: <3B53A87F.3FBB2D76@sgi.com> Date: Mon, 16 Jul 2001 22:52:47 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Hiro Sugawara CC: "'Matt D. Robinson'" , "'lkcd@oss.sgi.com'" Subject: Re: Compiling on SunOS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi Hiro, It's a necessity for the lexer and parser to support variable prefixes like the -P option to lex. This is the premise for being able to make the sial preprocessor and compiler work together inside a single image. So you most steer away from the SunOS lex implementation. As for the yack problem with the preprocessor file, I'll see what I can found out. SunOS is not something that has been on Matt or Tom's agenda as far as I know...and I'm following their cue. I'll check it out, but no promises :) I managed to find a SunOS 5 in munich.sgi so that's a good start. It could be a mather of adding some more sed substitutions in the sial-lsed and sialpp-lsed files. Did you try that ? More later. Thanks, Hiro Sugawara wrote: > > Okay, here's the complete log of my experiments (4 cases): > > =============================== > SunOS 5.8's native lex and yacc > SunOS' lex does not accept -P > =============================== > lex -Psialpp -t > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.l > > ./lex.sialpp.c > lex: illegal option -- P > Usage: lex [-ewctvnVY] [-Q(y/n)] [file] > > =============================== > flex 2.5.4 and SunOS 5.8's native yacc > Files compile, but linker fails > =============================== > yacc -psial -v -t -d > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y > > conflicts: 255 shift/reduce, 18 reduce/reduce > cat ./y.tab.c | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > > ./sial.tab.c > cat ./y.tab.h | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > > ./sial.tab.h > > ... > > yacc -psialpp -v -t -d > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y > > conflicts: 23 shift/reduce > cat ./y.tab.c | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > > ./sialpp.tab.c > cat ./y.tab.h | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > > ./sialpp.tab.h > gcc -gstabs -I. > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c > ./sialpp.tab.c > gcc -gstabs -I. > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c > ./sial.tab.c > flex -L -Psial -t > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.l > > ./lex.sial.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > ./lex.sial.c > flex -Psialpp -t > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.l > > ./lex.sialpp.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > ./lex.sialpp.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -o > mkbaseop > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/mkbaseop.c > ./mkbaseop > baseops.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > baseops.c > ar ccurl libsial.a sial_util.o sial_node.o sial_var.o sial_func.o sial_str.o > sial_op.o sial_num.o sial_stat.o sial_builtin.o sial_type.o sial_case.o > sial_api.o sial_member.o sial_alloc.o sial_define.o sial_input.o > sial_print.o sialpp.tab.o sial.tab.o lex.sial.o lex.sialpp.o baseops.o > make[1]: Leaving directory > `/users/home11/hsugawar/springboard/tools/obj/sparc-sun-solaris/powerpc-linu > x/lkcdutils/libsial' > > ... > > gcc -o lcrash -L. -L./../libklib -L./../liballoc -L./../librl > -L./../libsial main.o util.o eval.o report.o stabs.o struct.o vmdump.o > sial.o -lcmds -larch -lalloc -lrl -lklib -lncurses -lopcodes -lbfd -liberty > -ldl -lsial > ./../libsial/libsial.a(sial.tab.o)(.data+0x0): multiple definition of `yys' > ./../libsial/libsial.a(sialpp.tab.o)(.data+0x0): first defined here > ./../libsial/libsial.a(sial.tab.o)(.data+0x4): multiple definition of `yyv' > ./../libsial/libsial.a(sialpp.tab.o)(.data+0x4): first defined here > ./../libsial/libsial.a(sial.tab.o)(.data+0xc): multiple definition of > `yytoks' > ./../libsial/libsial.a(sialpp.tab.o)(.data+0xc): first defined here > /usr/gnu/sparc-sun-solaris2.7/bin/ld: Warning: size of symbol `yytoks' > changed from 208 to 808 in sial.tab.o > ./../libsial/libsial.a(sial.tab.o): In function `sial_toctype': > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y:423: > multiple definition of `yyreds' > ./../libsial/libsial.a(sialpp.tab.o):/usr/ccs/bin/yaccpar:136: first defined > here > /usr/gnu/sparc-sun-solaris2.7/bin/ld: Warning: size of symbol `yyreds' > changed from 116 to 740 in sial.tab.o > collect2: ld returned 1 exit status > make[1]: *** [lcrash] Error 1 > > ==================================== > flex 2.5.4 + bison 1.28 > sial.y compiles, but sialpp.y fails > ==================================== > bison -psial -v -t -d > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y -o > ./y.tab.c > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial.y > contains 253 shift/reduce conflicts and 20 reduce/reduce conflicts. > cat ./y.tab.c | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > > ./sial.tab.c > cat ./y.tab.h | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sial-lsed > > ./sial.tab.h > > ... > > bison -psialpp -v -t -d > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y -o > ./y.tab.c > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y > contains 23 shift/reduce conflicts. > cat ./y.tab.c | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > > ./sialpp.tab.c > cat ./y.tab.h | sed -f > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp-lsed > > ./sialpp.tab.h > gcc -gstabs -I. > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c > ./sialpp.tab.c > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y: In > function `sial_getppnode': > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: > `yyval' undeclared (first use in this function) > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: > (Each undeclared identifier is reported only once > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/sialpp.y:83: > for each function it appears in.) > make[1]: *** [sialpp.tab.o] Error 1 > > ==================================== > Linux' lex/yacc output files copied > Everything looks good > ==================================== > gcc -gstabs -I. > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c > ./sialpp.tab.c > gcc -gstabs -I. > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial -c > ./sial.tab.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > ./lex.sial.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > ./lex.sialpp.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -o > mkbaseop > /users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/mkbaseop.c > ./mkbaseop > baseops.c > gcc -g -D__BROCADE__ -Dlinux=1 -D__BIG_ENDIAN__=1 -I. -I./include > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial > -I/users/home11/hsugawar/springboard/tools/src/lkcdutils/libsial/include -c > baseops.c > > hiro > > > -----Original Message----- > > From: Hiro Sugawara > > Sent: Monday, July 16, 2001 16:56 > > To: 'Matt D. Robinson'; Luc Chouinard > > Cc: Hiro Sugawara; lkcd@oss.sgi.com > > Subject: RE: Compiling on SunOS > > > > > > Thanks for the kind responses. > > > > I used the yacc and lex that came with my SunOS 5.8, then > > tried bison 1.28 and flex 2.5.4, and none worked well. > > I think the exact problems were both in compilation and > > linking, but I only vaguely remember. > > > > I will post the exact symptom(s) as soon as I have time to > > reproduce the trouble (and I will have to do it anyway). > > > > Regards, > > hiro > > > > > -----Original Message----- > > > From: Matt D. Robinson [mailto:yakker@alacritech.com] > > > Sent: Monday, July 16, 2001 16:46 > > > To: Luc Chouinard > > > Cc: Hiro Sugawara; lkcd@oss.sgi.com > > > Subject: Re: Compiling on SunOS > > > > > > > > > To take this a step further, what lex/yacc revision are you using? > > > And is this an RPM-based user-land, and if so, which RPMs? > > > > > > If this is as simple as changing 'yacc' to 'bison', that's easy, > > > but if you're using the same lex/yacc revision that is commonly > > > used on x86 RH systems, then we've got a whole other problem to > > > solve. > > > > > > --Matt > > > > > > Luc Chouinard wrote: > > > > > > > > Hiro, I did a checkin last week on sourceforge to fix a > > problem with > > > > using the bison parser instead of yacc. Make sure you > > > cvs/update with > > > > the latest. If you are running with the latest, then send > > > me the error > > > > messages that you get I'll check it out. > > > > > > > > Let me know, > > > > > > > > Hiro Sugawara wrote: > > > > > > > > > > Hi! > > > > > > > > > > I am porting LKCD to our embedded PPC Linux with SunOS 5 as the > > > > > host. With modified gdbserver as an agent, lcrash can now show > > > > > ps, backtrace process stack, disassemble the code, and do other > > > > > things on a live kernel. > > > > > > > > > > One big problem is that the lex and yacc files do not compile > > > > > well on SunOS. I work around this problem by using Linux to > > > > > produce *.c files from the source and then copying those files > > > > > by hand. > > > > > > > > > > Does anybody have encountered (and hopefully solved) this > > > > > problem? > > > > > > > > > > hiro > > > > > > > > -- > > > > Luc > > > > > -- Luc From owner-lkcd@oss.sgi.com Mon Jul 16 20:53:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H3r1E07775 for lkcd-outgoing; Mon, 16 Jul 2001 20:53:01 -0700 Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H3qtV07772 for ; Mon, 16 Jul 2001 20:52:55 -0700 Received: from m2.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id MAA06592 for ; Tue, 17 Jul 2001 12:52:47 +0900 (JST) (envelope-from j-kondo@pst.fujitsu.com) Received: from meow.aoi.pst.fujitsu.com by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id MAA12929 for ; Tue, 17 Jul 2001 12:52:46 +0900 (JST) (envelope-from j-kondo@pst.fujitsu.com) Received: from localhost (really [127.0.0.1]) by meow.aoi.pst.fujitsu.com via smail with esmtp id (Debian Smail3.2.0.102) for ; Tue, 17 Jul 2001 12:52:45 +0900 (JST) To: lkcd@oss.sgi.com Subject: Re: Module support From: Jyunji Kondo Reply-To: j-kondo@pst.fujitsu.com In-Reply-To: <3B53A7B9.B6BFB0B2@sgi.com> References: <20010717113618I.j-kondo@pst.fujitsu.com> <3B53A7B9.B6BFB0B2@sgi.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010717125245L.j-kondo@pst.fujitsu.com> Date: Tue, 17 Jul 2001 12:52:45 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 12 Sender: owner-lkcd@oss.sgi.com Precedence: bulk > Jyunji, Andreas Herrmann has been doing some work on a feature like this > one for lcrash. I'm not sure how complete Andreas's work is at this > time. I know there was also some legal issues involved in releasing that > work to the group. That's sounds nice. > Andreas, any status ? Please let me know any pointers about this work? Thanks. From owner-lkcd@oss.sgi.com Tue Jul 17 03:46:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HAkc515628 for lkcd-outgoing; Tue, 17 Jul 2001 03:46:38 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HAkXV15621 for ; Tue, 17 Jul 2001 03:46:34 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA201446; Tue, 17 Jul 2001 12:46:22 +0200 Received: from d12ml004.de.ibm.com (d12ml004_cs0 [9.165.223.50]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6HAkLa197258; Tue, 17 Jul 2001 12:46:21 +0200 Importance: Normal Subject: Re: Module support To: j-kondo@pst.fujitsu.com Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: "Michael Holzheu" Date: Tue, 17 Jul 2001 12:42:27 +0200 X-MIMETrack: Serialize by Router on D12ML004/12/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 12:44:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, We would like to include the following in lcrash: Andreas Herrmann added a new command "symtab" to add Symbol tables from modules which can be created e.g with the "nm" command. In addition to this the ksyms (what you can see in /proc/ksyms) are now used as additional symbol information. Another new command is the "module" command which lists all loaded Kernel Modules and the addresses where they are loaded to. Example: ======== module_test.c #include #include int test_glob_1 = 4711; int test_glob_2 = 0815; int init_module(void) { printk("test_mod_init\n"); return 0; } void cleanup_module(void) { printk("test_mod_cleanup\n"); } > nm module_test.o > module_test.map > lcrash ... >> symtab -a module_test.map module_test Adding symbol table. filename: module_test.map text_offset: 0x881b060 data_offset: 0x881b0e8 rodata_offset: 0x881b0c4 bss_offset: 0 text_length: 100 data_length: 8 rodata_length: 34 bss_length: 0 size: 496 ..Done. >> module ADDR SIZE USED NAME REFS =========================================================================== 0x881b000 496 0 module_test [] 0x880d000 49472 1 ctc [] 0x8800000 46960 0 md [] 0x1a5400 0 1 kernel_module [] =========================================================================== >> findsym test_glob_1 ADDR OFFSET TYPE NAME ============================================================ 0x881b0e8 0 GLOBAL_DATA test_glob_1 ============================================================ 1 symbol found >> print *(int*)0x881b0e8 4711 > Here is a short description of the new features: ====== Symtab: ====== COMMAND: symtab [-l [-f] [symtable]] [-r symtable] [-a symtable modulename] [-a symtable offset size] [-a symtable t_off d_off rd_off b_off t_len d_len rd_len b_len] [-w outfile] Add/remove/list symbol table information. OPTIONS: -l [symtable] List information of (all) symbol table(s). -l -f [symtable] Show full list of symbols of (all) symbol table(s). -a symtable modulename Add new symbol table belonging to module modulename. -a symtable t_off d_off rd_off b_off t_len d_len rd_len b_len Add new symbol table using given segment offsets and lengths (off=offset, len=length, t=text, d=data, rd=rodata, b=bss). -a symtable offset size Add new symbol table using given offset and size. Regard size as size of object file corresponding to symtable. -r symtable Remove symbol table. -a [ksymtab] -r [ksymtab] -l [-f] [ksymtab] Add, remove or list table of exported kernel symbols. You can use only one of the above command lines at the syme time. ====== Module: ====== COMMAND: module [modulename] [-f [modulename]] [-w outfile] Display list of loaded modules and module symbols. OPTIONS: [modulename] Display information of (all) module structure(s) in linked list module_list of the kernel. Shows address of module structure, and size, usecount, name of module, and modules that depend on the module. Equals "cat /proc/modules" in a running Linux system. [-f [modulename]] Show list of exported module symbols of (all) module structure(s) in linked list module_list of the kernel. Equals "cat /proc/ksyms" in a running Linux system. The kernel_module can be accessed by using "kernel_module" as modulename. Regards Michael ------------------------------------------------------------------------ Linux/390 Development Phone: +49-7031-16-2360, Bld 71032-06-109 Email: holzheu@de.ibm.com Jyunji Kondo on 07/17/2001 05:52:45 AM Please respond to j-kondo@pst.fujitsu.com To: lkcd@oss.sgi.com cc: Subject: Re: Module support > Jyunji, Andreas Herrmann has been doing some work on a feature like this > one for lcrash. I'm not sure how complete Andreas's work is at this > time. I know there was also some legal issues involved in releasing that > work to the group. That's sounds nice. > Andreas, any status ? Please let me know any pointers about this work? Thanks. From owner-lkcd@oss.sgi.com Tue Jul 17 06:25:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HDP5N19006 for lkcd-outgoing; Tue, 17 Jul 2001 06:25:05 -0700 Received: from missioncriticallinux.com ([208.51.139.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HDP3V19003 for ; Tue, 17 Jul 2001 06:25:03 -0700 Received: from missioncriticallinux.com (orourke-home.lowell.mclinux.com [10.2.1.10]) by missioncriticallinux.com (8.9.3/8.9.3) with ESMTP id JAA25258; Tue, 17 Jul 2001 09:24:55 -0400 Message-ID: <3B543BB1.1090306@missioncriticallinux.com> Date: Tue, 17 Jul 2001 09:20:49 -0400 From: "Patrick O'Rourke" Reply-To: orourke@missioncriticallinux.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Hiro Sugawara CC: "'lkcd@oss.sgi.com'" Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hiro Sugawara wrote: > Has anyone tried to make lcrash support modules. If no one has, > I guess I have to reverse-engineer the query_modules system call. > Am I correct? Our crash tool supports modules and can also interpret an lkcd crash dump file: http://www.missioncriticallinux.com/technology/crash/ - pat -- Patrick O'Rourke 978.606.0236 orourke@missioncriticallinux.com From owner-lkcd@oss.sgi.com Tue Jul 17 11:23:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HINr526602 for lkcd-outgoing; Tue, 17 Jul 2001 11:23:53 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HINqV26598 for ; Tue, 17 Jul 2001 11:23:52 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6HIJus26408; Tue, 17 Jul 2001 11:19:56 -0700 Message-ID: <3B5482EB.900B1951@alacritech.com> Date: Tue, 17 Jul 2001 11:24:43 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: orourke@missioncriticallinux.com CC: Hiro Sugawara , "'lkcd@oss.sgi.com'" Subject: Re: Module support References: <3B543BB1.1090306@missioncriticallinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Patrick O'Rourke wrote: > > Hiro Sugawara wrote: > > > Has anyone tried to make lcrash support modules. If no one has, > > I guess I have to reverse-engineer the query_modules system call. > > Am I correct? > > Our crash tool supports modules and can also interpret an lkcd > crash dump file: > > http://www.missioncriticallinux.com/technology/crash/ > > - pat > > -- > Patrick O'Rourke > 978.606.0236 > orourke@missioncriticallinux.com One of the things we have wanted to do is to take the functions provided in MCL's work and build them into LKCD, so there aren't duplicated efforts. I know that ultimately this is the goal. I've tried contact Pat in the past, but haven't had any luck. :) I know lcrash has an extensive set of commands -- module support will be the last of the really "required" items. --Matt From owner-lkcd@oss.sgi.com Tue Jul 17 11:47:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HIle427438 for lkcd-outgoing; Tue, 17 Jul 2001 11:47:40 -0700 Received: from missioncriticallinux.com ([208.51.139.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HIldV27435 for ; Tue, 17 Jul 2001 11:47:39 -0700 Received: from missioncriticallinux.com (orourke.lowell.mclinux.com [10.1.8.59]) by missioncriticallinux.com (8.9.3/8.9.3) with ESMTP id OAA26686; Tue, 17 Jul 2001 14:47:18 -0400 Message-ID: <3B548889.6010506@missioncriticallinux.com> Date: Tue, 17 Jul 2001 14:48:41 -0400 From: "Patrick O'Rourke" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: "Matt D. Robinson" CC: Hiro Sugawara , "'lkcd@oss.sgi.com'" Subject: Re: Module support References: <3B543BB1.1090306@missioncriticallinux.com> <3B5482EB.900B1951@alacritech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Matt D. Robinson wrote: > One of the things we have wanted to do is to take the functions > provided in MCL's work and build them into LKCD, so there aren't > duplicated efforts. I know that ultimately this is the goal. > I've tried contact Pat in the past, but haven't had any luck. :) Sorry about that. You had sent mail to me and Mike Keefe and I saw that Mike had responded to you and seemed to answer your question. Let me know if this is not the case and I will try to provide more info. I am not doing any active development on lkcd, lcrash or crash at the moment, so Mike is better suited than I to respond in any event. Pat -- Patrick O'Rourke 978.606.0236 orourke@missioncriticallinux.com From owner-lkcd@oss.sgi.com Tue Jul 17 12:32:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HJWhg28915 for lkcd-outgoing; Tue, 17 Jul 2001 12:32:43 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HJWgV28911 for ; Tue, 17 Jul 2001 12:32:43 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA22800 for ; Tue, 17 Jul 2001 12:32:37 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 12:32:37 -0700 Message-ID: From: Hiro Sugawara To: lkcd@oss.sgi.com Cc: Les Smith , Raghaua Vatsavayi Subject: RE: Module support Date: Tue, 17 Jul 2001 12:32:35 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk > -----Original Message----- > From: KONDO Jyunji [mailto:j-kondo@pst.fujitsu.com] > Sent: Monday, July 16, 2001 19:36 > To: lkcd@oss.sgi.com > Subject: Re: Module support > > > > Hi, hiro. > > > Has anyone tried to make lcrash support modules. If no one has, > > I guess I have to reverse-engineer the query_modules system call. > > Am I correct? > > We are trying to do that by extending lcrash and using ksymoops. > > > Since most of our proprietary kernel code (device drivers) is > > in module, LKCD is not very useful with module support... ^^^^ Of course, I meant _without_ ;-) > I agree... > > At the moment, we are fixing our ideas and we'll be post it to this > group soon. > Please wait a moment. I'm happy to know that it sounds like there are some activities going on about modules support. I'd like to see a fairly automated mechanism like GDB's shared library auto-loading. I would expect a few new commands like "set module-prefix" and "lsmod." The "set module-prefix" command sets the module file loading path prefix which is necessary for a cross environment where lcrash runs on a different machine from the target; "lsmod" should be almost identical to Linux' lsmod with additional module loading address display. BTW, I have always been thinking that the "System.map" argument is redundant. It could be replaced with a shell command line like: `nm vmlinux|awk --posix '{if ($1 ~ /c[[:xdigit:]]{7}$) print}'|sort|uniq` (Some nm's seem to use 64 bit addresses. So, do not put an assumption of an 8-digit address field) This way, lcrash would only need the module binary files (with debug information for the better, but not mandatory). hiro From owner-lkcd@oss.sgi.com Tue Jul 17 19:27:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I2RR322003 for lkcd-outgoing; Tue, 17 Jul 2001 19:27:27 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I2RQV22000 for ; Tue, 17 Jul 2001 19:27:26 -0700 Received: from m7.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id LAA17063 for ; Wed, 18 Jul 2001 11:27:19 +0900 (JST) (envelope-from tachino@open.nm.fujitsu.co.jp) Received: from estartu.open.nm.fujitsu.co.jp by m7.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id LAA31496 for ; Wed, 18 Jul 2001 11:27:19 +0900 (envelope-from tachino@open.nm.fujitsu.co.jp) Received: from nisaaru.open.nm.fujitsu.co.jp (nisaaru.open.nm.fujitsu.co.jp [10.34.166.107]) by estartu.open.nm.fujitsu.co.jp (Postfix) with ESMTP id AB6FB1049; Wed, 18 Jul 2001 11:27:17 +0900 (JST) Date: Wed, 18 Jul 2001 11:27:17 +0900 Message-ID: From: Tachino Nobuhiro To: Hiro Sugawara Cc: lkcd@oss.sgi.com, Les Smith , Raghaua Vatsavayi Subject: Re: Module support In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) EMY/1.13.9 (Art is long, life is short) SLIM/1.14.7 () APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i586-kondara-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, At Tue, 17 Jul 2001 12:32:35 -0700, Hiro Sugawara wrote: > BTW, I have always been thinking that the "System.map" argument is > redundant. It could be replaced with a shell command line like: > > `nm vmlinux|awk --posix '{if ($1 ~ /c[[:xdigit:]]{7}$) print}'|sort|uniq` > (Some nm's seem to use 64 bit addresses. So, do not put an assumption > of an 8-digit address field) > > This way, lcrash would only need the module binary files (with debug > information for the better, but not mandatory). > You cannot use vmlinux if it is replaced by kernel update or any other reason. System.map is OK because it is saved with a crash dump by vmdump. I think module support requires the same function. You need the symbol maps of modules which was actually loaded when a crash occurred. From owner-lkcd@oss.sgi.com Wed Jul 18 02:14:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I9Emo15948 for lkcd-outgoing; Wed, 18 Jul 2001 02:14:48 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I9EjV15942 for ; Wed, 18 Jul 2001 02:14:45 -0700 Received: from m6.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id SAA25180 for ; Wed, 18 Jul 2001 18:14:38 +0900 (JST) (envelope-from ohno@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com by m6.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id SAA22629 for ; Wed, 18 Jul 2001 18:14:26 +0900 (envelope-from ohno@pst.fujitsu.com) Received: from pst.fujitsu.com (vivace.aoi.pst.fujitsu.com [172.23.72.231]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with ESMTP id SAA31608; Wed, 18 Jul 2001 18:14:16 +0900 Message-ID: <3B5552DF.1040103@pst.fujitsu.com> Date: Wed, 18 Jul 2001 18:11:59 +0900 From: "T.Ohno" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; JAPressMailingNov00) Gecko/20001108 Netscape6/6.0 X-Accept-Language: ja MIME-Version: 1.0 To: lkcd@oss.sgi.com CC: j-kondo@pst.fujitsu.com Subject: Re: Module support References: <20010717113618I.j-kondo@pst.fujitsu.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Dear all KONDO Jyunji wrote: > Hi, hiro. > > >> Has anyone tried to make lcrash support modules. If no one has, >> I guess I have to reverse-engineer the query_modules system call. >> Am I correct? > > > We are trying to do that by extending lcrash and using ksymoops. > > >> Since most of our proprietary kernel code (device drivers) is >> in module, LKCD is not very useful with module support... > > > I agree... > > At the moment, we are fixing our ideas and we'll be post it to this > group soon. > Please wait a moment. I am a Jyunji's co-worker. Now I will post our idea. I think Andreas's ideas are effective at debugging a specific module. Our idea is different from his one and aims at the investigation for detecting a system crash reason. Currently we are planning following procedure. 1. Extract symbols for debugging modules from dump file by using a new lcrash option or a dedicated command. 2. Create a System.map file including the all symbols of loaded modules by passing the result of #1 to ksymoops command. Using this System.map, the symbols of all modules which was loaded in kernel when system crash occurred are referable. In Andreas's idea, the modules installed at system crash or module map files must be saved and the map files must be loaded each lcrash. In our idea, as the System.map at the system crash is generated, module replacement causes no problem (of course after generating System.map) and the dump is analyzable at another machine. Any comment and suggestion are welcomed. Toshio Ohno From owner-lkcd@oss.sgi.com Wed Jul 18 06:58:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IDwDu08833 for lkcd-outgoing; Wed, 18 Jul 2001 06:58:13 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IDwAV08830 for ; Wed, 18 Jul 2001 06:58:10 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA200314 for ; Wed, 18 Jul 2001 15:57:59 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IDvxC142568 for ; Wed, 18 Jul 2001 15:57:59 +0200 Importance: Normal Subject: Re: Module support To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Wed, 18 Jul 2001 15:56:36 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 15:56:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk (Sorry for the late reply, I was on vacation until yesterday.) Luc Chouinard wrote: >Jyunji, Andreas Herrmann has been doing some work on a feature like this >one for lcrash. I'm not sure how complete Andreas's work is at this >time. I know there was also some legal issues involved in releasing that >work to the group. > >Andreas, any status ? I regard my work on this subject as finished. Of course, as always there is plenty of room for minor enhancements. The actual show stopper is the legal clearance issue. I can just say, we will check in the new stuff as soon as we have the legal clearance to do so. I know this situation is not satisfactory, but I can't help it. When we do the check-in we will tag the old lkcd version, so everybody can play around with the new commands. And if anybody dislikes the new stuff, an easy fallback to the old version can be made. Michael Holzheu has given already some information about the new stuff. Let me give some additional explanation. The new command "module" helps to investigate module structures in the dump. The starting point is the variable module_list of the kernel. It is the anchor of a chained list of structures of kind "struct module". Some information, received from these structs, can be displayed by using the "module" command. The second new command is "symtab". It is used for handling of multiple symbol tables. You can add, remove and show information of symbol tables. The command can automatically detect the segment offsets when symbol tables for modules are loaded. It uses a mechanism like ksymoops to detect the offsets. By the way, lcrash creates an additional symbol table "ksymtab" during startup. It contains all exported kernel symbols. From this table the segment offsets of modules are extracted. But the exploitation of this symbol table can and should be improved to use it as a default table when searching for symbols during "dis", "trace" etc. The advantages in having multiple symbol tables are: - findsym, dis, trace, strace, whatis commands can find symbol names of functions located in modules (iff symbol tables were previously added) - symbol tables can be removed and again added without restart of lcrash - I find it quite comfortable, if wrong table was loaded or while playing around with a live system and different module versions So, I ask you to be patient until we have our internal o.k. to check in the stuff. Regards, Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com Jyunji Kondo on 07/17/2001 05:52:45 AM Please respond to j-kondo@pst.fujitsu.com To: lkcd@oss.sgi.com cc: Subject: Re: Module support > Jyunji, Andreas Herrmann has been doing some work on a feature like this > one for lcrash. I'm not sure how complete Andreas's work is at this > time. I know there was also some legal issues involved in releasing that > work to the group. That's sounds nice. > Andreas, any status ? Please let me know any pointers about this work? Thanks. From owner-lkcd@oss.sgi.com Wed Jul 18 07:15:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IEFb510262 for lkcd-outgoing; Wed, 18 Jul 2001 07:15:37 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IEFYV10255 for ; Wed, 18 Jul 2001 07:15:34 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA53866 for ; Wed, 18 Jul 2001 16:15:26 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IEFQC147840 for ; Wed, 18 Jul 2001 16:15:26 +0200 Importance: Normal Subject: Re: Module support To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Wed, 18 Jul 2001 16:14:03 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 16:14:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk >I am a Jyunji's co-worker. Now I will post our idea. > >I think Andreas's ideas are effective at debugging >a specific module. > >Our idea is different from his one and aims at the >investigation for detecting a system crash reason. > >Currently we are planning following procedure. > > 1. Extract symbols for debugging modules from > dump file by using a new lcrash option or a > dedicated command. Which symbols do you like to extract from the dump? As far as I know, the Linux system stores only information about exported kernel symbols (ksyms). Usually only some symbols of kernel modules are exported. Hence, your method will likely miss the majority of symbol information for modules. > > 2. Create a System.map file including the all > symbols of loaded modules by passing the > result of #1 to ksymoops command. > >Using this System.map, the symbols of all modules >which was loaded in kernel when system crash occurred >are referable. > I think this is wrong. As above mentioned, only some symbols of loaded modules can be referred. And maybe the system has died while calling a module function, for which the symbol was not exported ... >In Andreas's idea, the modules installed at system >crash or module map files must be saved and the map files >must be loaded each lcrash. > I think we have two problems in current lcrash version. First: Map-files (System.map, symbol information for modules), "namelists" (Kerntypes, object files containing type information for modules), and the dump must belong together. So, it is a little tricky to collect all corresponding files in order to analyze a dump of a customer. Second: Currently there is no automatism to load symbol tables and namelists. To "disarm" the situation we should think about the following: - Receive symbol table not from map file, but from non-stripped object file. So, one object file (compiled with -gstabs) can be used to load both symbol and type information of a module. It means to let lcrash extract symbol information itself - like "nm" does. This way assumes, that compile option -gstabs generates the same code as without the option. Is this really the case for all supported lkcd-platforms? - Don't generate a separate Kerntypes file but use vmlinux (compiled with -gstabs) itself for symbol and type information of the kernel. In order to do so, the kernel build process must be patched to spy out also this vmlinux version of the kernel. - Introduction of a configuration file. E.g., there could be stored the information, which symbol table and namelist to load for which module. >In our idea, as the System.map at the system crash is >generated, module replacement causes no problem >(of course after generating System.map) >and the dump is analyzable at another machine. > >Any comment and suggestion are welcomed. > > >Toshio Ohno Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Wed Jul 18 08:05:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IF5sW14540 for lkcd-outgoing; Wed, 18 Jul 2001 08:05:54 -0700 Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IF5pV14537 for ; Wed, 18 Jul 2001 08:05:51 -0700 Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id BAA10870; Thu, 19 Jul 2001 01:02:15 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6IF5GU109192; Thu, 19 Jul 2001 01:05:16 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A8D.0052E0AB ; Thu, 19 Jul 2001 01:05:14 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: "Matt D. Robinson" , lkcd@oss.sgi.com Message-ID: Date: Wed, 18 Jul 2001 20:24:44 +0530 Subject: Non-disruptive dumps - expanding on the steps Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk This note expands on the steps listed in the earlier posting on non-disruptive (vs standalone ) dumps (with non-disruptive dumps, the system is expected to continue running after the dump is taken, but it is desirable to have an accurate consistent snapshot of the system). A slight digression on the point of accuracy vs consistency: Perfect accuracy would imply capturing the snapshot of the system, as is, at the exact instant when the dump was triggered, even if it is in an intermediate/ inconsistent state. Consistency, on the other hand would apply to related data/state within the snapshot being consistent with each other, for correct interpretation of some of data values to be possible. If a dump is triggered when state modifications are in progress and have not reached a consistency point, then in order to get consistent data, one may wait for the consistency point to be reached, typically by acquiring related (read)locks before capturing the state. Obviously, the kind of state that needs to be consistent depends on the kind of related data that the interpretation mechanism, or dump marshalling logic hinges on and hence requires consistency for. There is a requirement level tradeoff between the two, so in general, the objective is to attain maximum accuracy (minimum drift) while maintaining the minimum consistency requirements. Now onto the steps: This is again a high level view - more details on quiesce to follow as separate notes (in a drill down philosophy) : 1. Send an IPI to other CPUs to get them to capture their register state (i.e. save it in a memory area). Mechanism to initiate this: - Using an NMI IPI would help with accuracy (though it still would take non-zero time for the other CPUs to receive the IPI). However, during the later steps, spinning the CPU within this NMI handler while dump is in progress may not be appropriate. In such a case we could also consider saving the stack contents, in case spinning is postponed to outside of the NMI (which could affect consistency) - With a non-NMI IPI, there is a lesser likelihood of the above problem, though there would be a little more drift as the other CPUs wouldn't service the IPI as long as interrupts are disabled on those CPUs. BTW, the register state for the dumping CPU should also be saved in memory likewise. 2. Quiesce (to the minimal extent necessary for the following to work without disrupting the system). Here "quiesce" means waiting till the system reaches a (stable) state where dump can be initiated. There are 3 aspects: i. h/w state quiesce for i/o to work (transient states, in-flight DMA's or ios ) ii. s/w state quiesce for dump i/o s/w path to work (relevant locks / data structure consistencies, if we use the standard i/o path rather than a separate raw dump interface) iii. s/w state quiesce for dump data consistency Because a dump can be triggered at any point, for ii and iii, self-deadlocks with interrupted code on the same processor need to be avoided (self-deadlocks may sometimes appear in not-so-obvious ways as in the problem with dumping from interrupt context ). For this reason it may help to have the actual dump execute under a legal, preferably, separate thread of context, which gets activated on reaching a quiesce* on at least one CPU and waits for a complete quiesce prior to dump. (In (1), the register state, stack etc at the instant of dumping would have already been saved, so this is not lost during the quiesce, though other memory state drift may need to be dealt with). [*Will treat quiesce point detection as a separate subject ] Some of the things this involves: - Stop fresh operations from happening (some kind way to make the system and drivers hold off new work ) - Wait for relevant existing in-flight operations to drain out (some mechanism/support for getting notified about or explicitly poll for completion) Now, if we go via standard device driver interfaces then the wait required for (i) would happen automatically. If the dump device has a separate queue, and we issue the i/o from a legal context as far the system is concerned (avoid self-deadlock type situations) then (ii) would also get taken care of. As far as iii is concerned this is specific to the kind of data dumped, so won't discuss that rightway. The tradeoff which we have to consider as we quiesce is the drift that occurs during this time: We do have a segment/page protection based COW scheme in mind for being able to retain a snapshot at the point in time of dump, while system state changes, which we can detail in a separate note, but haven't yet figured out if the complexity (and additional resource requirements) for this is worth it. With that in place we should be able to do with minimal disruption, but its not without tradeoffs. The other aspect is to hold off new operations until the dump is complete. - Let other CPUs spin when they reach quiesce point, so that they don't generate any more activity - (Debatable/Optional) Interface with drivers to delay processing requests till dump is done (if this is possible). In some cases, this may involve blocking handling of interrupts / incoming packets or avoid feeding further (non-dump) i/os down post interrupt handling/non-task time. This calls for caution because the effects of such delays may result in some disruption (e.g loss of packets on a network interface) of the system. - Turn off scheduling/switches to other tasks (so that wait's in the dump code path don't schedule anything else to run ) 3. Set things up for i/o to dump device to work . This may involve waiting till the setup is done. Also before changing anything on the system, save associated state so we can restore these back to original settings after we are done. This may not be required as a separate step in general if we are using existing i/o paths/interfaces and not disabling interrupt handling on other CPUs. If we did know exactly which interrupts are involved, then we could have temporarily blocked all others (provided that does not affect continuation of operation after a dump), but that requires special support from the driver which may be hard. With a raw dump interface there may be dump_prepare request issued on the interface. 4. Perform actual dumping. Wait for completion. This is where the dump logic fits in - it picks up the dump snapshot pages and writes them out to the dump device, via either - The standard i/o path or - Raw dump interface (if the dump device driver supports one) 5. Restore the settings changed just for dump (i.e. get system ready to continue normal operation) This applies if we had any special device setup or interrupts disabling / irq changes in 3 above. 6. Release the system (i.e. let it continue) Unfreeze whatever was held up in step 2. Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Wed Jul 18 09:45:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IGjbo20119 for lkcd-outgoing; Wed, 18 Jul 2001 09:45:37 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IGjZV20115 for ; Wed, 18 Jul 2001 09:45:35 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA17615 for ; Wed, 18 Jul 2001 09:45:30 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 09:45:30 -0700 Message-ID: From: Hiro Sugawara To: lkcd@oss.sgi.com Subject: RE: Module support Date: Wed, 18 Jul 2001 09:45:29 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk I may be missing something. I thought System.map is a file that is created when the kernel is built; therefore if System.map is available and valid, so is vmlinux. In other words, I am using lcrash like: # lcrash /usr/src/linux/System.map /dev/mem /usr/src/linux/vmlinux I could not find the "KernTypes" file and finally found vmlinux worked as the third argument after some experiments. Am I wrong? hiro > -----Original Message----- > From: Tachino Nobuhiro [mailto:tachino@open.nm.fujitsu.co.jp] > Sent: Tuesday, July 17, 2001 19:27 > To: Hiro Sugawara > Cc: lkcd@oss.sgi.com; Les Smith; Raghaua Vatsavayi > Subject: Re: Module support > > > > Hi, > > At Tue, 17 Jul 2001 12:32:35 -0700, > Hiro Sugawara wrote: > > > BTW, I have always been thinking that the "System.map" argument is > > redundant. It could be replaced with a shell command line like: > > > > `nm vmlinux|awk --posix '{if ($1 ~ /c[[:xdigit:]]{7}$) > print}'|sort|uniq` > > (Some nm's seem to use 64 bit addresses. So, do not put an > assumption > > of an 8-digit address field) > > > > This way, lcrash would only need the module binary files (with debug > > information for the better, but not mandatory). > > > > You cannot use vmlinux if it is replaced by kernel update or > any other reason. System.map is OK because it is saved with a > crash dump by > vmdump. > I think module support requires the same function. You need the > symbol maps of modules which was actually loaded when a crash > occurred. > From owner-lkcd@oss.sgi.com Wed Jul 18 12:25:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IJPeS24247 for lkcd-outgoing; Wed, 18 Jul 2001 12:25:40 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IJPcV24238 for ; Wed, 18 Jul 2001 12:25:38 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA02109 for ; Wed, 18 Jul 2001 12:25:32 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 12:25:32 -0700 Message-ID: From: Hiro Sugawara To: lkcd@oss.sgi.com Subject: RE: Module support Date: Wed, 18 Jul 2001 12:25:31 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Thanks for the information, Andreas. I am actually wondering if I need to implement the front-end portion by myself with a different approach because our Linux application is purely embedded: The target system does not have a swap device and instead a dedicated 1MB flash memory is assigned for kernel crash dump saving. Well, the system has a total of 64MB RAM partially used for RAMfs. So, unless I can invent a super compression algorithm of some 64 to 1, I need to make lkcd save only selected memory segments of "true interest" because I cannot have the luxury of saving the whole memory contents. So, we are developing a prioritized kernel memory coloring scheme for crash dump saving. For example, the current process' task_struct and stack are the most important followed by those of "user processes." The kernel's static storage (data and bss) is also interesting but it's probably difficult to save the entire kernel heap. Another area for reducing the dump size may be improvement of data compression. I am not a data compression algorithm expert, but I can expect, even with the current simple RL algorithm, some saving by zero-clearing each process stack in sys_fork (if not yet done so). So, as to the module list, I may wish to save a "module directory" segment with a flags bit set in the page header instead of having lcrash search for it in the general page dump. If each module's name, file path, and text, data, bss base addresses are saved, it's not too difficult to relocate the symbols in the module file lcrash. Any suggestions are welcomed. hiro > -----Original Message----- > From: Andreas Herrmann [mailto:AHERRMAN@de.ibm.com] > Sent: Wednesday, July 18, 2001 06:57 > To: lkcd@oss.sgi.com > Subject: Re: Module support > The new command "module" helps to investigate module structures in > the dump. The starting point is the variable module_list of the > kernel. It is the anchor of a chained list of structures of kind > "struct module". Some information, received from these structs, > can be displayed by using the "module" command. > The second new command is "symtab". It is used for handling of > multiple symbol tables. You can add, remove and show information of > symbol tables. The command can automatically detect the segment > offsets when symbol tables for modules are loaded. It uses a mechanism > like ksymoops to detect the offsets. > By the way, lcrash creates an additional symbol table "ksymtab" during > startup. It contains all exported kernel symbols. From this table the > segment offsets of modules are extracted. But the exploitation of this > symbol table can and should be improved to use it as a default > table when searching for symbols during "dis", "trace" etc. > > The advantages in having multiple symbol tables are: > - findsym, dis, trace, strace, whatis commands can find symbol > names of functions located in modules (iff symbol tables were > previously added) > - symbol tables can be removed and again added without restart of > lcrash - I find it quite comfortable, if wrong table was loaded or > while playing around with a live system and different module > versions From owner-lkcd@oss.sgi.com Wed Jul 18 13:36:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IKasL30256 for lkcd-outgoing; Wed, 18 Jul 2001 13:36:54 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IKaqV30252 for ; Wed, 18 Jul 2001 13:36:52 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6IKWvs32104; Wed, 18 Jul 2001 13:32:57 -0700 Message-ID: <3B55F39A.39F00B65@alacritech.com> Date: Wed, 18 Jul 2001 13:37:46 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Herrmann CC: lkcd@oss.sgi.com Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Andreas Herrmann wrote: > > >I am a Jyunji's co-worker. Now I will post our idea. > > > >I think Andreas's ideas are effective at debugging > >a specific module. > > > >Our idea is different from his one and aims at the > >investigation for detecting a system crash reason. > > > >Currently we are planning following procedure. > > > > 1. Extract symbols for debugging modules from > > dump file by using a new lcrash option or a > > dedicated command. > > Which symbols do you like to extract from the dump? > As far as I know, the Linux system stores only information > about exported kernel symbols (ksyms). Usually only some > symbols of kernel modules are exported. Hence, your method > will likely miss the majority of symbol information for modules. > > > > > 2. Create a System.map file including the all > > symbols of loaded modules by passing the > > result of #1 to ksymoops command. > > > >Using this System.map, the symbols of all modules > >which was loaded in kernel when system crash occurred > >are referable. > > > > I think this is wrong. As above mentioned, only some symbols of > loaded modules can be referred. And maybe the system has died > while calling a module function, for which the symbol was not > exported ... > > >In Andreas's idea, the modules installed at system > >crash or module map files must be saved and the map files > >must be loaded each lcrash. > > > > I think we have two problems in current lcrash version. > > First: Map-files (System.map, symbol information for > modules), "namelists" (Kerntypes, object files containing type information > for > modules), and the dump must belong together. So, it is a little tricky > to collect all corresponding files in order to analyze a dump of a > customer. This is a fundamental problem in the kernel build mechanisms. It would be nice to avoid this scenario, but there's no clear way of merging any of the files together. I don't view this as an lcrash problem, but a kernel build problem. > Second: Currently there is no automatism to load symbol tables and > namelists. I'm not sure what you mean here ... you don't mean what 'vmdump save' does, right? Are you talking about copying the files to /boot, or saving them to /var/log/vmdump, or something else? > To "disarm" the situation we should think about the following: > - Receive symbol table not from map file, but from non-stripped object > file. > So, one object file (compiled with -gstabs) can be used to load both > symbol and type information of a module. It means to let lcrash extract > symbol > information itself - like "nm" does. This way assumes, that compile > option -gstabs generates the same code as without the option. > Is this really the case for all supported lkcd-platforms? > - Don't generate a separate Kerntypes file but use vmlinux > (compiled with -gstabs) itself for symbol and type information of the > kernel. Most people won't put up with building their entire kernel -gstabs. If that were the case, we would have done that a long time ago. I think it would be _GREAT_ to have that, but most people gag on the idea of putting all symbols into the kernel, as it creates huge kernels. > In order to do so, the kernel build process must be patched to spy out > also > this vmlinux version of the kernel. > - Introduction of a configuration file. E.g., there could be stored the > information, which symbol table and namelist to load for which module. We already tie the symbol.map file and the kernel together via a kernel_magic field. If that isn't working correctly, it should be fixed. Alternatively, we can tie all three together via the same mechanism. > >In our idea, as the System.map at the system crash is > >generated, module replacement causes no problem > >(of course after generating System.map) > >and the dump is analyzable at another machine. > > > >Any comment and suggestion are welcomed. > > > > > >Toshio Ohno > > Andreas > > -- > Linux for eServer Development > Tel : +49-7031-16-4640 > Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE > email : aherrman@de.ibm.com Good notes ... --Matt From owner-lkcd@oss.sgi.com Wed Jul 18 13:44:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IKi0b30777 for lkcd-outgoing; Wed, 18 Jul 2001 13:44:00 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IKhwV30774 for ; Wed, 18 Jul 2001 13:43:58 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6IKe5s32281; Wed, 18 Jul 2001 13:40:06 -0700 Message-ID: <3B55F546.419B21BA@alacritech.com> Date: Wed, 18 Jul 2001 13:44:54 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hiro Sugawara CC: lkcd@oss.sgi.com Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hiro Sugawara wrote: > > I may be missing something. I thought System.map is a file that is > created when the kernel is built; therefore if System.map is available > and valid, so is vmlinux. In other words, I am using lcrash like: > # lcrash /usr/src/linux/System.map /dev/mem /usr/src/linux/vmlinux > > I could not find the "KernTypes" file and finally found vmlinux worked > as the third argument after some experiments. > > Am I wrong? > > hiro If you don't have a Kerntypes file, you should build one. It is basically a .o file that includes linux/sched.h, but is built with -gstabs. It should be very easy to build (and if you have the LKCD patches installed, it's already built for you). Don't use 'vmlinux' as the Kerntypes (unless, of course, you're building your entire kernel with -gstabs). Otherwise, you're going to get some wierd results. :) --Matt > > > -----Original Message----- > > From: Tachino Nobuhiro [mailto:tachino@open.nm.fujitsu.co.jp] > > Sent: Tuesday, July 17, 2001 19:27 > > To: Hiro Sugawara > > Cc: lkcd@oss.sgi.com; Les Smith; Raghaua Vatsavayi > > Subject: Re: Module support > > > > > > > > Hi, > > > > At Tue, 17 Jul 2001 12:32:35 -0700, > > Hiro Sugawara wrote: > > > > > BTW, I have always been thinking that the "System.map" argument is > > > redundant. It could be replaced with a shell command line like: > > > > > > `nm vmlinux|awk --posix '{if ($1 ~ /c[[:xdigit:]]{7}$) > > print}'|sort|uniq` > > > (Some nm's seem to use 64 bit addresses. So, do not put an > > assumption > > > of an 8-digit address field) > > > > > > This way, lcrash would only need the module binary files (with debug > > > information for the better, but not mandatory). > > > > > > > You cannot use vmlinux if it is replaced by kernel update or > > any other reason. System.map is OK because it is saved with a > > crash dump by > > vmdump. > > I think module support requires the same function. You need the > > symbol maps of modules which was actually loaded when a crash > > occurred. > > From owner-lkcd@oss.sgi.com Wed Jul 18 13:58:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IKw2b32066 for lkcd-outgoing; Wed, 18 Jul 2001 13:58:02 -0700 Received: from missioncriticallinux.com ([208.51.139.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IKw1V32063 for ; Wed, 18 Jul 2001 13:58:01 -0700 Received: from mclinux.com (IDENT:anderson@anderson.lowell.mclinux.com [10.1.8.20]) by missioncriticallinux.com (8.9.3/8.9.3) with ESMTP id QAA09536 for ; Wed, 18 Jul 2001 16:57:57 -0400 Message-ID: <3B55F83C.3D2166E5@mclinux.com> Date: Wed, 18 Jul 2001 16:57:32 -0400 From: Dave Anderson Organization: Mission Critical Linux X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15smp2 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: Re: Module support References: <3B55F39A.39F00B65@alacritech.com> Content-Type: multipart/alternative; boundary="------------96038C9B341644096018F835" Sender: owner-lkcd@oss.sgi.com Precedence: bulk --------------96038C9B341644096018F835 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Most people won't put up with building their entire kernel -gstabs. If that were the case, we would have done that a long time ago. I think it would be _GREAT_ to have that, but most people gag on the idea of putting all symbols into the kernel, as it creates huge kernels. I've never quite understood this. We build our kernels with -g for the whole kernel, and to be sure, it creates a much larger vmlinux file -- maybe on the order of 4 times as large. But what gets loaded into the bzImage file, and subsequently into memory, hardly changes at all. In fact, if you also delete -fomit_frame_pointer along with adding -g, the kernel is actually smaller! (I'm guessing because of less aggressive in-lining?). Am I missing something here? Dave Anderson --------------96038C9B341644096018F835 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Most people won't put up with building their entire kernel -gstabs.
If that were the case, we would have done that a long time ago.  I
think it would be _GREAT_ to have that, but most people gag on the
idea of putting all symbols into the kernel, as it creates huge
kernels.

I've never quite understood this.  We build our kernels
with -g for the whole kernel, and to be sure, it
creates a much larger vmlinux file -- maybe on the
order of 4 times as large.  But what gets loaded
into the bzImage file, and subsequently into memory,
hardly changes at all.  In fact, if you also delete
-fomit_frame_pointer along with adding -g, the kernel
is actually smaller! (I'm guessing because of less
aggressive in-lining?).

Am I missing something here?

Dave Anderson
 
 
  --------------96038C9B341644096018F835-- From owner-lkcd@oss.sgi.com Wed Jul 18 14:20:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ILKtD01891 for lkcd-outgoing; Wed, 18 Jul 2001 14:20:55 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ILKsV01888 for ; Wed, 18 Jul 2001 14:20:54 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6ILH1s01031; Wed, 18 Jul 2001 14:17:01 -0700 Message-ID: <3B55FDEE.B71BD185@alacritech.com> Date: Wed, 18 Jul 2001 14:21:50 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Anderson CC: lkcd@oss.sgi.com Subject: Re: Module support References: <3B55F39A.39F00B65@alacritech.com> <3B55F83C.3D2166E5@mclinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Dave Anderson wrote: > > Most people won't put up with building their entire kernel -gstabs. > If that were the case, we would have done that a long time ago. I > think it would be _GREAT_ to have that, but most people gag on the > idea of putting all symbols into the kernel, as it creates huge > kernels. > > I've never quite understood this. We build our kernels > with -g for the whole kernel, and to be sure, it > creates a much larger vmlinux file -- maybe on the > order of 4 times as large. But what gets loaded > into the bzImage file, and subsequently into memory, > hardly changes at all. In fact, if you also delete > -fomit_frame_pointer along with adding -g, the kernel > is actually smaller! (I'm guessing because of less > aggressive in-lining?). You omit the frame pointer because it takes an extra register on x86 systems, which can slow the machine down tremendously (it has to do more with fewer registers). > Am I missing something here? > > Dave Anderson No, you're not missing the point. People just don't like to see large kernels. Trust me, I'd like to see -gstabs as a default for all systems, but Linus gagged on the idea about two years ago when I asked. Maybe things are different now ... Heh. :) Nice to see you again, Dave ... it's been a while. :) --Matt From owner-lkcd@oss.sgi.com Wed Jul 18 14:23:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ILNEK02129 for lkcd-outgoing; Wed, 18 Jul 2001 14:23:14 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ILNBV02123 for ; Wed, 18 Jul 2001 14:23:11 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6ILJHs01083; Wed, 18 Jul 2001 14:19:17 -0700 Message-ID: <3B55FE76.FBAF0769@alacritech.com> Date: Wed, 18 Jul 2001 14:24:06 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: bsuparna@in.ibm.com CC: lkcd@oss.sgi.com Subject: Re: Non-disruptive dumps - expanding on the steps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk bsuparna@in.ibm.com wrote: > > This note expands on the steps listed in the earlier posting on > non-disruptive (vs standalone ) dumps (with non-disruptive dumps, the > system is expected to continue running after the dump is taken, but it is > desirable to have an accurate consistent snapshot of the system). > > A slight digression on the point of accuracy vs consistency: > > Perfect accuracy would imply capturing the snapshot of the system, as is, > at the exact instant when the dump was triggered, even if it is in an > intermediate/ inconsistent state. This is always going to be unlikely for SMP systems, but it's a nice goal. Interrupts on secondary processors at the time of the system panic can cause all kinds of wierd results when you try and analyze the state after the crash. > Consistency, on the other hand would apply to related data/state within the > snapshot being consistent with each other, for correct interpretation of > some of data values to be possible. If a dump is triggered when state > modifications are in progress and have not reached a consistency point, > then in order to get consistent data, one may wait for the consistency > point to be reached, typically by acquiring related (read)locks before > capturing the state. Obviously, the kind of state that needs to be > consistent depends on the kind of related data that the interpretation > mechanism, or dump marshalling logic hinges on and hence requires > consistency for. > > There is a requirement level tradeoff between the two, so in general, the > objective is to attain maximum accuracy (minimum drift) while maintaining > the minimum consistency requirements. > > Now onto the steps: > > This is again a high level view - more details on quiesce to follow as > separate notes (in a drill down philosophy) : > > 1. Send an IPI to other CPUs to get them to capture their register state > (i.e. save it in a memory area). Sure ... if you're going this route, also capture: - system mode (kernel, user, interrupt, other) - CPU number - any task running on the CPU - stack frame pointer (or exception frame) for task per CPU > Mechanism to initiate this: > - Using an NMI IPI would help with accuracy (though it still would > take non-zero time for the other CPUs to receive the IPI). However, during > the later steps, spinning the CPU within this NMI handler while dump is in > progress may not be appropriate. In such a case we could also consider > saving the stack contents, in case spinning is postponed to outside of the > NMI (which could affect consistency) > - With a non-NMI IPI, there is a lesser likelihood of the above > problem, though there would be a little more drift as the other CPUs > wouldn't service the IPI as long as interrupts are disabled on those CPUs. > > BTW, the register state for the dumping CPU should also be saved in memory > likewise. > > 2. Quiesce (to the minimal extent necessary for the following to work > without disrupting the system). If you're talking about non-disruptive dumps here, I agree. Otherwise, I'm not so certain. I don't believe you should wait for anything. Stable system state when a panic() or die_if_kernel() is activated is completely ambiguous. Therefore, you should start acting right away, regardless of system state. > Here "quiesce" means waiting till the system reaches a (stable) state > where dump can be initiated. There are 3 aspects: > i. h/w state quiesce for i/o to work (transient states, in-flight > DMA's or ios ) > ii. s/w state quiesce for dump i/o s/w path to work (relevant locks / > data structure consistencies, if we use the standard i/o path rather than a > separate raw dump interface) > iii. s/w state quiesce for dump data consistency > Because a dump can be triggered at any point, for ii and iii, > self-deadlocks with interrupted code on the same processor need to be > avoided (self-deadlocks may sometimes appear in not-so-obvious ways as in > the problem with dumping from interrupt context ). For this reason it may > help to have the actual dump execute under a legal, preferably, separate > thread of context, which gets activated on reaching a quiesce* on at least > one CPU and waits for a complete quiesce prior to dump. (In (1), the > register state, stack etc at the instant of dumping would have already been > saved, so this is not lost during the quiesce, though other memory state > drift may need to be dealt with). If you're using your own I/O driver for dumping, then it eliminates the uncertainty associated with disruptive dumps. > [*Will treat quiesce point detection as a separate subject ] > > Some of the things this involves: > - Stop fresh operations from happening (some kind way to make the > system and drivers hold off new work ) > - Wait for relevant existing in-flight operations to drain out (some > mechanism/support for getting notified about or explicitly poll for > completion) Turn off interrupts, and prevent schedule() from doing anything. We do the latter today, but not really the former, as we can't determine which interrupts affect which I/O device. > Now, if we go via standard device driver interfaces then the wait required > for (i) would happen automatically. If the dump device has a separate > queue, and we issue the i/o from a legal context as far the system is > concerned (avoid self-deadlock type situations) then (ii) would also get > taken care of. > As far as iii is concerned this is specific to the kind of data dumped, so > won't discuss that rightway. > > The tradeoff which we have to consider as we quiesce is the drift that > occurs during this time: > > We do have a segment/page protection based COW scheme in mind for being > able to retain a snapshot at the point in time of dump, while system state > changes, which we can detail in a separate note, but haven't yet figured > out if the complexity (and additional resource requirements) for this is > worth it. > With that in place we should be able to do with minimal disruption, but its > not without tradeoffs. > > The other aspect is to hold off new operations until the dump is complete. > - Let other CPUs spin when they reach quiesce point, so that they > don't generate any more activity > - (Debatable/Optional) Interface with drivers to delay processing > requests till dump is done (if this is possible). In some cases, this may > involve blocking handling of interrupts / incoming packets or avoid feeding > further (non-dump) i/os down post interrupt handling/non-task time. This > calls for caution because the effects of such delays may result in some > disruption (e.g loss of packets on a network interface) of the system. > - Turn off scheduling/switches to other tasks (so that wait's in the > dump code path don't schedule anything else to run ) Again, something to keep in mind. Fundamentally, if your goal is to create a dump that a customer support person (or anyone for that matter) can review, then normally it's okay if a CPU continues operating, even for a few instructions, while the system prepares to dump. The reason being, most of the time the state of the system that caused the panic() or die_if_kernel() in the first place is not going to change drastically between the time that the crash dump situation takes place, and the time when you actually start dumping. There are only a _tiny_ set of cases where the amount of time would be so critical as to require that type of granularity. Most of the time, the other CPUs will try to continue their execution. The other CPUs are either: - running in another part of the kernel (so they don't matter) - running in the same part of the kernel (but don't touch the same data structures, so they don't matter) - touching the same data structures, but the corruption has already taken place, so you can see who did what already without worrying about timing. The only time that amount of time would matter is if the CPU that caused the problem (not the one that is detecting the problem) leaves an interrupt handler between the time that the crash took place and the time you've frozen the system CPUs. I think it's a corner case. > 3. Set things up for i/o to dump device to work . This may involve waiting > till the setup is done. Also before changing anything on the system, save > associated state so we can restore these back to original settings after we > are done. > > This may not be required as a separate step in general if we are using > existing i/o paths/interfaces and not disabling interrupt handling on other > CPUs. If we did know exactly which interrupts are involved, then we could > have temporarily blocked all others (provided that does not affect > continuation of operation after a dump), but that requires special support > from the driver which may be hard. > With a raw dump interface there may be dump_prepare request issued on > the interface. > > 4. Perform actual dumping. Wait for completion. > > This is where the dump logic fits in - it picks up the dump snapshot > pages and writes them out to the dump device, via either > - The standard i/o path > or > - Raw dump interface (if the dump device driver supports one) > > 5. Restore the settings changed just for dump (i.e. get system ready to > continue normal operation) > > This applies if we had any special device setup or interrupts > disabling / irq changes in 3 above. > > 6. Release the system (i.e. let it continue) > > Unfreeze whatever was held up in step 2. Everything else looks great. :) > Suparna Bhattacharya > IBM Software Lab, India > E-mail : bsuparna@in.ibm.com > Phone : 91-80-5267117, Extn : 2525 --Matt From owner-lkcd@oss.sgi.com Wed Jul 18 14:49:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ILnXn04476 for lkcd-outgoing; Wed, 18 Jul 2001 14:49:33 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ILnVV04471 for ; Wed, 18 Jul 2001 14:49:31 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA13700; Wed, 18 Jul 2001 14:49:24 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 14:49:24 -0700 Message-ID: From: Hiro Sugawara To: "'Matt D. Robinson'" , Hiro Sugawara Cc: lkcd@oss.sgi.com Subject: RE: Module support Date: Wed, 18 Jul 2001 14:49:23 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Ah, that's a very good point, Matt! I've so far been working only with a live kernel and I've never applied the lkcd kernel patch so that I did not create Kerntypes. No wonder I could not find Kerntypes! I instead rebuilt my kernel with -g. Yeah, the file size became over 4MB which is no good for an embedded system, but I am still in the development stage. What about my original question about the necessity of System.map? I found the kernel Makefile actually uses nm to create it. So, as long as the kernel image is available, it doesn't seem necessary. In an embedded application like ours, it costs money to keel extra files like System.map. So, I plan to modify lcrash so that it accepts a vmlinux file or even a zImage file as the first argument, and a compressed Kerntypes file as the third argument. It shouldn't be too difficult to make lcrash automatically distinguish the file types given to the command line. hiro > -----Original Message----- > From: Matt D. Robinson [mailto:yakker@alacritech.com] > Sent: Wednesday, July 18, 2001 13:45 > To: Hiro Sugawara > Cc: lkcd@oss.sgi.com > Subject: Re: Module support > > > If you don't have a Kerntypes file, you should build one. It is > basically a .o file that includes linux/sched.h, but is built with > -gstabs. It should be very easy to build (and if you have the > LKCD patches installed, it's already built for you). > > Don't use 'vmlinux' as the Kerntypes (unless, of course, you're > building your entire kernel with -gstabs). Otherwise, you're going > to get some wierd results. :) From owner-lkcd@oss.sgi.com Wed Jul 18 15:03:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IM3Of05673 for lkcd-outgoing; Wed, 18 Jul 2001 15:03:24 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IM3MV05667 for ; Wed, 18 Jul 2001 15:03:22 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6ILxTs02340; Wed, 18 Jul 2001 14:59:29 -0700 Message-ID: <3B5607E2.93C16C5B@alacritech.com> Date: Wed, 18 Jul 2001 15:04:18 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hiro Sugawara CC: lkcd@oss.sgi.com Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hiro Sugawara wrote: > > Ah, that's a very good point, Matt! > > I've so far been working only with a live kernel and I've never > applied the lkcd kernel patch so that I did not create Kerntypes. > No wonder I could not find Kerntypes! I instead rebuilt my kernel > with -g. Yeah, the file size became over 4MB which is no good for > an embedded system, but I am still in the development stage. > > What about my original question about the necessity of System.map? > I found the kernel Makefile actually uses nm to create it. So, as > long as the kernel image is available, it doesn't seem necessary. Sure, you can use that mechanism if you want -- I prefer to reference the created version rather than use 'nm', but the beauty of open source is you can do it however you want. :) :) As long as the kernel_magic and _end symbols match up, you're okay. That's the biggest concern. > In an embedded application like ours, it costs money to keel extra > files like System.map. So, I plan to modify lcrash so that it accepts > a vmlinux file or even a zImage file as the first argument, and a > compressed Kerntypes file as the third argument. It shouldn't be too > difficult to make lcrash automatically distinguish the file types > given to the command line. I'm in the process of building gzip / gunzip as a dump compression type. Let me think about the compressed Kerntypes file issue. I mean, you could stream uncompress it into 'lcrash', but I don't know if that's what you want to do. --Matt > hiro > > > -----Original Message----- > > From: Matt D. Robinson [mailto:yakker@alacritech.com] > > Sent: Wednesday, July 18, 2001 13:45 > > To: Hiro Sugawara > > Cc: lkcd@oss.sgi.com > > Subject: Re: Module support > > > > > > If you don't have a Kerntypes file, you should build one. It is > > basically a .o file that includes linux/sched.h, but is built with > > -gstabs. It should be very easy to build (and if you have the > > LKCD patches installed, it's already built for you). > > > > Don't use 'vmlinux' as the Kerntypes (unless, of course, you're > > building your entire kernel with -gstabs). Otherwise, you're going > > to get some wierd results. :) From owner-lkcd@oss.sgi.com Wed Jul 18 15:24:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IMOTS07629 for lkcd-outgoing; Wed, 18 Jul 2001 15:24:29 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IMOSV07625 for ; Wed, 18 Jul 2001 15:24:28 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA16476; Wed, 18 Jul 2001 15:24:22 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 15:24:22 -0700 Message-ID: From: Hiro Sugawara To: "'Matt D. Robinson'" , Hiro Sugawara Cc: lkcd@oss.sgi.com Subject: RE: Module support Date: Wed, 18 Jul 2001 15:24:19 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Sounds good. We are using lcrash on development hosts, currently SunOS 5.8. So embedding uncompressor is a reasonable solution. In fact, I was thinking something like: if (magic_number("Kerntypes") == ZIP) fp = popen("gunzip Kerntypes", "r"); else if (magic_number("Kerntypes") == ELF) fp = fopen("Kerntypes", "r"); else boom(); hiro > -----Original Message----- > From: Matt D. Robinson [mailto:yakker@alacritech.com] > Sent: Wednesday, July 18, 2001 15:04 > To: Hiro Sugawara > Cc: lkcd@oss.sgi.com > Subject: Re: Module support > I'm in the process of building gzip / gunzip as a dump compression > type. Let me think about the compressed Kerntypes file issue. I > mean, you could stream uncompress it into 'lcrash', but I don't know > if that's what you want to do. From owner-lkcd@oss.sgi.com Wed Jul 18 19:19:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J2JMd23582 for lkcd-outgoing; Wed, 18 Jul 2001 19:19:22 -0700 Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J2JLV23579 for ; Wed, 18 Jul 2001 19:19:21 -0700 Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id LAA25306 for ; Thu, 19 Jul 2001 11:19:14 +0900 (JST) (envelope-from tachino@open.nm.fujitsu.co.jp) Received: from estartu.open.nm.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id LAA22991 for ; Thu, 19 Jul 2001 11:19:13 +0900 (JST) (envelope-from tachino@open.nm.fujitsu.co.jp) Received: from nisaaru.open.nm.fujitsu.co.jp (nisaaru.open.nm.fujitsu.co.jp [10.34.166.107]) by estartu.open.nm.fujitsu.co.jp (Postfix) with ESMTP id A874E1049; Thu, 19 Jul 2001 11:19:11 +0900 (JST) Date: Thu, 19 Jul 2001 11:19:11 +0900 Message-ID: From: Tachino Nobuhiro To: Hiro Sugawara Cc: "'Matt D. Robinson'" , lkcd@oss.sgi.com Subject: Re: Module support In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) EMY/1.13.9 (Art is long, life is short) SLIM/1.14.7 () APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i586-kondara-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk At Wed, 18 Jul 2001 14:49:23 -0700, Hiro Sugawara wrote: > > What about my original question about the necessity of System.map? > I found the kernel Makefile actually uses nm to create it. So, as > long as the kernel image is available, it doesn't seem necessary. > If you use lcrash with a live system, vmlinux is okay. But if you examine a saved crash dump, you need the System.map of the kernel which is running when panic occurred. You can retrieve symbol information from vmlinux, but current vmdump command saves only System.map. Am I missing something too :-) From owner-lkcd@oss.sgi.com Wed Jul 18 22:09:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J59mT30329 for lkcd-outgoing; Wed, 18 Jul 2001 22:09:48 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J59kV30326 for ; Wed, 18 Jul 2001 22:09:46 -0700 Received: from m7.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id OAA08243 for ; Thu, 19 Jul 2001 14:09:39 +0900 (JST) (envelope-from j-kondo@pst.fujitsu.com) Received: from meow.aoi.pst.fujitsu.com by m7.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id OAA29522 for ; Thu, 19 Jul 2001 14:09:37 +0900 (envelope-from j-kondo@pst.fujitsu.com) Received: from localhost (really [127.0.0.1]) by meow.aoi.pst.fujitsu.com via smail with esmtp id (Debian Smail3.2.0.102) for ; Thu, 19 Jul 2001 14:09:35 +0900 (JST) To: lkcd@oss.sgi.com Subject: Re: Module support From: Jyunji Kondo Reply-To: j-kondo@pst.fujitsu.com In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010719140935I.j-kondo@pst.fujitsu.com> Date: Thu, 19 Jul 2001 14:09:35 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 30 Sender: owner-lkcd@oss.sgi.com Precedence: bulk > >Currently we are planning following procedure. > > > > 1. Extract symbols for debugging modules from > > dump file by using a new lcrash option or a > > dedicated command. > > Which symbols do you like to extract from the dump? For example, - __insmod_'MODULE NAME'_O'FULL PASS NAME OF MODULE FILE'_... - __insmod_'MODULE NAME'_S.text_... - __insmod_'MODULE NAME'_S.rodata_... - __insmod_'MODULE NAME'_S.data_... I think there are enough informations to resolve all of loaded modules' symbols. > As far as I know, the Linux system stores only information > about exported kernel symbols (ksyms). Usually only some > symbols of kernel modules are exported. Hence, your method > will likely miss the majority of symbol information for modules. If above-mentioned symbols are retrieved from the dump and written to a file in /proc/ksyms format, The ksymoops command produces modules' symbols (include which have unexported attribute) with using this file and merges them into System.map. Jyunji Kondo From owner-lkcd@oss.sgi.com Thu Jul 19 00:50:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J7ou604715 for lkcd-outgoing; Thu, 19 Jul 2001 00:50:56 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J7osV04712 for ; Thu, 19 Jul 2001 00:50:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id JAA502736 for ; Thu, 19 Jul 2001 09:50:26 +0200 (CEST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA03479 for ; Thu, 19 Jul 2001 17:49:23 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: lkcd@oss.sgi.com Subject: Re: Module support In-reply-to: Your message of "Wed, 18 Jul 2001 13:37:46 MST." <3B55F39A.39F00B65@alacritech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jul 2001 17:49:23 +1000 Message-ID: <1297.995528963@kao2.melbourne.sgi.com> Sender: owner-lkcd@oss.sgi.com Precedence: bulk On Wed, 18 Jul 2001 13:37:46 -0700, "Matt D. Robinson" wrote: >Andreas Herrmann wrote: >> First: Map-files (System.map, symbol information for >> modules), "namelists" (Kerntypes, object files containing type information >> for >> modules), and the dump must belong together. So, it is a little tricky >> to collect all corresponding files in order to analyze a dump of a >> customer. > >This is a fundamental problem in the kernel build mechanisms. It >would be nice to avoid this scenario, but there's no clear way of >merging any of the files together. > >I don't view this as an lcrash problem, but a kernel build problem. Absolutely, and it is my problem. The 2.5 kbuild will (eventually) put the required files in standard and documented places. It will also include information which will guarantee that the map, modules and kernel belong together. It is coming, but slowly, and will be 2.5 only. As for generating the complete system map including modules, I strongly recommend that you use ksymoops -s. All the cross checking code is already in ksymoops and will be enhanced for 2.5. Unless you like reinventing wheels, use the existing code. Keith Owens, modutils, ksymoops and kbuild maintainer. From owner-lkcd@oss.sgi.com Thu Jul 19 04:09:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JB9bW13616 for lkcd-outgoing; Thu, 19 Jul 2001 04:09:37 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JB9VV13607 for ; Thu, 19 Jul 2001 04:09:32 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA133562; Thu, 19 Jul 2001 13:09:19 +0200 Received: from d12ml004.de.ibm.com (d12ml004_cs0 [9.165.223.50]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JB9DI49930; Thu, 19 Jul 2001 13:09:13 +0200 Importance: Normal Subject: Re: Module support To: "Matt D. Robinson" Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: "Michael Holzheu" Date: Thu, 19 Jul 2001 13:03:41 +0200 X-MIMETrack: Serialize by Router on D12ML004/12/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 13:06:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk One reason that we do not build our kernels for Linux/390 with -gstabs is that we realized, that gcc produces less efficient code with -gstabs. But we consider this as a gcc bug and will investigate this further. Michael ------------------------------------------------------------------------ Linux/390 Development Phone: +49-7031-16-2360, Bld 71032-06-109 Email: holzheu@de.ibm.com "Matt D. Robinson" on 07/18/2001 11:21:50 PM Please respond to "Matt D. Robinson" To: Dave Anderson cc: lkcd@oss.sgi.com Subject: Re: Module support Dave Anderson wrote: > > Most people won't put up with building their entire kernel -gstabs. > If that were the case, we would have done that a long time ago. I > think it would be _GREAT_ to have that, but most people gag on the > idea of putting all symbols into the kernel, as it creates huge > kernels. > > I've never quite understood this. We build our kernels > with -g for the whole kernel, and to be sure, it > creates a much larger vmlinux file -- maybe on the > order of 4 times as large. But what gets loaded > into the bzImage file, and subsequently into memory, > hardly changes at all. In fact, if you also delete > -fomit_frame_pointer along with adding -g, the kernel > is actually smaller! (I'm guessing because of less > aggressive in-lining?). You omit the frame pointer because it takes an extra register on x86 systems, which can slow the machine down tremendously (it has to do more with fewer registers). > Am I missing something here? > > Dave Anderson No, you're not missing the point. People just don't like to see large kernels. Trust me, I'd like to see -gstabs as a default for all systems, but Linus gagged on the idea about two years ago when I asked. Maybe things are different now ... Heh. :) Nice to see you again, Dave ... it's been a while. :) --Matt From owner-lkcd@oss.sgi.com Thu Jul 19 05:57:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JCvM708539 for lkcd-outgoing; Thu, 19 Jul 2001 05:57:22 -0700 Received: from missioncriticallinux.com ([208.51.139.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JCvKV08529 for ; Thu, 19 Jul 2001 05:57:20 -0700 Received: from mclinux.com (IDENT:anderson@anderson.lowell.mclinux.com [10.1.8.20]) by missioncriticallinux.com (8.9.3/8.9.3) with ESMTP id IAA00641 for ; Thu, 19 Jul 2001 08:57:17 -0400 Message-ID: <3B56D912.6913385F@mclinux.com> Date: Thu, 19 Jul 2001 08:56:50 -0400 From: Dave Anderson Organization: Mission Critical Linux X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15smp2 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: -g and -fomit_frame_pointer Content-Type: multipart/alternative; boundary="------------6C4B838BE0BB1D4B44711EB9" Sender: owner-lkcd@oss.sgi.com Precedence: bulk --------------6C4B838BE0BB1D4B44711EB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit No, you're not missing the point. People just don't like to see large kernels. Trust me, I'd like to see -gstabs as a default for all systems, but Linus gagged on the idea about two years ago when I asked. Maybe things are different now ... Heh. :) Has Hell frozen over yet? I've so far been working only with a live kernel and I've never applied the lkcd kernel patch so that I did not create Kerntypes. No wonder I could not find Kerntypes! I instead rebuilt my kernel with -g. Yeah, the file size became over 4MB which is no good for an embedded system, but I am still in the development stage. Does your embedded system use the vmlinux file? I realize some non-x86 processors boot the vmlinux file instead of a bzImage file -- is that true with yours? You omit the frame pointer because it takes an extra register on x86 systems, which can slow the machine down tremendously (it has to do more with fewer registers) BTW, what do you consider "tremendously"? Has anybody every published any hard numbers on this? In any rough testing we've done, the loss in performance is neglible, i.e., in the low single-digit percentiles, if that. Just wondering, Dave Anderson --------------6C4B838BE0BB1D4B44711EB9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit No, you're not missing the point.  People just don't like to see
large kernels.  Trust me, I'd like to see -gstabs as a default
for all systems, but Linus gagged on the idea about two years
ago when I asked.  Maybe things are different now ... Heh. :)

Has Hell frozen over yet?

I've so far been working only with a live kernel and I've never
applied the lkcd kernel patch so that I did not create Kerntypes.
No wonder I could not find Kerntypes! I instead rebuilt my kernel
with -g. Yeah, the file size became over 4MB which is no good for
an embedded system, but I am still in the development stage.

Does your embedded system use the vmlinux file?
I realize some non-x86 processors boot the vmlinux
file instead of a bzImage file -- is that true
with yours?

You omit the frame pointer because it takes an extra register
on x86 systems, which can slow the machine down tremendously
(it has to do more with fewer registers)

BTW, what do you consider "tremendously"?  Has anybody
every published any hard numbers on this?  In any rough
testing we've done, the loss in performance is neglible,
i.e., in the low single-digit percentiles, if that.

Just wondering,
  Dave Anderson --------------6C4B838BE0BB1D4B44711EB9-- From owner-lkcd@oss.sgi.com Thu Jul 19 07:28:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JESqO28083 for lkcd-outgoing; Thu, 19 Jul 2001 07:28:52 -0700 Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JESoV28080 for ; Thu, 19 Jul 2001 07:28:50 -0700 Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id AAA43382 for ; Fri, 20 Jul 2001 00:25:14 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6JESGh64672 for ; Fri, 20 Jul 2001 00:28:16 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A8E.004F7CE2 ; Fri, 20 Jul 2001 00:28:13 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: "Matt D. Robinson" cc: lkcd@oss.sgi.com Message-ID: Date: Thu, 19 Jul 2001 19:47:37 +0530 Subject: Re: Non-disruptive dumps - expanding on the steps Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk >If you're talking about non-disruptive dumps here, I agree.Otherwise, >I'm not so certain. I don't believe you should wait for anything.Stable >system state when panic() or die_if_kernel() is activated is completely >ambiguous. Therefore, you should start acting right away,regardless of >system state. Yes, we were talking about non-disruptive dumps in the note. I understand your concern about panic type situations. That needs more thought. >If you're using your own I/O driver for dumping, then it eliminates the >uncertainty associated with disruptive dumps. Assuming that you are talking only about panic type/disruptive dumps here (not the non-disruptive case, right ?). One problem with the specialized i/o driver approach is that it may be hard to get this support for all kinds of disk i/o / dump h/w (all adapter types). So, we would need to address the cases where such a raw interface does not exist for the dump device and have a fall-back aproach for these cases (mcore style ?) Regards Suparna Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Thu Jul 19 10:54:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JHsZT23352 for lkcd-outgoing; Thu, 19 Jul 2001 10:54:35 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JHsWV23332 for ; Thu, 19 Jul 2001 10:54:33 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA197168; Thu, 19 Jul 2001 19:54:25 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JHsKI50396; Thu, 19 Jul 2001 19:54:20 +0200 Importance: Normal Subject: Re: Module support To: yakker@alacritech.com Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 19 Jul 2001 19:52:56 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 19:53:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk >> Second: Currently there is no automatism to load symbol tables and >> namelists. >I'm not sure what you mean here ... you don't mean what 'vmdump save' >does, right? Are you talking about copying the files to /boot, or >saving them to /var/log/vmdump, or something else? Something else I meant. In our new lcrash version (with support for multiple symbol tables) you have to execute several commands in lcrash to load symbol information and type information for the modules to be analyzed. It would be nice to automate these steps. One way would be to use a lcrash configuration file. There you could say: "for module xyz use symbol table xyz.map and type information of file xyz.o" etc. Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Thu Jul 19 11:29:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JITQa02176 for lkcd-outgoing; Thu, 19 Jul 2001 11:29:26 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JITOV02168 for ; Thu, 19 Jul 2001 11:29:24 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA06001; Thu, 19 Jul 2001 11:29:11 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 11:29:11 -0700 Message-ID: From: Hiro Sugawara To: "'Tachino Nobuhiro'" , Hiro Sugawara Cc: "'Matt D. Robinson'" , lkcd@oss.sgi.com Subject: RE: Module support Date: Thu, 19 Jul 2001 11:29:09 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Sorry, I am not yet clear. My understanding is: 1) System.map is created from vmlinux at kernel build time and placed in /boot 2) /sbin/vmdump simply copies /boot/System.map to /var/vmdump at a system boot time (i.e. _after_ a kernel panic, not when a panic occurs) So, I guess, as long as you do not rebuild vmlinux after you get a vmdump, System.map can always be reproduced from the vmlinux you used for the panicking system. ???? hiro > -----Original Message----- > From: Tachino Nobuhiro [mailto:tachino@open.nm.fujitsu.co.jp] > Sent: Wednesday, July 18, 2001 19:19 > To: Hiro Sugawara > Cc: 'Matt D. Robinson'; lkcd@oss.sgi.com > Subject: Re: Module support > > > > At Wed, 18 Jul 2001 14:49:23 -0700, > Hiro Sugawara wrote: > > > > What about my original question about the necessity of System.map? > > I found the kernel Makefile actually uses nm to create it. So, as > > long as the kernel image is available, it doesn't seem necessary. > > > > If you use lcrash with a live system, vmlinux is okay. But > if you examine a saved crash dump, you need the System.map of > the kernel > which is running when panic occurred. You can retrieve symbol > information from vmlinux, but current vmdump command saves > only System.map. > > Am I missing something too :-) > From owner-lkcd@oss.sgi.com Thu Jul 19 12:32:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JJWLv16375 for lkcd-outgoing; Thu, 19 Jul 2001 12:32:21 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JJWLV16372 for ; Thu, 19 Jul 2001 12:32:21 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6JJSSs31997; Thu, 19 Jul 2001 12:28:28 -0700 Message-ID: <3B5735FF.13EB3BA2@alacritech.com> Date: Thu, 19 Jul 2001 12:33:19 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Anderson CC: lkcd@oss.sgi.com Subject: Re: -g and -fomit_frame_pointer References: <3B56D912.6913385F@mclinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Dave Anderson wrote: > You omit the frame pointer because it takes an extra register > on x86 systems, which can slow the machine down tremendously > (it has to do more with fewer registers) > > BTW, what do you consider "tremendously"? Has anybody > every published any hard numbers on this? In any rough > testing we've done, the loss in performance is neglible, > i.e., in the low single-digit percentiles, if that. Some of our tests when I was at SGI showed measurements of 10% to 20%, depending on the code loops. One of my former co-workers found cases of up to 25%, but I didn't see the code to prove it myself. > Just wondering, > Dave Anderson That's the reason why it's fantastic that lcrash can work without requiring frame pointers. If they exist, great, but they aren't necessary. --Matt From owner-lkcd@oss.sgi.com Thu Jul 19 12:36:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JJa2h16529 for lkcd-outgoing; Thu, 19 Jul 2001 12:36:02 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JJa1V16526 for ; Thu, 19 Jul 2001 12:36:01 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6JJW7s32131; Thu, 19 Jul 2001 12:32:07 -0700 Message-ID: <3B5736DA.A9EEB8F6@alacritech.com> Date: Thu, 19 Jul 2001 12:36:58 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: bsuparna@in.ibm.com CC: lkcd@oss.sgi.com Subject: Re: Non-disruptive dumps - expanding on the steps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk bsuparna@in.ibm.com wrote: > > >If you're talking about non-disruptive dumps here, I agree.Otherwise, > >I'm not so certain. I don't believe you should wait for anything.Stable > >system state when panic() or die_if_kernel() is activated is completely > >ambiguous. Therefore, you should start acting right away,regardless of > >system state. > > Yes, we were talking about non-disruptive dumps in the note. I understand > your concern about panic type situations. That needs more thought. > > >If you're using your own I/O driver for dumping, then it eliminates the > >uncertainty associated with disruptive dumps. > > Assuming that you are talking only about panic type/disruptive dumps here > (not the non-disruptive case, right ?). > One problem with the specialized i/o driver approach is that it may be hard > to get this support for all kinds of disk i/o / dump h/w (all adapter > types). So, we would need to address the cases where such a raw interface > does not exist for the dump device and have a fall-back aproach for these > cases (mcore style ?) True, it is more difficult, but look at it from another perspective. Most of the I/O code involves either the disk driver itself, or some intermediary layer. I'd like to throw out most of the request code and buffer code in the I/O path, and stick to just writing pages of memory (specific ones at that) to the device. So you'd have a: dump_write() dump_io_write() dump_scsi_write() or dump_ide_write() The last one is simply a frame pointer depending on the dump device that is configured. And you still use the standard I/O path for checking the partition, making sure it's a valid device, getting device information and status, etc., when you call dump_open(). That way when the crash occurs, all you have to do is use stored data from the current dump device tables (sizes, etc.), and just write out the pages of memory in some block size format. The dump I/O driver does only ONE thing; it writes. It doesn't need to read, open, close, or any of that. Everything else is cached early on during the boot-up process when dump_open() is called. Does that sound legitimate? > Regards > Suparna > > Suparna Bhattacharya > IBM Software Lab, India > E-mail : bsuparna@in.ibm.com > Phone : 91-80-5267117, Extn : 2525 --Matt From owner-lkcd@oss.sgi.com Thu Jul 19 12:37:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JJb1m16584 for lkcd-outgoing; Thu, 19 Jul 2001 12:37:01 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JJb0V16581 for ; Thu, 19 Jul 2001 12:37:00 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6JJX6s32149; Thu, 19 Jul 2001 12:33:06 -0700 Message-ID: <3B573715.157FEBEC@alacritech.com> Date: Thu, 19 Jul 2001 12:37:57 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Herrmann CC: lkcd@oss.sgi.com Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk What about a '-m' option to specify additional map files on start-up? Or a '-M' to specify a map directory? Does that seem to be a better universal solution? --Matt Andreas Herrmann wrote: > > >> Second: Currently there is no automatism to load symbol tables and > >> namelists. > > >I'm not sure what you mean here ... you don't mean what 'vmdump save' > >does, right? Are you talking about copying the files to /boot, or > >saving them to /var/log/vmdump, or something else? > > Something else I meant. > > In our new lcrash version (with support for multiple symbol tables) you > have to execute several commands in lcrash to load symbol information and > type information for the modules to be analyzed. It would be nice to > automate these steps. One way would be to use a lcrash configuration file. > There > you could say: "for module xyz use symbol table xyz.map and type > information > of file xyz.o" etc. > > Andreas > > -- > Linux for eServer Development > Tel : +49-7031-16-4640 > Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE > email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Thu Jul 19 14:18:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JLILp22788 for lkcd-outgoing; Thu, 19 Jul 2001 14:18:21 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JLIKV22785 for ; Thu, 19 Jul 2001 14:18:20 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6JLENs02440; Thu, 19 Jul 2001 14:14:27 -0700 Message-ID: <3B574ED2.4162A0C3@alacritech.com> Date: Thu, 19 Jul 2001 14:19:14 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hiro Sugawara CC: "'Tachino Nobuhiro'" , lkcd@oss.sgi.com Subject: Re: Module support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hiro Sugawara wrote: > > Sorry, I am not yet clear. My understanding is: > > 1) System.map is created from vmlinux at kernel build time and placed > in /boot > 2) /sbin/vmdump simply copies /boot/System.map to /var/vmdump at a > system boot time (i.e. _after_ a kernel panic, not when a panic > occurs) > > So, I guess, as long as you do not rebuild vmlinux after you get a > vmdump, System.map can always be reproduced from the vmlinux you used > for the panicking system. That is correct. Most people don't panic()/die_if_kernel(), and then reboot on a new kernel. Most == nearly all. People who boot on different kernels either changed their lilo.conf before the crash but didn't boot on the new kernel (after running 'lilo'), or decided to boot on a different kernel by choice. Again, that doesn't happen often. People almost always come up on the kernel they were previously running. They don't change the kernel until they need to or want to try a fix. --Matt > ???? > > hiro > > > -----Original Message----- > > From: Tachino Nobuhiro [mailto:tachino@open.nm.fujitsu.co.jp] > > Sent: Wednesday, July 18, 2001 19:19 > > To: Hiro Sugawara > > Cc: 'Matt D. Robinson'; lkcd@oss.sgi.com > > Subject: Re: Module support > > > > > > > > At Wed, 18 Jul 2001 14:49:23 -0700, > > Hiro Sugawara wrote: > > > > > > What about my original question about the necessity of System.map? > > > I found the kernel Makefile actually uses nm to create it. So, as > > > long as the kernel image is available, it doesn't seem necessary. > > > > > > > If you use lcrash with a live system, vmlinux is okay. But > > if you examine a saved crash dump, you need the System.map of > > the kernel > > which is running when panic occurred. You can retrieve symbol > > information from vmlinux, but current vmdump command saves > > only System.map. > > > > Am I missing something too :-) > > From owner-lkcd@oss.sgi.com Fri Jul 20 12:20:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KJKvt20399 for lkcd-outgoing; Fri, 20 Jul 2001 12:20:57 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KJKtV20392 for ; Fri, 20 Jul 2001 12:20:56 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6KJH3s31704; Fri, 20 Jul 2001 12:17:03 -0700 Message-ID: <3B5884D3.6B4719B4@alacritech.com> Date: Fri, 20 Jul 2001 12:21:55 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: bsuparna@in.ibm.com CC: lkcd@oss.sgi.com Subject: Re: Non-disruptive dumps - expanding on the steps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk bsuparna@in.ibm.com wrote: > > >True, it is more difficult, but look at it from another perspective. > >Most of the I/O code involves either the disk driver itself, or some > >intermediary layer. I'd like to throw out most of the request code > >and buffer code in the I/O path, and stick to just writing pages of > >memory (specific ones at that) to the device. > > > >So you'd have a: > > > > dump_write() > > dump_io_write() > > dump_scsi_write() or dump_ide_write() > > > >The last one is simply a frame pointer depending on the dump device > >that is configured. And you still use the standard I/O path for > >checking the partition, making sure it's a valid device, getting > >device information and status, etc., when you call dump_open(). > >That way when the crash occurs, all you have to do is use stored > >data from the current dump device tables (sizes, etc.), and just > >write out the pages of memory in some block size format. > > > >The dump I/O driver does only ONE thing; it writes. It doesn't > >need to read, open, close, or any of that. Everything else is > >cached early on during the boot-up process when dump_open() is > >called. > > > >Does that sound legitimate? > > We'll need to study some of the low level i/o driver code to see if there > is any way to achieve something like this in a generic way for all scsi > adapters, say (is that what you intended ?) ... but this may be a little > more complicated than it appears at the outset, considering more involved > or specialized driver logic for certain configurations and adapter > characteristics. That's fine ... but IMHO, you build the driver function DIRECTLY into the driver in question. I wish they used a file_ops-like mechanism where you could determine the driver functions available and use those, if they exist, that way if a driver doesn't have a scsi_dump() operations tag, it doesn't support dumping. > There may also be a few additional things to think of (beyond the initial > dump_open). For example there may be a need to suspend/clear other i/o or > reset the dump device if the h/w was in use by the running system, before > dump can start. There would have to be some way to determine when a write > has completed (typically poll mode or in some way that avoids using the > system's interrupt handling code) so that the next write request can be > sent. All of this code shouldn't share any state with the standard driver. Agreed. > AIX has a dump interface architected for device drivers, a little like what > you suggest, but we weren't sure how feasible it would be to provide > something of that sort on linux, considering the range of hardware and > third party drivers to consider. Did you have some feedback from driver > maintainers about this ? I remember you had once mentioned that Linus had > suggested the need for a raw dump i/o interface during earlier discussions > about incorporating lkcd into the kernel. Feedback from driver maintainers? :) I think it has to be done on a one-by-one basis. I realize it may be difficult, but even if we end up sending out patches to their drivers, it's the right solution in the long run. If driver_ops were being used, each driver writer (for new devices) would try to fill in that driver requirement before inclusion in the kernel. That would ultimately be the goal ... Since you're going down, there are a lot of things about what's in the buffer cache that you don't worry about (for disruptive dumps). In addition, you throw out the request queue, because in theory, nothing for the device and partition you're targetting should be on that queue. The biggest thing you worry about is interrupt state. Solve that, and most of the other problems go away. > I'll be away at OLS and on vacation for a week after that, so will continue > these discussions then. > Bharata will be around, though. > > Regards > Suparna Sounds good. Enjoy OLS -- sorry I can't make it. :) --Matt > > Suparna Bhattacharya > IBM Software Lab, India > E-mail : bsuparna@in.ibm.com > Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Fri Jul 20 12:57:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KJv3m23711 for lkcd-outgoing; Fri, 20 Jul 2001 12:57:03 -0700 Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KJv0V23704 for ; Fri, 20 Jul 2001 12:57:01 -0700 Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id FAA67080 for ; Sat, 21 Jul 2001 05:53:22 +1000 From: bsuparna@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6KJuQM59340 for ; Sat, 21 Jul 2001 05:56:26 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A8F.006D8850 ; Sat, 21 Jul 2001 05:56:23 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: "Matt D. Robinson" cc: lkcd@oss.sgi.com Message-ID: Date: Fri, 20 Jul 2001 19:33:31 +0530 Subject: Re: Non-disruptive dumps - expanding on the steps Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk >True, it is more difficult, but look at it from another perspective. >Most of the I/O code involves either the disk driver itself, or some >intermediary layer. I'd like to throw out most of the request code >and buffer code in the I/O path, and stick to just writing pages of >memory (specific ones at that) to the device. > >So you'd have a: > > dump_write() > dump_io_write() > dump_scsi_write() or dump_ide_write() > >The last one is simply a frame pointer depending on the dump device >that is configured. And you still use the standard I/O path for >checking the partition, making sure it's a valid device, getting >device information and status, etc., when you call dump_open(). >That way when the crash occurs, all you have to do is use stored >data from the current dump device tables (sizes, etc.), and just >write out the pages of memory in some block size format. > >The dump I/O driver does only ONE thing; it writes. It doesn't >need to read, open, close, or any of that. Everything else is >cached early on during the boot-up process when dump_open() is >called. > >Does that sound legitimate? We'll need to study some of the low level i/o driver code to see if there is any way to achieve something like this in a generic way for all scsi adapters, say (is that what you intended ?) ... but this may be a little more complicated than it appears at the outset, considering more involved or specialized driver logic for certain configurations and adapter characteristics. There may also be a few additional things to think of (beyond the initial dump_open). For example there may be a need to suspend/clear other i/o or reset the dump device if the h/w was in use by the running system, before dump can start. There would have to be some way to determine when a write has completed (typically poll mode or in some way that avoids using the system's interrupt handling code) so that the next write request can be sent. All of this code shouldn't share any state with the standard driver. AIX has a dump interface architected for device drivers, a little like what you suggest, but we weren't sure how feasible it would be to provide something of that sort on linux, considering the range of hardware and third party drivers to consider. Did you have some feedback from driver maintainers about this ? I remember you had once mentioned that Linus had suggested the need for a raw dump i/o interface during earlier discussions about incorporating lkcd into the kernel. I'll be away at OLS and on vacation for a week after that, so will continue these discussions then. Bharata will be around, though. Regards Suparna Suparna Bhattacharya IBM Software Lab, India E-mail : bsuparna@in.ibm.com Phone : 91-80-5267117, Extn : 2525 From owner-lkcd@oss.sgi.com Thu Jul 26 08:38:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6QFc4c13228 for lkcd-outgoing; Thu, 26 Jul 2001 08:38:04 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6QFbuV13221 for ; Thu, 26 Jul 2001 08:38:01 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA26630; Thu, 26 Jul 2001 15:37:12 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 26 Jul 2001 15:37:12 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 08:37:10 -0700 Message-ID: <10C8636AE359D4119118009027AE99870CE2F85B@FMSMSX34> From: "Howell, David P" To: "'Dave Anderson'" , lkcd@oss.sgi.com Subject: RE: -g and -fomit_frame_pointer Date: Thu, 26 Jul 2001 08:37:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115E8.D4AF78B0" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C115E8.D4AF78B0 Content-Type: text/plain; charset="iso-8859-1" Back aways prior to my move to Intel, in the Pentium Pro days we measured this to be 4% on x86 code tests. The workload was a database engine running on a SVR4 Unix. We did the measurements as part of our optimization plan for the engine, to make the case to the vendor to use our omit frame pointer option. This was not gcc, may be different depending on how well gcc reuses %ebp and optimizes mem refs. This was a significant increase in our optimization plan for the database and did help performance. As I recall the number also held up (3%-4%) on other benchmarks we ran. Dave Howell -----Original Message----- From: Dave Anderson [mailto:anderson@mclinux.com] Sent: Thursday, July 19, 2001 8:57 AM To: lkcd@oss.sgi.com Subject: -g and -fomit_frame_pointer No, you're not missing the point. People just don't like to see large kernels. Trust me, I'd like to see -gstabs as a default for all systems, but Linus gagged on the idea about two years ago when I asked. Maybe things are different now ... Heh. :) Has Hell frozen over yet? I've so far been working only with a live kernel and I've never applied the lkcd kernel patch so that I did not create Kerntypes. No wonder I could not find Kerntypes! I instead rebuilt my kernel with -g. Yeah, the file size became over 4MB which is no good for an embedded system, but I am still in the development stage. Does your embedded system use the vmlinux file? I realize some non-x86 processors boot the vmlinux file instead of a bzImage file -- is that true with yours? You omit the frame pointer because it takes an extra register on x86 systems, which can slow the machine down tremendously (it has to do more with fewer registers) BTW, what do you consider "tremendously"? Has anybody every published any hard numbers on this? In any rough testing we've done, the loss in performance is neglible, i.e., in the low single-digit percentiles, if that. Just wondering, Dave Anderson ------_=_NextPart_001_01C115E8.D4AF78B0 Content-Type: text/html; charset="iso-8859-1"

Back aways prior to my move to Intel, in the Pentium Pro days we measured this to be 4% on x86
code tests. The workload was a database engine running on a SVR4 Unix. We did the measurements
as part of our optimization plan for the engine, to make the case to the vendor to use our omit frame
pointer option. This was not gcc, may be different depending on how well gcc reuses %ebp and
optimizes mem refs.
 
This was a significant increase in our optimization plan for the database and did help performance. As
I recall the number also held up (3%-4%) on other benchmarks we ran.
 
Dave Howell 
-----Original Message-----
From: Dave Anderson [mailto:anderson@mclinux.com]
Sent: Thursday, July 19, 2001 8:57 AM
To: lkcd@oss.sgi.com
Subject: -g and -fomit_frame_pointer

No, you're not missing the point.  People just don't like to see
large kernels.  Trust me, I'd like to see -gstabs as a default
for all systems, but Linus gagged on the idea about two years
ago when I asked.  Maybe things are different now ... Heh. :)

Has Hell frozen over yet?

I've so far been working only with a live kernel and I've never
applied the lkcd kernel patch so that I did not create Kerntypes.
No wonder I could not find Kerntypes! I instead rebuilt my kernel
with -g. Yeah, the file size became over 4MB which is no good for
an embedded system, but I am still in the development stage.

Does your embedded system use the vmlinux file?
I realize some non-x86 processors boot the vmlinux
file instead of a bzImage file -- is that true
with yours?

You omit the frame pointer because it takes an extra register
on x86 systems, which can slow the machine down tremendously
(it has to do more with fewer registers)

BTW, what do you consider "tremendously"?  Has anybody
every published any hard numbers on this?  In any rough
testing we've done, the loss in performance is neglible,
i.e., in the low single-digit percentiles, if that.

Just wondering,
  Dave Anderson

------_=_NextPart_001_01C115E8.D4AF78B0-- From owner-lkcd@oss.sgi.com Tue Jul 31 08:47:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VFlUN01361 for lkcd-outgoing; Tue, 31 Jul 2001 08:47:30 -0700 Received: from mailgw1.br.ibm.com (igw1.br.ibm.com [32.96.196.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VFlSV01358 for ; Tue, 31 Jul 2001 08:47:29 -0700 Received: from mailhub1.br.ibm.com (mailhub1.br.ibm.com [9.179.63.14]) by mailgw1.br.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA67896 for ; Tue, 31 Jul 2001 12:46:02 -0300 Received: from d24bml07 (d24bml07.br.ibm.com [9.179.62.110]) by mailhub1.br.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6VFlJM41510 for ; Tue, 31 Jul 2001 12:47:19 -0300 Importance: Normal Subject: Msg: input buffer overflow in lcrash. To: lkcd@oss.sgi.com From: "Evandro Tadeu S Vargas" Date: Tue, 31 Jul 2001 12:47:19 -0300 Message-ID: X-MIMETrack: Serialize by Router on d24bml07/24/M/IBM(Release 5.0.6a |January 17, 2001) at 31/07/2001 12:47:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. After compiler the lkcdutils, i created an dump (using Linux/390 standalone dump) and lcrash show following msg: input buffer overflow, can't enlarge buffer because scanner uses REJECT Could you explain this message and possible solution ? TIA. Evandro Vargas From owner-lkcd@oss.sgi.com Tue Jul 31 10:51:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VHpoN05310 for lkcd-outgoing; Tue, 31 Jul 2001 10:51:50 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VHpnV05306 for ; Tue, 31 Jul 2001 10:51:49 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6VHm9s26426; Tue, 31 Jul 2001 10:48:09 -0700 Message-ID: <3B66F092.98D5D11F@alacritech.com> Date: Tue, 31 Jul 2001 10:53:22 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Evandro Tadeu S Vargas CC: lkcd@oss.sgi.com Subject: Re: Msg: input buffer overflow in lcrash. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Evandro Tadeu S Vargas wrote: > > Hi, > > I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. > After compiler the lkcdutils, > i created an dump (using Linux/390 standalone dump) and lcrash show > following msg: > > input buffer overflow, can't enlarge buffer because scanner > uses REJECT > > Could you explain this message and possible solution ? > > TIA. > Evandro Vargas I'm not precisely sure as of yet, but it looks like this is generated by flex (out of libsial), not anything 'lcrash' is doing. The problem is that YY_USES_REJECT is being defined (no REJECTs in the flex code), so you can try to build lex.sial.c and lex.sialpp.c with -UYY_USES_REJECT and see what results that gives you. Just out of curiosity, how are you generating the message? When you first try to start 'lcrash'? And if so, what does your command line look like? Thanks ... --Matt P.S. I don't have an S/390, so I can't test this. Michael? From owner-lkcd@oss.sgi.com Tue Jul 31 11:54:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VIscv06999 for lkcd-outgoing; Tue, 31 Jul 2001 11:54:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VIsaV06994 for ; Tue, 31 Jul 2001 11:54:36 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09027 for ; Tue, 31 Jul 2001 11:54:19 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA40099; Tue, 31 Jul 2001 11:54:25 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id LAA61591; Tue, 31 Jul 2001 11:53:51 -0700 (PDT) Message-ID: <3B66FB7C.F4FFEE98@sgi.com> Date: Tue, 31 Jul 2001 14:39:56 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "Matt D. Robinson" CC: Evandro Tadeu S Vargas , lkcd@oss.sgi.com Subject: Re: Msg: input buffer overflow in lcrash. References: <3B66F092.98D5D11F@alacritech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk "Matt D. Robinson" wrote: > > Evandro Tadeu S Vargas wrote: > > > > Hi, > > > > I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. > > After compiler the lkcdutils, > > i created an dump (using Linux/390 standalone dump) and lcrash show > > following msg: > > > > input buffer overflow, can't enlarge buffer because scanner > > uses REJECT > > > > Could you explain this message and possible solution ? > > > > TIA. > > Evandro Vargas > > I'm not precisely sure as of yet, but it looks like this is generated > by flex (out of libsial), not anything 'lcrash' is doing. The problem > is that YY_USES_REJECT is being defined (no REJECTs in the flex code), > so you can try to build lex.sial.c and lex.sialpp.c with -UYY_USES_REJECT > and see what results that gives you. > > Just out of curiosity, how are you generating the message? When you > first try to start 'lcrash'? And if so, what does your command line > look like? > > Thanks ... > > --Matt > > P.S. I don't have an S/390, so I can't test this. Michael? I started looking at this a bit earlier but I got side tracked in doing something else. Matt is right about the YY_USES_REJECT define and the -U workaround should get you out of trouble. The question I still need to answer is why, with your particular configuration, YY_USES_REJECT is being defined. It's is not being defined on my RH60 build. I think I see a link beeween the -l option (lex compatibility) and YY_USES_REJECT being defined, but without a more scrutinized look I'm not sure if it's the only condition that can do this. -- Luc From owner-lkcd@oss.sgi.com Tue Jul 31 12:21:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VJLSW08237 for lkcd-outgoing; Tue, 31 Jul 2001 12:21:28 -0700 Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VJLRV08234 for ; Tue, 31 Jul 2001 12:21:27 -0700 Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id <36J3W8Y8>; Tue, 31 Jul 2001 15:21:21 -0400 Message-ID: <69C8DD8179FCD41187CC0003470E0196DD420F@srstart.lss.emc.com> From: "moumni, ismail" To: "'lkcd@oss.sgi.com'" Subject: lkcd versions Date: Tue, 31 Jul 2001 15:21:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-lkcd@oss.sgi.com Precedence: bulk Dear lkcd team, My name is Ismail Moumni. I work at EMC Corporation where we are looking to release an application running on linux. We would like our customers to take advantage of your suite to send us reliable information pertaining to our software. To this end I have 2 questions regarding your lkcd suite: 1) Do you expect to have a patch for the system startup scripts released soon for redhat 7.1. Also do you expect to have a version for suse 7.1? 2) We have noticed that the rc.sysinit patch for redhat 7.0 might have an error in it when trying to patch. (patch malformed at line 29). Do you expect to have a fix soon? Regards, Ismail Moumni From owner-lkcd@oss.sgi.com Tue Jul 31 12:30:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VJU2s08589 for lkcd-outgoing; Tue, 31 Jul 2001 12:30:02 -0700 Received: from astroarch.com (adsl-65-67-57-154.dsl.austtx.swbell.net [65.67.57.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VJU1V08585 for ; Tue, 31 Jul 2001 12:30:01 -0700 Received: from defender (defender.internal.astroarch.com [10.0.0.9]) by astroarch.com (8.11.2/8.11.0) with SMTP id f6VJU4X09551 for ; Tue, 31 Jul 2001 14:30:04 -0500 From: "Edward L. Haletky" To: Subject: Date: Tue, 31 Jul 2001 14:28:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <69C8DD8179FCD41187CC0003470E0196DD420F@srstart.lss.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0005 Importance: Normal Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello Matt and company, Well after many hours of frustration from a bad motherboard I went back to trying to get lkcd to work on my new athlon MB and I noticed that there are many failures on the patch for version 2.4.3 of the source as provided by redhat. Can a patch be made ready for this? Thanks, Edward Haletky From owner-lkcd@oss.sgi.com Tue Jul 31 14:55:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLtuo13051 for lkcd-outgoing; Tue, 31 Jul 2001 14:55:56 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLttV13048 for ; Tue, 31 Jul 2001 14:55:55 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6VLqIs02287; Tue, 31 Jul 2001 14:52:18 -0700 Message-ID: <3B6729CB.DD78345D@alacritech.com> Date: Tue, 31 Jul 2001 14:57:31 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "moumni, ismail" CC: "'lkcd@oss.sgi.com'" Subject: Re: lkcd versions References: <69C8DD8179FCD41187CC0003470E0196DD420F@srstart.lss.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk "moumni, ismail" wrote: > > Dear lkcd team, > > My name is Ismail Moumni. I work at EMC Corporation where we are looking to > release an application running on linux. We would like our customers to take > advantage of your suite to send us reliable information pertaining to our > software. To this end I have 2 questions regarding your lkcd suite: > > 1) Do you expect to have a patch for the system startup scripts > released soon for redhat 7.1. Also do you expect to have a version for suse > 7.1? The modifications should be straightforward. Try the attached patch. If that works for you (it should), I'll check it into the following release (and put it on the FTP site). > 2) We have noticed that the rc.sysinit patch for redhat 7.0 might have > an error in it when trying to patch. (patch malformed at line 29). Do you > expect to have a fix soon? Hmmm ... Where did you get your copy of the patch from? > Regards, > Ismail Moumni Let me know about (2), and I'll fix it (if it's broken). --Matt From owner-lkcd@oss.sgi.com Tue Jul 31 14:56:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLuiN13076 for lkcd-outgoing; Tue, 31 Jul 2001 14:56:44 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLugV13072 for ; Tue, 31 Jul 2001 14:56:42 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6VLr5s02369; Tue, 31 Jul 2001 14:53:05 -0700 Message-ID: <3B6729FB.67E8DE51@alacritech.com> Date: Tue, 31 Jul 2001 14:58:19 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "moumni, ismail" CC: "'lkcd@oss.sgi.com'" Subject: Re: lkcd versions References: <69C8DD8179FCD41187CC0003470E0196DD420F@srstart.lss.emc.com> Content-Type: multipart/mixed; boundary="------------294A40FAF3DBE38E2A526086" Sender: owner-lkcd@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------294A40FAF3DBE38E2A526086 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "moumni, ismail" wrote: > > Dear lkcd team, > > My name is Ismail Moumni. I work at EMC Corporation where we are looking to > release an application running on linux. We would like our customers to take > advantage of your suite to send us reliable information pertaining to our > software. To this end I have 2 questions regarding your lkcd suite: > > 1) Do you expect to have a patch for the system startup scripts > released soon for redhat 7.1. Also do you expect to have a version for suse > 7.1? > 2) We have noticed that the rc.sysinit patch for redhat 7.0 might have > an error in it when trying to patch. (patch malformed at line 29). Do you > expect to have a fix soon? > > Regards, > Ismail Moumni You know, it always helps to actually include the patch. :) --Matt --------------294A40FAF3DBE38E2A526086 Content-Type: text/plain; charset=us-ascii; name="rc.sysinit-redhat71.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.sysinit-redhat71.patch" --- rc.sysinit.rh71.old Tue Jul 31 14:50:14 2001 +++ rc.sysinit.rh71 Tue Jul 31 14:52:25 2001 @@ -145,9 +145,6 @@ fi fi -# Start up swapping. -action $"Activating swap partitions: " swapon -a -e - # Set the hostname. action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME} @@ -524,6 +521,14 @@ # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs + +if [ -x /sbin/vmdump ] ; then + action $"Configuring system for crash dumps: " /sbin/vmdump config + action $"Saving crash dump (if one exists): " /sbin/vmdump save +fi + +# Start up swapping. +action $"Activating swap partitions: " swapon -a -e if [ X"$_RUN_QUOTACHECK" = X1 -a -x /sbin/quotacheck ]; then if [ -x /sbin/convertquota ]; then --------------294A40FAF3DBE38E2A526086-- From owner-lkcd@oss.sgi.com Tue Jul 31 15:01:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VM1U413196 for lkcd-outgoing; Tue, 31 Jul 2001 15:01:30 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VM1SV13193 for ; Tue, 31 Jul 2001 15:01:28 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f6VLvps02552; Tue, 31 Jul 2001 14:57:51 -0700 Message-ID: <3B672B19.ACC0110B@alacritech.com> Date: Tue, 31 Jul 2001 15:03:05 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Edward L. Haletky" CC: lkcd@oss.sgi.com Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk "Edward L. Haletky" wrote: > > Hello Matt and company, > > Well after many hours of frustration from a bad motherboard I went back to > trying to get lkcd to work on my new athlon MB and I noticed that there are > many failures on the patch for version 2.4.3 of the source as provided by > redhat. > > Can a patch be made ready for this? > > Thanks, > Edward Haletky Are you using RH 2.4.2-2, or stock 2.4.3? I don't think RedHat releases a 2.4.3 kernel for RH 7.1 (but I could be completely missing it). I know we work well against 2.4.3 kernels (although you may see ia64 files that won't patch against non-existant files in the 2.4.3 tree). Let me know the right tree and I'll build an appropriate patch setup based on your tree. --Matt