From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 14 04:17:07 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ECF216A403 for ; Sun, 14 Jan 2007 04:17:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0A713C458 for ; Sun, 14 Jan 2007 04:17:06 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1246605wxc for ; Sat, 13 Jan 2007 20:17:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bqHpba8xU/dFlp4q7cX7aKLFIuhJerGMBxhaJ6/bRPx+onI9MJjQZ5QW80PHLEh3s1aSOC6gFqNUI4FCGAuMK68DmHaMdajQyg4z0MbsI9SArTIknkJKF4Tag9GCGqH2WIuMS3kRutOSxZuyqcm0YPhxNm8eXVvojliAe7O752Q= Received: by 10.64.27.7 with SMTP id a7mr3283876qba.1168748225316; Sat, 13 Jan 2007 20:17:05 -0800 (PST) Received: by 10.65.189.7 with HTTP; Sat, 13 Jan 2007 20:17:05 -0800 (PST) Message-ID: <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> Date: Sat, 13 Jan 2007 22:17:05 -0600 From: "Scot Hetzel" To: freebsd-emulation@freebsd.org In-Reply-To: <20070106130830.3c2e6d98@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_30898_24571429.1168748225274" References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> Cc: Alexander Leidinger Subject: Re: linuxolator: proc/filesystems and sysfs function implementations X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 04:17:07 -0000 ------=_Part_30898_24571429.1168748225274 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Attached is an implementation for the linux sysfs() function and linprocfs (proc/filesystems). I have run the sysfs01-06 LTP tests, and it passes all tests. NOTE: kldload ext2fs before running the sysfs01 test. The code uses 2 translation functions located in linux_util.c: bsd_to_linux_fs - converts BSD filesystem name to the Linux equivalent, and if the filesystem requires a dev entry (used by linprocfs_do_filesystems function). linux_to_bsd_fs - converts Linux filesystem name to the BSD equivalent Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_30898_24571429.1168748225274 Content-Type: text/x-diff; name=sysfs.patch; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ewwy5dlo Content-Disposition: attachment; filename="sysfs.patch" SW5kZXg6IGFtZDY0L2xpbnV4MzIvbGludXgzMl9kdW1teS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6 IC9ob21lL25jdnMvc3JjL3N5cy9hbWQ2NC9saW51eDMyL2xpbnV4MzJfZHVtbXkuYyx2CnJldHJp ZXZpbmcgcmV2aXNpb24gMS43CmRpZmYgLXUgLXIxLjcgbGludXgzMl9kdW1teS5jCi0tLSBhbWQ2 NC9saW51eDMyL2xpbnV4MzJfZHVtbXkuYwkzMSBEZWMgMjAwNiAxMzoxNjowMCAtMDAwMAkxLjcK KysrIGFtZDY0L2xpbnV4MzIvbGludXgzMl9kdW1teS5jCTMxIERlYyAyMDA2IDIzOjUxOjI2IC0w MDAwCkBAIC01MCw2ICs1MCw1IEBACiBEVU1NWShnZXRfa2VybmVsX3N5bXMpOwogRFVNTVkocXVv dGFjdGwpOwogRFVNTVkoYmRmbHVzaCk7Ci1EVU1NWShzeXNmcyk7CiBEVU1NWShxdWVyeV9tb2R1 bGUpOwogRFVNTVkobmZzc2VydmN0bCk7CiBJbmRleDogaTM4Ni9saW51eC9saW51eF9kdW1teS5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9pMzg2L2xpbnV4L2xpbnV4 X2R1bW15LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDUKZGlmZiAtdSAtcjEuNDUgbGludXhf ZHVtbXkuYwotLS0gaTM4Ni9saW51eC9saW51eF9kdW1teS5jCTMxIERlYyAyMDA2IDEzOjE2OjAw IC0wMDAwCTEuNDUKKysrIGkzODYvbGludXgvbGludXhfZHVtbXkuYwkzMSBEZWMgMjAwNiAyMzo1 NTo1NyAtMDAwMApAQCAtNTIsNiArNTIsNSBAQAogRFVNTVkoZ2V0X2tlcm5lbF9zeW1zKTsKIERV TU1ZKHF1b3RhY3RsKTsKIERVTU1ZKGJkZmx1c2gpOwotRFVNTVkoc3lzZnMpOwogRFVNTVkodm04 Nik7CiBEVU1NWShxdWVyeV9tb2R1bGUpOwpJbmRleDogY29tcGF0L2xpbnV4L2xpbnV4X21pc2Mu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L2xpbnV4L2xp bnV4X21pc2MuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMDUKZGlmZiAtdSAtcjEuMjA1IGxp bnV4X21pc2MuYwotLS0gY29tcGF0L2xpbnV4L2xpbnV4X21pc2MuYwk3IEphbiAyMDA3IDE5OjMw OjE5IC0wMDAwCTEuMjA1CisrKyBjb21wYXQvbGludXgvbGludXhfbWlzYy5jCTE0IEphbiAyMDA3 IDAxOjU2OjQxIC0wMDAwCkBAIC0xNzExLDMgKzE3MjQsODMgQEAKIAogCXJldHVybiAoZXJyb3Ip OwogfQogCiBpbnQKIGxpbnV4X2Nocm9vdChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGxpbnV4 X2Nocm9vdF9hcmdzICphcmdzKQogewogCXJldHVybiAoY2hyb290KHRkLCAoc3RydWN0IGNocm9v dF9hcmdzICopYXJncykpOwp9CisKK2ludAorbGludXhfc3lzZnMoc3RydWN0IHRocmVhZCAqdGQs IHN0cnVjdCBsaW51eF9zeXNmc19hcmdzICphcmdzKQoreworCWludCBlcnJvcj0wOworCXVuc2ln bmVkIGludCBpbmRleCA9IDA7CisJc2l6ZV90IGxlbjsKKwljaGFyICpidWY7CisJY2hhciAqbmFt ZTsKKwlzdHJ1Y3QgbGludXhfZmlsZV9zeXN0ZW1fdHlwZSBmczsKKwlzdHJ1Y3QgdmZzY29uZiAq dmZzcDsKKworCXN3aXRjaCAoYXJncy0+b3B0aW9uKSB7CisJCS8qCisJCSAqIFRyYW5zbGF0ZSB0 aGUgZmlsZXN5c3RlbSBpZGVudGlmaWVyIHN0cmluZyBpbnRvIGEKKwkJICogZmlsZXN5c3RlbSB0 eXBlIGluZGV4LgorCQkgKi8KKwkJY2FzZSAxOgorCQkJLyogaXMgYXJncy0+YXJnMSBpcyB2YWxp ZCwgaWYgbm90IHZhbGlkIHJldHVybiBFRkFVTFQgKi8KKwkJCW5hbWUgPSAoY2hhciAqKSBtYWxs b2MoTUZTTkFNRUxFTiwgTV9URU1QLCBNX1dBSVRPSyk7CisJCQllcnJvciA9IGNvcHlpbnN0cigo Y2hhciAqKSh1aW50cHRyX3QpYXJncy0+YXJnMSwgbmFtZSwKKwkJCQkJICBNRlNOQU1FTEVOLCAm bGVuKTsKKwkJCWlmIChlcnJvcikgeworCQkJCUxGUkVFUEFUSChuYW1lKTsKKwkJCQlyZXR1cm4g KGVycm9yKTsKKyAJCQl9CisKKwkJCWVycm9yID0gRUlOVkFMOworCisJCQlsaW51eF90b19ic2Rf ZnMobmFtZSwgJmZzKTsKKworCQkJVEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29uZiwgdmZjX2xp c3QpCisJCQkJaWYgKHN0cmNtcCh2ZnNwLT52ZmNfbmFtZSwgZnMubmFtZSkgPT0gMCkgeworCQkJ CQl0ZC0+dGRfcmV0dmFsWzBdID0gaW5kZXg7CisJCQkJCWVycm9yID0gMDsKKwkJCQkJYnJlYWs7 CisJCQkJfSBlbHNlCisJCQkJCWluZGV4Kys7CisJCQlMRlJFRVBBVEgobmFtZSk7CisJCQlicmVh azsKKworCQkvKgorCQkgKiBUcmFuc2xhdGUgdGhlIGZpbGUtc3lzdGVtIHR5cGUgaW5kZXggaW50 byBhIG51bGwtdGVybWluYXRlZAorCQkgKiBmaWxlc3lzdGVtIGlkZW50aWZpZXIgc3RyaW5nLgor CQkgKi8KKwkJY2FzZSAyOgorCQkJaW5kZXggPSBhcmdzLT5hcmcxOworCQkJYnVmID0gKGNoYXIg KikodWludHB0cl90KWFyZ3MtPmFyZzI7CisKKwkJCVRBSUxRX0ZPUkVBQ0godmZzcCwgJnZmc2Nv bmYsIHZmY19saXN0KQorCQkJCWlmIChpbmRleC0tIDw9IDApCisJCQkJCWJyZWFrOworCQkJaWYg KCF2ZnNwKQorCQkJCXJldHVybiBFSU5WQUw7CisKKwkJCWJzZF90b19saW51eF9mcyh2ZnNwLT52 ZmNfbmFtZSwgJmZzKTsKKwkJCWxlbiA9IHN0cmxlbihmcy5uYW1lKSArIDE7CisJCQllcnJvciA9 IGNvcHlvdXQoZnMubmFtZSwgYnVmLCBsZW4pOworCQkJYnJlYWs7CisKKwkJLyoKKwkJICogUmV0 dXJuIHRoZSB0b3RhbCBudW1iZXIgb2YgZmlsZSBzeXN0ZW0gdHlwZXMgY3VycmVudGx5IHByZXNl bnQKKwkJICogaW4gdGhlIGtlcm5lbC4KKwkJICovCisJCWNhc2UgMzoKKwkJCVRBSUxRX0ZPUkVB Q0godmZzcCwgJnZmc2NvbmYsIHZmY19saXN0KQorCQkJCWluZGV4Kys7CisJCQl0ZC0+dGRfcmV0 dmFsWzBdID0gaW5kZXg7CisJCQlicmVhazsKKwkJZGVmYXVsdDoKKwkJCWVycm9yID0gRUlOVkFM OworCX0KKwlyZXR1cm4gKGVycm9yKTsKK30KSW5kZXg6IGNvbXBhdC9saW51eC9saW51eF91dGls LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9saW51eC9s aW51eF91dGlsLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzEKZGlmZiAtdSAtcjEuMzEgbGlu dXhfdXRpbC5jCi0tLSBjb21wYXQvbGludXgvbGludXhfdXRpbC5jCTE1IEF1ZyAyMDA2IDEyOjU0 OjI5IC0wMDAwCTEuMzEKKysrIGNvbXBhdC9saW51eC9saW51eF91dGlsLmMJMTQgSmFuIDIwMDcg MDI6MTE6MDggLTAwMDAKQEAgLTIyNCwzICsyMjQsODIgQEAKIAogCXJldHVybiAoRUlOVkFMKTsK IH0KKwordm9pZAorYnNkX3RvX2xpbnV4X2ZzKGNoYXIgKm5hbWUsIHN0cnVjdCBsaW51eF9maWxl X3N5c3RlbV90eXBlICpmcykKK3sKKyNkZWZpbmUgTF9OT0RFVihmbmFtZSkgXAorCWlmIChzdHJj bXAoZm5hbWUsIG5hbWUpID09IDApIFwKKwkgICAgZnMtPmZzX2ZsYWdzID0gMDsKKyNkZWZpbmUg RjJMX05BTUUoZm5hbWUsIGxuYW1lKSBcCisJaWYgKHN0cmNtcChmbmFtZSwgbmFtZSkgPT0gMCkg XAorCSAgIHN0cmNweShmcy0+bmFtZSwgbG5hbWUpOworCisJTF9OT0RFVigiOXAiKQorCWVsc2Ug TF9OT0RFVigiYWZzIikKKwllbHNlIExfTk9ERVYoImF1dG9mcyIpCisJZWxzZSBMX05PREVWKCJj aWZzIikKKwllbHNlIExfTk9ERVYoImNvZGEiKQorCWVsc2UgTF9OT0RFVigiY29uZmlnZnMiKQor CWVsc2UgTF9OT0RFVigiZGVidWdmcyIpCisJZWxzZSBMX05PREVWKCJkZXZmcyIpCisJZWxzZSBM X05PREVWKCJkZXZwdHMiKQorCWVsc2UgTF9OT0RFVigiZmRlc2NmcyIpCisJZWxzZSBMX05PREVW KCJmdXNlIikKKwllbHNlIExfTk9ERVYoImhvc3RmcyIpCisJZWxzZSBMX05PREVWKCJocHBmcyIp CisJZWxzZSBMX05PREVWKCJodWdldGxiZnMiKQorCWVsc2UgTF9OT0RFVigiamZmczIiKQorCWVs c2UgTF9OT0RFVigibWZzIikKKwllbHNlIExfTk9ERVYoIm5jcGZzIikKKwllbHNlIExfTk9ERVYo Im5mcyIpCisJZWxzZSBMX05PREVWKCJuZnM0IikKKwllbHNlIExfTk9ERVYoIm5mc2QiKQorCWVs c2UgTF9OT0RFVigibnVsbGZzIikKKwllbHNlIExfTk9ERVYoIm9wZW5wcm9tZnMiKQorCWVsc2Ug TF9OT0RFVigicG9ydGFsZnMiKQorCWVsc2UgTF9OT0RFVigicHJvY2ZzIikKKwllbHNlIExfTk9E RVYoImxpbnByb2NmcyIpCisJZWxzZSBMX05PREVWKCJyYW1mcyIpCisJZWxzZSBMX05PREVWKCJy b290ZnMiKQorCWVsc2UgTF9OT0RFVigic21iZnMiKQorCWVsc2UgTF9OT0RFVigibGluc3lzZnMi KQorCWVsc2UgTF9OT0RFVigidW5pb25mcyIpCisJZWxzZQorCQlmcy0+ZnNfZmxhZ3MgPSAxOwkv KiBGU19SRVFVSVJFU19ERVYgKi8KKworCUYyTF9OQU1FKCJleHQyZnMiLCAiZXh0MiIpCisJZWxz ZSBGMkxfTkFNRSgiY2Q5NjYwIiwgImlzbzk2NjAiKQorCWVsc2UgRjJMX05BTUUoIm1zZG9zZnMi LCAibXNkb3MiKQorCWVsc2UgRjJMX05BTUUoInByb2NmcyIsICJic2Rwcm9jZnMiKQorCWVsc2Ug RjJMX05BTUUoImxpbnByb2NmcyIsICJwcm9jIikKKwllbHNlIEYyTF9OQU1FKCJsaW5zeXNmcyIs ICJzeXNmcyIpCisJZWxzZSBGMkxfTkFNRSgiZmZzIiwgInVmcyIpCisJZWxzZQorCQlzdHJjcHko ZnMtPm5hbWUsIG5hbWUpOworI3VuZGVmIExfTk9ERVYKKyN1bmRlZiBGMkxfTkFNRQorfQorCit2 b2lkCitsaW51eF90b19ic2RfZnMoY2hhciAqbmFtZSwgc3RydWN0IGxpbnV4X2ZpbGVfc3lzdGVt X3R5cGUgKmZzKQoreworCisjZGVmaW5lIEwyRl9OQU1FKGxuYW1lLCBmbmFtZSkgXAorCWlmIChz dHJjbXAobG5hbWUsIG5hbWUpID09IDApIFwKKwkgICBzdHJjcHkoZnMtPm5hbWUsIGZuYW1lKTsK KworCUwyRl9OQU1FKCJleHQyIiwgImV4dDJmcyIpCisJZWxzZSBMMkZfTkFNRSgiZXh0MyIsICJl eHQyZnMiKQorCWVsc2UgTDJGX05BTUUoImlzbzk2NjAiLCAiY2Q5NjYwIikKKwllbHNlIEwyRl9O QU1FKCJtc2RvcyIsICJtc2Rvc2ZzIikKKwllbHNlIEwyRl9OQU1FKCJic2Rwcm9jZnMiLCAicHJv Y2ZzIikKKwllbHNlIEwyRl9OQU1FKCJwcm9jIiwgImxpbnByb2NmcyIpCisJZWxzZSBMMkZfTkFN RSgic3lzZnMiLCAibGluc3lzZnMiKQorCWVsc2UgTDJGX05BTUUoInVmcyIsICJmZnMiKQorCWVs c2UgTDJGX05BTUUoInZmYXQiLCAibXNkb3NmcyIpCisJZWxzZQorCQlzdHJjcHkoZnMtPm5hbWUs IG5hbWUpOworCisjdW5kZWYgTDJGX05BTUUKK30KSW5kZXg6IGNvbXBhdC9saW51eC9saW51eF91 dGlsLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9saW51 eC9saW51eF91dGlsLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjgKZGlmZiAtdSAtcjEuMjgg bGludXhfdXRpbC5oCi0tLSBjb21wYXQvbGludXgvbGludXhfdXRpbC5oCTI3IEp1biAyMDA2IDE4 OjMwOjQ5IC0wMDAwCTEuMjgKKysrIGNvbXBhdC9saW51eC9saW51eF91dGlsLmgJMTQgSmFuIDIw MDcgMDI6MDg6NDIgLTAwMDAKQEAgLTEwMSw0ICsxMDEsMTIgQEAKIGNoYXIJKmxpbnV4X2dldF9j aGFyX2RldmljZXModm9pZCk7CiB2b2lkCWxpbnV4X2ZyZWVfZ2V0X2NoYXJfZGV2aWNlcyhjaGFy ICpzdHJpbmcpOwogCitzdHJ1Y3QgbGludXhfZmlsZV9zeXN0ZW1fdHlwZSB7CisJY2hhcgluYW1l WzE2XTsKKwlpbnQJZnNfZmxhZ3M7Cit9OworCit2b2lkCWJzZF90b19saW51eF9mcyhjaGFyICpu YW1lLCBzdHJ1Y3QgbGludXhfZmlsZV9zeXN0ZW1fdHlwZSAqZnMpOwordm9pZAlsaW51eF90b19i c2RfZnMoY2hhciAqbmFtZSwgc3RydWN0IGxpbnV4X2ZpbGVfc3lzdGVtX3R5cGUgKmZzKTsKKwog I2VuZGlmIC8qICFfTElOVVhfVVRJTF9IXyAqLwpJbmRleDogY29tcGF0L2xpbnByb2Nmcy9saW5w cm9jZnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L2xp bnByb2Nmcy9saW5wcm9jZnMuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMDEKZGlmZiAtdSAt cjEuMTAxIGxpbnByb2Nmcy5jCi0tLSBjb21wYXQvbGlucHJvY2ZzL2xpbnByb2Nmcy5jCTI3IE5v diAyMDA2IDIxOjEwOjU1IC0wMDAwCTEuMTAxCisrKyBjb21wYXQvbGlucHJvY2ZzL2xpbnByb2Nm cy5jCTE0IEphbiAyMDA3IDAwOjA3OjI4IC0wMDAwCkBAIC0xMDMxLDYgKzEwMzEsMjQgQEAKIH0K IAogLyoKKyAqIEZpbGxlciBmdW5jdGlvbiBmb3IgcHJvYy9maWxlc3lzdGVtcworICovCitzdGF0 aWMgaW50CitsaW5wcm9jZnNfZG9maWxlc3lzdGVtcyhQRlNfRklMTF9BUkdTKQoreworCXN0cnVj dCB2ZnNjb25mICp2ZnNwOworCXN0cnVjdCBsaW51eF9maWxlX3N5c3RlbV90eXBlIGZzOworCisJ VEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29uZiwgdmZjX2xpc3QpIHsKKwkJYnNkX3RvX2xpbnV4 X2ZzKHZmc3AtPnZmY19uYW1lLCAmZnMpOworCQlzYnVmX3ByaW50ZihzYiwgIiVzXHQlc1xuIiwg XAorCQkgICAgZnMuZnNfZmxhZ3MgPyAiIiA6ICJub2RldiIsIGZzLm5hbWUpOworCX0KKworCXJl dHVybiAoMCk7Cit9CisKKy8qCiAgKiBGaWxsZXIgZnVuY3Rpb24gZm9yIHByb2MvY21kbGluZQog ICovCiBzdGF0aWMgaW50CkBAIC0xMDc2LDYgKzEwOTQsOCBAQAogCSAgICBOVUxMLCBOVUxMLCBQ RlNfUkQpOwogCXBmc19jcmVhdGVfZmlsZShyb290LCAiZGV2aWNlcyIsICZsaW5wcm9jZnNfZG9k ZXZpY2VzLAogCSAgICBOVUxMLCBOVUxMLCBQRlNfUkQpOworCXBmc19jcmVhdGVfZmlsZShyb290 LCAiZmlsZXN5c3RlbXMiLCAmbGlucHJvY2ZzX2RvZmlsZXN5c3RlbXMsCisJICAgIE5VTEwsIE5V TEwsIFBGU19SRCk7CiAJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJsb2FkYXZnIiwgJmxpbnByb2Nm c19kb2xvYWRhdmcsCiAJICAgIE5VTEwsIE5VTEwsIFBGU19SRCk7CiAJcGZzX2NyZWF0ZV9maWxl KHJvb3QsICJtZW1pbmZvIiwgJmxpbnByb2Nmc19kb21lbWluZm8sCg== ------=_Part_30898_24571429.1168748225274-- From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 14 09:28:19 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10BF116A415; Sun, 14 Jan 2007 09:28:19 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E57D713C43E; Sun, 14 Jan 2007 09:28:18 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 2A7D863B; Sun, 14 Jan 2007 03:28:18 -0600 (CST) Date: Sun, 14 Jan 2007 03:28:18 -0600 To: Andrew Pantyukhin Message-ID: <20070114092818.GB1223@soaustin.net> References: <21940630@bsam.ru> <20061223211725.GB24163@soaustin.net> <20061224120420.0542dfdb@Magellan.Leidinger.net> <20061224113035.GA25941@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: emulation@freebsd.org, Mark Linimon , Alexander Leidinger Subject: Re: Overlong mailing-list maintainer address in ports X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 09:28:19 -0000 On Sat, Jan 13, 2007 at 11:15:33PM +0300, Andrew Pantyukhin wrote: > Right. The question is, should we stick to shorter > form for maintainership or allow both forms being > used on a case-by-case basis. We should pick one or the other; otherwise, there are duplicate posts to the mailing lists from the reminder-mail from GNATS, among other annoyances. mcl From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 14 10:52:43 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E70416A407 for ; Sun, 14 Jan 2007 10:52:43 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 955FA13C44B for ; Sun, 14 Jan 2007 10:52:42 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0EAqdlV008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jan 2007 11:52:39 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0EAqdF6008117; Sun, 14 Jan 2007 11:52:39 +0100 (CET) Date: Sun, 14 Jan 2007 11:52:39 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070114105239.GA6955@stud.fit.vutbr.cz> References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: Alexander Leidinger , freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 10:52:43 -0000 a few notes.. =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_misc.c,v retrieving revision 1.205 diff -u -r1.205 linux_misc.c --- compat/linux/linux_misc.c 7 Jan 2007 19:30:19 -0000 1.205 +++ compat/linux/linux_misc.c 14 Jan 2007 01:56:41 -0000 @@ -1711,3 +1724,83 @@ return (error); } int linux_chroot(struct thread *td, struct linux_chroot_args *args) { return (chroot(td, (struct chroot_args *)args)); } + +int +linux_sysfs(struct thread *td, struct linux_sysfs_args *args) +{ + int error=0; + unsigned int index = 0; + size_t len; + char *buf; + char *name; + struct linux_file_system_type fs; + struct vfsconf *vfsp; + + switch (args->option) { + /* + * Translate the filesystem identifier string into a + * filesystem type index. + */ + case 1: I'd use #define BAH 1. I know linux code uses 1,2,3 but we are not linux :) + /* is args->arg1 is valid, if not valid return EFAULT */ + name = (char *) malloc(MFSNAMELEN, M_TEMP, M_WAITOK); + error = copyinstr((char *)(uintptr_t)args->arg1, name, + MFSNAMELEN, &len); + if (error) { + LFREEPATH(name); use free() here. the LFREEPATH is meant to be used with the LCONVPATH... macros. + return (error); + } + + error = EINVAL; + + linux_to_bsd_fs(name, &fs); + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) + if (strcmp(vfsp->vfc_name, fs.name) == 0) { + td->td_retval[0] = index; + error = 0; + break; + } else + index++; + LFREEPATH(name); + break; + + /* + * Translate the file-system type index into a null-terminated + * filesystem identifier string. + */ + case 2: + index = args->arg1; + buf = (char *)(uintptr_t)args->arg2; + + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) + if (index-- <= 0) + break; + if (!vfsp) + return EINVAL; style - return (EINVAL); + bsd_to_linux_fs(vfsp->vfc_name, &fs); + len = strlen(fs.name) + 1; + error = copyout(fs.name, buf, len); no need to check if it fits in the userspace buffer? also you dont check return value + break; + + /* + * Return the total number of file system types currently present + * in the kernel. + */ + case 3: + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) + index++; + td->td_retval[0] = index; does this make sense? shouldnt we return just the number of filesystems that we share with linux? + break; + default: + error = EINVAL; + } + return (error); +} Index: compat/linux/linux_util.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_util.c,v retrieving revision 1.31 diff -u -r1.31 linux_util.c --- compat/linux/linux_util.c 15 Aug 2006 12:54:29 -0000 1.31 +++ compat/linux/linux_util.c 14 Jan 2007 02:11:08 -0000 @@ -224,3 +224,82 @@ return (EINVAL); } + +void +bsd_to_linux_fs(char *name, struct linux_file_system_type *fs) +{ +#define L_NODEV(fname) \ + if (strcmp(fname, name) == 0) \ + fs->fs_flags = 0; +#define F2L_NAME(fname, lname) \ + if (strcmp(fname, name) == 0) \ + strcpy(fs->name, lname); + + L_NODEV("9p") + else L_NODEV("afs") + else L_NODEV("autofs") + else L_NODEV("cifs") + else L_NODEV("coda") + else L_NODEV("configfs") + else L_NODEV("debugfs") + else L_NODEV("devfs") + else L_NODEV("devpts") + else L_NODEV("fdescfs") + else L_NODEV("fuse") + else L_NODEV("hostfs") + else L_NODEV("hppfs") + else L_NODEV("hugetlbfs") + else L_NODEV("jffs2") + else L_NODEV("mfs") + else L_NODEV("ncpfs") + else L_NODEV("nfs") + else L_NODEV("nfs4") + else L_NODEV("nfsd") + else L_NODEV("nullfs") + else L_NODEV("openpromfs") + else L_NODEV("portalfs") + else L_NODEV("procfs") + else L_NODEV("linprocfs") + else L_NODEV("ramfs") + else L_NODEV("rootfs") + else L_NODEV("smbfs") + else L_NODEV("linsysfs") + else L_NODEV("unionfs") + else + fs->fs_flags = 1; /* FS_REQUIRES_DEV */ + + F2L_NAME("ext2fs", "ext2") + else F2L_NAME("cd9660", "iso9660") + else F2L_NAME("msdosfs", "msdos") + else F2L_NAME("procfs", "bsdprocfs") + else F2L_NAME("linprocfs", "proc") + else F2L_NAME("linsysfs", "sysfs") + else F2L_NAME("ffs", "ufs") + else + strcpy(fs->name, name); +#undef L_NODEV +#undef F2L_NAME man, this is ugly :) cant you come up with some translation table or something? also... you strcpy string to another string, are you sure it always fits? how do you asure that? +} + +void +linux_to_bsd_fs(char *name, struct linux_file_system_type *fs) +{ + +#define L2F_NAME(lname, fname) \ + if (strcmp(lname, name) == 0) \ + strcpy(fs->name, fname); + + L2F_NAME("ext2", "ext2fs") + else L2F_NAME("ext3", "ext2fs") + else L2F_NAME("iso9660", "cd9660") + else L2F_NAME("msdos", "msdosfs") + else L2F_NAME("bsdprocfs", "procfs") + else L2F_NAME("proc", "linprocfs") + else L2F_NAME("sysfs", "linsysfs") + else L2F_NAME("ufs", "ffs") + else L2F_NAME("vfat", "msdosfs") + else + strcpy(fs->name, name); ditto as for bsd_to_linux_fs +#undef L2F_NAME +} Index: compat/linux/linux_util.h =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_util.h,v retrieving revision 1.28 diff -u -r1.28 linux_util.h --- compat/linux/linux_util.h 27 Jun 2006 18:30:49 -0000 1.28 +++ compat/linux/linux_util.h 14 Jan 2007 02:08:42 -0000 @@ -101,4 +101,12 @@ char *linux_get_char_devices(void); void linux_free_get_char_devices(char *string); +struct linux_file_system_type { + char name[16]; + int fs_flags; +}; 16? why 16? please comment or something +void bsd_to_linux_fs(char *name, struct linux_file_system_type *fs); +void linux_to_bsd_fs(char *name, struct linux_file_system_type *fs); + #endif /* !_LINUX_UTIL_H_ */ Index: compat/linprocfs/linprocfs.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linprocfs/linprocfs.c,v retrieving revision 1.101 diff -u -r1.101 linprocfs.c --- compat/linprocfs/linprocfs.c 27 Nov 2006 21:10:55 -0000 1.101 +++ compat/linprocfs/linprocfs.c 14 Jan 2007 00:07:28 -0000 @@ -1031,6 +1031,24 @@ } /* + * Filler function for proc/filesystems + */ +static int +linprocfs_dofilesystems(PFS_FILL_ARGS) +{ + struct vfsconf *vfsp; + struct linux_file_system_type fs; + + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) { + bsd_to_linux_fs(vfsp->vfc_name, &fs); + sbuf_printf(sb, "%s\t%s\n", \ + fs.fs_flags ? "" : "nodev", fs.name); + } + + return (0); +} + +/* * Filler function for proc/cmdline */ static int @@ -1076,6 +1094,8 @@ NULL, NULL, PFS_RD); pfs_create_file(root, "devices", &linprocfs_dodevices, NULL, NULL, PFS_RD); + pfs_create_file(root, "filesystems", &linprocfs_dofilesystems, + NULL, NULL, PFS_RD); pfs_create_file(root, "loadavg", &linprocfs_doloadavg, NULL, NULL, PFS_RD); pfs_create_file(root, "meminfo", &linprocfs_domeminfo, From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 14 20:54:30 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23C3E16A412 for ; Sun, 14 Jan 2007 20:54:30 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id D307913C45B for ; Sun, 14 Jan 2007 20:54:29 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so772257wra for ; Sun, 14 Jan 2007 12:54:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QPY6+XRwrRo9W4wMfgk8MR1lHxC4DfyvVro6PjP6/+0m/cUzz0LeD2FxHRqRaGauyfW1FIPm7lauIAG6PNSvD0IEQYazVbWVbR/P99OXz8FzBiI4nd5tjZ69SwDWFBghoudLR3NjjjDKpCQ9rSLPKPq8bBTTMuPEp3laWwtzdkE= Received: by 10.64.27.13 with SMTP id a13mr4434098qba.1168808068828; Sun, 14 Jan 2007 12:54:28 -0800 (PST) Received: by 10.65.189.7 with HTTP; Sun, 14 Jan 2007 12:54:28 -0800 (PST) Message-ID: <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> Date: Sun, 14 Jan 2007 14:54:28 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070114105239.GA6955@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_34096_20425344.1168808068782" References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> Cc: Alexander Leidinger , freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 20:54:30 -0000 ------=_Part_34096_20425344.1168808068782 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/14/07, Divacky Roman wrote: > a few notes.. > > + switch (args->option) { > + /* > + * Translate the filesystem identifier string into a > + * filesystem type index. > + */ > + case 1: > > I'd use #define BAH 1. I know linux code uses 1,2,3 but we are not linux :) > Ok, I'll change them to GETFSIND, GETFSTYP, and GETNFSTYP, found them defined in a couple of other online man pages (sgi, HP-UX, ..) for sysfs. http://www.docs.hp.com/en/B9106-90009/sysfs.2.html > + if (error) { > + LFREEPATH(name); > > use free() here. the LFREEPATH is meant to be used with the LCONVPATH... > macros. > Wasn't sure, if I should use free or LFREEPATH, it's simple enough to change. > + if (!vfsp) > + return EINVAL; > > style - return (EINVAL); > Missed that one, will make the change. > + buf = (char *)(uintptr_t)args->arg2; : > + bsd_to_linux_fs(vfsp->vfc_name, &fs); > + len = strlen(fs.name) + 1; > + error = copyout(fs.name, buf, len); > > no need to check if it fits in the userspace buffer? also you > dont check return value > According to the linux man page, there isn't a way to check the size of buf, as we are only passed the value of the pointer in args->arg2. Should I replace buf with (char *)(uintptr_t)args->arg2 in the copyout, since it is only used there. http://www.die.net/doc/linux/man/man2/sysfs.2.html I didn't check the return value, as error is going to be set to either 0 or EFAULT by the copyout function. Since it's the end of the case, it falls thru to the return statement at the bottom of the function. > + break; > + > + /* > + * Return the total number of file system types currently present > + * in the kernel. > + */ > + case 3: > + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) > + index++; > + td->td_retval[0] = index; > > does this make sense? shouldnt we return just the number of filesystems > that we share with linux? > There are only 7 filesystems that are freebsd specific (devfs, fdescfs, mfs, nullfs, portalfs, procfs (bsd), unionfs). If we exclude these filesystems, then we would need to ensure that we skip them in the other two options. The way that it is currently emulated, is that all freebsd filesystems (kldloaded filesystems) are available to the linuxolator. > + break; > + default: > + error = EINVAL; > + } > + return (error); > +} > Index: compat/linux/linux_util.c > =================================================================== > RCS file: /home/ncvs/src/sys/compat/linux/linux_util.c,v > retrieving revision 1.31 > diff -u -r1.31 linux_util.c > --- compat/linux/linux_util.c 15 Aug 2006 12:54:29 -0000 1.31 > +++ compat/linux/linux_util.c 14 Jan 2007 02:11:08 -0000 > @@ -224,3 +224,82 @@ > > return (EINVAL); > } > + > +void > +bsd_to_linux_fs(char *name, struct linux_file_system_type *fs) > +{ > +#define L_NODEV(fname) \ > + if (strcmp(fname, name) == 0) \ > + fs->fs_flags = 0; > +#define F2L_NAME(fname, lname) \ > + if (strcmp(fname, name) == 0) \ > + strcpy(fs->name, lname); > + > + L_NODEV("9p") > + else L_NODEV("afs") > + else L_NODEV("autofs") > + else L_NODEV("cifs") > + else L_NODEV("coda") > + else L_NODEV("configfs") > + else L_NODEV("debugfs") > + else L_NODEV("devfs") > + else L_NODEV("devpts") > + else L_NODEV("fdescfs") > + else L_NODEV("fuse") > + else L_NODEV("hostfs") > + else L_NODEV("hppfs") > + else L_NODEV("hugetlbfs") > + else L_NODEV("jffs2") > + else L_NODEV("mfs") > + else L_NODEV("ncpfs") > + else L_NODEV("nfs") > + else L_NODEV("nfs4") > + else L_NODEV("nfsd") > + else L_NODEV("nullfs") > + else L_NODEV("openpromfs") > + else L_NODEV("portalfs") > + else L_NODEV("procfs") > + else L_NODEV("linprocfs") > + else L_NODEV("ramfs") > + else L_NODEV("rootfs") > + else L_NODEV("smbfs") > + else L_NODEV("linsysfs") > + else L_NODEV("unionfs") > + else > + fs->fs_flags = 1; /* FS_REQUIRES_DEV */ > + > + F2L_NAME("ext2fs", "ext2") > + else F2L_NAME("cd9660", "iso9660") > + else F2L_NAME("msdosfs", "msdos") > + else F2L_NAME("procfs", "bsdprocfs") > + else F2L_NAME("linprocfs", "proc") > + else F2L_NAME("linsysfs", "sysfs") > + else F2L_NAME("ffs", "ufs") > + else > + strcpy(fs->name, name); > +#undef L_NODEV > +#undef F2L_NAME > > man, this is ugly :) cant you come up with some translation table or something? > I had created a table (see attached linux.fs), but wasn't sure how to parse it, or how to keep it up todate as more filesystems are added. > also... you strcpy string to another string, are you sure it always fits? how do you > asure that? > name can't be larger than MFSNAMELEN, and sizeof(fs->name) == MFSNAMELEN. > RCS file: /home/ncvs/src/sys/compat/linux/linux_util.h,v > retrieving revision 1.28 > diff -u -r1.28 linux_util.h > --- compat/linux/linux_util.h 27 Jun 2006 18:30:49 -0000 1.28 > +++ compat/linux/linux_util.h 14 Jan 2007 02:08:42 -0000 > @@ -101,4 +101,12 @@ > char *linux_get_char_devices(void); > void linux_free_get_char_devices(char *string); > > +struct linux_file_system_type { > + char name[16]; > + int fs_flags; > +}; > > 16? why 16? please comment or something > 16 is the value of MFSNAMELEN and used by the vfsconf struct to define the max size of vfc_name. I kept name (in the linux_file_system_type struct) the same size, so that we didn't have to worry about the size when using strcpy. I also wasn't sure if I should add: #include in linux_util.h so that MFSNAMELEN could be used to define the size of name in the struct (it may also affect other files, that include linux_util.h). Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_34096_20425344.1168808068782 Content-Type: text/plain; name=linux.fs; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ewxubaua Content-Disposition: attachment; filename="linux.fs" CmxfbmFtZQkJZl9uYW1lCQlrX21vZHVsZSwJZmxhZ3MJCQlkZXNjcmlwdGlvbgoiOXAiLAkJTlVM TCwJCU5VTEwsCQlOVUxMLAkJCSJQbGFuIDkgRmlsZXN5c3RlbSIsCiJhZGZzIiwJCU5VTEwsCQlO VUxMLAkJRlNfUkVRVUlSRVNfREVWLAkiIiwKImFmZnMiLAkJTlVMTCwJCU5VTEwsCQlGU19SRVFV SVJFU19ERVYsCSJBbWlnYSBGaWxlc3lzdGVtIiwKImFmcyIsCQlOVUxMLAkJTlVMTCwJCUZTX0JJ TkFSWV9NT1VOVERBVEEsCSJBRlMgQ2xpZW50IEZpbGVzeXN0ZW0iLAoiYXV0b2ZzIiwJTlVMTCwJ CU5VTEwsCQlOVUxMLAkJCSJBdXRvIEZpbGVzeXN0ZW0iLAoiYmVmcyIsCQlOVUxMLAkJTlVMTCwJ CUZTX1JFUVVJUkVTX0RFViwJIkJlT1MgRmlsZXN5c3RlbSAoQmVGUykiLAoiYmZzIiwJCU5VTEws CQlOVUxMLAkJRlNfUkVRVUlSRVNfREVWLAkiU0NPIFVuaXhXYXJlIEJGUyBGaWxlc3lzdGVtIiwK ImNpZnMiCQlOVUxMLAkJTlVMTCwJCU5VTEwsCQkJIlNOSUEgQ0lGUyBGaWxlc3lzdGVtIiwKImNv ZGEiLAkJTlVMTCwJCU5VTEwsCQlGU19CSU5BUllfTU9VTlREQVRBLAkiIiwKImNvbmZpZ2ZzIglO VUxMLAkJTlVMTCwJCU5VTEwsCQkJIlNpbXBsZSBSQU0gRmlsZXN5c3RlbSBmb3IgdXNlciBkcml2 ZW4ga2VybmVsIHN1YnN5c3RlbSBjb25maWd1cmF0aW9uLiIsCiJjcmFtZnMiLAlOVUxMLAkJTlVM TCwJCUZTX1JFUVVJUkVTX0RFViwJIkNvbXByZXNzZWQgUk9NIEZpbGVzeXN0ZW0iLAoiZGVidWdm cyIsCU5VTEwsCQlOVUxMLAkJTlVMTCwJCQkiIiwKTlVMTCwJCSJkZXZmcyIsCSJkZXZmcyIsCU5V TEwsCQkJIkZyZWVCU0QgRGV2aWNlIEZpbGVzeXN0ZW0iLAoiZGV2cHRzIiwJTlVMTCwJCU5VTEwJ CU5VTEwsLAkJCSIiLAoiZWZzIiwJCU5VTEwsCQlOVUxMLAkJRlNfUkVRVUlSRVNfREVWLAkiIiwK ImV4dDIiLAkJImV4dDJmcyIsCSJleHQyZnMiLAlGU19SRVFVSVJFU19ERVYsCSJTZWNvbmQgRXh0 ZW5kZWQgRmlsZXN5c3RlbSIsCiJleHQzIiwJCSJleHQyZnMiLAkiZXh0MmZzIiwJRlNfUkVRVUlS RVNfREVWLAkiU2Vjb25kIEV4dGVuZGVkIEZpbGVzeXN0ZW0gd2l0aCBKb3VybmFsaW5nIiwKTlVM TCwJCSJmZGVzY2ZzIiwJImZkZXNjZnMiLAlOVUxMLAkJCSJGcmVlQlNEIEZpbGUgRGVzY3JpcHRv ciBGaWxlc3lzdGVtIiwKImZ1c2UiCQlOVUxMLAkJTlVMTCwJCU5VTEwsCQkJIkZpbGVzeXN0ZW0g aW4gVXNlcnNwYWNlIiwKImhmcyIsCQlOVUxMLAkJTlVMTCwJCUZTX1JFUVVJUkVTX0RFViwJIk1h Y2ludG9zaCBGaWxlc3lzdGVtIiwKImhmc3BsdXMiCU5VTEwsCQlOVUxMLAkJRlNfUkVRVUlSRVNf REVWLAkiRXh0ZW5kZWQgTWFjaW50b3NoIEZpbGVzeXN0ZW0iLAoiaG9zdGZzIglOVUxMLAkJTlVM TCwJCU5VTEwsCQkJIiIsCiJocGZzIiwJCU5VTEwsCQlOVUxMLAkJRlNfUkVRVUlSRVNfREVWLAki IiwKImhwcGZzIiwJTlVMTCwJCU5VTEwsCQlOVUxMLAkJCSIiLAoiaHVnZXRsYmZzIiwJTlVMTCwJ CU5VTEwsCQlOVUxMLAkJCSIiLAoiaXNvOTY2MCIsCSJjZDk2NjAiLAkiY2Q5NjYwIiwJRlNfUkVR VUlSRVNfREVWLAkiIiwKImpmZnMiLAkJTlVMTCwJCU5VTEwsCQlGU19SRVFVSVJFU19ERVYsCSJK b3VybmFsbGluZyBGbGFzaCBGaWxlc3lzdGVtIiwKImpmZnMyIiwJTlVMTCwJCU5VTEwsCQlOVUxM LAkJCSJUaGUgSm91cm5hbGxpbmcgRmxhc2ggRmlsZXN5c3RlbSwgdjIiLAoiamZzIiwJCU5VTEws CQlOVUxMLAkJRlNfUkVRVUlSRVNfREVWLAkiVGhlIEpvdXJuYWxlZCBGaWxlc3lzdGVtIChKRlMp IiwKTlVMTCwJCSJtZnMiCQkiZ19tZCIsCQlOVUxMLAkJCSJGcmVlQlNEIE1lbW9yeSBGaWxlc3lz dGVtIiwKIm1pbml4IiwJTlVMTCwJCU5VTEwsCQlGU19SRVFVSVJFU19ERVYsCSIiLAoibXNkb3Mi LAkibXNkb3NmcyIsCSJtc2Rvc2ZzIiwJRlNfUkVRVUlSRVNfREVWLAkiTVMtRE9TIGZpbGVzeXN0 ZW0gc3VwcG9ydCIsCiJuY3BmcyIsCU5VTEwsCQlOVUxMLAkJTlVMTCwJCQkiIiwKIm5mcyIsCQki bmZzIiwJCSJuZnMiLAkJRlNfT0REX1JFTkFNRXxGU19SRVZBTF9ET1R8RlNfQklOQVJZX01PVU5U REFUQSwJIiIsCiJuZnM0IiwJCSJuZnM0IiwJCSJuZnM0IiwJCUZTX09ERF9SRU5BTUV8RlNfUkVW QUxfRE9UfEZTX0JJTkFSWV9NT1VOVERBVEEsCSIiLAoibmZzZCIsCQlOVUxMLAkJTlVMTCwJCU5V TEwsCQkJIiIsCiJudGZzIgkJIm50ZnMiLAkJIm50ZnMiLAkJRlNfUkVRVUlSRVNfREVWLAkiTlRG UyAxLjIvMy54IGRyaXZlciAtIENvcHlyaWdodCAoYykgMjAwMS0yMDA2IEFudG9uIEFsdGFwYXJt YWtvdiIsCk5VTEwsCQkibnVsbGZzIiwJIm51bGxmcyIJTlVMTCwJCQkiRnJlZUJTRCBOdWxsIEZp bGVzeXN0ZW0iLAoib2NmczIiCQlOVUxMLAkJTlVMTCwJCUZTX1JFUVVJUkVTX0RFViwJIk9DRlMy IDEuMy4zIiwKIm9wZW5wcm9tZnMiLAlOVUxMLAkJTlVMTCwJCU5VTEwsCQkJIiIsCk5VTEwsCQki cG9ydGFsZnMiLAkicG9ydGFsZnMiLAlOVUxMLAkJCSJGcmVlQlNEIFBvcnRhbCBGaWxlc3lzdGVt IiwKTlVMTCwJCSJwcm9jZnMiLAkicHJvY2ZzIiwJTlVMTCwJCQkiRnJlZUJTRCBQcm9jZXNzIEZp bGVzeXN0ZW0iLAoicHJvYyIsCQkibGlucHJvY2ZzIiwJImxpbnByb2NmcyIsCU5VTEwsCQkJIkxp bnV4IFByb2Nlc3MgRmlsZXN5c3RlbSIsCiJxbng0IiwJCU5VTEwsCQlOVUxMLAkJRlNfUkVRVUlS RVNfREVWLAkiUU5YNCBmaWxlIHN5c3RlbSIsCiJyYW1mcyIsCU5VTEwsCQlOVUxMLAkJTlVMTCwJ CQkiUmVzaXphYmxlIHNpbXBsZSBSQU0gRmlsZXN5c3RlbSIsCiJyb290ZnMiLAlOVUxMLAkJTlVM TCwJCU5VTEwsCQkJIiIsCiJyZWlzZXJmcyIsCSJyZWlzZXJmcyIsCSJyZWlzZXJmcyIsCUZTX1JF UVVJUkVTX0RFViwJIlJlaXNlckZTIEpvdXJuYWxlZCBGaWxlc3lzdGVtIiwKInJvbWZzIgkJTlVM TCwJCU5VTEwsCQlGU19SRVFVSVJFU19ERVYsCSJST01GUyBGaWxlc3lzdGVtIiwKInNtYmZzIiwJ InNtYmZzIiwJInNtYmZzIiwJRlNfQklOQVJZX01PVU5UREFUQSwJIiIsCiJzeXNmcyIsCSJsaW5z eXNmcyIsCSJsaW5zeXNmcyIsCU5VTEwsCQkJIkxpbnV4IFN5c3RlbSBGaWxlc3lzdGVtIiwKInN5 c3YiLAkJTlVMTCwJCU5VTEwsCQlGU19SRVFVSVJFU19ERVYsCSIiLAoidjciLAkJTlVMTCwJCU5V TEwsCQlGU19SRVFVSVJFU19ERVYsCSIiLAoidWRmIgkJInVkZiIsCQkidWRmIiwJCUZTX1JFUVVJ UkVTX0RFViwJIlVuaXZlcnNhbCBEaXNrIEZvcm1hdCBGaWxlc3lzdGVtIiwKTlVMTCwJCSJmZnMi LAkJInVmcyIsCQlGU19SRVFVSVJFU19ERVYsCSJCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0iLAoi dWZzIiwJCSJ1ZnMiLAkJInVmcyIsCQlGU19SRVFVSVJFU19ERVYsCSJCZXJrZWxleSBGYXN0IEZp bGVzeXN0ZW0iLApOVUxMLAkJInVuaW9uZnMiLAkidW5pb25mcyIJTlVMTCwJCQkiRnJlZUJTRCBV bmlvbiBGaWxlc3lzdGVtIiwKInZmYXQiLAkJIm1zZG9zZnMiLAkibXNkb3NmcyIsCUZTX1JFUVVJ UkVTX0RFViwJIlZGQVQgRmlsZXN5c3RlbSIsCiJ2eGZzIiwJCU5VTEwsCQlOVUxMLAkJRlNfUkVR VUlSRVNfREVWLAkiVmVyaXRhcyBGaWxlc3lzdGVtIChWeEZTKSBkcml2ZXIiLAoieGZzIiwJCSJ4 ZnMiLAkJInhmcyIsCQlGU19SRVFVSVJFU19ERVYsCSJTR0kgWEZTIiwKTlVMTCwJCSJ6ZnMiCQki emZzIgkJRlNfUkVRVUlSRVNfREVWLAkiU29sYXJpcyBaZXR0YWJ5dGUgRmlsZSBTeXN0ZW0i ------=_Part_34096_20425344.1168808068782-- From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 15 08:33:40 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56A4316A416 for ; Mon, 15 Jan 2007 08:33:40 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id F088813C47E for ; Mon, 15 Jan 2007 08:33:39 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0F8Xbc5002779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 09:33:37 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0F8XaCm002778; Mon, 15 Jan 2007 09:33:36 +0100 (CET) Date: Mon, 15 Jan 2007 09:33:36 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070115083336.GA2073@stud.fit.vutbr.cz> References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: Alexander Leidinger , freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 08:33:40 -0000 > >+ buf = (char *)(uintptr_t)args->arg2; > : > >+ bsd_to_linux_fs(vfsp->vfc_name, &fs); > >+ len = strlen(fs.name) + 1; > >+ error = copyout(fs.name, buf, len); > > > >no need to check if it fits in the userspace buffer? also you > >dont check return value > > > > According to the linux man page, there isn't a way to check the size > of buf, as we are only passed the value of the pointer in args->arg2. > Should I replace buf with (char *)(uintptr_t)args->arg2 in the > copyout, since it is only used there. > > http://www.die.net/doc/linux/man/man2/sysfs.2.html > > I didn't check the return value, as error is going to be set to either > 0 or EFAULT by the copyout function. Since it's the end of the case, > it falls thru to the return statement at the bottom of the function. ok > >+ break; > >+ > >+ /* > >+ * Return the total number of file system types currently > >present > >+ * in the kernel. > >+ */ > >+ case 3: > >+ TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) > >+ index++; > >+ td->td_retval[0] = index; > > > >does this make sense? shouldnt we return just the number of filesystems > >that we share with linux? > > > > There are only 7 filesystems that are freebsd specific (devfs, > fdescfs, mfs, nullfs, portalfs, procfs (bsd), unionfs). If we exclude > these filesystems, then we would need to ensure that we skip them in > the other two options. > > The way that it is currently emulated, is that all freebsd filesystems > (kldloaded filesystems) are available to the linuxolator. sounds sane... but what happens when userspace program gets FSs it doesnt know or something? I mean.. is it safe to reveal everything? > >+ else L_NODEV("rootfs") > >+ else L_NODEV("smbfs") > >+ else L_NODEV("linsysfs") > >+ else L_NODEV("unionfs") > >+ else > >+ fs->fs_flags = 1; /* FS_REQUIRES_DEV */ > >+ > >+ F2L_NAME("ext2fs", "ext2") > >+ else F2L_NAME("cd9660", "iso9660") > >+ else F2L_NAME("msdosfs", "msdos") > >+ else F2L_NAME("procfs", "bsdprocfs") > >+ else F2L_NAME("linprocfs", "proc") > >+ else F2L_NAME("linsysfs", "sysfs") > >+ else F2L_NAME("ffs", "ufs") > >+ else > >+ strcpy(fs->name, name); > >+#undef L_NODEV > >+#undef F2L_NAME > > > >man, this is ugly :) cant you come up with some translation table or > >something? > > > I had created a table (see attached linux.fs), but wasn't sure how to > parse it, or how to keep it up todate as more filesystems are added. well. this is not performance sensitive so basically any kind of parsing should do it. I like the table MUCH more then the macro thing you presented previously. dont worry about performance of the parsing - table with 30 (or so) entries is not performance critical > >also... you strcpy string to another string, are you sure it always fits? > >how do you > >asure that? > > > > name can't be larger than MFSNAMELEN, and sizeof(fs->name) == MFSNAMELEN. sounds fair > >RCS file: /home/ncvs/src/sys/compat/linux/linux_util.h,v > >retrieving revision 1.28 > >diff -u -r1.28 linux_util.h > >--- compat/linux/linux_util.h 27 Jun 2006 18:30:49 -0000 1.28 > >+++ compat/linux/linux_util.h 14 Jan 2007 02:08:42 -0000 > >@@ -101,4 +101,12 @@ > > char *linux_get_char_devices(void); > > void linux_free_get_char_devices(char *string); > > > >+struct linux_file_system_type { > >+ char name[16]; > >+ int fs_flags; > >+}; > > > >16? why 16? please comment or something > > > 16 is the value of MFSNAMELEN and used by the vfsconf struct to define > the max size of vfc_name. I kept name (in the linux_file_system_type > struct) the same size, so that we didn't have to worry about the size > when using strcpy. > > I also wasn't sure if I should add: > > #include > > in linux_util.h so that MFSNAMELEN could be used to define the size of > name in the struct (it may also affect other files, that include > linux_util.h). definitely use the define MFSNAMELEN instead of 16 From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 15 09:59:31 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C6AC16A40F for ; Mon, 15 Jan 2007 09:59:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id CC5A513C44C for ; Mon, 15 Jan 2007 09:59:30 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D01F.dip.t-dialin.net [84.165.208.31]) by redbull.bpaserver.net (Postfix) with ESMTP id 980D82E216; Mon, 15 Jan 2007 11:06:34 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id B8CDA5B497E; Mon, 15 Jan 2007 10:59:21 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0F9xLHp018715; Mon, 15 Jan 2007 10:59:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 15 Jan 2007 10:59:21 +0100 Message-ID: <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 15 Jan 2007 10:59:21 +0100 From: Alexander Leidinger To: Scot Hetzel References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> In-Reply-To: <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.71, required 6, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_CP 0.08, TW_OC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 09:59:31 -0000 Quoting Scot Hetzel (from Sun, 14 Jan 2007 =20 14:54:28 -0600): > On 1/14/07, Divacky Roman wrote: >> + buf =3D (char *)(uintptr_t)args->arg2; > : >> + bsd_to_linux_fs(vfsp->vfc_name, &fs); >> + len =3D strlen(fs.name) + 1; >> + error =3D copyout(fs.name, buf, len); >> >> no need to check if it fits in the userspace buffer? also you >> dont check return value >> > > According to the linux man page, there isn't a way to check the size > of buf, as we are only passed the value of the pointer in args->arg2. Ugh... there's not even an implicit size because of a fixed definition =20 of the target buffer in some header? That would be very bad design. =20 The kernel could overwrite userland data even if the kernel is not =20 malicious (load a new FS with a too long name and BOOOOM). > Should I replace buf with (char *)(uintptr_t)args->arg2 in the > copyout, since it is only used there. > > http://www.die.net/doc/linux/man/man2/sysfs.2.html ---snip--- BUGS There is no libc or glibc support. There is no way to guess how large =20 buf should be. ---snip--- That's bad. That's very very bad. I don't like this in the FreeBSD =20 kernel, I want an upper bound. Would you please try to find some =20 artificial upper bound? The MFSNAMELEN would be one candidate. A =20 better candidate would be a similar Linux value. > I didn't check the return value, as error is going to be set to either > 0 or EFAULT by the copyout function. Since it's the end of the case, > it falls thru to the return statement at the bottom of the function. > >> + break; >> + >> + /* >> + * Return the total number of file system types =20 >> currently present >> + * in the kernel. >> + */ >> + case 3: >> + TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) >> + index++; >> + td->td_retval[0] =3D index; >> >> does this make sense? shouldnt we return just the number of filesystems >> that we share with linux? >> > > There are only 7 filesystems that are freebsd specific (devfs, > fdescfs, mfs, nullfs, portalfs, procfs (bsd), unionfs). If we exclude > these filesystems, then we would need to ensure that we skip them in > the other two options. > > The way that it is currently emulated, is that all freebsd filesystems > (kldloaded filesystems) are available to the linuxolator. I suggest to keep the FreeBSD ones visible, we can revisit this =20 decision in case we find a case where whe shouldn't do this. >> also... you strcpy string to another string, are you sure it always =20 >> fits? how do you >> asure that? >> > > name can't be larger than MFSNAMELEN, and sizeof(fs->name) =3D=3D MFSNAMEL= EN. Please use strlcpy with the sizeof (defensive programming). >> RCS file: /home/ncvs/src/sys/compat/linux/linux_util.h,v >> retrieving revision 1.28 >> diff -u -r1.28 linux_util.h >> --- compat/linux/linux_util.h 27 Jun 2006 18:30:49 -0000 1.28 >> +++ compat/linux/linux_util.h 14 Jan 2007 02:08:42 -0000 >> @@ -101,4 +101,12 @@ >> char *linux_get_char_devices(void); >> void linux_free_get_char_devices(char *string); >> >> +struct linux_file_system_type { >> + char name[16]; >> + int fs_flags; >> +}; >> >> 16? why 16? please comment or something >> > 16 is the value of MFSNAMELEN and used by the vfsconf struct to define > the max size of vfc_name. I kept name (in the linux_file_system_type Is there a similar value in Linux? It would be better to use this if =20 it exists. > struct) the same size, so that we didn't have to worry about the size > when using strcpy. When you find a value like MFSNAMELEN on Linux, please have a look at =20 linux_misc.c:linux_prctl(), specially the LINUX_PR_{SET|GET}_NAME case =20 and the comments in there. What you are doing here should be done =20 similar. > I also wasn't sure if I should add: > > #include > > in linux_util.h so that MFSNAMELEN could be used to define the size of > name in the struct (it may also affect other files, that include > linux_util.h). I agree with Roman here. Do you intend to submit more patches to the linuxulator? If yes, do =20 you want to get write access to our perforce repository (that's not an =20 official CVS or developer account, but a step in this direction)? If =20 yes, what username do you prefer? Bye, Alexander. --=20 I'm still waiting for the advent of the computer science groupie. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 15 11:08:08 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 216B816A4CA for ; Mon, 15 Jan 2007 11:08:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 103F513C468 for ; Mon, 15 Jan 2007 11:08:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0FB87Tx031665 for ; Mon, 15 Jan 2007 11:08:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0FB864H031661 for freebsd-emulation@FreeBSD.org; Mon, 15 Jan 2007 11:08:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jan 2007 11:08:06 GMT Message-Id: <200701151108.l0FB864H031661@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 11:08:08 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/77710 emulation [linux] Linux page fault sigcontext information is wro o kern/101453 emulation [linux] [patch] linprocfs disallows non-zero file offs f ports/102474 emulation linux_base-fc-4_8 appears broken, does not allow to ru o kern/102956 emulation [linux] [patch] Add partial support for SO_PEERCRED in 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] feature request: easier wine/w23 support o kern/55835 emulation [linux] [patch] Linux IPC emulation missing SETALL sys a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula 8 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 15 21:43:01 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 032E116A416 for ; Mon, 15 Jan 2007 21:43:01 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id B931B13C455 for ; Mon, 15 Jan 2007 21:43:00 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so903778ana for ; Mon, 15 Jan 2007 13:42:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kp29p4GkyxwmMyPOHzo1cP535WrZGgkB6tw34A3a2+6YH72yWdo0Fb2slExvqUlfFmR4ZXtuBEmtU1p03+4kNRJ+3Qg5OD/r74n3iuwQ9QN9wHafmwwIc1jHSyoFQBrjk6ZGKKXZoxxQ/H1yNIcenSjipPEDhYim7gkK6If4W+8= Received: by 10.65.38.7 with SMTP id q7mr6396928qbj.1168895674010; Mon, 15 Jan 2007 13:14:34 -0800 (PST) Received: by 10.65.189.7 with HTTP; Mon, 15 Jan 2007 13:14:33 -0800 (PST) Message-ID: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> Date: Mon, 15 Jan 2007 15:14:33 -0600 From: "Scot Hetzel" To: emulation@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 21:43:01 -0000 Trying to compile the programs and libraries required by azureus using emerge, and while it completed the build of binutils (w/vfork fix), it won't finish building libX11, instead I get the following fatal trap 12: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8: 0xffffffffa2cb1ce8 stack pointer = 0x10:0xffffffffa32139d0 frame pointer = 0x10:0xffffffffa3213150 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13488 (bash) [thread pid 13488 tid 100104] Stopped at linux_proc_exit+0xb8: cmpq %r14,(%rax) db> bt Tracing pid 13488 tid 100104 td 0xffffff00269e9290 linux_proc_exit() at linux_proc_exit+0xb8 exit1() at exit1+0x1b9 linux_exit_group() at linux_exit_group+0xe1 ia32_syscall() at ia32_syscall+0x190 Xint0x80_syscall() at Xint0x80_syscall+0x60 db> Has anyone seen this problem on i386, and was it fixed? Let me know if you need more information as I can easily reproduce it. This is using -CURRENT as of 01-14-2007. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 15 22:01:34 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 830D416A412 for ; Mon, 15 Jan 2007 22:01:34 +0000 (UTC) (envelope-from igor.v.kovalenko@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id 07B0513C4CC for ; Mon, 15 Jan 2007 22:01:33 +0000 (UTC) (envelope-from igor.v.kovalenko@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so1060682wra for ; Mon, 15 Jan 2007 14:01:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hinzDHeZW+RI8JEZJAl6vTbfCHPPUfEK45WEmFqkS36muV/JMrnuIMA4tvAWc9oC5OmmWBN44reO7sD1z57sXm/64j87PMslMn29wev9dXqtRXUyf49j5Wpwsr1yfA4pmbsCzxOOoYnEmTLx+Pc51B5FU8UOC0IjNHNZvLCB18U= Received: by 10.78.20.13 with SMTP id 13mr60719hut.1168896874950; Mon, 15 Jan 2007 13:34:34 -0800 (PST) Received: by 10.78.167.13 with HTTP; Mon, 15 Jan 2007 13:34:33 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 00:34:33 +0300 From: "Igor Kovalenko" To: qemu-devel@nongnu.org In-Reply-To: <45A70296.9010705@windriver.com> MIME-Version: 1.0 References: <20070109204740.GA98620@saturn.kn-bremen.de> <20070109230403.GA4552@saturn.kn-bremen.de> <20070112014143.GA50646@saturn.kn-bremen.de> <45A70296.9010705@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: [Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more) [PATCH] X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 22:01:34 -0000 On 1/12/07, Jason Wessel wrote: > > I posted a similar patch last year, but it was not accepted for some > reason. Making this change allows UDP nfs to work to a remote file > server as well. > > I would recommend, making one further change as included in this patch. > It allows KGDBOE to operate on the local host or from a remote host > because it allow the special 10.0.2.2 address to be translated. > > I have included the patch in the e-mail once again. > > signed-off-by: jason.wessel@windriver.com > > Jason. > > > > > Juergen Lock wrote: > > On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote: > > > >> ... > >> Ok, garrison on irc just helped solve this mystery: This (the same) > >> one actually goes out first, before the 10.0.2.3 one (I didn't notice > >> at first), and since slirp reuses the socket because the source ip and > >> port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the > >> dest ip), the second packet with the 10.0.2.3 dest ip (which gets > >> replaced with the hosts's dns) goes out wrong. And the reason this > >> worked previously with the same guest is multicast started working > >> only recently... > >> > > > > And here's the fix I just added to the FreeBSD qemu port: (thanx > garrison!) > > > > Index: qemu/slirp/udp.c > > @@ -205,8 +208,6 @@ > > /* udp_last_so = so; */ > > so->so_laddr = ip->ip_src; > > so->so_lport = uh->uh_sport; > > - so->so_faddr = ip->ip_dst; /* XXX */ > > - so->so_fport = uh->uh_dport; /* XXX */ > > > > if ((so->so_iptos = udp_tos(so)) == 0) > > so->so_iptos = ip->ip_tos; > > @@ -216,6 +217,15 @@ > > * and if it is, do the fork_exec() etc. > > */ > > } > > + > > + /* > > + * Assign destination unconditionally > > + * > > + * This fixes the case where packets are sent from the same > > + * source ip/port to different destination ips/ports > > + */ > > + so->so_faddr = ip->ip_dst; /* XXX */ > > + so->so_fport = uh->uh_dport; /* XXX */ > > > > iphlen += sizeof(struct udphdr); > > m->m_len -= iphlen; > > > > > > _______________________________________________ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > > > Index: qemu/slirp/udp.c > =================================================================== > --- qemu.orig/slirp/udp.c > +++ qemu/slirp/udp.c > @@ -205,8 +205,6 @@ udp_input(m, iphlen) > /* udp_last_so = so; */ > so->so_laddr = ip->ip_src; > so->so_lport = uh->uh_sport; > - so->so_faddr = ip->ip_dst; /* XXX */ > - so->so_fport = uh->uh_dport; /* XXX */ > > if ((so->so_iptos = udp_tos(so)) == 0) > so->so_iptos = ip->ip_tos; > @@ -216,6 +214,13 @@ udp_input(m, iphlen) > * and if it is, do the fork_exec() etc. > */ > } > + /* Always reset the from address as it can change, > + * as with NFS for example where it will talk to > + * the same destination port with multiple source > + * addresses. Or different gdb session to kgdboe. > + */ > + so->so_faddr = ip->ip_dst; /* XXX */ > + so->so_fport = uh->uh_dport; /* XXX */ > > iphlen += sizeof(struct udphdr); > m->m_len -= iphlen; > @@ -312,7 +317,8 @@ int udp_output(struct socket *so, struct > struct sockaddr_in saddr, daddr; > > saddr = *addr; > - if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr) > { > + if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr > && > + addr->sin_addr.s_addr == htonl(0x7f000001)) { > saddr.sin_addr.s_addr = so->so_faddr.s_addr; > if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff)) > saddr.sin_addr.s_addr = alias_addr.s_addr; > > Indeed here it is http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00392.html seems like that comment there is wrong though - the patch helps setting correct destination addr/port, not the source ones. IMHO slirp UDP proxy bugfix is unconditionally worth committing :) but it should be separated from host loopback address translation enhancement. It is not clear if that would work at all in case guest is talking via UDP to different destinations from the same source address. -- Kind regards, Igor V. Kovalenko From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 07:00:45 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC22816A4B3 for ; Tue, 16 Jan 2007 07:00:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6E23713C428 for ; Tue, 16 Jan 2007 07:00:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5EFD9.dip.t-dialin.net [84.165.239.217]) by redbull.bpaserver.net (Postfix) with ESMTP id 64B342E06D; Tue, 16 Jan 2007 08:07:42 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0C7FA5B497E; Tue, 16 Jan 2007 08:00:16 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0G70F7M033202; Tue, 16 Jan 2007 08:00:15 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 16 Jan 2007 08:00:15 +0100 Message-ID: <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 16 Jan 2007 08:00:15 +0100 From: Alexander Leidinger To: Scot Hetzel References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> In-Reply-To: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 07:00:46 -0000 Quoting Scot Hetzel (from Mon, 15 Jan 2007 =20 15:14:33 -0600): > Trying to compile the programs and libraries required by azureus using > emerge, and while it completed the build of binutils (w/vfork fix), it > won't finish building libX11, instead I get the following fatal trap > 12: > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x0 > fault code =3D supervisor read data, page not present > current process =3D 13488 (bash) > [thread pid 13488 tid 100104] > Stopped at linux_proc_exit+0xb8: cmpq %r14,(%rax) > db> bt > Tracing pid 13488 tid 100104 td 0xffffff00269e9290 > linux_proc_exit() at linux_proc_exit+0xb8 > exit1() at exit1+0x1b9 > linux_exit_group() at linux_exit_group+0xe1 > ia32_syscall() at ia32_syscall+0x190 > Xint0x80_syscall() at Xint0x80_syscall+0x60 > db> Please compile with debug symbols ("makeoptions DEBUG=3D-g" in the =20 kernel config), generate a coredump and run kgdb on it. If you load =20 modules, you need to run "make gdbinit" in the kernel compile =20 directory (old style kernel compiling, not the make buildkernel one). =20 This will allow to run "kldsyms" in kgdb which loads the debug symbols =20 for the modules. A trace will show the line numbers then. Bye, Alexander. --=20 The camel has a single hump; The dromedary two; Or else the other way around. I'm never sure. Are you? =09=09-- Ogden Nash http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 18:05:44 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B59E116A407 for ; Tue, 16 Jan 2007 18:05:44 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id E9E8B13C44B for ; Tue, 16 Jan 2007 18:05:38 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1083120ana for ; Tue, 16 Jan 2007 10:05:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gLNytljZBkH2c6yJJQfSnH8r0KtXETwnANFdVr4RPhkGzAkm/WtCah/aUZQPt4fufOnFidtCswyNYSPedshBFOmUTBsU6gUMc6mhrDZ29EHZ0lwlmjp3hr4YGWJkJD/8fwOksBji+LZgzQcRa1GnBZ4X5bsxeVR4Gprq6DROS+s= Received: by 10.65.23.7 with SMTP id a7mr8305495qbj.1168970737565; Tue, 16 Jan 2007 10:05:37 -0800 (PST) Received: by 10.65.189.7 with HTTP; Tue, 16 Jan 2007 10:05:37 -0800 (PST) Message-ID: <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> Date: Tue, 16 Jan 2007 12:05:37 -0600 From: "Scot Hetzel" To: "Alexander Leidinger" In-Reply-To: <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> Cc: emulation@freebsd.org Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 18:05:44 -0000 On 1/16/07, Alexander Leidinger wrote: > Please compile with debug symbols ("makeoptions DEBUG=-g" in the > kernel config), generate a coredump and run kgdb on it. If you load > modules, you need to run "make gdbinit" in the kernel compile > directory (old style kernel compiling, not the make buildkernel one). > This will allow to run "kldsyms" in kgdb which loads the debug symbols > for the modules. A trace will show the line numbers then. > # uname -a FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Jan 16 01:47:09 CST 2007 swhetzel@hp010:/usr/src/7x/sys-orig/amd64/compile/GENERIC.debug amd64 NOTE: GENERIC.debug is the same as the GENERIC config file, except I removed the debugging options from GENERIC, and placed them in GENERIC.debug. GENERIC.debug just includes GENERIC. # cd /usr/src/7x/sys-orig/amd64/compile/GENERIC.debug # kdb -n 0 kernel.debug Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffffa2cb3ce8 stack pointer = 0x10:0xffffffffa314e9d0 frame pointer = 0x10:0xffffffffa314ea50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23285 (bash) panic: from debugger cpuid = 0 Uptime: 22m17s Physical memory: 1008 MB Dumping 122 MB: 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) kldsysms : (kgdb) list *0xffffffffa2cb3ce8 0xffffffffa2cb3ce8 is in linux_proc_exit (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173). 168 child_clear_tid = em->child_clear_tid; 169 170 EMUL_UNLOCK(&emul_lock); 171 172 EMUL_SHARED_WLOCK(&emul_shared_lock); 173 LIST_REMOVE(em, threads); 174 175 PROC_LOCK(p); 176 p->p_emuldata = NULL; 177 PROC_UNLOCK(p); (kgdb) backtrace #0 doadump () at pcpu.h:172 During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff80445bbc. #1 0xffffffff804464b9 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:411 #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from debugger") at ../../../kern/kern_shutdown.c:567 #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0, count=0x0, modif=0x0) at ../../../ddb/db_command.c:433 #4 0xffffffff801acd69 in db_command_loop () at ../../../ddb/db_command.c:401 #5 0xffffffff801aec73 in db_trap (type=0xa314e6d0, code=0x0) at ../../../ddb/db_main.c:222 #6 0xffffffff8046c428 in kdb_trap (type=0xc, code=0x0, tf=0xffffffffa314e920) at ../../../kern/subr_kdb.c:502 #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa314e920, eva=0xffffff00279ee000) at ../../../amd64/amd64/trap.c:691 #8 0xffffffff80655313 in trap_pfault (frame=0xffffffffa314e920, usermode=0x0) at ../../../amd64/amd64/trap.c:614 #9 0xffffffff80655575 in trap (frame=0xffffffffa314e920) at ../../../amd64/amd64/trap.c:382 #10 0xffffffff8063d39e in calltrap () at ../../../amd64/amd64/exception.S:169 #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 #12 0xffffffff8042a689 in exit1 (td=0xffffff00279ee000, rv=0x0) at ../../../kern/kern_exit.c:233 #13 0xffffffffa2cbe5a1 in linux_exit_group (td=0xffffff00279ee000, args=0xffffffffa314ebe0) at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_misc.c:1634 #14 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa314ec80) at ../../../amd64/ia32/ia32_syscall.c:187 #15 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65 #16 0x00000000281923e3 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 11 #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 173 LIST_REMOVE(em, threads); (kgdb) p *em $2 = { pid = 0x5af5, child_set_tid = 0x0, child_clear_tid = 0x0, shared = 0xffffff002ea8b8f0, pdeath_signal = 0x0, threads = { le_next = 0x0, le_prev = 0x0 } } Anything else we need to debug this? Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 18:37:01 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A3FF16A416 for ; Tue, 16 Jan 2007 18:37:01 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id E3E4113C45E for ; Tue, 16 Jan 2007 18:37:00 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0GIIeBP081920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 19:18:40 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0GIIeFP081919; Tue, 16 Jan 2007 19:18:40 +0100 (CET) Date: Tue, 16 Jan 2007 19:18:39 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070116181839.GA80994@stud.fit.vutbr.cz> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 18:37:01 -0000 On Tue, Jan 16, 2007 at 12:05:37PM -0600, Scot Hetzel wrote: > On 1/16/07, Alexander Leidinger wrote: > >Please compile with debug symbols ("makeoptions DEBUG=-g" in the > >kernel config), generate a coredump and run kgdb on it. If you load > >modules, you need to run "make gdbinit" in the kernel compile > >directory (old style kernel compiling, not the make buildkernel one). > >This will allow to run "kldsyms" in kgdb which loads the debug symbols > >for the modules. A trace will show the line numbers then. > > > > # uname -a > FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Jan 16 01:47:09 > CST 2007 swhetzel@hp010:/usr/src/7x/sys-orig/amd64/compile/GENERIC.debug > amd64 > > NOTE: GENERIC.debug is the same as the GENERIC config file, except I > removed the debugging options from GENERIC, and placed them in > GENERIC.debug. GENERIC.debug just includes GENERIC. > > # cd /usr/src/7x/sys-orig/amd64/compile/GENERIC.debug > # kdb -n 0 kernel.debug > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffffa2cb3ce8 > stack pointer = 0x10:0xffffffffa314e9d0 > frame pointer = 0x10:0xffffffffa314ea50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 23285 (bash) > panic: from debugger > cpuid = 0 > Uptime: 22m17s > Physical memory: 1008 MB > Dumping 122 MB: 107 91 75 59 43 27 11 > > #0 doadump () at pcpu.h:172 > 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) kldsysms > : > (kgdb) list *0xffffffffa2cb3ce8 > 0xffffffffa2cb3ce8 is in linux_proc_exit > (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173). > 168 child_clear_tid = em->child_clear_tid; > 169 > 170 EMUL_UNLOCK(&emul_lock); > 171 > 172 EMUL_SHARED_WLOCK(&emul_shared_lock); > 173 LIST_REMOVE(em, threads); > 174 > 175 PROC_LOCK(p); > 176 p->p_emuldata = NULL; > 177 PROC_UNLOCK(p); > (kgdb) backtrace > #0 doadump () at pcpu.h:172 > During symbol reading, Incomplete CFI data; unspecified registers at > 0xffffffff80445bbc. > #1 0xffffffff804464b9 in boot (howto=0x104) at > ../../../kern/kern_shutdown.c:411 > #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from > debugger") at ../../../kern/kern_shutdown.c:567 > #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0, > count=0x0, modif=0x0) at ../../../ddb/db_command.c:433 > #4 0xffffffff801acd69 in db_command_loop () at > ../../../ddb/db_command.c:401 > #5 0xffffffff801aec73 in db_trap (type=0xa314e6d0, code=0x0) at > ../../../ddb/db_main.c:222 > #6 0xffffffff8046c428 in kdb_trap (type=0xc, code=0x0, > tf=0xffffffffa314e920) at ../../../kern/subr_kdb.c:502 > #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa314e920, > eva=0xffffff00279ee000) > at ../../../amd64/amd64/trap.c:691 > #8 0xffffffff80655313 in trap_pfault (frame=0xffffffffa314e920, > usermode=0x0) at ../../../amd64/amd64/trap.c:614 > #9 0xffffffff80655575 in trap (frame=0xffffffffa314e920) at > ../../../amd64/amd64/trap.c:382 > #10 0xffffffff8063d39e in calltrap () at > ../../../amd64/amd64/exception.S:169 > #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 > #12 0xffffffff8042a689 in exit1 (td=0xffffff00279ee000, rv=0x0) at > ../../../kern/kern_exit.c:233 > #13 0xffffffffa2cbe5a1 in linux_exit_group (td=0xffffff00279ee000, > args=0xffffffffa314ebe0) > at > /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_misc.c:1634 > #14 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa314ec80) at > ../../../amd64/ia32/ia32_syscall.c:187 > #15 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65 > #16 0x00000000281923e3 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) frame 11 > #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 > 173 LIST_REMOVE(em, threads); > (kgdb) p *em > $2 = { > pid = 0x5af5, > child_set_tid = 0x0, > child_clear_tid = 0x0, > shared = 0xffffff002ea8b8f0, > pdeath_signal = 0x0, > threads = { > le_next = 0x0, > le_prev = 0x0 > } > } I dont understand why it paniced. the threads LIST is empty and LIST_REMOVE(something, empty_list) is perfectly legal. can someone shed some light to this? scot, can you please describe whats going on? I mean.. fbsd shell forks-and-execs linux XYZ, XYZ execs ABC, something like that. when you run with WITNESS/INVARIATNS does it spit any useful info? thnx roman From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 21:17:51 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59D6616A53A for ; Tue, 16 Jan 2007 21:17:51 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 06CC413C469 for ; Tue, 16 Jan 2007 21:17:50 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1135222ana for ; Tue, 16 Jan 2007 13:17:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=d6ORI9zeF61aKb0NRRaqEIJ3fnUH2flaF2MP7cZUV2BJmKxztxz+dIZsN+gqJcbldG1Mv7yF/hGI2ReB+rWB2CaifiAmnWzdUEWlVKGeditBd+Rs4XwiJN/pR8e80bhfPXD8aNUdvT6/2x25yy5wgDbKsK+Rz8jQkDkpZ8udIvo= Received: by 10.64.193.8 with SMTP id q8mr8610032qbf.1168982252694; Tue, 16 Jan 2007 13:17:32 -0800 (PST) Received: by 10.65.189.7 with HTTP; Tue, 16 Jan 2007 13:17:32 -0800 (PST) Message-ID: <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> Date: Tue, 16 Jan 2007 15:17:32 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070116181839.GA80994@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_55911_25200285.1168982252626" References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:17:51 -0000 ------=_Part_55911_25200285.1168982252626 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/16/07, Divacky Roman wrote: > On Tue, Jan 16, 2007 at 12:05:37PM -0600, Scot Hetzel wrote: > > On 1/16/07, Alexander Leidinger wrote: > > >Please compile with debug symbols ("makeoptions DEBUG=-g" in the > > >kernel config), generate a coredump and run kgdb on it. If you load > > >modules, you need to run "make gdbinit" in the kernel compile > > >directory (old style kernel compiling, not the make buildkernel one). > > >This will allow to run "kldsyms" in kgdb which loads the debug symbols > > >for the modules. A trace will show the line numbers then. > > > > > > > # uname -a > > FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Jan 16 01:47:09 > > CST 2007 swhetzel@hp010:/usr/src/7x/sys-orig/amd64/compile/GENERIC.debug > > amd64 > > > > NOTE: GENERIC.debug is the same as the GENERIC config file, except I > > removed the debugging options from GENERIC, and placed them in > > GENERIC.debug. GENERIC.debug just includes GENERIC. > > > > # cd /usr/src/7x/sys-orig/amd64/compile/GENERIC.debug > > # kdb -n 0 kernel.debug > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor read data, page not present > > instruction pointer = 0x8:0xffffffffa2cb3ce8 > > stack pointer = 0x10:0xffffffffa314e9d0 > > frame pointer = 0x10:0xffffffffa314ea50 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 23285 (bash) > > panic: from debugger > > cpuid = 0 > > Uptime: 22m17s > > Physical memory: 1008 MB > > Dumping 122 MB: 107 91 75 59 43 27 11 > > > > #0 doadump () at pcpu.h:172 > > 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > > (kgdb) kldsysms > > : > > (kgdb) list *0xffffffffa2cb3ce8 > > 0xffffffffa2cb3ce8 is in linux_proc_exit > > (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173). > > 168 child_clear_tid = em->child_clear_tid; > > 169 > > 170 EMUL_UNLOCK(&emul_lock); > > 171 > > 172 EMUL_SHARED_WLOCK(&emul_shared_lock); > > 173 LIST_REMOVE(em, threads); > > 174 > > 175 PROC_LOCK(p); > > 176 p->p_emuldata = NULL; > > 177 PROC_UNLOCK(p); > > (kgdb) backtrace > > #0 doadump () at pcpu.h:172 > > During symbol reading, Incomplete CFI data; unspecified registers at > > 0xffffffff80445bbc. > > #1 0xffffffff804464b9 in boot (howto=0x104) at > > ../../../kern/kern_shutdown.c:411 > > #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from > > debugger") at ../../../kern/kern_shutdown.c:567 > > #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0, > > count=0x0, modif=0x0) at ../../../ddb/db_command.c:433 > > #4 0xffffffff801acd69 in db_command_loop () at > > ../../../ddb/db_command.c:401 > > #5 0xffffffff801aec73 in db_trap (type=0xa314e6d0, code=0x0) at > > ../../../ddb/db_main.c:222 > > #6 0xffffffff8046c428 in kdb_trap (type=0xc, code=0x0, > > tf=0xffffffffa314e920) at ../../../kern/subr_kdb.c:502 > > #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa314e920, > > eva=0xffffff00279ee000) > > at ../../../amd64/amd64/trap.c:691 > > #8 0xffffffff80655313 in trap_pfault (frame=0xffffffffa314e920, > > usermode=0x0) at ../../../amd64/amd64/trap.c:614 > > #9 0xffffffff80655575 in trap (frame=0xffffffffa314e920) at > > ../../../amd64/amd64/trap.c:382 > > #10 0xffffffff8063d39e in calltrap () at > > ../../../amd64/amd64/exception.S:169 > > #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) > > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 > > #12 0xffffffff8042a689 in exit1 (td=0xffffff00279ee000, rv=0x0) at > > ../../../kern/kern_exit.c:233 > > #13 0xffffffffa2cbe5a1 in linux_exit_group (td=0xffffff00279ee000, > > args=0xffffffffa314ebe0) > > at > > /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_misc.c:1634 > > #14 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa314ec80) at > > ../../../amd64/ia32/ia32_syscall.c:187 > > #15 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65 > > #16 0x00000000281923e3 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) frame 11 > > #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80) > > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173 > > 173 LIST_REMOVE(em, threads); > > (kgdb) p *em > > $2 = { > > pid = 0x5af5, > > child_set_tid = 0x0, > > child_clear_tid = 0x0, > > shared = 0xffffff002ea8b8f0, > > pdeath_signal = 0x0, > > threads = { > > le_next = 0x0, > > le_prev = 0x0 > > } > > } > > I dont understand why it paniced. the threads LIST is empty > and LIST_REMOVE(something, empty_list) is perfectly legal. > > can someone shed some light to this? > > scot, can you please describe whats going on? I mean.. fbsd shell > forks-and-execs linux XYZ, XYZ execs ABC, something like that. > when you run with WITNESS/INVARIATNS does it spit any useful info? > The kernel does have WITNESS/INVARIANTS compiled in, but I'm not seeing anything useful from it. What I'm doing is: chroot /root/ports/gentoo-stage3 bash emerge libX11 It finally built, then I tried emerge azureus Then I got that same panic again, but on a different dependancy (libXi-1.0.1) Rebooted the system again, and libXi-1.0.1 built (emerge libXi). Then tried to build 2 dependacies, and it built recordproto, but paniced again on libXtst. The last message from the build on the screen at the time of the panic is: if /bin/sh ../libtool --mode=compile i386-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -mtune=i686 -pipe -MT XTest.lo -MD -MP -MF ".deps/XTest.Tpo" \ -c -o XTest.lo `test -f 'XTest.c' || echo './'`XTest.c; ; \ then mv -f ".deps/XTest.Tpo" ".deps/XTest.Plo"; \ else rm -f ".deps/XTest.Tpo"; exit 1; \ fi Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffffa2cb3ce8 stack pointer = 0x10:0xffffffffa30cc9d0 frame pointer = 0x10:0xffffffffa30cca50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15514 (bash) (kgdb) list *0xffffffffa2cb3ce8 0xffffffffa2cb3ce8 is in linux_proc_exit (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173). 168 child_clear_tid = em->child_clear_tid; 169 170 EMUL_UNLOCK(&emul_lock); 171 172 EMUL_SHARED_WLOCK(&emul_shared_lock); 173 LIST_REMOVE(em, threads); 174 175 PROC_LOCK(p); 176 p->p_emuldata = NULL; 177 PROC_UNLOCK(p); (kgdb) p *em $1 = { pid = 0x3c9a, child_set_tid = 0x0, child_clear_tid = 0x0, shared = 0xffffff002f52c9a0, pdeath_signal = 0x0, threads = { le_next = 0x0, le_prev = 0x0 } } (kgdb) p threads No symbol "threads" in current context. (kgdb) p *threads No symbol "threads" in current context. (kgdb) p &threads No symbol "threads" in current context. (kgdb) Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_55911_25200285.1168982252626 Content-Type: text/plain; name="GENERIC.debug" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="GENERIC.debug" X-Attachment-Id: f_ex0trvai IwojIEdFTkVSSUMgZGVidWdnaW5nIGtlcm5lbAojCiMgVG8gdXNlIHRoaXMga2VybmVsLCB5b3Ug bmVlZCB0byBhZGQgdGhlIGZvbGxvd2luZyB0bwojIHlvdXIgL2Jvb3QvbG9hZGVyLmNvbmYKIwoj IGtlcm5lbD1rZXJuZWxfZGVidWcKIwojICRGcmVlQlNEJAoKaW5jbHVkZSBHRU5FUklDCgppZGVu dAkJR0VORVJJQy1kZWJ1ZwoKbWFrZW9wdGlvbnMJREVCVUc9LWcJCSMgQnVpbGQga2VybmVsIHdp dGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMKbWFrZW9wdGlvbnMJS09ESVI9L2Jvb3QvJHtLRVJORUx9 X2RlYnVnCgojIERlYnVnZ2luZyBmb3IgdXNlIGluIC1jdXJyZW50Cm9wdGlvbnMgCUtEQgkJCSMg RW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0LgpvcHRpb25zIAlEREIJCQkjIFN1cHBvcnQg RERCLgpvcHRpb25zIAlHREIJCQkjIFN1cHBvcnQgcmVtb3RlIEdEQi4Kb3B0aW9ucyAJSU5WQVJJ QU5UUwkJIyBFbmFibGUgY2FsbHMgb2YgZXh0cmEgc2FuaXR5IGNoZWNraW5nCm9wdGlvbnMgCUlO VkFSSUFOVF9TVVBQT1JUCSMgRXh0cmEgc2FuaXR5IGNoZWNrcyBvZiBpbnRlcm5hbCBzdHJ1Y3R1 cmVzLCByZXF1aXJlZCBieSBJTlZBUklBTlRTCm9wdGlvbnMgCVdJVE5FU1MJCQkjIEVuYWJsZSBj aGVja3MgdG8gZGV0ZWN0IGRlYWRsb2NrcyBhbmQgY3ljbGVzCm9wdGlvbnMgCVdJVE5FU1NfU0tJ UFNQSU4JIyBEb24ndCBydW4gd2l0bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkCg== ------=_Part_55911_25200285.1168982252626-- From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 22:11:54 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C51C816A416 for ; Tue, 16 Jan 2007 22:11:54 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 57FE713C428 for ; Tue, 16 Jan 2007 22:11:54 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0GMBr3o010220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 23:11:53 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0GMBoZu010214; Tue, 16 Jan 2007 23:11:50 +0100 (CET) Date: Tue, 16 Jan 2007 23:11:50 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070116221150.GA9429@stud.fit.vutbr.cz> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 22:11:54 -0000 please test this patch: Index: linux_emul.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v retrieving revision 1.12 diff -u -r1.12 linux_emul.c --- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 +++ linux_emul.c 16 Jan 2007 22:11:06 -0000 @@ -170,7 +170,8 @@ EMUL_UNLOCK(&emul_lock); EMUL_SHARED_WLOCK(&emul_shared_lock); - LIST_REMOVE(em, threads); + if (!LIST_EMPTY(em->shared->threads) + LIST_REMOVE(em, threads); PROC_LOCK(p); p->p_emuldata = NULL; thnx roman From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 17 04:00:22 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CAA916A412 for ; Wed, 17 Jan 2007 04:00:22 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFA013C45B for ; Wed, 17 Jan 2007 04:00:22 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so343956nzh for ; Tue, 16 Jan 2007 20:00:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b8x35iq0FquKxsw6r6CyK5o0lvbqoezqmFEBkDh7G7f80jalWq8ArFaZbZugfh1qxGKFDJS2R2wmTXWkZq3CTtBgf8gdQUaqKbibyZAXMS9WgCTwJyHeYL+kfjZqPnSL0kJeXxCuGI5kkbsUpi78gbVBszNjW/k7a8fvuuDcXCg= Received: by 10.65.23.3 with SMTP id a3mr2536234qbj.1169006421344; Tue, 16 Jan 2007 20:00:21 -0800 (PST) Received: by 10.65.189.7 with HTTP; Tue, 16 Jan 2007 20:00:21 -0800 (PST) Message-ID: <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> Date: Tue, 16 Jan 2007 22:00:21 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070116221150.GA9429@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 04:00:22 -0000 On 1/16/07, Divacky Roman wrote: > please test this patch: > > Index: linux_emul.c > =================================================================== > RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v > retrieving revision 1.12 > diff -u -r1.12 linux_emul.c > --- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 > +++ linux_emul.c 16 Jan 2007 22:11:06 -0000 > @@ -170,7 +170,8 @@ > EMUL_UNLOCK(&emul_lock); > > EMUL_SHARED_WLOCK(&emul_shared_lock); > - LIST_REMOVE(em, threads); > + if (!LIST_EMPTY(em->shared->threads) Wouldn't compile as shown above (complained about '->' when compiling), changed it to: if (!LIST_EMPTY(&em->shared->threads)) but now I'm getting: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffffa2cb3b2c stack pointer = 0x10:0xffffffffa3135ad0 frame pointer = 0x10:0xffffffffa3135b10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 20225 (bash) panic: from debugger cpuid = 0 Uptime: 9m59s Physical memory: 1008 MB (kgdb) list *0xffffffffa2cb3b2c 0xffffffffa2cb3b2c is in linux_proc_init (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138). 133 } 134 } 135 if (child != 0) { 136 EMUL_UNLOCK(&emul_lock); 137 EMUL_SHARED_WLOCK(&emul_shared_lock); 138 LIST_INSERT_HEAD(&em->shared->threads, em, threads); 139 EMUL_SHARED_WUNLOCK(&emul_shared_lock); 140 141 p = pfind(child); 142 /* we might have a sleeping linux_schedtail */ (kgdb) bt #0 doadump () at pcpu.h:172 During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff80445bbc. #1 0xffffffff804464b9 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:411 #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from debugger") at ../../../kern/kern_shutdown.c:567 #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0, count=0x0, modif=0x0) at ../../../ddb/db_command.c:433 #4 0xffffffff801acd69 in db_command_loop () at ../../../ddb/db_command.c:401 #5 0xffffffff801aec73 in db_trap (type=0xa3135830, code=0x0) at ../../../ddb/db_main.c:222 #6 0xffffffff8046c428 in kdb_trap (type=0x9, code=0x0, tf=0xffffffffa3135a20) at ../../../kern/subr_kdb.c:502 #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa3135a20, eva=0xffffff002d1d9290) at ../../../amd64/amd64/trap.c:691 #8 0xffffffff8065551a in trap (frame=0xffffffffa3135a20) at ../../../amd64/amd64/trap.c:499 #9 0xffffffff8063d39e in calltrap () at ../../../amd64/amd64/exception.S:169 #10 0xffffffffa2cb3b2c in linux_proc_init (td=0xffffff002d1d9290, child=0x4f5c, flags=0x0) at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138 #11 0xffffffffa2cbb810 in linux_fork (td=0xffffff002d1d9290, args=0x0) at /usr/src/7x/sys-orig/modules/linux/../../amd64/linux32/linux32_machdep.c:467 #12 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa3135c80) at ../../../amd64/ia32/ia32_syscall.c:187 #13 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65 #14 0x0000000028192358 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xffffffffa2cb3b2c in linux_proc_init (td=0xffffff002d1d9290, child=0x4f5c, flags=0x0) at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138 138 LIST_INSERT_HEAD(&em->shared->threads, em, threads); (kgdb) p &em->shared->threads $1 = (struct {...} *) 0xdeadc0dedeadc0e6 (kgdb) p *em $3 = { pid = 0xdeadc0de, child_set_tid = 0x0, child_clear_tid = 0x0, shared = 0xdeadc0dedeadc0de, pdeath_signal = 0xdeadc0de, threads = { le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de } } Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 17 07:03:17 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 817B916A40F for ; Wed, 17 Jan 2007 07:03:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE6513C45B for ; Wed, 17 Jan 2007 07:03:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D3F5.dip.t-dialin.net [84.165.211.245]) by redbull.bpaserver.net (Postfix) with ESMTP id 87DB22E113; Wed, 17 Jan 2007 08:10:52 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 03A5B5B4CA0; Wed, 17 Jan 2007 08:03:10 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0H73ASV091699; Wed, 17 Jan 2007 08:03:10 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 17 Jan 2007 08:03:10 +0100 Message-ID: <20070117080310.jhbtrvl1c0c04k8k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 17 Jan 2007 08:03:10 +0100 From: Alexander Leidinger To: Scot Hetzel References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> In-Reply-To: <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.364, required 6, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, IMPRONONCABLE_2 1.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 07:03:17 -0000 Quoting Scot Hetzel (from Tue, 16 Jan 2007 =20 22:00:21 -0600): > On 1/16/07, Divacky Roman wrote: >> please test this patch: >> >> Index: linux_emul.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v >> retrieving revision 1.12 >> diff -u -r1.12 linux_emul.c >> --- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 >> +++ linux_emul.c 16 Jan 2007 22:11:06 -0000 >> @@ -170,7 +170,8 @@ >> EMUL_UNLOCK(&emul_lock); >> >> EMUL_SHARED_WLOCK(&emul_shared_lock); >> - LIST_REMOVE(em, threads); >> + if (!LIST_EMPTY(em->shared->threads) I didn't had a look at the code, but my first impression about this =20 was, that it is trying to hide the problem. Currently I think it is =20 either memory corruption, a race (inappropriate locking), or keeping a =20 pointer when it should be cleaned/removed, or some memory is not =20 initialized before inserting/using it somewhere. > Wouldn't compile as shown above (complained about '->' when > compiling), changed it to: > > if (!LIST_EMPTY(&em->shared->threads)) > > but now I'm getting: > #10 0xffffffffa2cb3b2c in linux_proc_init (td=3D0xffffff002d1d9290, > child=3D0x4f5c, flags=3D0x0) > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:1= 38 > 138 LIST_INSERT_HEAD(&em->shared->threads, em, threads= ); > (kgdb) p &em->shared->threads > $1 =3D (struct {...} *) 0xdeadc0dedeadc0e6 > (kgdb) p *em > $3 =3D { > pid =3D 0xdeadc0de, > child_set_tid =3D 0x0, > child_clear_tid =3D 0x0, > shared =3D 0xdeadc0dedeadc0de, > pdeath_signal =3D 0xdeadc0de, > threads =3D { > le_next =3D 0xdeadc0dedeadc0de, > le_prev =3D 0xdeadc0dedeadc0de > } > } deadc0de means that the memory was freed before use. Bye, Alexander. --=20 Lord, what fools these mortals be! =09=09-- William Shakespeare, "A Midsummer-Night's Dream" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 17 09:15:33 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F298A16A412 for ; Wed, 17 Jan 2007 09:15:33 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 979FC13C455 for ; Wed, 17 Jan 2007 09:15:31 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0H9FUbh049166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:15:30 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0H9FUeO049165; Wed, 17 Jan 2007 10:15:30 +0100 (CET) Date: Wed, 17 Jan 2007 10:15:30 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070117091530.GA48578@stud.fit.vutbr.cz> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 09:15:34 -0000 On Tue, Jan 16, 2007 at 10:00:21PM -0600, Scot Hetzel wrote: > On 1/16/07, Divacky Roman wrote: > >please test this patch: > > > >Index: linux_emul.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v > >retrieving revision 1.12 > >diff -u -r1.12 linux_emul.c > >--- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 > >+++ linux_emul.c 16 Jan 2007 22:11:06 -0000 > >@@ -170,7 +170,8 @@ > > EMUL_UNLOCK(&emul_lock); > > > > EMUL_SHARED_WLOCK(&emul_shared_lock); > >- LIST_REMOVE(em, threads); > >+ if (!LIST_EMPTY(em->shared->threads) > > Wouldn't compile as shown above (complained about '->' when > compiling), changed it to: > > if (!LIST_EMPTY(&em->shared->threads)) > > but now I'm getting: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0xffffffffa2cb3b2c > stack pointer = 0x10:0xffffffffa3135ad0 > frame pointer = 0x10:0xffffffffa3135b10 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 20225 (bash) > panic: from debugger > cpuid = 0 > Uptime: 9m59s > Physical memory: 1008 MB > > (kgdb) list *0xffffffffa2cb3b2c > 0xffffffffa2cb3b2c is in linux_proc_init > (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138). > 133 } > 134 } > 135 if (child != 0) { > 136 EMUL_UNLOCK(&emul_lock); > 137 EMUL_SHARED_WLOCK(&emul_shared_lock); > 138 LIST_INSERT_HEAD(&em->shared->threads, em, threads); > 139 EMUL_SHARED_WUNLOCK(&emul_shared_lock); > 140 > 141 p = pfind(child); > 142 /* we might have a sleeping linux_schedtail */ > (kgdb) bt > #0 doadump () at pcpu.h:172 > During symbol reading, Incomplete CFI data; unspecified registers at > 0xffffffff80445bbc. > #1 0xffffffff804464b9 in boot (howto=0x104) at > ../../../kern/kern_shutdown.c:411 > #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from > debugger") at ../../../kern/kern_shutdown.c:567 > #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0, > count=0x0, modif=0x0) at ../../../ddb/db_command.c:433 > #4 0xffffffff801acd69 in db_command_loop () at > ../../../ddb/db_command.c:401 > #5 0xffffffff801aec73 in db_trap (type=0xa3135830, code=0x0) at > ../../../ddb/db_main.c:222 > #6 0xffffffff8046c428 in kdb_trap (type=0x9, code=0x0, > tf=0xffffffffa3135a20) at ../../../kern/subr_kdb.c:502 > #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa3135a20, > eva=0xffffff002d1d9290) > at ../../../amd64/amd64/trap.c:691 > #8 0xffffffff8065551a in trap (frame=0xffffffffa3135a20) at > ../../../amd64/amd64/trap.c:499 > #9 0xffffffff8063d39e in calltrap () at > ../../../amd64/amd64/exception.S:169 > #10 0xffffffffa2cb3b2c in linux_proc_init (td=0xffffff002d1d9290, > child=0x4f5c, flags=0x0) > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138 > #11 0xffffffffa2cbb810 in linux_fork (td=0xffffff002d1d9290, args=0x0) > at > /usr/src/7x/sys-orig/modules/linux/../../amd64/linux32/linux32_machdep.c:467 > #12 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa3135c80) at > ../../../amd64/ia32/ia32_syscall.c:187 > #13 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65 > #14 0x0000000028192358 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) frame 10 > #10 0xffffffffa2cb3b2c in linux_proc_init (td=0xffffff002d1d9290, > child=0x4f5c, flags=0x0) > at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:138 > 138 LIST_INSERT_HEAD(&em->shared->threads, em, threads); > (kgdb) p &em->shared->threads > $1 = (struct {...} *) 0xdeadc0dedeadc0e6 > (kgdb) p *em > $3 = { > pid = 0xdeadc0de, > child_set_tid = 0x0, > child_clear_tid = 0x0, > shared = 0xdeadc0dedeadc0de, > pdeath_signal = 0xdeadc0de, > threads = { > le_next = 0xdeadc0dedeadc0de, > le_prev = 0xdeadc0dedeadc0de > } > } scot, please test this patch and report me what it prints out just before the panic, btw.. your machine is SMP? thnx Index: linux_emul.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v retrieving revision 1.12 diff -u -r1.12 linux_emul.c --- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 +++ linux_emul.c 17 Jan 2007 09:13:08 -0000 @@ -133,8 +133,11 @@ } } if (child != 0) { + printf("before: %p\n", em->shared); EMUL_UNLOCK(&emul_lock); + printf("after1: %p\n", em->shared); EMUL_SHARED_WLOCK(&emul_shared_lock); + printf("after2: %p\n", em->shared); LIST_INSERT_HEAD(&em->shared->threads, em, threads); EMUL_SHARED_WUNLOCK(&emul_shared_lock); @@ -170,7 +173,8 @@ EMUL_UNLOCK(&emul_lock); EMUL_SHARED_WLOCK(&emul_shared_lock); - LIST_REMOVE(em, threads); + if (!LIST_EMPTY(&em->shared->threads)) + LIST_REMOVE(em, threads); PROC_LOCK(p); p->p_emuldata = NULL; From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 17 17:55:44 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F21716A40F for ; Wed, 17 Jan 2007 17:55:44 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6FFC813C459 for ; Wed, 17 Jan 2007 17:55:42 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so251904nfc for ; Wed, 17 Jan 2007 09:55:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gB++b3BqbgakUOCccWQi/BDpiF51rXdi9blogFYuKyz6ZAEGeJbaqHaK1JaGJHKhyoa7WUGleBLLUU/UVUlodFyNpnZKG/JLPg66kGCdfx/UGC6Ofj16BfCDTc522n+7blWLniyoQ6OG++VOUlv6dw+T8pQFTUuFkxdfYO7XE5Y= Received: by 10.82.116.15 with SMTP id o15mr1598607buc.1169056541242; Wed, 17 Jan 2007 09:55:41 -0800 (PST) Received: by 10.82.186.2 with HTTP; Wed, 17 Jan 2007 09:55:40 -0800 (PST) Message-ID: <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> Date: Wed, 17 Jan 2007 11:55:40 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070117091530.GA48578@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 17:55:44 -0000 On 1/17/07, Divacky Roman wrote: > scot, please test this patch and report me what it prints out > just before the panic, btw.. your machine is SMP? > The system has only one processor. $ dmesg | grep -i cpu CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1994.21-MHz K8-class CPU) cpu0: on acpi0 powernow0: on cpu0 # kgdb -n 3 kernel.debug : Unread portion of the kernel message buffer: before: 0xffffff002ea7b9f0 after1: 0xffffff002ea7b9f0 after2: 0xffffff002ea7b9f0 before: 0xffffff002ea7b8c0 after1: 0xffffff002ea7b8c0 after2: 0xffffff002ea7b8c0 before: 0xffffff002ea7b8e0 after1: 0xffffff002ea7b8e0 after2: 0xffffff002ea7b8e0 before: 0xffffff002ea7b950 after1: 0xffffff002ea7b950 after2: 0xffffff002ea7b950 before: 0xffffff002ea7b9b0 after1: 0xffffff002ea7b9b0 after2: 0xffffff002ea7b9b0 before: 0xffffff002ea7b540 after1: 0xffffff002ea7b540 after2: 0xffffff002ea7b540 before: 0xffffff002ea7b560 after1: 0xffffff002ea7b560 after2: 0xffffff002ea7b560 before: 0xffffff002ea7b500 after1: 0xffffff002ea7b500 after2: 0xdeadc0dedeadc0de Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffffa2cb3b65 stack pointer = 0x10:0xffffffffa3210ad0 frame pointer = 0x10:0xffffffffa3210b10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1281 (bash) panic: from debugger cpuid = 0 Uptime: 4m6s Physical memory: 1008 MB Dumping 115 MB: 100 84 68 52 36 20 4 (kgdb) list *0xffffffffa2cb3b65 0xffffffffa2cb3b65 is in linux_proc_init (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:141). 136 printf("before: %p\n", em->shared); 137 EMUL_UNLOCK(&emul_lock); 138 printf("after1: %p\n", em->shared); 139 EMUL_SHARED_WLOCK(&emul_shared_lock); 140 printf("after2: %p\n", em->shared); 141 LIST_INSERT_HEAD(&em->shared->threads, em, threads); 142 EMUL_SHARED_WUNLOCK(&emul_shared_lock); 143 144 p = pfind(child); 145 /* we might have a sleeping linux_schedtail */ On 1/17/07, Divacky Roman wrote: > also please show me the "flags" arugment to linux_proc_init > (kgdb) p flags $1 = 0x0 (kgdb) p child $2 = 0x514 (kgdb) p *td $3 = { td_proc = 0xffffff0023bf9380, td_plist = { tqe_next = 0x0, tqe_prev = 0xffffff0023bf9390 }, td_slpq = { tqe_next = 0x0, tqe_prev = 0xffffff0029064180 }, td_lockq = { tqe_next = 0x0, tqe_prev = 0xffffffffa320b580 }, td_selq = { tqh_first = 0x0, tqh_last = 0x0 }, td_sleepqueue = 0xffffff0029064180, td_turnstile = 0xffffff0029064300, td_umtxq = 0xffffff0029064400, td_tid = 0x18709, td_sigqueue = { sq_signals = { __bits = {0x0, 0x0, 0x0, 0x0} }, sq_kill = { __bits = {0x0, 0x0, 0x0, 0x0} }, sq_list = { tqh_first = 0x0, tqh_last = 0xffffff0025766088 }, sq_proc = 0xffffff0023bf9380, sq_flags = 0x1 }, td_flags = 0x5000002, td_inhibitors = 0x0, td_pflags = 0x0, td_dupfd = 0x0, td_sqqueue = 0x0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 0x0, td_oncpu = 0x0, td_owepreempt = 0x0, td_locks = 0x1, td_tsqueue = 0x0, td_blocked = 0x0, td_lockname = 0x0, td_contested = { lh_first = 0x0 }, td_sleeplocks = 0xffffffff809ed7e8, td_intr_nesting_level = 0x0, td_pinned = 0x1, td_mailbox = 0x0, td_ucred = 0xffffff0028276300, td_standin = 0x0, td_upcall = 0x0, td_estcpu = 0x127, td_slptime = 0x0, td_pticks = 0x0, td_sticks = 0x0, td_iticks = 0x0, td_uticks = 0x0, td_uuticks = 0x0, td_usticks = 0x0, td_intrval = 0x0, ---Type to continue, or q to quit--- td_oldsigmask = { __bits = {0x0, 0x0, 0x0, 0x0} }, td_sigmask = { __bits = {0x80080002, 0x0, 0x0, 0x0} }, td_generation = 0x3d, td_sigstk = { ss_sp = 0x0, ss_size = 0x0, ss_flags = 0x4 }, td_kflags = 0x0, td_xsig = 0x0, td_profil_addr = 0x0, td_profil_ticks = 0x0, td_name = '\0' , td_base_pri = 0xbe, td_priority = 0xbe, td_pri_class = 0x3, td_user_pri = 0xbe, td_base_user_pri = 0xbe, td_pcb = 0xffffffffa3210d50, td_state = TDS_RUNNING, td_retval = {0x514, 0x0}, td_slpcallout = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0x0, c_arg = 0x0, c_func = 0, c_mtx = 0x0, c_flags = 0x10 }, td_frame = 0xffffffffa3210c80, td_kstack_obj = 0xffffff0025775bb8, td_kstack = 0xffffffffa320d000, td_kstack_pages = 0x4, td_altkstack_obj = 0x0, td_altkstack = 0x0, td_altkstack_pages = 0x0, td_critnest = 0x0, td_md = { md_spinlock_count = 0x0, md_saved_flags = 0x46 }, td_sched = 0xffffff0025766260, td_ar = 0x0 } Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 17 22:30:27 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E539716A407 for ; Wed, 17 Jan 2007 22:30:27 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 751B713C44B for ; Wed, 17 Jan 2007 22:30:27 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0HMUP6S023059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 23:30:25 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0HMUPhi023058; Wed, 17 Jan 2007 23:30:25 +0100 (CET) Date: Wed, 17 Jan 2007 23:30:25 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070117223025.GA21199@stud.fit.vutbr.cz> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 22:30:28 -0000 > td_flags = 0x5000002, this flags show... #define TDF_SCHED0 0x01000000 /* Reserved for scheduler private use */ #define TDF_SCHED2 0x04000000 /* Reserved for scheduler private use */ I am no expert but I quickly looked at the sources and this doesnt seem to be possible to be set (if its possible please someone tell em). what scheduler are you using? if you use the other one can you reproduce the panic? can you try this patch (added to the pathces you already have): the locking there sucks, I'll have to revisit it together with the LIST magic ;( Index: linux_emul.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_emul.c,v retrieving revision 1.12 diff -u -r1.12 linux_emul.c --- linux_emul.c 7 Jan 2007 19:09:20 -0000 1.12 +++ linux_emul.c 17 Jan 2007 22:28:51 -0000 @@ -91,11 +91,11 @@ struct linux_emuldata_shared *s; s = malloc(sizeof *s, M_LINUX, M_WAITOK | M_ZERO); - em->shared = s; s->refs = 1; s->group_pid = child; LIST_INIT(&s->threads); + em->shared = s; } p = pfind(child); KASSERT(p != NULL, ("process not found in proc_init\n")); roman From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 18 07:17:50 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DFCB16A415 for ; Thu, 18 Jan 2007 07:17:50 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id E4DC413C448 for ; Thu, 18 Jan 2007 07:17:49 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so106120nfc for ; Wed, 17 Jan 2007 23:17:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UC7qwdhCfv1VYO9/HygauVInKD9D4ni+4IqTyd82+FZ9Afvoqn2JHt32spXHqccQmQBaQiSOGlV4XOJctEh5dOgOmJ7QFoNB58yLQYrWwEOABapeCxQCCznPdlZp9N7AN01MaANsNlz26ohQ13XEPoFkWAdiSk+y1wROv1kac5I= Received: by 10.82.184.2 with SMTP id h2mr109313buf.1169104668474; Wed, 17 Jan 2007 23:17:48 -0800 (PST) Received: by 10.82.186.2 with HTTP; Wed, 17 Jan 2007 23:17:48 -0800 (PST) Message-ID: <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> Date: Thu, 18 Jan 2007 01:17:48 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070117223025.GA21199@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 07:17:50 -0000 On 1/17/07, Divacky Roman wrote: > what scheduler are you using? if you use the other one can you reproduce > the panic? > > SCHED_4BSD > can you try this patch (added to the pathces you already have): > > the locking there sucks, I'll have to revisit it together with > the LIST magic ;( > Tried the patch, but it didn't solve the problem. I had noticed today that the kernel would panic on a LTP run (2.4.2). On one of the LTP runs, I noticed it had paniced after the fork06 test. Had a look on P4, and saw change 113083, applied it to linux_emul.c. So far it has passed 2 LTP tests (2.4.2, 2.6.16) with out panicing the kernel. Currently, I'm runing 'emerge azureus', and is currently at 18 of 188 ports. It usually paniced on the first or second port. So it looks like the problem may be solved by P4 Change 113083. Thanks for taking the time to look into this problem. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 18 08:48:39 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2A16A40F for ; Thu, 18 Jan 2007 08:48:39 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id AD3ED13C43E for ; Thu, 18 Jan 2007 08:48:38 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0I8mbfj059798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 09:48:37 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0I8maLl059795; Thu, 18 Jan 2007 09:48:36 +0100 (CET) Date: Thu, 18 Jan 2007 09:48:36 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070118084836.GA59381@stud.fit.vutbr.cz> References: <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 08:48:39 -0000 On Thu, Jan 18, 2007 at 01:17:48AM -0600, Scot Hetzel wrote: > On 1/17/07, Divacky Roman wrote: > >what scheduler are you using? if you use the other one can you reproduce > >the panic? > > > > > SCHED_4BSD > > >can you try this patch (added to the pathces you already have): > > > >the locking there sucks, I'll have to revisit it together with > >the LIST magic ;( > > > Tried the patch, but it didn't solve the problem. I had noticed today > that the kernel would panic on a LTP run (2.4.2). On one of the LTP > runs, I noticed it had paniced after the fork06 test. > > Had a look on P4, and saw change 113083, applied it to linux_emul.c. > So far it has passed 2 LTP tests (2.4.2, 2.6.16) with out panicing the > kernel. Currently, I'm runing 'emerge azureus', and is currently at > 18 of 188 ports. It usually paniced on the first or second port. > > So it looks like the problem may be solved by P4 Change 113083. hehe... nice things happen :) I really didnt expect this to help but it did :) I have some more patches in queue so if you had problems please take them from p4 repo (I hope to commit them in minutes now). roman From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 19 02:52:42 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49B3F16A407 for ; Fri, 19 Jan 2007 02:52:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 382C413C44B for ; Fri, 19 Jan 2007 02:52:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 483621A4D9E for ; Thu, 18 Jan 2007 18:52:41 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 92A83512E1; Thu, 18 Jan 2007 21:52:35 -0500 (EST) Date: Thu, 18 Jan 2007 21:52:35 -0500 From: Kris Kennaway To: freebsd-emulation@FreeBSD.org Message-ID: <20070119025235.GA82939@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: [ports-amd64@pointyhat.freebsd.org: rtc-2004.02.24.1_8 failed on amd64 7] X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 02:52:42 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI; can you please investigate and/or report to the developers? If you are already aware of this problem but do not yet have a fix, please mark the port BROKEN in the appropriate case, so that users do not unexpectedly encounter it. See http://pointyhat.freebsd.org for the full log. Thanks, Kris ----- Forwarded message from User Ports-amd64 ----- X-Original-To: kkenn@localhost Delivered-To: kkenn@localhost.obsecurity.org X-Original-To: kris@FreeBSD.org Delivered-To: kris@FreeBSD.org Date: Fri, 19 Jan 2007 02:20:15 GMT From: User Ports-amd64 To: kris@FreeBSD.org Subject: rtc-2004.02.24.1_8 failed on amd64 7 X-UIDL: 9)V"!cL9"!AS+!!0b0!! X-Bogosity: Ham, tests=3Dbogofilter, spamicity=3D0.000000, version=3D1.0.3 building rtc-2004.02.24.1_8 on fbsd-amd64.isc.org in directory /u0/pkgbld/7/chroot/4377 building for: 7.0-CURRENT amd64 maintained by: freebsd-emulation@FreeBSD.org port directory: /usr/ports/emulators/rtc build started at Fri Jan 19 02:43:41 UTC 2007 FETCH_DEPENDS=3D PATCH_DEPENDS=3D EXTRACT_DEPENDS=3D BUILD_DEPENDS=3D RUN_DEPENDS=3Dlinux_base-fc-4_9.tbz prefixes: LOCALBASE=3Dusr/local X11BASE=3Dusr/X11R6 add_pkg =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D add_pkg =3D=3D=3D> Extracting for rtc-2004.02.24.1_8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D add_pkg =3D=3D=3D> Patching for rtc-2004.02.24.1_8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D add_pkg =3D=3D=3D> Configuring for rtc-2004.02.24.1_8 =3D=3D=3D> Building for rtc-2004.02.24.1_8 "/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated in fav= or of NO_MAN "/sys/conf/kmod.mk", line 247: warning: duplicate script for target "@" ign= ored @ -> /sys awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h Warning: Object directory not changed from original /work/a/ports/emulators= /rtc/work/files machine -> /usr/src/sys/amd64/include cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=3D202 -D_KERNEL -DKLD_MODU= LE -std=3Dc99 -nostdinc -I/work/a/ports/emulators/rtc/work/files -I/sys -I= . -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D1= 00 --param large-function-growth=3D1000 -fno-common -fno-omit-frame-pointe= r -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ff= ormat-extensions -c rtc.c cc1: error: unrecognized command line option "-Wno-pointer-sign" *** Error code 1 Stop in /work/a/ports/emulators/rtc/work/files. *** Error code 1 Stop in /a/ports/emulators/rtc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D build of /usr/ports/emulators/rtc ended at Fri Jan 19 02:43:45 UTC 2007 ----- End forwarded message ----- --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFsDJzWry0BWjoQKURAtzZAKDrPRv7XQxryqL4pJgTVm0AcK+SGQCfbCVz dwfqP9dW2gnAlnE94bCWOnQ= =oQgZ -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 19 07:52:23 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFFA316A412 for ; Fri, 19 Jan 2007 07:52:23 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 451F113C457 for ; Fri, 19 Jan 2007 07:52:23 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so361896uge for ; Thu, 18 Jan 2007 23:52:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Dcahg03jgVqWzYe07G+9BWXjxKtcd0b7kJuafWV15N9dcYY9jQX6wfesd7N+ziAf8jj/3f0dhga8mj5JAHRcgMIdgUZcxY41nixUUBV5WGT0b1IssWsk919mCWmUDn/ICtQnqZ0rl4c40KV+hws3CMXxw/nceZgGO/COP9jfDWI= Received: by 10.82.138.6 with SMTP id l6mr459705bud.1169193141904; Thu, 18 Jan 2007 23:52:21 -0800 (PST) Received: by 10.82.186.2 with HTTP; Thu, 18 Jan 2007 23:52:21 -0800 (PST) Message-ID: <790a9fff0701182352n43071a18yd015ba1ace41fff@mail.gmail.com> Date: Fri, 19 Jan 2007 01:52:21 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070118084836.GA59381@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> <20070118084836.GA59381@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 07:52:23 -0000 On 1/18/07, Divacky Roman wrote: >> kernel. Currently, I'm runing 'emerge azureus', and is currently at >> 18 of 188 ports. It usually paniced on the first or second port. >> > > So it looks like the problem may be solved by P4 Change 113083. > > hehe... nice things happen :) I really didnt expect this to help > but it did :) > The problem is fixed with this change, as it built 181 of the 188 ports. The only port it can't finish building is dbus (remaining ports have a dependancy on dbus), but at least it no longer panics the kernel. hp010 dbus-0.62 # emerge --pretend azureus These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-apps/dbus-0.62-r2 USE="X gtk python qt3 qt4 -debug -doc -mono (-selinux)" [ebuild N ] gnome-base/gnome-vfs-2.16.3 USE="ipv6 ssl -avahi -debug -doc -gnutls -hal -samba" [ebuild N ] gnome-base/libgnome-2.16.0 USE="-debug -doc -esd -static" [ebuild N ] gnome-base/libbonoboui-2.16.0 USE="X -debug -doc" [ebuild N ] gnome-base/libgnomeui-2.16.1 USE="jpeg -debug -doc" [ebuild N ] dev-java/swt-3.2-r2 USE="gnome opengl -cairo -seamonkey" [ebuild N ] net-p2p/azureus-2.5.0.0-r3 USE="-source" hp010 dbus-0.62 # emerge dbus : Making all in tools gmake[2]: Entering directory `/var/tmp/portage/dbus-0.62-r2/work/dbus-0.62/tools' DBUS_TOP_BUILDDIR=.. ./run-with-tmp-session-bus.sh ./dbus-send --print-reply=literal --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.Introspectable.Introspect > dbus-bus-introspect.xml.tmp && mv dbus-bus-introspect.xml.tmp dbus-bus-introspect.xml escaped service dir is: ..\/test\/data\/valid-service-files Created configuration file ./run-with-tmp-session-bus.conf Running ../tools/dbus-launch --sh-syntax --config-file=./run-with-tmp-session-bus.conf Started bus pid 58623 at unix:path=/tmp/dbus-N3npYJ4n1g,guid=6366b045035d377a786f9a79f1f2e000 Running ./dbus-send --print-reply=literal --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.Introspectable.Introspect Failed to open connection to session message bus: No reply within specified time killing message bus 58623 ./run-with-tmp-session-bus.sh: script "./dbus-send" failed gmake[2]: *** [dbus-bus-introspect.xml] Error 1 gmake[2]: Leaving directory `/var/tmp/portage/dbus-0.62-r2/work/dbus-0.62/tools' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/tmp/portage/dbus-0.62-r2/work/dbus-0.62' gmake: *** [all] Error 2 Looks like dbus-send is not getting any response thru a socket (/tmp/dbus-N3npYJ4n1g) that dbus-launch is using to communicate with it. I also tried a kernel that had all the P4 patches applied, and same results. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 19 08:57:04 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AFD716A40F for ; Fri, 19 Jan 2007 08:57:04 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E312A13C457 for ; Fri, 19 Jan 2007 08:57:03 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5DF46.dip.t-dialin.net [84.165.223.70]) by redbull.bpaserver.net (Postfix) with ESMTP id 29D2E2E1AB; Fri, 19 Jan 2007 10:05:07 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 755295B488C; Fri, 19 Jan 2007 09:56:53 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0J8urO5098222; Fri, 19 Jan 2007 09:56:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 19 Jan 2007 09:56:53 +0100 Message-ID: <20070119095653.c9mwdda84wsk008o@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 19 Jan 2007 09:56:53 +0100 From: Alexander Leidinger To: Scot Hetzel References: <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <20070116181839.GA80994@stud.fit.vutbr.cz> <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> <20070118084836.GA59381@stud.fit.vutbr.cz> <790a9fff0701182352n43071a18yd015ba1ace41fff@mail.gmail.com> In-Reply-To: <790a9fff0701182352n43071a18yd015ba1ace41fff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-15.464, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, MD5_CONTENT -0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 08:57:04 -0000 Quoting Scot Hetzel (from Fri, 19 Jan 2007 =20 01:52:21 -0600): > On 1/18/07, Divacky Roman wrote: >>> kernel. Currently, I'm runing 'emerge azureus', and is currently at >>> 18 of 188 ports. It usually paniced on the first or second port. >>> >>> So it looks like the problem may be solved by P4 Change 113083. >> >> hehe... nice things happen :) I really didnt expect this to help >> but it did :) >> > The problem is fixed with this change, as it built 181 of the 188 > ports. The only port it can't finish building is dbus (remaining > ports have a dependancy on dbus), but at least it no longer panics the > kernel. Roman, would wyou please give him the most recent races-fix patch to =20 test it? Scot, would you please test to compile some emerge packages =20 with it? I don't expect it to fix the dbus problem. The main =20 motivation is to know if this new changes introduces a visible =20 regression or not. > Started bus pid 58623 at > unix:path=3D/tmp/dbus-N3npYJ4n1g,guid=3D6366b045035d377a786f9a79f1f2e000 > Running ./dbus-send --print-reply=3Dliteral --dest=3Dorg.freedesktop.DBus > /org/freedesktop/DBus org.freedesktop.DBus.Introspectable.Introspect > Failed to open connection to session message bus: No reply within > specified time > killing message bus 58623 > ./run-with-tmp-session-bus.sh: script "./dbus-send" failed > gmake[2]: *** [dbus-bus-introspect.xml] Error 1 > Looks like dbus-send is not getting any response thru a socket > (/tmp/dbus-N3npYJ4n1g) that dbus-launch is using to communicate with > it. First of all: we have a problem in FreeBSD regaring sending zero-size =20 data over sockets. Andre is working on fixing this. This may a be the =20 cause, or it may not be the cause. I don't think it is the cause. We have some other problems as indicated in the LTP tests. So I will =20 be not surprised if there's something else we have to take care of. Do you have time/energy to try the network tests in the LTP? You have =20 to setup a second box which gives access to a second linux instance =20 with the LTP stuff (can maybe done with a jail which starts a linux =20 remote access daemon). Bye, Alexander. --=20 A pipe gives a wise man time to think and a fool something to stick in his mouth. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 19 12:10:10 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C64416A407 for ; Fri, 19 Jan 2007 12:10:10 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9510713C442 for ; Fri, 19 Jan 2007 12:10:09 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0JCA8Zx006262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jan 2007 13:10:08 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0JCA7Nf006259; Fri, 19 Jan 2007 13:10:07 +0100 (CET) Date: Fri, 19 Jan 2007 13:10:07 +0100 From: Divacky Roman To: Alexander Leidinger Message-ID: <20070119121007.GA4267@stud.fit.vutbr.cz> References: <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <20070116221150.GA9429@stud.fit.vutbr.cz> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> <20070118084836.GA59381@stud.fit.vutbr.cz> <790a9fff0701182352n43071a18yd015ba1ace41fff@mail.gmail.com> <20070119095653.c9mwdda84wsk008o@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070119095653.c9mwdda84wsk008o@webmail.leidinger.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Scot Hetzel Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 12:10:10 -0000 On Fri, Jan 19, 2007 at 09:56:53AM +0100, Alexander Leidinger wrote: > Quoting Scot Hetzel (from Fri, 19 Jan 2007 > 01:52:21 -0600): > > >On 1/18/07, Divacky Roman wrote: > >>>kernel. Currently, I'm runing 'emerge azureus', and is currently at > >>>18 of 188 ports. It usually paniced on the first or second port. > >>> > >>>So it looks like the problem may be solved by P4 Change 113083. > >> > >>hehe... nice things happen :) I really didnt expect this to help > >>but it did :) > >> > >The problem is fixed with this change, as it built 181 of the 188 > >ports. The only port it can't finish building is dbus (remaining > >ports have a dependancy on dbus), but at least it no longer panics the > >kernel. > > Roman, would wyou please give him the most recent races-fix patch to > test it? Scot, would you please test to compile some emerge packages > with it? I don't expect it to fix the dbus problem. The main > motivation is to know if this new changes introduces a visible > regression or not. www.stud.fit.vutbr.cz/~xdivac02/linux-races.patch alexander, when commiting this to src please change the comment as jhb suggested. From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 00:25:35 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F147216A401 for ; Sat, 20 Jan 2007 00:25:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9984C13C43E for ; Sat, 20 Jan 2007 00:25:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0K00X3S069394 for ; Fri, 19 Jan 2007 19:00:33 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Fri, 19 Jan 2007 19:00:28 -0500 User-Agent: KMail/1.6.2 References: <200701191851.08685.jkim@FreeBSD.org> In-Reply-To: <200701191851.08685.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701191900.30814.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2466/Thu Jan 18 18:49:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: A new mmap finger printer X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 00:25:36 -0000 On Friday 19 January 2007 06:51 pm, Jung-uk Kim wrote: > I added PROT_EXEC test and cleaned up Marcin Cieslak's mmap finger > printer. Can any one try this on a real Linux/i386 box and send me > the output? Also available from here: http://people.freebsd.org/~jkim/mmap_test.c Thanks, Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 00:25:52 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C69316A402 for ; Sat, 20 Jan 2007 00:25:52 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3E52113C45B for ; Sat, 20 Jan 2007 00:25:52 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0JNpBdU069079 for ; Fri, 19 Jan 2007 18:51:11 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Fri, 19 Jan 2007 18:51:03 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_slVsFRjAyW28ZgI" Message-Id: <200701191851.08685.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2466/Thu Jan 18 18:49:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: A new mmap finger printer X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 00:25:52 -0000 --Boundary-00=_slVsFRjAyW28ZgI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline I added PROT_EXEC test and cleaned up Marcin Cieslak's mmap finger printer. Can any one try this on a real Linux/i386 box and send me the output? Thanks, Jung-uk Kim --Boundary-00=_slVsFRjAyW28ZgI Content-Type: text/plain; charset="iso-8859-1"; name="mmap_test.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mmap_test.c" #include #include #include #include #include #include #include #include struct intdesc { const int val; const char *desc; }; static sigjmp_buf env; static char nofile[] = "anonymous"; static char testfile[] = "/tmp/test.XXXXXX"; #if defined(__amd64__) || defined(__x86_64__) static char testfunc[] = { 0x55, /* push %rbp */ 0x48, 0x89, 0xe5, /* mov %rsp,%rbp */ 0xc7, 0x45, 0xfc, 0x42, 0x00, 0x00, 0x00, /* movl $0x42,-4(%rbp) */ 0xc9, /* leaveq */ 0xc3 /* retq */ }; #define TOFFSET 7 #elif defined(__i386__) static char testfunc[] = { 0x55, /* push %ebp */ 0x89, 0xe5, /* mov %esp,%ebp */ 0x83, 0xec, 0x04, /* sub $0x4,%esp */ 0xc7, 0x45, 0xfc, 0x42, 0x00, 0x00, 0x00, /* movl $0x42,-4(%ebp) */ 0xc9, /* leave */ 0xc3 /* ret */ }; #define TOFFSET 9 #else #warn "Sorry, this platform is not supported." #endif static char * mmap_test(int map_prot, int map_mode, int fd) { char *qp; qp = mmap(0, 1024, map_prot, map_mode, fd, 0); if (qp != MAP_FAILED) { printf("mmap OK "); return (qp); } else { printf("mmap error (%d)", errno); return (NULL); } } static void unmap_test(void *ptr) { if (ptr != NULL) munmap(ptr, 1024); } static int sigsegv = 0; static int buserr = 0; static int othersig = 0; static void handle_sig(int sig) { switch(sig) { case SIGSEGV: sigsegv ++; break; case SIGBUS: buserr ++; break; default: othersig = sig; } siglongjmp(env, 1); } #define PRINT_SIGNAL() \ do { \ if (sigsegv) \ printf("sigsegv"); \ if (buserr) \ printf("buserr"); \ if (othersig) \ printf("sig%02d", othersig); \ } while(0) static void access_test(void *ptr) { struct sigaction newsig = { .sa_handler = &handle_sig, .sa_flags = 0, .sa_mask = 0, }; struct sigaction oldsegv; struct sigaction oldbus; char *qp = (char *)ptr; /* read test */ sigsegv = buserr = othersig = 0; sigaction(SIGSEGV, &newsig, &oldsegv); sigaction(SIGBUS, &newsig, &oldbus); printf("read: "); if (sigsetjmp(env, 1) == 0) printf("0x%02x", qp[TOFFSET]); else PRINT_SIGNAL(); /* write test */ sigsegv = buserr = othersig = 0; printf(" write: "); if (sigsetjmp(env, 1) == 0) { memcpy(qp, testfunc, sizeof(testfunc)); qp[TOFFSET] = 0x41; printf("OK"); } else PRINT_SIGNAL(); /* exec test */ sigsegv = buserr = othersig = 0; printf(" exec: "); if (sigsetjmp(env, 1) == 0) { ((void (*)())qp)(); printf("OK"); } else PRINT_SIGNAL(); sigaction(SIGSEGV, &oldsegv, NULL); sigaction(SIGBUS, &oldbus, NULL); } #undef PRINT_SIGNAL static void run_cases(struct intdesc filemodes[], struct intdesc mapmodes[], struct intdesc mapprots[], char *(*mapfunc)(int, int, int), void (*accessfunc)(void *), void (*unmapfunc)(void *)) { struct intdesc *filemode, *map_mode, *map_prot; int fd, caseid, anon; void *region; caseid = 1; for (filemode = filemodes; filemode->desc != NULL; filemode++) { for (map_mode = mapmodes; map_mode->desc != NULL; map_mode++) { for (map_prot = mapprots; map_prot->desc != NULL; map_prot++) { if (filemode->desc != nofile) { anon = 0; if ((fd = open(testfile, filemode->val, 0644)) < 0 ) { perror("open testfile"); return; } } else { fd = -1; anon = MAP_ANON; } printf("%04d: mmap(0, 1024, %s, %s%s, ...)\n" " for filemode %s: ", caseid, map_prot->desc, anon ? "MAP_ANON|" : "", map_mode->desc, filemode->desc); region = (*mapfunc)(map_prot->val, anon | map_mode->val, fd); if (region) { (*accessfunc)(region); (*unmapfunc)(region); } caseid++; if (fd >= 0) close(fd); printf("\n"); } } } } int main(void) { struct intdesc filemodes[] = { {O_RDONLY, "O_RDONLY"}, {O_WRONLY, "O_WRONLY"}, {O_RDWR, "O_RDWR"}, {-1, nofile}, {-1, NULL}, }; struct intdesc mapmodes[] = { #if 0 {0, "none"}, #endif {MAP_SHARED, "MAP_SHARED"}, {MAP_PRIVATE, "MAP_PRIVATE"}, {-1, NULL}, }; struct intdesc mapprots[] = { {PROT_NONE, "PROT_NONE"}, {PROT_READ, "PROT_READ"}, {PROT_WRITE, "PROT_WRITE"}, {PROT_EXEC, "PROT_EXEC"}, {PROT_READ|PROT_WRITE, "PROT_READ|PROT_WRITE"}, {PROT_READ|PROT_EXEC, "PROT_READ|PROT_EXEC"}, {PROT_WRITE|PROT_EXEC, "PROT_WRITE|PROT_EXEC"}, {PROT_READ|PROT_WRITE|PROT_EXEC, "PROT_READ|PROT_WRITE|PROT_EXEC"}, {-1, NULL}, }; int fd; fd = mkstemp(testfile); if (fd < 0) { perror("open testfile"); return (-1); } if (write(fd, testfunc, sizeof(testfunc)) != sizeof(testfunc)) { perror("write testfile"); return (-1); } close(fd); run_cases(filemodes, mapmodes, mapprots, &mmap_test, &access_test, &unmap_test); unlink(testfile); return (0); } --Boundary-00=_slVsFRjAyW28ZgI-- From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 07:05:44 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABE6416A402 for ; Sat, 20 Jan 2007 07:05:44 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4EEE813C459 for ; Sat, 20 Jan 2007 07:05:44 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0K75goh077621 for ; Sat, 20 Jan 2007 02:05:42 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Sat, 20 Jan 2007 02:05:30 -0500 User-Agent: KMail/1.6.2 References: <200701191851.08685.jkim@FreeBSD.org> In-Reply-To: <200701191851.08685.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701200205.41517.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2467/Fri Jan 19 23:42:15 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: A new mmap finger printer X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:05:44 -0000 On Friday 19 January 2007 06:51 pm, Jung-uk Kim wrote: > I added PROT_EXEC test and cleaned up Marcin Cieslak's mmap finger > printer. Can any one try this on a real Linux/i386 box and send me > the output? This one had a serious bug. Please fetch it again from here: http://people.freebsd.org/~jkim/mmap_test.c Sorry, Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 07:09:06 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 180F716A402; Sat, 20 Jan 2007 07:09:06 +0000 (UTC) (envelope-from don@siad.net) Received: from mail872.megamailservers.com (mail872.carrierinternetsolutions.com [69.49.106.82]) by mx1.freebsd.org (Postfix) with ESMTP id BD66713C465; Sat, 20 Jan 2007 07:09:05 +0000 (UTC) (envelope-from don@siad.net) X-Authenticated-User: belcherd.covad.net Received: from [69.3.214.123] (rover.siad.net [69.3.214.123]) (authenticated bits=0) by mail872.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id l0K63pSi028679; Sat, 20 Jan 2007 01:03:53 -0500 Message-ID: <45B1B0C7.8060603@siad.net> Date: Fri, 19 Jan 2007 22:03:51 -0800 From: "Don L. Belcher" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061031 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org Subject: FreeBSD Port: linux-xorg-libs-6.8.2_5 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:09:06 -0000 The doom3 game does not work on my system with the linux-xorg-libs. WARNING: vertex array range in virtual memory (SLOW) signal caught: Segmentation fault si_code 12 Trying to exit gracefully.. Shutting down sound hardware ------ OSS Sound Shutdown ------ It works with the linux-XFree86-libs, but I accidently deleted the library and it does not show up in the ports tree either. So is there someplace I can pickup the linux-XFree86-libs From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 07:25:16 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04B3D16A400 for ; Sat, 20 Jan 2007 07:25:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABB913C428 for ; Sat, 20 Jan 2007 07:25:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so688868nfc for ; Fri, 19 Jan 2007 23:25:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pk/yMxj/t9D+b6jvBmnfsLD5c+KtfroY+/pnrnBou4H1uG0Byw7X3R9L0+FkvZC/RR+o6EBlRDmQdaDi47u8y5EiBKy9Y7dzDqnFr/DTE4d6kwSYBBINzg5g1aW/Qq7OZGvfxh5FYRB6juD+cJMdKFk2qg5n+R9E2NpgZdKZ5vI= Received: by 10.82.107.15 with SMTP id f15mr1956208buc.1169277914119; Fri, 19 Jan 2007 23:25:14 -0800 (PST) Received: by 10.82.186.2 with HTTP; Fri, 19 Jan 2007 23:25:14 -0800 (PST) Message-ID: <790a9fff0701192325o15dcf63bo86764ee3fb5b0220@mail.gmail.com> Date: Sat, 20 Jan 2007 01:25:14 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070119121007.GA4267@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701161317q74b28955jf61b6e9651168a36@mail.gmail.com> <790a9fff0701162000s5f48d51fk2e5a4a74bd7021f9@mail.gmail.com> <20070117091530.GA48578@stud.fit.vutbr.cz> <790a9fff0701170955o5674c8feu98117320a72e63ef@mail.gmail.com> <20070117223025.GA21199@stud.fit.vutbr.cz> <790a9fff0701172317k6876ad77p1c29ac76fa400d65@mail.gmail.com> <20070118084836.GA59381@stud.fit.vutbr.cz> <790a9fff0701182352n43071a18yd015ba1ace41fff@mail.gmail.com> <20070119095653.c9mwdda84wsk008o@webmail.leidinger.net> <20070119121007.GA4267@stud.fit.vutbr.cz> Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:25:16 -0000 On 1/19/07, Divacky Roman wrote: > On Fri, Jan 19, 2007 at 09:56:53AM +0100, Alexander Leidinger wrote: > > Quoting Scot Hetzel (from Fri, 19 Jan 2007 > > 01:52:21 -0600): > > > > >On 1/18/07, Divacky Roman wrote: > > >>>kernel. Currently, I'm runing 'emerge azureus', and is currently at > > >>>18 of 188 ports. It usually paniced on the first or second port. > > >>> > > >>>So it looks like the problem may be solved by P4 Change 113083. > > >> > > >>hehe... nice things happen :) I really didnt expect this to help > > >>but it did :) > > >> > > >The problem is fixed with this change, as it built 181 of the 188 > > >ports. The only port it can't finish building is dbus (remaining > > >ports have a dependancy on dbus), but at least it no longer panics the > > >kernel. > > > > Roman, would wyou please give him the most recent races-fix patch to > > test it? Scot, would you please test to compile some emerge packages > > with it? I don't expect it to fix the dbus problem. The main > > motivation is to know if this new changes introduces a visible > > regression or not. > > www.stud.fit.vutbr.cz/~xdivac02/linux-races.patch > > alexander, when commiting this to src please change the comment as jhb > suggested. > Reverted the -CURRENT sources back to the original files, and then applied this patch. I don't get the kernel panic with this patch either. emerge azureus - completed 213 of 220 ports (stopped at dbus). Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 10:46:11 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45A8716A402; Sat, 20 Jan 2007 10:46:11 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id BA05813C45B; Sat, 20 Jan 2007 10:46:10 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 686011383B2; Sat, 20 Jan 2007 11:18:41 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 5FB57138371; Sat, 20 Jan 2007 11:18:40 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id DD0E92CAA72; Sat, 20 Jan 2007 11:18:36 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0KAIavR001278; Sat, 20 Jan 2007 11:18:36 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Sat, 20 Jan 2007 11:18:34 +0100 User-Agent: KMail/1.9.5 References: <200701191851.08685.jkim@FreeBSD.org> <200701200205.41517.jkim@FreeBSD.org> In-Reply-To: <200701200205.41517.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701201118.35835.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Jung-uk Kim Subject: Re: A new mmap finger printer X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 10:46:11 -0000 On Saturday 20 January 2007 08:05, Jung-uk Kim wrote: > On Friday 19 January 2007 06:51 pm, Jung-uk Kim wrote: > > I added PROT_EXEC test and cleaned up Marcin Cieslak's mmap finger > > printer. Can any one try this on a real Linux/i386 box and send me > > the output? Linux 2.6.8-3-686 #01: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #02: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #03: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #04: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #05: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #06: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #07: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #08: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #09: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #10: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #11: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: OK, exec: OK #12: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #13: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: OK, exec: OK #14: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #15: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #16: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: Operation not permitted (1) #17: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #18: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #19: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #20: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #21: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #22: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #23: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #24: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #25: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #26: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #27: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #28: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #29: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #30: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #31: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #32: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Operation not permitted (1) #33: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #34: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #35: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: OK, exec: OK #36: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #37: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #38: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #39: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #40: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #41: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #42: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #43: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: OK, exec: OK #44: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #45: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #46: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #47: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #48: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: Operation not permitted (1) #49: mmap(0, 1024, PROTO_NONE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #50: mmap(0, 1024, PROTO_READ, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #51: mmap(0, 1024, PROTO_WRITE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: OK, exec: OK #52: mmap(0, 1024, PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #53: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #54: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #55: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #56: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #57: mmap(0, 1024, PROTO_NONE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #58: mmap(0, 1024, PROTO_READ, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #59: mmap(0, 1024, PROTO_WRITE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: OK, exec: OK #60: mmap(0, 1024, PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #61: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #62: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #63: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #64: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 16:07:34 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C545116A405; Sat, 20 Jan 2007 16:07:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 5341713C45D; Sat, 20 Jan 2007 16:07:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5DAA7.dip.t-dialin.net [84.165.218.167]) by redbull.bpaserver.net (Postfix) with ESMTP id B589F2E05E; Sat, 20 Jan 2007 17:15:58 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 3C4A45B482A; Sat, 20 Jan 2007 17:07:24 +0100 (CET) Date: Sat, 20 Jan 2007 17:07:23 +0100 From: Alexander Leidinger To: current@freebsd.org Message-ID: <20070120170723.34c223fb@Magellan.Leidinger.net> Followup-To: emulation@freebsd.org X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: CFT/HEADS-UP: linux 2.6.16 emulation X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 16:07:34 -0000 Hi, today I committed the last fixes for the showstopper problems (panics) in the linux 2.6.16 emulation. I intend to switch the default version to 2.6.16 on i386 "soon" (see below), so please help testing it. More recent linux distributions (e.g. FC5) require a 2.6 kernel and don't work with 2.4.2 anymore. And because FC4 is "abandon-ware" (no security fixes from fedoralegacy anymore), getting 2.6.16 emulation up an running is very important. If you use a linux program, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desktop is running with 2.6.16 emulation since some days already). After the next boot (or after running "sysctl compat.linux.osrelease=2.6.16", please make sure no linux program is running already) any linux program will start with a linux kernel version of 2.6.16 instead of 2.4.2. The default linux base port (FC4) will then use different code paths (e.g. within glibc). In case you want to switch back to the 2.4.2 emulation without a reboot, please make sure no linux program is running anymore. So far we fixed all known/repeatable problems with acroread, realplayer, skype and linux firefox. If you encounter strange behavior with any linux program, please tell us (emulation@freebsd.org) which program you used, how to repeat the problem, what the problem is, and if it only is visible with 2.6.16 or with 2.4.2 too. You should also watch out for messages in the dmesg (unimplemented system calls or other stuff, this is used to determine the priority of missing syscalls). Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I intend to document the known problems there. If you find your problem there, please tell us about it if you are willing to test fixes. We are specially interested in reports (good or bad) on SMP systems. Please beat the hell out of the linuxulator! On amd64 systems we have not the same functionality as on i386, missing are futexes and TLS. In P4 we already have the futex part covered, but the TLS part is still missing (anyone with a clue about the kernel side of TLS on amd64 is welcome to give a hint or two to jkim@ and rdivacky@). So if you get a message about missing futexes or TLS on amd64: we know about it (testers for the futex stuff are welcome, but first you need to use a program which uses futexes and complains). As long as we get problem reports with 2.6.16 I will not switch the default to 2.6.16. If we don't get a report at all, I will switch the default on i386 to 2.6.16 in two weeks. If we get some problem reports, we will push back the switch a little bit depending on the severity of the problem. Bye, Alexander. -- Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ... http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 20 18:32:39 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6472616A405 for ; Sat, 20 Jan 2007 18:32:39 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id E2FB013C459 for ; Sat, 20 Jan 2007 18:32:38 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so665222uge for ; Sat, 20 Jan 2007 10:32:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=aOz//YiF5gfrYNfWLgxq2BQwi+1sCUoyzohxFuw77jk/J2uvo46MSeQ7kpbtfeYUDTrE3/dQAQfbEA4KpIUEYPW3G7fPb2pZr/V343nsNiglCturm+c6Ks9p1Yv5l5H0zQivFDv4AaDyGP/4JLB+CjmMyPZBk5L32xW3uT4Kk60= Received: by 10.66.244.11 with SMTP id r11mr4979580ugh.1169316364338; Sat, 20 Jan 2007 10:06:04 -0800 (PST) Received: from roadrunner.q.local ( [85.180.180.12]) by mx.google.com with ESMTP id k1sm4250770ugf.2007.01.20.10.06.02; Sat, 20 Jan 2007 10:06:03 -0800 (PST) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l0KI3ALC009548; Sat, 20 Jan 2007 19:03:10 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l0KI3AkL009547; Sat, 20 Jan 2007 19:03:10 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sat, 20 Jan 2007 19:03:09 +0100 From: Ulrich Spoerlein To: Jung-uk Kim Message-ID: <20070120180309.GC1548@roadrunner.q.local> Mail-Followup-To: Jung-uk Kim , freebsd-emulation@FreeBSD.org References: <200701191851.08685.jkim@FreeBSD.org> <200701200205.41517.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701200205.41517.jkim@FreeBSD.org> Cc: freebsd-emulation@FreeBSD.org Subject: Re: A new mmap finger printer X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 18:32:39 -0000 Jung-uk Kim wrote: > http://people.freebsd.org/~jkim/mmap_test.c % uname -a Linux PC03 2.6.17-gentoo-r4 #1 SMP PREEMPT Mon Aug 14 17:19:40 CEST 2006 i686 Intel(R) Celeron(R) CPU 3.06GHz GNU/Linux % ./mmap_test #01: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #02: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #03: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #04: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #05: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #06: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #07: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #08: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDONLY: mmap: Permission denied (13) #09: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #10: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #11: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: SIGSEGV, write: OK, exec: OK #12: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #13: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: OK, exec: OK #14: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #15: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: OK, exec: OK #16: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDONLY: mmap: OK, read: 0x41, write: OK, exec: OK #17: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #18: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #19: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #20: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #21: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #22: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #23: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #24: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_WRONLY: mmap: Permission denied (13) #25: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #26: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #27: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #28: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #29: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #30: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #31: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #32: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_WRONLY: mmap: Permission denied (13) #33: mmap(0, 1024, PROTO_NONE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #34: mmap(0, 1024, PROTO_READ, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x41, write: SIGSEGV, exec: OK #35: mmap(0, 1024, PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: OK, exec: OK #36: mmap(0, 1024, PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #37: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #38: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #39: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #40: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_SHARED, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #41: mmap(0, 1024, PROTO_NONE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #42: mmap(0, 1024, PROTO_READ, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #43: mmap(0, 1024, PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: SIGSEGV, write: OK, exec: OK #44: mmap(0, 1024, PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #45: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #46: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: SIGSEGV, exec: OK #47: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #48: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_PRIVATE, ...) for filemode O_RDWR: mmap: OK, read: 0x42, write: OK, exec: OK #49: mmap(0, 1024, PROTO_NONE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #50: mmap(0, 1024, PROTO_READ, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #51: mmap(0, 1024, PROTO_WRITE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: OK, exec: OK #52: mmap(0, 1024, PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #53: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #54: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #55: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #56: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_SHARED, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #57: mmap(0, 1024, PROTO_NONE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: SIGSEGV, exec: SIGSEGV #58: mmap(0, 1024, PROTO_READ, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #59: mmap(0, 1024, PROTO_WRITE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: SIGSEGV, write: OK, exec: OK #60: mmap(0, 1024, PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #61: mmap(0, 1024, PROTO_READ|PROTO_WRITE, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #62: mmap(0, 1024, PROTO_READ|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: SIGSEGV, exec: SIGSEGV #63: mmap(0, 1024, PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK #64: mmap(0, 1024, PROTO_READ|PROTO_WRITE|PROTO_EXEC, MAP_ANON|MAP_PRIVATE, ...) for filemode N/A: mmap: OK, read: 0x00, write: OK, exec: OK Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon?