From owner-freebsd-mobile@FreeBSD.ORG Tue Oct 30 16:16:02 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C8416A419; Tue, 30 Oct 2007 16:16:02 +0000 (UTC) (envelope-from mpumford@mpc-data.co.uk) Received: from warcop.mpc-data.co.uk (cvs.mpc-ogw.co.uk [81.2.99.171]) by mx1.freebsd.org (Postfix) with ESMTP id 149DD13C4B8; Tue, 30 Oct 2007 16:16:01 +0000 (UTC) (envelope-from mpumford@mpc-data.co.uk) Received: from [192.150.92.163] (buntingford.mpc-data.co.uk [192.150.92.163]) by warcop.mpc-data.co.uk (8.12.9p2/8.12.9) with ESMTP id l9UFjxhx036249; Tue, 30 Oct 2007 15:46:00 GMT (envelope-from mpumford@mpc-data.co.uk) Message-ID: <472751B7.9040505@mpc-data.co.uk> Date: Tue, 30 Oct 2007 15:45:59 +0000 From: Mike Pumford User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <461307.47075.qm@web33709.mail.mud.yahoo.com> In-Reply-To: <461307.47075.qm@web33709.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luis Neves , freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 16:16:02 -0000 Abdullah Ibn Hamad Al-Marri wrote: > > Previously I didn't mention that there are some functions missing from > > the FreeBSD's NDIS api. These are: > > With the help of NDIS reference and Linux ndiswrapper I have been able > > to implement all but KeBugCheckEx (they are all rather simple but I > Can help you with this one. This is the Windows equivalent of panic(). So just call panic with an appropriate string. If the string includes the bugcheck code and parameters so much the better. Mike From owner-freebsd-mobile@FreeBSD.ORG Wed Oct 31 06:41:03 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D684D16A474 for ; Wed, 31 Oct 2007 06:41:03 +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 0D66213C480 for ; Wed, 31 Oct 2007 06:41:02 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so32559nfb for ; Tue, 30 Oct 2007 23:40:28 -0700 (PDT) Received: by 10.86.1.1 with SMTP id 1mr5966099fga.1193803018078; Tue, 30 Oct 2007 20:56:58 -0700 (PDT) Received: by 10.86.71.6 with HTTP; Tue, 30 Oct 2007 20:56:58 -0700 (PDT) Message-ID: <790a9fff0710302056m60167d70lcf94a9774c06d09@mail.gmail.com> Date: Tue, 30 Oct 2007 22:56:58 -0500 From: "Scot Hetzel" To: "Mike Pumford" In-Reply-To: <472751B7.9040505@mpc-data.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4198_9968625.1193803018076" References: <461307.47075.qm@web33709.mail.mud.yahoo.com> <472751B7.9040505@mpc-data.co.uk> Cc: freebsd-mobile@freebsd.org, freebsd-stable@freebsd.org, Abdullah Ibn Hamad Al-Marri Subject: Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 06:41:04 -0000 ------=_Part_4198_9968625.1193803018076 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/30/07, Mike Pumford wrote: > Abdullah Ibn Hamad Al-Marri wrote: > > > > > Previously I didn't mention that there are some functions missing from > > > > the FreeBSD's NDIS api. These are: > > > > With the help of NDIS reference and Linux ndiswrapper I have been able > > > > to implement all but KeBugCheckEx (they are all rather simple but I > > > Can help you with this one. This is the Windows equivalent of panic(). > So just call panic with an appropriate string. If the string includes > the bugcheck code and parameters so much the better. > Thanks for your hint to use panic() in the KeBugCheckEx function. I have KeBugCheckEx partially implemented. It currently prints the bugcheck code and the 4 paramators that are sent to KeBugCheckEx. The KeBugCheckEx function still needs to be changed to display the right information depending on the bugcheck code. Abdullah, I made a minor change to your patch, strncat should be prefixed with ntoskrnl_strncat. changed IMPORT_CFUNC(strncat..) to IMPORT_CFUNC_MAP(ntoskrnl_strncat..). Scot ------=_Part_4198_9968625.1193803018076 Content-Type: text/plain; name=ndis.patch Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Content-Disposition: attachment; filename=ndis.patch SW5kZXg6IG5kaXNfdmFyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lz L2NvbXBhdC9uZGlzL25kaXNfdmFyLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDcKZGlmZiAt dSAtcjEuNDcgbmRpc192YXIuaAotLS0gbmRpc192YXIuaAk2IEFwciAyMDA3IDExOjE4OjU3IC0w MDAwCTEuNDcKKysrIG5kaXNfdmFyLmgJMzEgT2N0IDIwMDcgMDM6MzE6MjQgLTAwMDAKQEAgLTQ5 LDYgKzQ5LDEwIEBACiB0eXBlZGVmIHJlZ2lzdGVyX3QgbmRpc19rc3Bpbl9sb2NrOwogdHlwZWRl ZiB1aW50OF90IG5kaXNfa2lycWw7CiAKKy8qIFZlcnNpb24gb2YgTkRJUyBzdXBwb3J0ZWQgYnkg RnJlZUJTRCAqLworI2RlZmluZQlORElTX1ZFUlNJT05fNTEJCQkweDAwMDUwMDAxCisjZGVmaW5l CU5ESVNfVkVSU0lPTgkJCU5ESVNfVkVSU0lPTl81MQorCiAvKgogICogTkRJUyBzdGF0dXMgY29k ZXMgKHRoZXJlIGFyZSBsb3RzIG9mIHRoZW0pLiBUaGUgb25lcyB0aGF0CiAgKiBkb24ndCBzZWVt IHRvIGZpdCB0aGUgcGF0dGVybiBhcmUgYWN0dWFsbHkgbWFwcGVkIHRvIGdlbmVyaWMKSW5kZXg6 IG50b3Nrcm5sX3Zhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9j b21wYXQvbmRpcy9udG9za3JubF92YXIuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40MwpkaWZm IC11IC1yMS40MyBudG9za3JubF92YXIuaAotLS0gbnRvc2tybmxfdmFyLmgJMTcgQXVnIDIwMDYg MjI6NTA6MzIgLTAwMDAJMS40MworKysgbnRvc2tybmxfdmFyLmgJMzEgT2N0IDIwMDcgMDM6MzE6 MjQgLTAwMDAKQEAgLTEyMDIsMTQgKzEyMDIsMjIgQEAKIAogLyogTWVtb3J5IHBvb2wgdHlwZXMs IGZvciBFeEFsbG9jYXRlUG9vbFdpdGhUYWcoKSAqLwogCi0jZGVmaW5lIE5vblBhZ2VkUG9vbAkJ CTB4MDAwMDAwMDAKLSNkZWZpbmUgUGFnZWRQb29sCQkJMHgwMDAwMDAwMQotI2RlZmluZSBOb25Q YWdlZFBvb2xNdXN0U3VjY2VlZAkJMHgwMDAwMDAwMgotI2RlZmluZSBEb250VXNlVGhpc1R5cGUJ CQkweDAwMDAwMDAzCi0jZGVmaW5lIE5vblBhZ2VkUG9vbENhY2hlQWxpZ25lZAkweDAwMDAwMDA0 Ci0jZGVmaW5lIFBhZ2VkUG9vbENhY2hlQWxpZ25lZAkJMHgwMDAwMDAwNQotI2RlZmluZSBOb25Q YWdlZFBvb2xDYWNoZUFsaWduZWRNdXN0UwkweDAwMDAwMDA2Ci0jZGVmaW5lIE1heFBvb2xUeXBl CQkJMHgwMDAwMDAwNworI2RlZmluZQlOb25QYWdlZFBvb2wJCQkJMHgwMDAwMDAwMAorI2RlZmlu ZQlQYWdlZFBvb2wJCQkJMHgwMDAwMDAwMQorI2RlZmluZQlOb25QYWdlZFBvb2xNdXN0U3VjY2Vl ZAkJCTB4MDAwMDAwMDIKKyNkZWZpbmUJRG9udFVzZVRoaXNUeXBlCQkJCTB4MDAwMDAwMDMKKyNk ZWZpbmUJTm9uUGFnZWRQb29sQ2FjaGVBbGlnbmVkCQkweDAwMDAwMDA0CisjZGVmaW5lCVBhZ2Vk UG9vbENhY2hlQWxpZ25lZAkJCTB4MDAwMDAwMDUKKyNkZWZpbmUJTm9uUGFnZWRQb29sQ2FjaGVB bGlnbmVkTXVzdFMJCTB4MDAwMDAwMDYKKyNkZWZpbmUJTWF4UG9vbFR5cGUJCQkJMHgwMDAwMDAw NworCisjZGVmaW5lCU5vblBhZ2VkUG9vbFNlc3Npb24JCQkweDAwMDAwMDIwCisjZGVmaW5lCVBh Z2VkUG9vbFNlc3Npb24JCQkweDAwMDAwMDIxCisjZGVmaW5lCU5vblBhZ2VkUG9vbE11c3RTdWNj ZWVkU2Vzc2lvbgkJMHgwMDAwMDAyMgorI2RlZmluZQlEb250VXNlVGhpc1R5cGVTZXNzaW9uCQkJ MHgwMDAwMDAyMworI2RlZmluZQlOb25QYWdlZFBvb2xDYWNoZUFsaWduZWRTZXNzaW9uCQkweDAw MDAwMDI0CisjZGVmaW5lCVBhZ2VkUG9vbENhY2hlQWxpZ25lZFNlc3Npb24JCTB4MDAwMDAwMjUK KyNkZWZpbmUJTm9uUGFnZWRQb29sQ2FjaGVBbGlnbmVkTXVzdFNTZXNzaW9uCTB4MDAwMDAwMjYK IAogLyoKICAqIElPX1dPUktJVEVNIGlzIGFuIG9wYXF1ZSBzdHJ1Y3R1cmVzIHRoYXQgbXVzdCBi ZSBhbGxvY2F0ZWQKQEAgLTEzNTcsOCArMTM2NSwxMiBAQAogZXh0ZXJuIHVpbnQ4X3QgS2VTeW5j aHJvbml6ZUV4ZWN1dGlvbihraW50ZXJydXB0ICosIHZvaWQgKiwgdm9pZCAqKTsKIGV4dGVybiB1 aW50cHRyX3QgSW50ZXJsb2NrZWRFeGNoYW5nZSh2b2xhdGlsZSB1aW50MzJfdCAqLAogCXVpbnRw dHJfdCk7CitleHRlcm4gdm9pZCAqRXhBbGxvY2F0ZVBvb2wodWludDMyX3QsIHNpemVfdCk7Citl eHRlcm4gdm9pZCAqRXhBbGxvY2F0ZVBvb2xXaXRoUXVvdGEodWludDMyX3QsIHNpemVfdCk7Citl eHRlcm4gdm9pZCAqRXhBbGxvY2F0ZVBvb2xXaXRoUXVvdGFUYWcodWludDMyX3QsIHNpemVfdCwg dWludDMyX3QpOwogZXh0ZXJuIHZvaWQgKkV4QWxsb2NhdGVQb29sV2l0aFRhZyh1aW50MzJfdCwg c2l6ZV90LCB1aW50MzJfdCk7CiBleHRlcm4gdm9pZCBFeEZyZWVQb29sKHZvaWQgKik7CitleHRl cm4gdm9pZCBFeEZyZWVQb29sV2l0aFRhZyh2b2lkICosIHVpbnQzMl90KTsKIGV4dGVybiB1aW50 MzJfdCBJb0Nvbm5lY3RJbnRlcnJ1cHQoa2ludGVycnVwdCAqKiwgdm9pZCAqLCB2b2lkICosCiAJ a3NwaW5fbG9jayAqLCB1aW50MzJfdCwgdWludDhfdCwgdWludDhfdCwgdWludDhfdCwgdWludDhf dCwKIAl1aW50MzJfdCwgdWludDhfdCk7CkluZGV4OiBzdWJyX25kaXMuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD UyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L25kaXMvc3Vicl9uZGlzLmMsdgpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMTA4CmRpZmYgLXUgLXIxLjEwOCBzdWJyX25kaXMuYwotLS0gc3Vi cl9uZGlzLmMJMzEgTWF5IDIwMDcgMTE6NTE6NDkgLTAwMDAJMS4xMDgKKysrIHN1YnJfbmRpcy5j CTMxIE9jdCAyMDA3IDAzOjMxOjI0IC0wMDAwCkBAIC0yNzIsNiArMjcyLDcgQEAKIHN0YXRpYyB2 b2lkIE5kaXNVbm1hcEZpbGUobmRpc19oYW5kbGUpOwogc3RhdGljIHZvaWQgTmRpc0Nsb3NlRmls ZShuZGlzX2hhbmRsZSk7CiBzdGF0aWMgdWludDhfdCBOZGlzU3lzdGVtUHJvY2Vzc29yQ291bnQo dm9pZCk7CitzdGF0aWMgdm9pZCBOZGlzR2V0Q3VycmVudFByb2Nlc3NvckNvdW50cyh1aW50MzJf dCAqLCB1aW50MzJfdCAqLCB1aW50MzJfdCopOwogc3RhdGljIHZvaWQgTmRpc01JbmRpY2F0ZVN0 YXR1c0NvbXBsZXRlKG5kaXNfaGFuZGxlKTsKIHN0YXRpYyB2b2lkIE5kaXNNSW5kaWNhdGVTdGF0 dXMobmRpc19oYW5kbGUsIG5kaXNfc3RhdHVzLAogICAgICAgICB2b2lkICosIHVpbnQzMl90KTsK QEAgLTI4Miw2ICsyODMsNyBAQAogCXVpbnQzMl90LCB1aW50MzJfdCwgbmRpc19wYWNrZXQgKiwg dWludDMyX3QsIHVpbnQzMl90ICopOwogc3RhdGljIHZvaWQgTmRpc0NvcHlGcm9tUGFja2V0VG9Q YWNrZXRTYWZlKG5kaXNfcGFja2V0ICosCiAJdWludDMyX3QsIHVpbnQzMl90LCBuZGlzX3BhY2tl dCAqLCB1aW50MzJfdCwgdWludDMyX3QgKiwgdWludDMyX3QpOworc3RhdGljIHZvaWQgTmRpc0lN Q29weVNlbmRQZXJQYWNrZXRJbmZvKG5kaXNfcGFja2V0ICosIG5kaXNfcGFja2V0ICopOwogc3Rh dGljIG5kaXNfc3RhdHVzIE5kaXNNUmVnaXN0ZXJEZXZpY2UobmRpc19oYW5kbGUsCiAJdW5pY29k ZV9zdHJpbmcgKiwgdW5pY29kZV9zdHJpbmcgKiwgZHJpdmVyX2Rpc3BhdGNoICoqLAogCXZvaWQg KiosIG5kaXNfaGFuZGxlICopOwpAQCAtMzExNSw2ICszMTE3LDIwIEBACiAJcmV0dXJuKG1wX25j cHVzKTsKIH0KIAorc3RhdGljIHZvaWQKK05kaXNHZXRDdXJyZW50UHJvY2Vzc29yQ291bnRzKGlk bGVjb3VudCwga2VybmVsdXNlciwgaW5kZXgpCisJdWludDMyX3QJCSppZGxlY291bnQ7CisJdWlu dDMyX3QJCSprZXJuZWx1c2VyOworCXVpbnQzMl90CQkqaW5kZXg7Cit7CisJaW50IGNwdSA9IDA7 IC8qIEN1cnJlbnQgQ1BVICovCisKKwkqaWRsZWNvdW50ID0gY3BfdGltZVtDUF9JRExFXTsKKwkq a2VybmVsdXNlciA9CShjcF90aW1lW0NQX1VTRVJdICsgY3BfdGltZVtDUF9OSUNFXSkgKyBcCisJ CQkoY3BfdGltZVtDUF9TWVNdICsgY3BfdGltZVtDUF9JTlRSXSk7CisJKmluZGV4ID0gY3B1Owor fQorCiB0eXBlZGVmIHZvaWQgKCpuZGlzX3N0YXR1c2RvbmVfaGFuZGxlcikobmRpc19oYW5kbGUp OwogdHlwZWRlZiB2b2lkICgqbmRpc19zdGF0dXNfaGFuZGxlcikobmRpc19oYW5kbGUsIG5kaXNf c3RhdHVzLAogICAgICAgICB2b2lkICosIHVpbnQzMl90KTsKQEAgLTMyODgsNiArMzMwNCwxNCBA QAogCXJldHVybjsKIH0KIAorc3RhdGljIHZvaWQKK05kaXNJTUNvcHlTZW5kUGVyUGFja2V0SW5m byhkcGt0LCBzcGt0KQorCW5kaXNfcGFja2V0CQkqZHBrdDsKKwluZGlzX3BhY2tldAkJKnNwa3Q7 Cit7CisJbWVtY3B5KCZkcGt0LT5ucF9leHQsICZzcGt0LT5ucF9leHQsIHNpemVvZihuZGlzX3Bh Y2tldF9leHRlbnNpb24pKTsKK30KKwogc3RhdGljIG5kaXNfc3RhdHVzCiBOZGlzTVJlZ2lzdGVy RGV2aWNlKGhhbmRsZSwgZGV2bmFtZSwgc3ltbmFtZSwgbWFqb3JmdW5jcywgZGV2b2JqLCBkZXZo YW5kbGUpCiAJbmRpc19oYW5kbGUJCWhhbmRsZTsKQEAgLTMzNDYsNiArMzM3MCwxMiBAQAogCXJl dHVybjsKIH0KIAorc3RhdGljIHVpbnQzMl90CitOZGlzR2V0VmVyc2lvbigpCit7CisJcmV0dXJu KE5ESVNfVkVSU0lPTik7Cit9CisKIHN0YXRpYyB2b2lkCiBkdW1teSgpCiB7CkBAIC0zMzY1LDEw ICszMzk1LDEyIEBACiBpbWFnZV9wYXRjaF90YWJsZSBuZGlzX2Z1bmN0YmxbXSA9IHsKIAlJTVBP UlRfU0ZVTkMoTmRpc0NvcHlGcm9tUGFja2V0VG9QYWNrZXQsIDYpLAogCUlNUE9SVF9TRlVOQyhO ZGlzQ29weUZyb21QYWNrZXRUb1BhY2tldFNhZmUsIDcpLAorCUlNUE9SVF9TRlVOQyhOZGlzSU1D b3B5U2VuZFBlclBhY2tldEluZm8sIDIpLAogCUlNUE9SVF9TRlVOQyhOZGlzU2NoZWR1bGVXb3Jr SXRlbSwgMSksCiAJSU1QT1JUX1NGVU5DKE5kaXNNSW5kaWNhdGVTdGF0dXNDb21wbGV0ZSwgMSks CiAJSU1QT1JUX1NGVU5DKE5kaXNNSW5kaWNhdGVTdGF0dXMsIDQpLAogCUlNUE9SVF9TRlVOQyhO ZGlzU3lzdGVtUHJvY2Vzc29yQ291bnQsIDApLAorCUlNUE9SVF9TRlVOQyhOZGlzR2V0Q3VycmVu dFByb2Nlc3NvckNvdW50cywgMyksCiAJSU1QT1JUX1NGVU5DKE5kaXNVbmNoYWluQnVmZmVyQXRC YWNrLCAyKSwKIAlJTVBPUlRfU0ZVTkMoTmRpc0dldEZpcnN0QnVmZmVyRnJvbVBhY2tldCwgNSks CiAJSU1QT1JUX1NGVU5DKE5kaXNHZXRGaXJzdEJ1ZmZlckZyb21QYWNrZXRTYWZlLCA2KSwKQEAg LTM0ODIsNiArMzUxNCw3IEBACiAJSU1QT1JUX1NGVU5DKE5kaXNNRGVyZWdpc3RlckRldmljZSwg MSksCiAJSU1QT1JUX1NGVU5DKE5kaXNNUXVlcnlBZGFwdGVySW5zdGFuY2VOYW1lLCAyKSwKIAlJ TVBPUlRfU0ZVTkMoTmRpc01SZWdpc3RlclVubG9hZEhhbmRsZXIsIDIpLAorCUlNUE9SVF9TRlVO QyhOZGlzR2V0VmVyc2lvbiwgMCksCiAJSU1QT1JUX1NGVU5DKG5kaXNfdGltZXJjYWxsLCA0KSwK IAlJTVBPUlRfU0ZVTkMobmRpc19hc3luY21lbV9jb21wbGV0ZSwgMiksCiAJSU1QT1JUX1NGVU5D KG5kaXNfaW50ciwgMiksCkluZGV4OiBzdWJyX250b3Nrcm5sLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9uZGlzL3N1YnJfbnRvc2tybmwuYyx2CnJldHJp ZXZpbmcgcmV2aXNpb24gMS45MQpkaWZmIC11IC1yMS45MSBzdWJyX250b3Nrcm5sLmMKLS0tIHN1 YnJfbnRvc2tybmwuYwkyMCBPY3QgMjAwNyAyMzoyMzoxMiAtMDAwMAkxLjkxCisrKyBzdWJyX250 b3Nrcm5sLmMJMzEgT2N0IDIwMDcgMDM6MzE6MjQgLTAwMDAKQEAgLTIxOSw2ICsyMTksOCBAQAog c3RhdGljIGludCByYW5kKHZvaWQpOwogc3RhdGljIHZvaWQgc3JhbmQodW5zaWduZWQgaW50KTsK IHN0YXRpYyB2b2lkIG50b3Nrcm5sX3RpbWUodWludDY0X3QgKik7CitzdGF0aWMgdm9pZCBLZVF1 ZXJ5U3lzdGVtVGltZSh1aW50NjRfdCAqKTsKK3N0YXRpYyB1aW50MzJfdCBLZVRpY2tDb3VudCh2 b2lkKTsKIHN0YXRpYyB1aW50OF90IElvSXNXZG1WZXJzaW9uQXZhaWxhYmxlKHVpbnQ4X3QsIHVp bnQ4X3QpOwogc3RhdGljIHZvaWQgbnRvc2tybmxfdGhyZnVuYyh2b2lkICopOwogc3RhdGljIG5k aXNfc3RhdHVzIFBzQ3JlYXRlU3lzdGVtVGhyZWFkKG5kaXNfaGFuZGxlICosCkBAIC0yMjYsNiAr MjI4LDggQEAKIHN0YXRpYyBuZGlzX3N0YXR1cyBQc1Rlcm1pbmF0ZVN5c3RlbVRocmVhZChuZGlz X3N0YXR1cyk7CiBzdGF0aWMgbmRpc19zdGF0dXMgSW9HZXREZXZpY2VQcm9wZXJ0eShkZXZpY2Vf b2JqZWN0ICosIHVpbnQzMl90LAogCXVpbnQzMl90LCB2b2lkICosIHVpbnQzMl90ICopOworc3Rh dGljIHZvaWQgS2VCdWdDaGVja0V4KHVpbnQzMl90ICwgdWludDMyX3QgKiwgdWludDMyX3QgKiwg dWludDMyX3QgKiwKKwl1aW50MzJfdCAqKTsKIHN0YXRpYyB2b2lkIEtlSW5pdGlhbGl6ZU11dGV4 KGttdXRhbnQgKiwgdWludDMyX3QpOwogc3RhdGljIHVpbnQzMl90IEtlUmVsZWFzZU11dGV4KGtt dXRhbnQgKiwgdWludDhfdCk7CiBzdGF0aWMgdWludDMyX3QgS2VSZWFkU3RhdGVNdXRleChrbXV0 YW50ICopOwpAQCAtMjM4LDggKzI0MiwxMCBAQAogc3RhdGljIHVpbnQzMl90IFdtaVRyYWNlTWVz c2FnZSh1aW50NjRfdCwgdWludDMyX3QsIHZvaWQgKiwgdWludDE2X3QsIC4uLik7CiBzdGF0aWMg dWludDMyX3QgSW9XTUlSZWdpc3RyYXRpb25Db250cm9sKGRldmljZV9vYmplY3QgKiwgdWludDMy X3QpOwogc3RhdGljIHZvaWQgKm50b3Nrcm5sX21lbXNldCh2b2lkICosIGludCwgc2l6ZV90KTsK K3N0YXRpYyBpbnQgbnRvc2tybmxfbWVtY21wKHZvaWQgKiwgdm9pZCAqLCBzaXplX3QpOwogc3Rh dGljIHZvaWQgKm50b3Nrcm5sX21lbW1vdmUodm9pZCAqLCB2b2lkICosIHNpemVfdCk7CiBzdGF0 aWMgdm9pZCAqbnRvc2tybmxfbWVtY2hyKHZvaWQgKiwgdW5zaWduZWQgY2hhciwgc2l6ZV90KTsK K3N0YXRpYyBjaGFyICpudG9za3JubF9zdHJuY2F0KGNoYXIgKiwgY2hhciAqLCBzaXplX3QpOwog c3RhdGljIGNoYXIgKm50b3Nrcm5sX3N0cnN0cihjaGFyICosIGNoYXIgKik7CiBzdGF0aWMgaW50 IG50b3Nrcm5sX3RvdXBwZXIoaW50KTsKIHN0YXRpYyBpbnQgbnRvc2tybmxfdG9sb3dlcihpbnQp OwpAQCAtNDI5LDYgKzQzNSwxNiBAQAogCXJldHVybihtZW1zZXQoYnVmLCBjaCwgc2l6ZSkpOwog fQogCisKK3N0YXRpYyBpbnQKK250b3Nrcm5sX21lbWNtcChidWYxLCBidWYyLCBzaXplKQorCXZv aWQJCQkqYnVmMTsKKwl2b2lkCQkJKmJ1ZjI7CisJc2l6ZV90CQkJc2l6ZTsKK3sKKwlyZXR1cm4o bWVtY21wKGJ1ZjEsIGJ1ZjIsIHNpemUpKTsKK30KKwogc3RhdGljIHZvaWQgKgogbnRvc2tybmxf bWVtbW92ZShkc3QsIHNyYywgc2l6ZSkKIAl2b2lkCQkJKnNyYzsKQEAgLTQ1Niw2ICs0NzIsMjkg QEAKIAlyZXR1cm4gKE5VTEwpOwogfQogCisvKiBUYWtlbiBmcm9tIGxpYmMgKi8KK2NoYXIgKgor bnRvc2tybmxfc3RybmNhdChkc3QsIHNyYywgbikKKwljaGFyCQkqZHN0OworCWNoYXIJCSpzcmM7 CisJc2l6ZV90CQluOworeworCWlmIChuICE9IDApIHsKKwkJY2hhciAqZCA9IGRzdDsKKwkJY29u c3QgY2hhciAqcyA9IHNyYzsKKwkJCisJCXdoaWxlICgqZCAhPSAwKQorCQkJZCsrOworCQlkbyB7 CisJCQlpZiAoKCpkID0gKnMrKykgPT0gMCkKKwkJCQlicmVhazsKKwkJCWQrKzsKKwkJfSB3aGls ZSAoLS1uICE9IDApOworCQkqZCA9IDA7CisJfQorCXJldHVybiAoZHN0KTsKK30KKwogc3RhdGlj IGNoYXIgKgogbnRvc2tybmxfc3Ryc3RyKHMsIGZpbmQpCiAJY2hhciAqcywgKmZpbmQ7CkBAIC02 MjQsNiArNjYzLDMxIEBACiB9CiAKIHZvaWQgKgorRXhBbGxvY2F0ZVBvb2wocG9vbHR5cGUsIGxl bikKKwl1aW50MzJfdAkJcG9vbHR5cGU7CisJc2l6ZV90CQkJbGVuOworeworCXJldHVybihFeEFs bG9jYXRlUG9vbFdpdGhUYWcocG9vbHR5cGUsIGxlbiwgMCkpOworfQorCit2b2lkICoKK0V4QWxs b2NhdGVQb29sV2l0aFF1b3RhKHBvb2x0eXBlLCBsZW4pCisJdWludDMyX3QJCXBvb2x0eXBlOwor CXNpemVfdAkJCWxlbjsKK3sKKwlyZXR1cm4oRXhBbGxvY2F0ZVBvb2xXaXRoVGFnKHBvb2x0eXBl LCBsZW4sIDApKTsKK30KKwordm9pZCAqCitFeEFsbG9jYXRlUG9vbFdpdGhRdW90YVRhZyhwb29s dHlwZSwgbGVuLCB0YWcpCisJdWludDMyX3QJCXBvb2x0eXBlOworCXNpemVfdAkJCWxlbjsKKwl1 aW50MzJfdAkJdGFnOworeworCXJldHVybihFeEFsbG9jYXRlUG9vbFdpdGhUYWcocG9vbHR5cGUs IGxlbiwgdGFnKSk7Cit9CisKK3ZvaWQgKgogRXhBbGxvY2F0ZVBvb2xXaXRoVGFnKHBvb2x0eXBl LCBsZW4sIHRhZykKIAl1aW50MzJfdAkJcG9vbHR5cGU7CiAJc2l6ZV90CQkJbGVuOwpAQCAtNjQy LDYgKzcwNiwxNCBAQAogRXhGcmVlUG9vbChidWYpCiAJdm9pZAkJCSpidWY7CiB7CisJRXhGcmVl UG9vbFdpdGhUYWcoYnVmLCAwKTsKK30KKwordm9pZAorRXhGcmVlUG9vbFdpdGhUYWcoYnVmLCB0 YWcpCisJdm9pZAkJCSpidWY7CisJdWludDMyX3QJCXRhZzsKK3sKIAlmcmVlKGJ1ZiwgTV9ERVZC VUYpOwogCXJldHVybjsKIH0KQEAgLTE1ODcsNiArMTY1OSwyMSBAQAogCXJldHVybjsKIH0KIAor c3RhdGljIHZvaWQKK0tlUXVlcnlTeXN0ZW1UaW1lKGN1cnJlbnRfdGltZSkKKwl1aW50NjRfdAkJ KmN1cnJlbnRfdGltZTsKK3sKKwludG9za3JubF90aW1lKGN1cnJlbnRfdGltZSk7Cit9CisKK3N0 YXRpYyB1aW50MzJfdAorS2VUaWNrQ291bnQodm9pZCkKK3sKKwlzdHJ1Y3QgdGltZXZhbCB0djsK KwlnZXRtaWNyb3VwdGltZSgmdHYpOworCXJldHVybiB0dnRvaHooJnR2KTsKK30KKwogLyoKICAq IEtlV2FpdEZvclNpbmdsZU9iamVjdCgpIGlzIGEgdHJpY2t5IGJlYXN0LCBiZWNhdXNlIGl0IGNh biBiZSB1c2VkCiAgKiB3aXRoIHNldmVyYWwgZGlmZmVyZW50IG9iamVjdCB0eXBlczogc2VtYXBo b3JlcywgdGltZXJzLCBldmVudHMsCkBAIC0yMzE2LDYgKzI0MDMsMjIgQEAKIH0KIAogdm9pZAor S2VCdWdDaGVja0V4KGJ1Z2NoZWNrLCBwYXJhbTEsIHBhcmFtMiwgcGFyYW0zLCBwYXJhbTQpCisJ dWludDMyX3QJCWJ1Z2NoZWNrOworCXVpbnQzMl90CQkqcGFyYW0xOworCXVpbnQzMl90CQkqcGFy YW0yOworCXVpbnQzMl90CQkqcGFyYW0zOworCXVpbnQzMl90CQkqcGFyYW00OworeworCS8qIGh0 dHA6Ly9tc2RuMi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvbXM4MDE2NDUuYXNweCAqLwor CisJcGFuaWMoIktlQnVnQ2hlY2tFeDogU1RPUDogJSMwOHgsICglOHAsICU4cCwgJThwLCAlOHAp IiwKKwkJYnVnY2hlY2ssIHBhcmFtMSwgcGFyYW0yLCBwYXJhbTMsIHBhcmFtNCk7CisKKyAgICAg ICAgcmV0dXJuOworfQorCit2b2lkCiBLZUluaXRpYWxpemVTcGluTG9jayhsb2NrKQogCWtzcGlu X2xvY2sJCSpsb2NrOwogewpAQCAtMjgxNCw3ICsyOTE3LDcgQEAKIAlmb3IgKGkgPSAwOyBpIDwg V09SS0lURU1fVEhSRUFEUzsgaSsrKSB7CiAJCWtxID0gd3FfcXVldWVzICsgaTsKIAkJa3EtPmtx X2V4aXQgPSAxOwotCQlLZVNldEV2ZW50KCZrcS0+a3FfcHJvYywgSU9fTk9fSU5DUkVNRU5ULCBG QUxTRSk7CQorCQlLZVNldEV2ZW50KCZrcS0+a3FfcHJvYywgSU9fTk9fSU5DUkVNRU5ULCBGQUxT RSk7CiAJCXdoaWxlIChrcS0+a3FfZXhpdCkKIAkJCXRzbGVlcChrcS0+a3FfdGQtPnRkX3Byb2Ms IFBXQUlULCAid2FpdGl3IiwgaHovMTApOwogCX0KQEAgLTMxODIsNyArMzI4NSwxMCBAQAogCXVp bnQ4X3QJCQltYWpvcjsKIAl1aW50OF90CQkJbWlub3I7CiB7Ci0JaWYgKG1ham9yID09IFdETV9N QUpPUiAmJiBtaW5vciA9PSBXRE1fTUlOT1JfV0lOWFApCisJaWYgKG1ham9yID09IFdETV9NQUpP UiAmJiAKKwkgICAobWlub3IgPT0gV0RNX01JTk9SX1dJTjIwMDMJfHwJLyogV2luZG93cyAyMDAz ICovCisJICAgIG1pbm9yID09IFdETV9NSU5PUl9XSU5YUAl8fAkvKiBXaW5kb3dzIFhQICovCisJ ICAgIG1pbm9yID09IFdETV9NSU5PUl9XSU4yMDAwKSkJLyogV2luZG93cyAyMDAwICovCiAJCXJl dHVybihUUlVFKTsKIAlyZXR1cm4oRkFMU0UpOwogfQpAQCAtNDIxOCw2ICs0MzI0LDcgQEAKIAlJ TVBPUlRfQ0ZVTkMoc3RybmNtcCwgMCksCiAJSU1QT1JUX0NGVU5DKHN0cmNtcCwgMCksCiAJSU1Q T1JUX0NGVU5DX01BUChzdHJpY21wLCBzdHJjYXNlY21wLCAwKSwKKwlJTVBPUlRfQ0ZVTkNfTUFQ KHN0cm5jYXQsIG50b3Nrcm5sX3N0cm5jYXQsIDApLAogCUlNUE9SVF9DRlVOQyhzdHJuY3B5LCAw KSwKIAlJTVBPUlRfQ0ZVTkMoc3RyY3B5LCAwKSwKIAlJTVBPUlRfQ0ZVTkMoc3RybGVuLCAwKSwK QEAgLTQyMjksNiArNDMzNiw3IEBACiAJSU1QT1JUX0NGVU5DKG1lbWNweSwgMCksCiAJSU1QT1JU X0NGVU5DX01BUChtZW1tb3ZlLCBudG9za3JubF9tZW1tb3ZlLCAwKSwKIAlJTVBPUlRfQ0ZVTkNf TUFQKG1lbXNldCwgbnRvc2tybmxfbWVtc2V0LCAwKSwKKwlJTVBPUlRfQ0ZVTkNfTUFQKG1lbWNt cCwgbnRvc2tybmxfbWVtY21wLCAwKSwKIAlJTVBPUlRfQ0ZVTkNfTUFQKG1lbWNociwgbnRvc2ty bmxfbWVtY2hyLCAwKSwKIAlJTVBPUlRfU0ZVTkMoSW9BbGxvY2F0ZURyaXZlck9iamVjdEV4dGVu c2lvbiwgNCksCiAJSU1QT1JUX1NGVU5DKElvR2V0RHJpdmVyT2JqZWN0RXh0ZW5zaW9uLCAyKSwK QEAgLTQyOTAsOCArNDM5OCwxMiBAQAogCQlJbnRlcmxvY2tlZFB1c2hFbnRyeVNMaXN0LCAyKSwK IAlJTVBPUlRfRkZVTkMoRXhJbnRlcmxvY2tlZFBvcEVudHJ5U0xpc3QsIDIpLAogCUlNUE9SVF9G RlVOQyhFeEludGVybG9ja2VkUHVzaEVudHJ5U0xpc3QsIDMpLAorCUlNUE9SVF9TRlVOQyhFeEFs bG9jYXRlUG9vbCwgMiksCisJSU1QT1JUX1NGVU5DKEV4QWxsb2NhdGVQb29sV2l0aFF1b3RhLCAy KSwKKwlJTVBPUlRfU0ZVTkMoRXhBbGxvY2F0ZVBvb2xXaXRoUXVvdGFUYWcsIDMpLAogCUlNUE9S VF9TRlVOQyhFeEFsbG9jYXRlUG9vbFdpdGhUYWcsIDMpLAogCUlNUE9SVF9TRlVOQyhFeEZyZWVQ b29sLCAxKSwKKwlJTVBPUlRfU0ZVTkMoRXhGcmVlUG9vbFdpdGhUYWcsIDIpLAogI2lmZGVmIF9f aTM4Nl9fCiAJSU1QT1JUX0ZGVU5DKEtlZkFjcXVpcmVTcGluTG9ja0F0RHBjTGV2ZWwsIDEpLAog CUlNUE9SVF9GRlVOQyhLZWZSZWxlYXNlU3BpbkxvY2tGcm9tRHBjTGV2ZWwsMSksCkBAIC00MzM2 LDYgKzQ0NDgsNyBAQAogCUlNUE9SVF9TRlVOQyhJb1F1ZXVlV29ya0l0ZW0sIDQpLAogCUlNUE9S VF9TRlVOQyhFeFF1ZXVlV29ya0l0ZW0sIDIpLAogCUlNUE9SVF9TRlVOQyhudG9za3JubF93b3Jr aXRlbSwgMiksCisJSU1QT1JUX1NGVU5DKEtlQnVnQ2hlY2tFeCwgNSksCiAJSU1QT1JUX1NGVU5D KEtlSW5pdGlhbGl6ZU11dGV4LCAyKSwKIAlJTVBPUlRfU0ZVTkMoS2VSZWxlYXNlTXV0ZXgsIDIp LAogCUlNUE9SVF9TRlVOQyhLZVJlYWRTdGF0ZU11dGV4LCAxKSwKQEAgLTQzNjUsNiArNDQ3OCw4 IEBACiAJSU1QT1JUX1NGVU5DKElvV01JUmVnaXN0cmF0aW9uQ29udHJvbCwgMiksCiAJSU1QT1JU X1NGVU5DKFdtaVF1ZXJ5VHJhY2VJbmZvcm1hdGlvbiwgNSksCiAJSU1QT1JUX0NGVU5DKFdtaVRy YWNlTWVzc2FnZSwgMCksCisJSU1QT1JUX1NGVU5DKEtlUXVlcnlTeXN0ZW1UaW1lLCAxKSwKKwlJ TVBPUlRfQ0ZVTkMoS2VUaWNrQ291bnQsIDApLAogCiAJLyoKIAkgKiBUaGlzIGxhc3QgZW50cnkg aXMgYSBjYXRjaC1hbGwgZm9yIGFueSBmdW5jdGlvbiB3ZSBoYXZlbid0Cg== ------=_Part_4198_9968625.1193803018076-- From owner-freebsd-mobile@FreeBSD.ORG Wed Oct 31 09:55:22 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E692F16A41B for ; Wed, 31 Oct 2007 09:55:21 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33713.mail.mud.yahoo.com (web33713.mail.mud.yahoo.com [68.142.201.210]) by mx1.freebsd.org (Postfix) with SMTP id 915AF13C4B7 for ; Wed, 31 Oct 2007 09:55:21 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 37045 invoked by uid 60001); 31 Oct 2007 09:54:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=4Ajmr6UeBaT0tMLcuzk3lFv91Dq8DqD4LADhuYpVplskx4lv3zYjqptzJB/NcIGnzrere0T3J8ANKgt+uK9OxB/IkO8EOHQbSuuPlP3YhZzRUlkfwGhR1sw/SQSXYzxK/37tL8mi33M3HcSpi+gbLjUNydw5TKIYVwNvqGsxSXw=; X-YMail-OSG: YWySVHAVM1lYNjADl_mWf1X6LucujWUkCLw1NMLL9TzlIKXRl7foz7g_VW2YUeQWWQ3CXA2Xzwzmo4JxD4V5g2E0xhLJcUutkmpXRW.UH8tW8b0rpZA- Received: from [212.77.203.38] by web33713.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2007 02:54:44 PDT X-Mailer: YahooMailRC/814.06 YahooMailWebService/0.7.134.12 Date: Wed, 31 Oct 2007 02:54:44 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: Scot Hetzel , Marcin Simonides MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <322454.36756.qm@web33713.mail.mud.yahoo.com> Cc: freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 09:55:22 -0000 =0A----- Original Message ----=0A=0AFrom: Scot Hetzel = =0A=0ATo: Mike Pumford =0A=0ACc: freebsd-mobile@fr= eebsd.org; freebsd-stable@freebsd.org; Abdullah Ibn Hamad Al-Marri =0A=0ASent: Wednesday, October 31, 2007 6:56:58 AM=0A=0ASubject= : Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure=0A=0A=0A=0A On 10= /30/07, Mike Pumford wrote:=0A=0A> Abdullah Ibn H= amad Al-Marri wrote:=0A=0A>=0A=0A> >=0A=0A> > Previously I didn't mention t= hat there are some functions missing from=0A=0A> >=0A=0A> > the FreeBSD's = NDIS api. These are:=0A=0A> >=0A=0A> > With the help of NDIS reference and = Linux ndiswrapper I have been able=0A=0A> >=0A=0A> > to implement all but = KeBugCheckEx (they are all rather simple but I=0A=0A> >=0A=0A> Can help you= with this one. This is the Windows equivalent of panic().=0A=0A> So just = call panic with an appropriate string. If the string includes=0A=0A> the bu= gcheck code and parameters so much the better.=0A=0A>=0A=0AThanks for your = hint to use panic() in the KeBugCheckEx function.=0A=0AI have KeBugCheckEx = partially implemented. It currently prints the=0A=0Abugcheck code=0A=0Aand= the 4 paramators that are sent to KeBugCheckEx.=0A=0A=0A=0AThe KeBugCheckE= x function still needs to be changed to display=0A=0Athe right information = depending on the bugcheck code.=0A=0A=0A=0A=0A=0A=0A=0AAbdullah, I made a m= inor change to your patch, strncat should be=0A=0Aprefixed with ntoskrnl_st= rncat.=0A=0Achanged IMPORT_CFUNC(strncat..) to IMPORT_CFUNC_MAP(ntoskrnl_s= trncat..).=0A=0A=0A=0AScot=0A=0A=0A=0A=0A=0A-----Inline Attachment Follows-= ----=0A=0A=0A=0AIndex: ndis_var.h=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A=0ARCS file: /home/ncvs/src/sys/compat/ndis/ndis_var.h,v= =0A=0Aretrieving revision 1.47=0A=0Adiff -u -r1.47 ndis_var.h=0A=0A--- ndis= _var.h 6 Apr 2007 11:18:57 -0000 1.47=0A=0A+++ ndis_var.h 31 Oct 2= 007 03:31:24 -0000=0A=0A@@ -49,6 +49,10 @@=0A=0A typedef register_t ndis_ks= pin_lock;=0A=0A typedef uint8_t ndis_kirql;=0A=0A =0A=0A+/* Version of NDIS= supported by FreeBSD */=0A=0A+#define NDIS_VERSION_51 0x0005= 0001=0A=0A+#define NDIS_VERSION NDIS_VERSION_51=0A=0A+=0A=0A = /*=0A=0A * NDIS status codes (there are lots of them). The ones that=0A=0A= * don't seem to fit the pattern are actually mapped to generic=0A=0AIndex= : ntoskrnl_var.h=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =0A=0ARCS file: /home/ncvs/src/sys/compat/ndis/ntoskrnl_var.h,v=0A=0Aretrie= ving revision 1.43=0A=0Adiff -u -r1.43 ntoskrnl_var.h=0A=0A--- ntoskrnl_var= .h 17 Aug 2006 22:50:32 -0000 1.43=0A=0A+++ ntoskrnl_var.h 31 Oct = 2007 03:31:24 -0000=0A=0A@@ -1202,14 +1202,22 @@=0A=0A =0A=0A /* Memory poo= l types, for ExAllocatePoolWithTag() */=0A=0A =0A=0A-#define NonPagedPool = 0x00000000=0A=0A-#define PagedPool 0x00000001=0A=0A-#d= efine NonPagedPoolMustSucceed 0x00000002=0A=0A-#define DontUseThisTy= pe 0x00000003=0A=0A-#define NonPagedPoolCacheAligned 0x000000= 04=0A=0A-#define PagedPoolCacheAligned 0x00000005=0A=0A-#define NonP= agedPoolCacheAlignedMustS 0x00000006=0A=0A-#define MaxPoolType = 0x00000007=0A=0A+#define NonPagedPool 0x00000000=0A=0A+= #define PagedPool 0x00000001=0A=0A+#define NonPagedPoo= lMustSucceed 0x00000002=0A=0A+#define DontUseThisType = 0x00000003=0A=0A+#define NonPagedPoolCacheAligned 0x00000= 004=0A=0A+#define PagedPoolCacheAligned 0x00000005=0A=0A+#def= ine NonPagedPoolCacheAlignedMustS 0x00000006=0A=0A+#define Max= PoolType 0x00000007=0A=0A+=0A=0A+#define NonPagedPoolSess= ion 0x00000020=0A=0A+#define PagedPoolSession 0x00= 000021=0A=0A+#define NonPagedPoolMustSucceedSession 0x00000022=0A= =0A+#define DontUseThisTypeSession 0x00000023=0A=0A+#define = NonPagedPoolCacheAlignedSession 0x00000024=0A=0A+#define PagedP= oolCacheAlignedSession 0x00000025=0A=0A+#define NonPagedPoolCache= AlignedMustSSession 0x00000026=0A=0A =0A=0A /*=0A=0A * IO_WORKITEM is a= n opaque structures that must be allocated=0A=0A@@ -1357,8 +1365,12 @@=0A= =0A extern uint8_t KeSynchronizeExecution(kinterrupt *, void *, void *);=0A= =0A extern uintptr_t InterlockedExchange(volatile uint32_t *,=0A=0A uin= tptr_t);=0A=0A+extern void *ExAllocatePool(uint32_t, size_t);=0A=0A+extern = void *ExAllocatePoolWithQuota(uint32_t, size_t);=0A=0A+extern void *ExAlloc= atePoolWithQuotaTag(uint32_t, size_t, uint32_t);=0A=0A extern void *ExAlloc= atePoolWithTag(uint32_t, size_t, uint32_t);=0A=0A extern void ExFreePool(vo= id *);=0A=0A+extern void ExFreePoolWithTag(void *, uint32_t);=0A=0A extern = uint32_t IoConnectInterrupt(kinterrupt **, void *, void *,=0A=0A kspin_= lock *, uint32_t, uint8_t, uint8_t, uint8_t, uint8_t,=0A=0A uint32_t, u= int8_t);=0A=0AIndex: subr_ndis.c=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A=0ARCS file: /home/ncvs/src/sys/compat/ndis/subr_ndis.c,v= =0A=0Aretrieving revision 1.108=0A=0Adiff -u -r1.108 subr_ndis.c=0A=0A--- s= ubr_ndis.c 31 May 2007 11:51:49 -0000 1.108=0A=0A+++ subr_ndis.c 3= 1 Oct 2007 03:31:24 -0000=0A=0A@@ -272,6 +272,7 @@=0A=0A static void NdisUn= mapFile(ndis_handle);=0A=0A static void NdisCloseFile(ndis_handle);=0A=0A s= tatic uint8_t NdisSystemProcessorCount(void);=0A=0A+static void NdisGetCurr= entProcessorCounts(uint32_t *, uint32_t *, uint32_t*);=0A=0A static void N= disMIndicateStatusComplete(ndis_handle);=0A=0A static void NdisMIndicateSta= tus(ndis_handle, ndis_status,=0A=0A void *, uint32_t);=0A=0A@@ -282= ,6 +283,7 @@=0A=0A uint32_t, uint32_t, ndis_packet *, uint32_t, uint32_= t *);=0A=0A static void NdisCopyFromPacketToPacketSafe(ndis_packet *,=0A=0A= uint32_t, uint32_t, ndis_packet *, uint32_t, uint32_t *, uint32_t);= =0A=0A+static void NdisIMCopySendPerPacketInfo(ndis_packet *, ndis_packet *= );=0A=0A static ndis_status NdisMRegisterDevice(ndis_handle,=0A=0A unic= ode_string *, unicode_string *, driver_dispatch **,=0A=0A void **, ndis= _handle *);=0A=0A@@ -3115,6 +3117,20 @@=0A=0A return(mp_ncpus);=0A=0A }= =0A=0A =0A=0A+static void=0A=0A+NdisGetCurrentProcessorCounts(idlecount, ke= rneluser, index)=0A=0A+ uint32_t *idlecount;=0A=0A+ uint32_t = *kerneluser;=0A=0A+ uint32_t *index;=0A=0A+{=0A=0A+ int = cpu =3D 0; /* Current CPU */=0A=0A+=0A=0A+ *idlecount =3D cp_time[CP_IDL= E];=0A=0A+ *kerneluser =3D (cp_time[CP_USER] + cp_time[CP_NICE]) + \= =0A=0A+ (cp_time[CP_SYS] + cp_time[CP_INTR]);=0A=0A+ *index = =3D cpu;=0A=0A+}=0A=0A+=0A=0A typedef void (*ndis_statusdone_handler)(ndis_= handle);=0A=0A typedef void (*ndis_status_handler)(ndis_handle, ndis_status= ,=0A=0A void *, uint32_t);=0A=0A@@ -3288,6 +3304,14 @@=0A=0A re= turn;=0A=0A }=0A=0A =0A=0A+static void=0A=0A+NdisIMCopySendPerPacketInfo(dp= kt, spkt)=0A=0A+ ndis_packet *dpkt;=0A=0A+ ndis_packet = *spkt;=0A=0A+{=0A=0A+ memcpy(&dpkt->np_ext, &spkt->np_ext, sizeof(ndis_= packet_extension));=0A=0A+}=0A=0A+=0A=0A static ndis_status=0A=0A NdisMRegi= sterDevice(handle, devname, symname, majorfuncs, devobj, devhandle)=0A=0A = ndis_handle handle;=0A=0A@@ -3346,6 +3370,12 @@=0A=0A return= ;=0A=0A }=0A=0A =0A=0A+static uint32_t=0A=0A+NdisGetVersion()=0A=0A+{=0A=0A= + return(NDIS_VERSION);=0A=0A+}=0A=0A+=0A=0A static void=0A=0A dummy()= =0A=0A {=0A=0A@@ -3365,10 +3395,12 @@=0A=0A image_patch_table ndis_functbl[= ] =3D {=0A=0A IMPORT_SFUNC(NdisCopyFromPacketToPacket, 6),=0A=0A IM= PORT_SFUNC(NdisCopyFromPacketToPacketSafe, 7),=0A=0A+ IMPORT_SFUNC(NdisI= MCopySendPerPacketInfo, 2),=0A=0A IMPORT_SFUNC(NdisScheduleWorkItem, 1)= ,=0A=0A IMPORT_SFUNC(NdisMIndicateStatusComplete, 1),=0A=0A IMPORT_= SFUNC(NdisMIndicateStatus, 4),=0A=0A IMPORT_SFUNC(NdisSystemProcessorCo= unt, 0),=0A=0A+ IMPORT_SFUNC(NdisGetCurrentProcessorCounts, 3),=0A=0A = IMPORT_SFUNC(NdisUnchainBufferAtBack, 2),=0A=0A IMPORT_SFUNC(NdisGetF= irstBufferFromPacket, 5),=0A=0A IMPORT_SFUNC(NdisGetFirstBufferFromPack= etSafe, 6),=0A=0A@@ -3482,6 +3514,7 @@=0A=0A IMPORT_SFUNC(NdisMDeregist= erDevice, 1),=0A=0A IMPORT_SFUNC(NdisMQueryAdapterInstanceName, 2),=0A= =0A IMPORT_SFUNC(NdisMRegisterUnloadHandler, 2),=0A=0A+ IMPORT_SFUNC= (NdisGetVersion, 0),=0A=0A IMPORT_SFUNC(ndis_timercall, 4),=0A=0A I= MPORT_SFUNC(ndis_asyncmem_complete, 2),=0A=0A IMPORT_SFUNC(ndis_intr, 2= ),=0A=0AIndex: subr_ntoskrnl.c=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A=0ARCS file: /home/ncvs/src/sys/compat/ndis/subr_ntoskrnl.c,= v=0A=0Aretrieving revision 1.91=0A=0Adiff -u -r1.91 subr_ntoskrnl.c=0A=0A--= - subr_ntoskrnl.c 20 Oct 2007 23:23:12 -0000 1.91=0A=0A+++ subr_ntosk= rnl.c 31 Oct 2007 03:31:24 -0000=0A=0A@@ -219,6 +219,8 @@=0A=0A static i= nt rand(void);=0A=0A static void srand(unsigned int);=0A=0A static void nto= skrnl_time(uint64_t *);=0A=0A+static void KeQuerySystemTime(uint64_t *);=0A= =0A+static uint32_t KeTickCount(void);=0A=0A static uint8_t IoIsWdmVersionA= vailable(uint8_t, uint8_t);=0A=0A static void ntoskrnl_thrfunc(void *);=0A= =0A static ndis_status PsCreateSystemThread(ndis_handle *,=0A=0A@@ -226,6 += 228,8 @@=0A=0A static ndis_status PsTerminateSystemThread(ndis_status);=0A= =0A static ndis_status IoGetDeviceProperty(device_object *, uint32_t,=0A=0A= uint32_t, void *, uint32_t *);=0A=0A+static void KeBugCheckEx(uint32_t= , uint32_t *, uint32_t *, uint32_t *,=0A=0A+ uint32_t *);=0A=0A static= void KeInitializeMutex(kmutant *, uint32_t);=0A=0A static uint32_t KeRelea= seMutex(kmutant *, uint8_t);=0A=0A static uint32_t KeReadStateMutex(kmutant= *);=0A=0A@@ -238,8 +242,10 @@=0A=0A static uint32_t WmiTraceMessage(uint64= _t, uint32_t, void *, uint16_t, ...);=0A=0A static uint32_t IoWMIRegistrat= ionControl(device_object *, uint32_t);=0A=0A static void *ntoskrnl_memset(v= oid *, int, size_t);=0A=0A+static int ntoskrnl_memcmp(void *, void *, size_= t);=0A=0A static void *ntoskrnl_memmove(void *, void *, size_t);=0A=0A stat= ic void *ntoskrnl_memchr(void *, unsigned char, size_t);=0A=0A+static char = *ntoskrnl_strncat(char *, char *, size_t);=0A=0A static char *ntoskrnl_strs= tr(char *, char *);=0A=0A static int ntoskrnl_toupper(int);=0A=0A static in= t ntoskrnl_tolower(int);=0A=0A@@ -429,6 +435,16 @@=0A=0A return(memset(= buf, ch, size));=0A=0A }=0A=0A =0A=0A+=0A=0A+static int=0A=0A+ntoskrnl_memc= mp(buf1, buf2, size)=0A=0A+ void *buf1;=0A=0A+ void = *buf2;=0A=0A+ size_t size;=0A=0A+{=0A=0A+ return(memc= mp(buf1, buf2, size));=0A=0A+}=0A=0A+=0A=0A static void *=0A=0A ntoskrnl_me= mmove(dst, src, size)=0A=0A void *src;=0A=0A@@ -456,6 +472,2= 9 @@=0A=0A return (NULL);=0A=0A }=0A=0A =0A=0A+/* Taken from libc */=0A= =0A+char *=0A=0A+ntoskrnl_strncat(dst, src, n)=0A=0A+ char *dst;= =0A=0A+ char *src;=0A=0A+ size_t n;=0A=0A+{=0A=0A+ i= f (n !=3D 0) {=0A=0A+ char *d =3D dst;=0A=0A+ const char *s = =3D src;=0A=0A+ =0A=0A+ while (*d !=3D 0)=0A=0A+ d= ++;=0A=0A+ do {=0A=0A+ if ((*d =3D *s++) =3D=3D 0)=0A=0A+= break;=0A=0A+ d++;=0A=0A+ } while (--n != =3D 0);=0A=0A+ *d =3D 0;=0A=0A+ }=0A=0A+ return (dst);=0A=0A+}= =0A=0A+=0A=0A static char *=0A=0A ntoskrnl_strstr(s, find)=0A=0A char *= s, *find;=0A=0A@@ -624,6 +663,31 @@=0A=0A }=0A=0A =0A=0A void *=0A=0A+ExAll= ocatePool(pooltype, len)=0A=0A+ uint32_t pooltype;=0A=0A+ size= _t len;=0A=0A+{=0A=0A+ return(ExAllocatePoolWithTag(pooltype,= len, 0));=0A=0A+}=0A=0A+=0A=0A+void *=0A=0A+ExAllocatePoolWithQuota(poolty= pe, len)=0A=0A+ uint32_t pooltype;=0A=0A+ size_t le= n;=0A=0A+{=0A=0A+ return(ExAllocatePoolWithTag(pooltype, len, 0));=0A=0A= +}=0A=0A+=0A=0A+void *=0A=0A+ExAllocatePoolWithQuotaTag(pooltype, len, tag)= =0A=0A+ uint32_t pooltype;=0A=0A+ size_t len;=0A=0A= + uint32_t tag;=0A=0A+{=0A=0A+ return(ExAllocatePoolWithTag(po= oltype, len, tag));=0A=0A+}=0A=0A+=0A=0A+void *=0A=0A ExAllocatePoolWithTag= (pooltype, len, tag)=0A=0A uint32_t pooltype;=0A=0A size_t = len;=0A=0A@@ -642,6 +706,14 @@=0A=0A ExFreePool(buf)=0A=0A vo= id *buf;=0A=0A {=0A=0A+ ExFreePoolWithTag(buf, 0);=0A=0A+}=0A= =0A+=0A=0A+void=0A=0A+ExFreePoolWithTag(buf, tag)=0A=0A+ void = *buf;=0A=0A+ uint32_t tag;=0A=0A+{=0A=0A free(buf, M_DEVBUF)= ;=0A=0A return;=0A=0A }=0A=0A@@ -1587,6 +1659,21 @@=0A=0A return;= =0A=0A }=0A=0A =0A=0A+static void=0A=0A+KeQuerySystemTime(current_time)=0A= =0A+ uint64_t *current_time;=0A=0A+{=0A=0A+ ntoskrnl_time(curr= ent_time);=0A=0A+}=0A=0A+=0A=0A+static uint32_t=0A=0A+KeTickCount(void)=0A= =0A+{=0A=0A+ struct timeval tv;=0A=0A+ getmicrouptime(&tv);=0A=0A+ = return tvtohz(&tv);=0A=0A+}=0A=0A+=0A=0A /*=0A=0A * KeWaitForSingleObject= () is a tricky beast, because it can be used=0A=0A * with several differen= t object types: semaphores, timers, events,=0A=0A@@ -2316,6 +2403,22 @@=0A= =0A }=0A=0A =0A=0A void=0A=0A+KeBugCheckEx(bugcheck, param1, param2, param3= , param4)=0A=0A+ uint32_t bugcheck;=0A=0A+ uint32_t *pa= ram1;=0A=0A+ uint32_t *param2;=0A=0A+ uint32_t *param3;= =0A=0A+ uint32_t *param4;=0A=0A+{=0A=0A+ /* http://msdn2.micro= soft.com/en-us/library/ms801645.aspx */=0A=0A+=0A=0A+ panic("KeBugCheckE= x: STOP: %#08x, (%8p, %8p, %8p, %8p)",=0A=0A+ bugcheck, param1, para= m2, param3, param4);=0A=0A+=0A=0A+ return;=0A=0A+}=0A=0A+=0A=0A+void= =0A=0A KeInitializeSpinLock(lock)=0A=0A kspin_lock *lock;=0A=0A = {=0A=0A@@ -2814,7 +2917,7 @@=0A=0A for (i =3D 0; i < WORKITEM_THREADS; = i++) {=0A=0A kq =3D wq_queues + i;=0A=0A kq->kq_exit =3D 1;= =0A=0A- KeSetEvent(&kq->kq_proc, IO_NO_INCREMENT, FALSE); =0A=0A+= KeSetEvent(&kq->kq_proc, IO_NO_INCREMENT, FALSE);=0A=0A whi= le (kq->kq_exit)=0A=0A tsleep(kq->kq_td->td_proc, PWAIT, "waiti= w", hz/10);=0A=0A }=0A=0A@@ -3182,7 +3285,10 @@=0A=0A uint8_t = major;=0A=0A uint8_t minor;=0A=0A {=0A=0A- if (majo= r =3D=3D WDM_MAJOR && minor =3D=3D WDM_MINOR_WINXP)=0A=0A+ if (major =3D= =3D WDM_MAJOR && =0A=0A+ (minor =3D=3D WDM_MINOR_WIN2003 || /* = Windows 2003 */=0A=0A+ minor =3D=3D WDM_MINOR_WINXP || /* Wind= ows XP */=0A=0A+ minor =3D=3D WDM_MINOR_WIN2000)) /* Windows 2000= */=0A=0A return(TRUE);=0A=0A return(FALSE);=0A=0A }=0A=0A@@ -4= 218,6 +4324,7 @@=0A=0A IMPORT_CFUNC(strncmp, 0),=0A=0A IMPORT_CFUNC= (strcmp, 0),=0A=0A IMPORT_CFUNC_MAP(stricmp, strcasecmp, 0),=0A=0A+ = IMPORT_CFUNC_MAP(strncat, ntoskrnl_strncat, 0),=0A=0A IMPORT_CFUNC(strn= cpy, 0),=0A=0A IMPORT_CFUNC(strcpy, 0),=0A=0A IMPORT_CFUNC(strlen, = 0),=0A=0A@@ -4229,6 +4336,7 @@=0A=0A IMPORT_CFUNC(memcpy, 0),=0A=0A = IMPORT_CFUNC_MAP(memmove, ntoskrnl_memmove, 0),=0A=0A IMPORT_CFUNC_MAP= (memset, ntoskrnl_memset, 0),=0A=0A+ IMPORT_CFUNC_MAP(memcmp, ntoskrnl_m= emcmp, 0),=0A=0A IMPORT_CFUNC_MAP(memchr, ntoskrnl_memchr, 0),=0A=0A = IMPORT_SFUNC(IoAllocateDriverObjectExtension, 4),=0A=0A IMPORT_SFUNC(= IoGetDriverObjectExtension, 2),=0A=0A@@ -4290,8 +4398,12 @@=0A=0A I= nterlockedPushEntrySList, 2),=0A=0A IMPORT_FFUNC(ExInterlockedPopEntryS= List, 2),=0A=0A IMPORT_FFUNC(ExInterlockedPushEntrySList, 3),=0A=0A+ = IMPORT_SFUNC(ExAllocatePool, 2),=0A=0A+ IMPORT_SFUNC(ExAllocatePoolWith= Quota, 2),=0A=0A+ IMPORT_SFUNC(ExAllocatePoolWithQuotaTag, 3),=0A=0A = IMPORT_SFUNC(ExAllocatePoolWithTag, 3),=0A=0A IMPORT_SFUNC(ExFreePool,= 1),=0A=0A+ IMPORT_SFUNC(ExFreePoolWithTag, 2),=0A=0A #ifdef __i386__=0A= =0A IMPORT_FFUNC(KefAcquireSpinLockAtDpcLevel, 1),=0A=0A IMPORT_FFU= NC(KefReleaseSpinLockFromDpcLevel,1),=0A=0A@@ -4336,6 +4448,7 @@=0A=0A = IMPORT_SFUNC(IoQueueWorkItem, 4),=0A=0A IMPORT_SFUNC(ExQueueWorkItem, 2= ),=0A=0A IMPORT_SFUNC(ntoskrnl_workitem, 2),=0A=0A+ IMPORT_SFUNC(KeB= ugCheckEx, 5),=0A=0A IMPORT_SFUNC(KeInitializeMutex, 2),=0A=0A IMPO= RT_SFUNC(KeReleaseMutex, 2),=0A=0A IMPORT_SFUNC(KeReadStateMutex, 1),= =0A=0A@@ -4365,6 +4478,8 @@=0A=0A IMPORT_SFUNC(IoWMIRegistrationControl= , 2),=0A=0A IMPORT_SFUNC(WmiQueryTraceInformation, 5),=0A=0A IMPORT= _CFUNC(WmiTraceMessage, 0),=0A=0A+ IMPORT_SFUNC(KeQuerySystemTime, 1),= =0A=0A+ IMPORT_CFUNC(KeTickCount, 0),=0A=0A =0A=0A /*=0A=0A * T= his last entry is a catch-all for any function we haven't=0A=0A=0A=0A=0A=0A= =0A=0A-----Inline Attachment Follows-----=0A=0A=0A=0A____________=0A=0A=0AH= ello Marcin,=0A=0ACould you please try this patch which modified by Mr. Sco= t Hetzel please?=0A=0A=0A=0A-- =0A=0ARegards, =0A=0A-Abdullah Ibn Hamad Al-= Marri=0A=0AArab Portal=0A=0Ahttp://www.WeArab.Net/=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A__________________________________________________=0ADo You Yahoo!= ?=0ATired of spam? Yahoo! Mail has the best spam protection around =0Ahttp= ://mail.yahoo.com From owner-freebsd-mobile@FreeBSD.ORG Wed Oct 31 15:46:41 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F22F16A417 for ; Wed, 31 Oct 2007 15:46:41 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by mx1.freebsd.org (Postfix) with ESMTP id D82D813C494 for ; Wed, 31 Oct 2007 15:46:40 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-msk-nat.sw.ru [195.214.232.10]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id l9VEF0BL004166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Oct 2007 17:15:01 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InELU-000P69-8a for freebsd-mobile@freebsd.org; Wed, 31 Oct 2007 17:15:00 +0300 From: Vladimir Grebenschikov To: freebsd-mobile Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Wed, 31 Oct 2007 17:14:59 +0300 Message-Id: <1193840099.95027.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Subject: Potential hardware issue with too often HDD heads parking X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 15:46:41 -0000 Hi Probably does not related to FreeBSD, but anybody may confirm that FreeBSD laptops are not affected ? https://launchpad.net/bug59695.html > When switching to battery power, /etc/acpi/power.sh issues the command > hdparm -B 1 to all block devices. This leads to extremely frequent > load cycles. For example, my new thinkpad has already done well over > 7000 load cycles -- in only 100 hours. That's at least one unloading > per minute. Googling for "load unload cycles notebook OR laptop" shows > that most laptop drives handle up to 600,000 such cycles. As these > values clearly show, this issue is of high importance and should be > fixed sooner rather than later. > > Please see for yourself how often your drive is load cycling: > smartctl -d ata -a /dev/sda > (This command is for an SATA drive; you'll need to install the > smartmontools package first.) > > See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a > rather dramatic account of the effects the current default values may > have. > > Just in case the load/unload timeout depends on the specific laptop or > disk model, here are my system specifications: > ThinkPad Z60m & Hitachi HTS541080G9SA00 disk (80GB) -- Vladimir B. Grebenschikov SWsoft Inc. vova@swsoft.com From owner-freebsd-mobile@FreeBSD.ORG Wed Oct 31 17:44:18 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC1B16A41B for ; Wed, 31 Oct 2007 17:44:18 +0000 (UTC) (envelope-from Tad1214@aol.com) Received: from imr-m06.mx.aol.com (imr-m06.mx.aol.com [64.12.138.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5B96113C4A6 for ; Wed, 31 Oct 2007 17:44:18 +0000 (UTC) (envelope-from Tad1214@aol.com) Received: from imo-d22.mx.aol.com (imo-d22.mail.aol.com [172.18.157.196]) by imr-m06.mx.aol.com (v107.10) with ESMTP id RELAYIN6-74728b3b9373; Wed, 31 Oct 2007 12:56:25 -0400 Received: from Tad1214@aol.com by imo-d22.mx.aol.com (mail_out_v38_r9.3.) id n.c01.22c68265 (37254) for ; Wed, 31 Oct 2007 12:29:54 -0400 (EDT) Received: from [192.168.1.181] (mail.gertens.com [68.178.61.59]) by cia-ma07.mx.aol.com (v120.9) with ESMTP id MAILCIAMA074-91864728ad7fb5; Wed, 31 Oct 2007 12:29:52 -0400 Message-ID: <4728AD90.50604@aol.com> Date: Wed, 31 Oct 2007 11:30:08 -0500 From: Tom Donnelly User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-mobile@freebsd.org References: <1193840099.95027.16.camel@localhost> In-Reply-To: <1193840099.95027.16.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 172.18.157.196 X-Mailer: Unknown (No Version) X-Spam-Flag: NO Subject: Re: Potential hardware issue with too often HDD heads parking X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 17:44:18 -0000 > Hi > > Probably does not related to FreeBSD, but anybody may confirm that > FreeBSD laptops are not affected ? > > https://launchpad.net/bug59695.html > > >> When switching to battery power, /etc/acpi/power.sh issues the command >> hdparm -B 1 to all block devices. This leads to extremely frequent >> load cycles. For example, my new thinkpad has already done well over >> 7000 load cycles -- in only 100 hours. That's at least one unloading >> per minute. Googling for "load unload cycles notebook OR laptop" shows >> that most laptop drives handle up to 600,000 such cycles. As these >> values clearly show, this issue is of high importance and should be >> fixed sooner rather than later. >> >> Please see for yourself how often your drive is load cycling: >> smartctl -d ata -a /dev/sda >> (This command is for an SATA drive; you'll need to install the >> smartmontools package first.) >> >> See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a >> rather dramatic account of the effects the current default values may >> have. >> >> Just in case the load/unload timeout depends on the specific laptop or >> disk model, here are my system specifications: >> ThinkPad Z60m & Hitachi HTS541080G9SA00 disk (80GB) >> > > > From owner-freebsd-mobile@FreeBSD.ORG Wed Oct 31 19:49:16 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B565A16A420 for ; Wed, 31 Oct 2007 19:49:16 +0000 (UTC) (envelope-from vasilyev@inr.ru) Received: from ugw.inr.troitsk.ru (ugw.inr.troitsk.ru [194.67.74.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B01713C4B6 for ; Wed, 31 Oct 2007 19:49:16 +0000 (UTC) (envelope-from vasilyev@inr.ru) Received: from al20.localdomain ([172.20.74.5] helo=al20.inr.troitsk.ru ident=Debian-exim) by ugw.inr.troitsk.ru with esmtp (Exim 4.50) id 1InIsY-0002ag-J1; Wed, 31 Oct 2007 22:05:26 +0300 Received: from mail by al20.inr.troitsk.ru with drweb-scanned (Exim 4.50 #1 (Debian)) id 1InIsY-0007f2-HD; Wed, 31 Oct 2007 22:05:26 +0300 Received: from al20.inr.troitsk.ru ([194.67.74.5] helo=[127.0.0.1] ident=vasilyev) by al20.inr.troitsk.ru with esmtp (Exim 4.50 #1 (Debian)) id 1InIsY-0007en-Ez; Wed, 31 Oct 2007 22:05:26 +0300 Message-ID: <4728D1D1.8030807@inr.ru> Date: Wed, 31 Oct 2007 22:04:49 +0300 From: Ivan Vasilyev User-Agent: Thunderbird 2.0.0.6 (X11/20070921) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <1193840099.95027.16.camel@localhost> In-Reply-To: <1193840099.95027.16.camel@localhost> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-mobile Subject: Re: Potential hardware issue with too often HDD heads parking X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 19:49:16 -0000 Vladimir Grebenschikov wrote: > Hi > > Probably does not related to FreeBSD, but anybody may confirm that > FreeBSD laptops are not affected ? > > https://launchpad.net/bug59695.html > > At least mine is affected. It's HP nx6310 with Fujitsu MVH2060BH hdd. During ten months of operation Power-off_Retract_Count value went up to 60000. "ataidle -P 254" brought that to stop and periodic clicks had also disappeared. From owner-freebsd-mobile@FreeBSD.ORG Thu Nov 1 00:25:23 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC32D16A41B for ; Thu, 1 Nov 2007 00:25:22 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by mx1.freebsd.org (Postfix) with ESMTP id 56A3213C4A8 for ; Thu, 1 Nov 2007 00:25:21 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-msk-nat.sw.ru [195.214.232.10]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id l9VJSDWq002636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Oct 2007 22:28:16 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InJEa-000FWv-P0 for freebsd-mobile@freebsd.org; Wed, 31 Oct 2007 22:28:12 +0300 From: Vladimir Grebenschikov To: freebsd-mobile In-Reply-To: <1193840099.95027.16.camel@localhost> References: <1193840099.95027.16.camel@localhost> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 31 Oct 2007 22:28:09 +0300 Message-Id: <1193858889.97052.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Subject: Re: Potential hardware issue with too often HDD heads parking X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 00:25:23 -0000 =F7 =D3=D2, 31/10/2007 =D7 17:14 +0300, Vladimir Grebenschikov =D0=C9=DB=C5= =D4: > Hi >=20 > Probably does not related to FreeBSD, but anybody may confirm that > FreeBSD laptops are not affected ? >=20 > https://launchpad.net/bug59695.html Looks like FreeBSD notebooks also affected: # smartctl -A /dev/ad0 SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED = WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 086 079 034 Pre-fail Always = - 208994276 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always = - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always = - 572 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always = - 0 7 Seek_Error_Rate 0x000f 078 060 030 Pre-fail Always = - 78468856 9 Power_On_Hours 0x0032 098 098 000 Old_age Always = - 257148281948519 10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always = - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always = - 512 187 Unknown_Attribute 0x0032 100 100 000 Old_age Always = - 0 189 Unknown_Attribute 0x003a 092 092 000 Old_age Always = - 8 190 Temperature_Celsius 0x0022 056 046 045 Old_age Always = - 773390380 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always = - 4 192 Power-Off_Retract_Count 0x0032 100 001 000 Old_age Always = - 212 > 193 Load_Cycle_Count 0x0022 001 001 000 Old_age Always = - 435202 194 Temperature_Celsius 0x001a 044 054 000 Old_age Always = - 44 (Lifetime Min/Max 0/17) 195 Hardware_ECC_Recovered 0x0012 065 060 000 Old_age Always = - 208994276 196 Reallocated_Event_Count 0x0010 098 098 000 Old_age Offline = - 252410933020409 197 Current_Pending_Sector 0x003e 100 100 000 Old_age Always = - 0 198 Offline_Uncorrectable 0x0000 100 100 000 Old_age Offline = - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always = - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline = - 0 202 TA_Increase_Count 0x0000 100 253 000 Old_age Offline = - 0 sysutils/smartmontools was installed to query SMART attributes > > When switching to battery power, /etc/acpi/power.sh issues the command > > hdparm -B 1 to all block devices. This leads to extremely frequent > > load cycles. For example, my new thinkpad has already done well over > > 7000 load cycles -- in only 100 hours. That's at least one unloading > > per minute. Googling for "load unload cycles notebook OR laptop" shows > > that most laptop drives handle up to 600,000 such cycles. As these > > values clearly show, this issue is of high importance and should be > > fixed sooner rather than later. > >=20 > > Please see for yourself how often your drive is load cycling: > > smartctl -d ata -a /dev/sda > > (This command is for an SATA drive; you'll need to install the > > smartmontools package first.) > >=20 > > See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a > > rather dramatic account of the effects the current default values may > > have. > >=20 > > Just in case the load/unload timeout depends on the specific laptop or > > disk model, here are my system specifications: > > ThinkPad Z60m & Hitachi HTS541080G9SA00 disk (80GB) >=20 >=20 --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-mobile@FreeBSD.ORG Thu Nov 1 09:10:42 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 265AD16A419 for ; Thu, 1 Nov 2007 09:10:42 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by mx1.freebsd.org (Postfix) with ESMTP id F043013C480 for ; Thu, 1 Nov 2007 09:10:39 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-msk-nat.sw.ru [195.214.232.10]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id lA199uQ6005181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2007 12:09:58 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InW3o-0005dt-KV; Thu, 01 Nov 2007 12:09:56 +0300 From: Vladimir Grebenschikov To: davidb@boothscientific.com In-Reply-To: <200710312037.42490.davidb@boothscientific.com> References: <1193840099.95027.16.camel@localhost> <1193858889.97052.16.camel@localhost> <200710312037.42490.davidb@boothscientific.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 01 Nov 2007 12:09:55 +0300 Message-Id: <1193908195.1479.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-mobile Subject: Re: Potential hardware issue with too often HDD heads parking X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 09:10:42 -0000 =F7 =D3=D2, 31/10/2007 =D7 20:37 -0500, David Booth =D0=C9=DB=C5=D4: > On Wednesday 31 October 2007, Vladimir Grebenschikov wrote: > > =F7 =D3=D2, 31/10/2007 =D7 17:14 +0300, Vladimir Grebenschikov =D0=C9= =DB=C5=D4: > > > Hi > > > > > > Probably does not related to FreeBSD, but anybody may confirm > > > that FreeBSD laptops are not affected ? > > > > > > https://launchpad.net/bug59695.html > > > > Looks like FreeBSD notebooks also affected: > I am not sure you should trust those numbers as based on the report > of=20 > Power_On_Hours you hard drive has been powered on for some 29 billion=20 > years. According to man-page: RAW_VALUE is measured in some internal HDD units (depends of HDD vendor), but VALUE - is normalized number in range 0 - 255, lesser number - worse, higher number - better (for most parameters), and THRESHold is value when we should expect failures. And my Load_Cycle_Count is 1 of 255, and only on point above threshold. --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 00:19:56 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A1316A41A for ; Fri, 2 Nov 2007 00:19:56 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id 09CA113C4A3 for ; Fri, 2 Nov 2007 00:19:55 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-AV: E=Sophos;i="4.21,360,1188743400"; d="scan'208";a="223987938" Received: from ppp121-45-121-213.lns11.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.121.213]) by ipmail01.adl2.internode.on.net with ESMTP; 02 Nov 2007 10:23:53 +1030 Received: from wolf.clearchain.com (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lA1NriY2099916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2007 10:23:50 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <472A6708.9030109@clearchain.com> Date: Fri, 02 Nov 2007 10:23:44 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.0 (X11/20070615) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Fri, 02 Nov 2007 10:23:50 +1030 (CST) Cc: freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 00:19:57 -0000 Howdy All, I'm pleased to announce the first 'official' experimental version of the wpi wireless driver and hence require your help in making it become stable. Expect a few things not to work (ie bg scanning, setting txpower) but in general the driver should be usable in station mode (hostap is not yet supported). If you've got an Intel 3945abg wireless card, grab the tarball at: http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz Untar and follow the instructions in the README. If you want more info about the driver, or to checkout the FAQ checkout: http://www.clearchain.com/wiki/Wpi I'm interested in all reports related to panics, things not working as expected, etc. The driver still has debug enabled so expect a few messages to be dumped to the screen whilst in use. Finally, many thanks to all those that have been helping debug the driver along the way. Cheers, Benjamin From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 00:42:50 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03EFF16A418; Fri, 2 Nov 2007 00:42:50 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.ipv6.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE5C13C4C4; Fri, 2 Nov 2007 00:42:49 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 367793A57C; Fri, 2 Nov 2007 01:42:48 +0100 (CET) Date: Fri, 2 Nov 2007 01:42:48 +0100 From: Lars Engels To: Benjamin Close Message-ID: <20071102004248.GA5253@e.0x20.net> Mail-Followup-To: Lars Engels , Benjamin Close , freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org References: <472A6708.9030109@clearchain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <472A6708.9030109@clearchain.com> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 00:42:50 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 02, 2007 at 10:23:44AM +1030, Benjamin Close wrote: > Howdy All, I'm pleased to announce the first 'official' experim= ental version of the wpi wireless driver and hence require your help in mak= ing it become=20 > stable. > Expect a few things not to work (ie bg scanning, setting txpower) but in = general the driver should be usable in station mode (hostap is not yet supp= orted). >=20 > If you've got an Intel 3945abg wireless card, grab the tarball at: >=20 > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.t= ar.gz >=20 > Untar and follow the instructions in the README. > If you want more info about the driver, or to checkout the FAQ checkout: >=20 > http://www.clearchain.com/wiki/Wpi >=20 > I'm interested in all reports related to panics, things not working as ex= pected, etc. > The driver still has debug enabled so expect a few messages to be dumped = to the screen whilst in use. >=20 > Finally, many thanks to all those that have been helping debug the driver= along the way. >=20 > Cheers, > Benjamin Good to know that someone is still working on it. However, it doesn't work for me. I cannot load the firmware: lars@ttyp3 # kldload wpifw lars@ttyp3 # dmesg wpifw: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. wpifw: If you agree with the license, set legal.intel_wpi.license_ack=3D1 in /boot/loader.conf. module_register_init: MOD_LOAD (wpifw_fw, 0xc6d1151c, 0) error 1 lars@ttyp3 # grep legal.intel_wpi.license_ack /boot/loader.conf legal.intel_wpi.license_ack=3D1 lars@ttyp3 # sysctl legal sysctl: unknown oid 'legal' And I even read the license! ;-) Lars --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHKnKIKc512sD3afgRAp1pAJ4mAoMYbQrY3AzUZ4gukiInEs1XoACcCydj LJRcWlbKK1inM62rC8sWL7g= =qADt -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 01:11:31 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C5316A418 for ; Fri, 2 Nov 2007 01:11:31 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id CF37013C447 for ; Fri, 2 Nov 2007 01:11:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so838704waf for ; Thu, 01 Nov 2007 18:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/Vo2lL7hdCjK5O/4tzLt1eLN3A6BD+QQfiNsJ0UPBZY=; b=JlO3P6ykhFSQy5BNt7ciO9LMgLxAct6YdPk3G2Uba0jAKeVj2mjNEVJnph7iRPl3tgjaYjmMFlCZeO9zvushBbQ6aBPNYoszcqo6LHZUgoah6lmXzx4k+Z4H/5BxI9mmShDow/GRNTlysbpdPtPazBcGdmjyuFpqHs/wQdnk2n0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NNM0SXtGE3C0gvq8WUiMJjyJaXyZHVZwhDslSoedI4PI42k2uncaeGsWu4TdllbV7sh958lbJGYyVkb7V4KcBt9644sGWmUbbcTrxz42N/nWJsK9fgslEvPjdZN1nTGZSjB530CVXkzIgj5wcJC1s9+Icu9NMmi0BRCi5NnEV3g= Received: by 10.115.22.1 with SMTP id z1mr1263571wai.1193964326259; Thu, 01 Nov 2007 17:45:26 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Thu, 1 Nov 2007 17:45:26 -0700 (PDT) Message-ID: Date: Thu, 1 Nov 2007 17:45:26 -0700 From: "Kip Macy" To: "Lars Engels" , "Benjamin Close" , freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org In-Reply-To: <20071102004248.GA5253@e.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <472A6708.9030109@clearchain.com> <20071102004248.GA5253@e.0x20.net> Cc: Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 01:11:31 -0000 man kenv On 11/1/07, Lars Engels wrote: > On Fri, Nov 02, 2007 at 10:23:44AM +1030, Benjamin Close wrote: > > Howdy All, I'm pleased to announce the first 'official' experimental version of the wpi wireless driver and hence require your help in making it become > > stable. > > Expect a few things not to work (ie bg scanning, setting txpower) but in general the driver should be usable in station mode (hostap is not yet supported). > > > > If you've got an Intel 3945abg wireless card, grab the tarball at: > > > > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz > > > > Untar and follow the instructions in the README. > > If you want more info about the driver, or to checkout the FAQ checkout: > > > > http://www.clearchain.com/wiki/Wpi > > > > I'm interested in all reports related to panics, things not working as expected, etc. > > The driver still has debug enabled so expect a few messages to be dumped to the screen whilst in use. > > > > Finally, many thanks to all those that have been helping debug the driver along the way. > > > > Cheers, > > Benjamin > > Good to know that someone is still working on it. > However, it doesn't work for me. I cannot load the firmware: > > lars@ttyp3 # kldload wpifw > lars@ttyp3 # dmesg > wpifw: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. > wpifw: If you agree with the license, set legal.intel_wpi.license_ack=1 > in /boot/loader.conf. > module_register_init: MOD_LOAD (wpifw_fw, 0xc6d1151c, 0) error 1 > > lars@ttyp3 # grep legal.intel_wpi.license_ack /boot/loader.conf > legal.intel_wpi.license_ack=1 > > lars@ttyp3 # sysctl legal > sysctl: unknown oid 'legal' > > And I even read the license! ;-) > > Lars > > From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 01:32:11 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B7DE16A420; Fri, 2 Nov 2007 01:32:11 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id D6EBA13C48D; Fri, 2 Nov 2007 01:32:07 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-AV: E=Sophos;i="4.21,360,1188743400"; d="scan'208";a="224043007" Received: from ppp121-45-121-213.lns11.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.121.213]) by ipmail01.adl2.internode.on.net with ESMTP; 02 Nov 2007 11:48:31 +1030 Received: from wolf.clearchain.com (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lA21ILHU000769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2007 11:48:27 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <472A7ADD.3010002@clearchain.com> Date: Fri, 02 Nov 2007 11:48:21 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.0 (X11/20070615) MIME-Version: 1.0 To: Max Laier References: <472A6708.9030109@clearchain.com> <20071102004248.GA5253@e.0x20.net> <200711020152.53535.max@love2party.net> In-Reply-To: <200711020152.53535.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Fri, 02 Nov 2007 11:48:28 +1030 (CST) Cc: Lars Engels , freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 01:32:11 -0000 Max Laier wrote: > On Friday 02 November 2007, Lars Engels wrote: > >> On Fri, Nov 02, 2007 at 10:23:44AM +1030, Benjamin Close wrote: >> >>> Howdy All, I'm pleased to announce the first 'official' >>> experimental version of the wpi wireless driver and hence require >>> your help in making it become stable. >>> Expect a few things not to work (ie bg scanning, setting txpower) but >>> in general the driver should be usable in station mode (hostap is not >>> yet supported). >>> >>> If you've got an Intel 3945abg wireless card, grab the tarball at: >>> >>> >>> http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi. >>> tar.gz >>> >>> Untar and follow the instructions in the README. >>> If you want more info about the driver, or to checkout the FAQ >>> checkout: >>> >>> http://www.clearchain.com/wiki/Wpi >>> >>> I'm interested in all reports related to panics, things not working >>> as expected, etc. The driver still has debug enabled so expect a few >>> messages to be dumped to the screen whilst in use. >>> >>> Finally, many thanks to all those that have been helping debug the >>> driver along the way. >>> >>> Cheers, >>> Benjamin >>> >> Good to know that someone is still working on it. >> However, it doesn't work for me. I cannot load the firmware: >> >> lars@ttyp3 # kldload wpifw >> lars@ttyp3 # dmesg >> wpifw: You need to read the LICENSE file in >> /usr/share/doc/legal/intel_wpi/. wpifw: If you agree with the license, >> set legal.intel_wpi.license_ack=1 in /boot/loader.conf. >> module_register_init: MOD_LOAD (wpifw_fw, 0xc6d1151c, 0) error 1 >> >> lars@ttyp3 # grep legal.intel_wpi.license_ack /boot/loader.conf >> legal.intel_wpi.license_ack=1 >> >> lars@ttyp3 # sysctl legal >> sysctl: unknown oid 'legal' >> > > It's not a sysctl it's in kenv, but if it's in loader.conf it should be in > kenv, too. > > >> And I even read the license! ;-) >> > > > You shouldn't need to manually kldload the wpifw, wpi will pull it in for you. However, if you have the line in loader.conf it should work - I take it you did reboot for the setting to be grabbed? Cheers, Benjamin From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 12:09:02 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EB016A417; Fri, 2 Nov 2007 12:09:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7063A13C494; Fri, 2 Nov 2007 12:09:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-044-048.pools.arcor-ip.net [88.66.44.48]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1InkmN38wV-0006w6; Fri, 02 Nov 2007 01:52:56 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org, Lars Engels Date: Fri, 2 Nov 2007 01:52:44 +0100 User-Agent: KMail/1.9.7 References: <472A6708.9030109@clearchain.com> <20071102004248.GA5253@e.0x20.net> In-Reply-To: <20071102004248.GA5253@e.0x20.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1448871.x47iAX1EqJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711020152.53535.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19wX6xz7zvLyKEPl2knS4+0lvMY3McrRmaeMyD 715sfY2WaXUGrLK6VqOmLUUjgPLvJwBjgZj0UmEfewYkqDGVaF wn8hsIjaxrWN1aw1ZDunhikkwGR8g9vjcCxVMYSqAo= Cc: Benjamin Close , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 12:09:03 -0000 --nextPart1448871.x47iAX1EqJ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 02 November 2007, Lars Engels wrote: > On Fri, Nov 02, 2007 at 10:23:44AM +1030, Benjamin Close wrote: > > Howdy All, I'm pleased to announce the first 'official' > > experimental version of the wpi wireless driver and hence require > > your help in making it become stable. > > Expect a few things not to work (ie bg scanning, setting txpower) but > > in general the driver should be usable in station mode (hostap is not > > yet supported). > > > > If you've got an Intel 3945abg wireless card, grab the tarball at: > > > > =20 > > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi. > >tar.gz > > > > Untar and follow the instructions in the README. > > If you want more info about the driver, or to checkout the FAQ > > checkout: > > > > http://www.clearchain.com/wiki/Wpi > > > > I'm interested in all reports related to panics, things not working > > as expected, etc. The driver still has debug enabled so expect a few > > messages to be dumped to the screen whilst in use. > > > > Finally, many thanks to all those that have been helping debug the > > driver along the way. > > > > Cheers, > > Benjamin > > Good to know that someone is still working on it. > However, it doesn't work for me. I cannot load the firmware: > > lars@ttyp3 # kldload wpifw > lars@ttyp3 # dmesg > wpifw: You need to read the LICENSE file in > /usr/share/doc/legal/intel_wpi/. wpifw: If you agree with the license, > set legal.intel_wpi.license_ack=3D1 in /boot/loader.conf. > module_register_init: MOD_LOAD (wpifw_fw, 0xc6d1151c, 0) error 1 > > lars@ttyp3 # grep legal.intel_wpi.license_ack /boot/loader.conf > legal.intel_wpi.license_ack=3D1 > > lars@ttyp3 # sysctl legal > sysctl: unknown oid 'legal' It's not a sysctl it's in kenv, but if it's in loader.conf it should be in= =20 kenv, too. > And I even read the license! ;-) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1448871.x47iAX1EqJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHKnTlXyyEoT62BG0RAliyAJ0USnzcHoQRnN/R/6momwSAiQn8rACeNHvy OWqrj8s/fRTsPqASqQgEXD0= =Jbpn -----END PGP SIGNATURE----- --nextPart1448871.x47iAX1EqJ-- From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 19:24:44 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA5916A41A for ; Fri, 2 Nov 2007 19:24:44 +0000 (UTC) (envelope-from frankstaals@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A1CED13C4A5 for ; Fri, 2 Nov 2007 19:24:43 +0000 (UTC) (envelope-from frankstaals@gmx.net) Received: (qmail invoked by alias); 02 Nov 2007 19:17:35 -0000 Received: from ip176-173-59-62.adsl.versatel.nl (EHLO Rena.FStaals.net) [62.59.173.176] by mail.gmx.net (mp047) with SMTP; 02 Nov 2007 20:17:35 +0100 X-Authenticated: #25365336 X-Provags-ID: V01U2FsdGVkX1/OANdROuHO5L5+r5K6W37T69ADNVUKVD0sWCnvvp ybCU5ctroAVtsS Message-ID: <472B779B.9060002@gmx.net> Date: Fri, 02 Nov 2007 20:16:43 +0100 From: Frank Staals User-Agent: Thunderbird 2.0.0.6 (X11/20070929) MIME-Version: 1.0 To: Benjamin Close References: <472A6708.9030109@clearchain.com> In-Reply-To: <472A6708.9030109@clearchain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 19:24:44 -0000 Benjamin Close wrote: > Howdy All, I'm pleased to announce the first 'official' > experimental version of the wpi wireless driver and hence require your > help in making it become stable. > Expect a few things not to work (ie bg scanning, setting txpower) but > in general the driver should be usable in station mode (hostap is not > yet supported). > > If you've got an Intel 3945abg wireless card, grab the tarball at: > > > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz > > > Untar and follow the instructions in the README. > If you want more info about the driver, or to checkout the FAQ checkout: > > http://www.clearchain.com/wiki/Wpi > > I'm interested in all reports related to panics, things not working as > expected, etc. > The driver still has debug enabled so expect a few messages to be > dumped to the screen whilst in use. > > Finally, many thanks to all those that have been helping debug the > driver along the way. > > Cheers, > Benjamin > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > Woei ! It's working for me so far :) Allthough I still have issues when switching from one tty to one other. Here the output of the script I am using to do the connecting : loaded the module at boot ran my script which does: ( output snipped ) wlannic=wpi0 # clear the selected gateway: route flush # Set the interface ifconfig ${wlannic} 192.168.5.5 ssid # Set a new gateway route add default 192.168.5.1 # make sure to give the LAN-NIC an other IP-address ifconfig ${lannic} 192.168.200.2 ifconfig ${wlannic} up # test connection ping -c 1 192.168.5.1 # start a screen session with ssh connection for authentication screen -d -m ssh -l wifi 192.168.5.1 # wait a while before testing the connection sleep 3 # test conn: ping -c 1 google.nl Everything works fine with the connection itself. Allthough sometimes when switching from tty9 to tty0 and back the system locks up. I've had it before when switching from tty1 to tty0. Anyone with the same problems ? Anyway; Great work on the driver so far :D -- -Frank Staals From owner-freebsd-mobile@FreeBSD.ORG Fri Nov 2 21:32:17 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1CDD16A46E; Fri, 2 Nov 2007 21:32:17 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id 177EB13C4B2; Fri, 2 Nov 2007 21:32:14 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAOYwK0d5LYjs/2dsb2JhbACBW45c X-IronPort-AV: E=Sophos;i="4.21,364,1188743400"; d="scan'208";a="224636654" Received: from ppp121-45-136-236.lns11.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.136.236]) by ipmail01.adl2.internode.on.net with ESMTP; 03 Nov 2007 07:54:48 +1030 Received: from [192.168.155.249] (draco.internal.clearchain.com [192.168.155.249]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lA2LOjjb009753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2007 07:54:46 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <472B9597.2050108@clearchain.com> Date: Sat, 03 Nov 2007 07:54:39 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Frank Staals References: <472A6708.9030109@clearchain.com> <472B779B.9060002@gmx.net> In-Reply-To: <472B779B.9060002@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Sat, 03 Nov 2007 07:54:46 +1030 (CST) Cc: freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 21:32:18 -0000 Frank Staals wrote: > Benjamin Close wrote: >> Howdy All, I'm pleased to announce the first 'official' >> experimental version of the wpi wireless driver and hence require >> your help in making it become stable. >> Expect a few things not to work (ie bg scanning, setting txpower) but >> in general the driver should be usable in station mode (hostap is not >> yet supported). >> >> If you've got an Intel 3945abg wireless card, grab the tarball at: >> >> >> http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz >> >> >> Untar and follow the instructions in the README. >> If you want more info about the driver, or to checkout the FAQ checkout: >> >> http://www.clearchain.com/wiki/Wpi >> >> I'm interested in all reports related to panics, things not working >> as expected, etc. >> The driver still has debug enabled so expect a few messages to be >> dumped to the screen whilst in use. >> >> Finally, many thanks to all those that have been helping debug the >> driver along the way. >> >> Cheers, >> Benjamin >> _______________________________________________ >> freebsd-mobile@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile >> To unsubscribe, send any mail to >> "freebsd-mobile-unsubscribe@freebsd.org" >> > Woei ! It's working for me so far :) Allthough I still have issues > when switching from one tty to one other. Here the output of the > script I am using to do the connecting : > > loaded the module at boot > > ran my script which does: ( output snipped ) > > wlannic=wpi0 > > # clear the selected gateway: > route flush > > # Set the interface ifconfig ${wlannic} 192.168.5.5 ssid > > > # Set a new gateway > route add default 192.168.5.1 > # make sure to give the LAN-NIC an other IP-address > ifconfig ${lannic} 192.168.200.2 > > ifconfig ${wlannic} up > > # test connection > ping -c 1 192.168.5.1 > # start a screen session with ssh connection for > authentication > screen -d -m ssh -l wifi 192.168.5.1 > # wait a while before testing the connection > sleep 3 > > # test conn: > ping -c 1 google.nl > > > > Everything works fine with the connection itself. Allthough sometimes > when switching from tty9 to tty0 and back the system locks up. I've > had it before when switching from tty1 to tty0. Anyone with the same > problems ? > > Anyway; Great work on the driver so far :D > I've similar issues and believe it might be due to the amount of kernel printfs that are happening. Can you sysctl debug.wpi=0 and see if the problem still exists? By chance are you using ZFS? I caught a memory modified after free panic in zfs the other day pid was from syslogd. I'm trying to work out if it's related. Cheers, Benjamin