From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akio Takebe Subject: [Patch] Enable "sysrq c" handler for domU coredump Date: Tue, 01 Aug 2006 12:11:26 +0900 Message-ID: <4DC6B5182D2981takebe_akio@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary-ZQvPsLEPi58cwgwA7nmWJ" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel , Horms , Kouya Shimura List-Id: xen-devel@lists.xenproject.org --Boundary-ZQvPsLEPi58cwgwA7nmWJ Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Description: Mail message body Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU's memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0). On Domain0, crash_kexec() is called by panic() if implemented. I tested the below. 1. vi /etc/xen/xend-config.sxp (enabel-dump yes) 2. xm create -c domU echo 1 >/proc/sys/kernel/sysrq (on domU) 3. xm sysrq domU c (on dom0) 4. ls -lh /var/xen/dump Signed-off-by: Akio Takebe Signed-off-by: Kouya Shimura Best Regards, Akio Takebe --Boundary-ZQvPsLEPi58cwgwA7nmWJ Content-Type: application/octet-stream; name="xen_sysrq_domUcore.patch" Content-Disposition: attachment; filename="xen_sysrq_domUcore.patch" Content-Transfer-Encoding: BASE64 ZGlmZiAtciBkMmJmMWE3Y2MxMzEgcGF0Y2hlcy9saW51eC0yLjYuMTYuMTMveGVuX3N5c3Jx X2Zvcl9kb21VY29yZS5wYXRjaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg MTk3MCArMDAwMAorKysgYi9wYXRjaGVzL2xpbnV4LTIuNi4xNi4xMy94ZW5fc3lzcnFfZm9y X2RvbVVjb3JlLnBhdGNoCVR1ZSBBdWcgMDEgMDE6NTU6MTAgMjAwNiArMDkwMApAQCAtMCww ICsxLDQ2IEBACistLS0gLi4vcHJpc3RpbmUtbGludXgtMi42LjE2LjEzL2RyaXZlcnMvY2hh ci9zeXNycS5jCTIwMDYtMDUtMDMgMDY6Mzg6NDQuMDAwMDAwMDAwICswOTAwCisrKysgLi9k cml2ZXJzL2NoYXIvc3lzcnEuYwkyMDA2LTA4LTAxIDAxOjU0OjI1LjQxMzYxNzMzNiArMDkw MAorQEAgLTk1LDYgKzk1LDE5IEBAIHN0YXRpYyBzdHJ1Y3Qgc3lzcnFfa2V5X29wIHN5c3Jx X3VucmF3X28KKyB9OworICNlbmRpZiAvKiBDT05GSUdfVlQgKi8KKyAKKysjaWZkZWYgQ09O RklHX1hFTgorK3N0YXRpYyB2b2lkIHN5c3JxX2hhbmRsZV9jcmFzaChpbnQga2V5LCBzdHJ1 Y3QgcHRfcmVncyAqcHRfcmVncywKKysJCQkgICAgICBzdHJ1Y3QgdHR5X3N0cnVjdCAqdHR5 KSAKKyt7CisrCXBhbmljKCJQYW5pYyBkb21haW4gYnkgcmVxdWVzdFxuIik7CisrfQorK3N0 YXRpYyBzdHJ1Y3Qgc3lzcnFfa2V5X29wIHN5c3JxX2NyYXNoX29wID0geworKwkuaGFuZGxl cgk9IHN5c3JxX2hhbmRsZV9jcmFzaCwKKysJLmhlbHBfbXNnCT0gIkNyYXNoRG9tYWluIiwK KysJLmFjdGlvbl9tc2cJPSAiUGFuaWMgZG9tYWluIGJ5IHJlcXVlc3QiLAorKwkuZW5hYmxl X21hc2sJPSBTWVNSUV9FTkFCTEVfRFVNUCwKKyt9OworKyNlbHNlCisgI2lmZGVmIENPTkZJ R19LRVhFQworIC8qIGNyYXNoZHVtcCBzeXNycSBoYW5kbGVyICovCisgc3RhdGljIHZvaWQg c3lzcnFfaGFuZGxlX2NyYXNoZHVtcChpbnQga2V5LCBzdHJ1Y3QgcHRfcmVncyAqcHRfcmVn cywKK0BAIC0xMDksNiArMTIyLDcgQEAgc3RhdGljIHN0cnVjdCBzeXNycV9rZXlfb3Agc3lz cnFfY3Jhc2hkdQorIAkuZW5hYmxlX21hc2sJPSBTWVNSUV9FTkFCTEVfRFVNUCwKKyB9Owor ICNlbmRpZgorKyNlbmRpZgorIAorIC8qIHJlYm9vdCBzeXNycSBoYW5kbGVyICovCisgc3Rh dGljIHZvaWQgc3lzcnFfaGFuZGxlX3JlYm9vdChpbnQga2V5LCBzdHJ1Y3QgcHRfcmVncyAq cHRfcmVncywKK0BAIC0zMDQsMTEgKzMxOCwxNSBAQCBzdGF0aWMgc3RydWN0IHN5c3JxX2tl eV9vcCAqc3lzcnFfa2V5X3RhCisgCQkgaXQgaXMgaGFuZGxlZCBzcGVjaWFsbHkgb24gdGhl IHNwYXJjCisgCQkgYW5kIHdpbGwgbmV2ZXIgYXJyaXZlICovCisgLyogYiAqLwkmc3lzcnFf cmVib290X29wLAorKyNpZmRlZiBDT05GSUdfWEVOIC8qIGZvciBkb21VIGNyYXNoIGR1bXAg Ki8KKysvKiBjICovCSZzeXNycV9jcmFzaF9vcCwKKysjZWxzZQorICNpZmRlZiBDT05GSUdf S0VYRUMKKyAvKiBjICovICZzeXNycV9jcmFzaGR1bXBfb3AsCisgI2Vsc2UKKyAvKiBjICov CU5VTEwsCisgI2VuZGlmCisrI2VuZGlmCisgI2lmZGVmIENPTkZJR19ERUJVR19NVVRFWEVT CisgLyogZCAqLyAmc3lzcnFfc2hvd2xvY2tzX29wLAorICNlbHNlCg== --Boundary-ZQvPsLEPi58cwgwA7nmWJ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --Boundary-ZQvPsLEPi58cwgwA7nmWJ--