From gnb@melbourne.sgi.com Wed Jun 1 01:17:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 01:17:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j518HRXq022082 for ; Wed, 1 Jun 2005 01:17:28 -0700 Received: from [134.14.55.176] (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA15672; Wed, 1 Jun 2005 18:16:26 +1000 Subject: Re: Locking model for NAPI drivers From: Greg Banks To: "David S. Miller" Cc: Linux Network Development list In-Reply-To: <20050531.154847.63995530.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> Content-Type: text/plain Organization: Silicon Graphics Inc, Australian Software Group. Message-Id: <1117613796.26331.2479.camel@hole.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Wed, 01 Jun 2005 18:16:36 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 1940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: netdev On Wed, 2005-06-01 at 08:48, David S. Miller wrote: > So the idea is, if we can make all of the spinlocks BH locks we'll > solve a whole bunch of problems: > [...] > 2) the driver will actually produce useful profiling data > via oprofile and friends since timer interrupts will run > even while holding the locks That would be really, really nice. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From herbert@gondor.apana.org.au Wed Jun 1 01:44:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 01:44:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j518i1Xq023834 for ; Wed, 1 Jun 2005 01:44:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdOoK-0005CB-00; Wed, 01 Jun 2005 18:42:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdOoF-00082p-00; Wed, 01 Jun 2005 18:42:43 +1000 From: Herbert Xu To: ak@muc.de (Andi Kleen) Subject: Re: Locking model for NAPI drivers Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 01 Jun 2005 18:42:43 +1000 X-archive-position: 1941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Andi Kleen wrote: > > That is because of the kmap_atomic it does right? At least in the i386 > highmem implementation I don't see any code that would be less safe in > hard interrupt context compared to BHs. And FRV and mips look like they > allow it too. To make it safe we'll have to allocate another precious km_type entry. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From raghunathan.venkatesan@wipro.com Wed Jun 1 04:40:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 04:41:12 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51BepXq004532 for ; Wed, 1 Jun 2005 04:40:54 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 5CA9D205E4; Wed, 1 Jun 2005 17:00:54 +0530 (IST) Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3B276205E1; Wed, 1 Jun 2005 17:00:54 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 17:09:48 +0530 Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Jun 2005 17:04:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5669D.E951F95B" Subject: Unable to handle kernel paging request at virtual address 04000460 Date: Wed, 1 Jun 2005 17:01:23 +0530 Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Unable to handle kernel paging request at virtual address 04000460 Thread-Index: AcVgd+bKyjXc1BZZTzOXOhBhBJ2c9wAwfS0wAFOR2UABBPMC8A== From: To: , , X-OriginalArrivalTime: 01 Jun 2005 11:34:44.0715 (UTC) FILETIME=[E8897BB0:01C5669D] X-archive-position: 1942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: raghunathan.venkatesan@wipro.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------_=_NextPart_001_01C5669D.E951F95B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, We are facing the following crash in custom Linux 2.4.26 kernel, when we run a netperf TCP Stream (sizes varying from 64 to 32586 bytes) test over an IPSEC tunnel created between a host and a VPN server through our box. This is a Au1550 MIPS32 based board (DB1550 Cabernet board from AMD). We observe that crash happens randomly (the PrId keeps changing at each crash), because of burstiness in the netperf tool generated traffic. Please look into the following capture below. I'd like some help in debugging this issue. The same set of IPSEC drivers (not from Linux) works fine on a custom Linux 2.4.25 based kernel. We debugged the Oops traces and found that all problems arise in skbuff (donno where in skbuff). Is there a patch that needs to be applied for Linux 2.4.26 ?=20 Thanks & Regards, Raghu Venkatesan Project Manager (E & PE, Semiconductor & Access), CDC2, Sozhanganallur, Chennai - 600 119, INDIA +91 -44-24500200 Ext. 2643 raghunathan.venkatesan@wipro.com =20 ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_send1.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_send1.oops Content-Disposition: attachment; filename="recent.cap_send1.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDIwMDA0 ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWJiYjYwMCAwMjAw MDQ2MCAwMjAwMDQ2MCA4YWJiYjVlYyAwMDAwMDAwMCAwMDAwMDVlYwokOCA6IDVhZDM0MzZlIDhh YmJiZGVjIGIzZGU1ZDcxIDU2NzM2OTg4IDA3ODNmZGZiIDgwMzIzODU4IDgwMzIzODA0IDI0ZTEy YWU1CiQxNjogMDIwMDA0NjAgMDAwMDAwMDEgOGFiYmI4MDAgMDAwMDA2MDAgMDAwMDBjZmMgMDAw MDA1ZGMgMDAwMDAwMTQgMDAwMDM0MDgKJDI0OiAwMDAwMDAwMCAyYWVhM2M3MCAgICAgICAgICAg ICAgICAgICA4MDMyMjAwMCA4MDMyM2EyOCAwMDAwMzQxYyA4MDI0YjA5NApIaSA6IDAwMDAwMDAw CkxvIDogMDAwMDA4MDAKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDhiOTYyNDgwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwODAwIDhiNmFmNDYwIDgwMjRiMDk0CiA4YjZhZjQ2MCA4YWJiYjgwMCAwMDAwMDYwMCAw MDAwMGNmYyAwMDAwMDVkYyAwMDAwMDgwMCA4YjZhZjQ2MCA4MDI0YjdjYwogODAyNGI3YjAgMjRl MTJhZTUgODAzMjM4NTggODAzMjM4MDQgYzAxYzIwNTAgOGI2YWY0NjAgODAzYTA0MDAgMDAwMDA1 YzgKIDgxMmJlMzAwIDgwMjUwMWQ0IDAwMDAwNWRjIDAwMDAwMDE0IDAwMDAyZTQwIDAwMDAwMDAw IDJhZWEzYzcwIDhiNmFmNDYwCiA4YWVhMTE2MCAwMDAwMDVjOCA4MDI2YTllOCAwMDAwMmU1NCA4 MDI2YTE4NCAxMDAwZmMwMyAwMDAwMDAwMCA4YjZhZjQ2MAogOGFiYmIwMTAgLi4uCkNhbGwgVHJh Y2U6ICAgWzw4MDI0YjA5ND5dIFs8ODAyNGI3Y2M+XSBbPDgwMjRiN2IwPl0gWzw4MDI1MDFkND5d IFs8ODAyNmE5ZTg+XQogWzw4MDI2YTE4ND5dIFs8ODAyNmEzMGM+XSBbPDgwMjZhMWRjPl0gWzw4 MDI2YTkwYz5dIFs8ODAyNmE5MGM+XSBbPDgwMjljNDE4Pl0KIFs8ODAyNmE5MGM+XSBbPDgwMjZh OTBjPl0gWzw4MDI1YTQ4ND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhOTBjPl0gWzw4MDI1YTk0OD5d CiBbPDgwMmRhMGUwPl0gWzw4MDI2YTkwYz5dIFs8ODAyNmE4ZDQ+XSBbPDgwMjZhOTBjPl0gWzw4 MDI2YTMwYz5dIFs8ODAyNmExODQ+XQogWzw4MDI2NzEzMD5dIFs8ODAyNjcxYjA+XSBbPDgwMjZh NzQ0Pl0gWzw4MDI1YTk4Yz5dIFs8ODAyOWVkODg+XSBbPDgwMjY3MTMwPl0KIFs8ODAyOWZkMzQ+ XSBbPDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4 MDI1YTQ4ND5dCiBbPGMwMWNlMmE4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVh OThjPl0gWzw4MDI1YTk0OD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGM1MDAwMDggIGFjNDAw MDA4ICAwMjAwMjAyMSA8OGM4MjAwNzQ+IDEwNTEwMDA5ICA4ZTEwMDAwMCAgYzA4MzAwNzQgIDAw NzExMDIzICBlMDgyMDA3NAoKCj4+UkE7ICAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9k YXRhK2IwL2JjPgo+PiQxMzsgMDAwMDAwMDA4MDMyMzg1OCA8aW5pdF90YXNrX3VuaW9uKzE4NTgv MjAwMD4KPj4kMTQ7IDAwMDAwMDAwODAzMjM4MDQgPGluaXRfdGFza191bmlvbisxODA0LzIwMDA+ Cj4+JDI4OyAwMDAwMDAwMDgwMzIyMDAwIDxpbml0X3Rhc2tfdW5pb24rMC8yMDAwPgo+PiQyOTsg MDAwMDAwMDA4MDMyM2EyOCA8aW5pdF90YXNrX3VuaW9uKzFhMjgvMjAwMD4KPj4kMzE7IDAwMDAw MDAwODAyNGIwOTQgPHNrYl9yZWxlYXNlX2RhdGErYjAvYmM+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0 YWY2YyA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzQvNzQ+ICAgPD09PT09CgpUcmFjZTsgMDAwMDAwMDA4 MDI0YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNGI3Y2Mg PHNrYl9saW5lYXJpemUrYzQvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI0YjdiMCA8c2tiX2xpbmVh cml6ZSthOC8xNGM+ClRyYWNlOyAwMDAwMDAwMDgwMjUwMWQ0IDxkZXZfcXVldWVfeG1pdCs1MC8z Yjg+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0cHV0MitlYy8xNTA+ClRy YWNlOyAwMDAwMDAwMDgwMjZhMTg0IDxpcF9mcmFnbWVudCsyNDAvNTAwPgpUcmFjZTsgMDAwMDAw MDA4MDI2YTMwYyA8aXBfZnJhZ21lbnQrM2M4LzUwMD4KVHJhY2U7IDAwMDAwMDAwODAyNmExZGMg PGlwX2ZyYWdtZW50KzI5OC81MDA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0 MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjljNDE4IDxpcF9yZWZyYWcrNjgvNzQ+ClRyYWNl OyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAw MDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgw MjVhNDg0IDxuZl9pdGVyYXRlKzk0LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9v dXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgv MWY4PgpUcmFjZTsgMDAwMDAwMDA4MDJkYTBlMCA8bWVtc2V0KzAvMWM+ClRyYWNlOyAwMDAwMDAw MDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZh OGQ0IDxpcF9maW5pc2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxp cF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFn bWVudCszYzgvNTAwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUw MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFj ZTsgMDAwMDAwMDA4MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAw MDAwMDgwMjZhNzQ0IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAy NWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI5ZWQ4OCA8aXBf Y3RfcmVmcmVzaCs4NC9iOD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmlu aXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRy YWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAw MDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAw ODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8 aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0 ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/ Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNl OyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAw ODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8 bmZfaG9va19zbG93KzEyOC8xZjg+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8c2tiX2Ryb3Bf ZnJhZ2xpc3QrMjgvNzQ+CjAwMDAwMDAwIDxfUEM+OgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8 c2tiX2Ryb3BfZnJhZ2xpc3QrMjgvNzQ+CiAgIDA6ICAgOGM1MDAwMDggIGx3ICAgICAgczAsOCh2 MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjQgPHNrYl9kcm9wX2ZyYWdsaXN0KzJjLzc0PgogICA0 OiAgIGFjNDAwMDA4ICBzdyAgICAgIHplcm8sOCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjgg PHNrYl9kcm9wX2ZyYWdsaXN0KzMwLzc0PgogICA4OiAgIDAyMDAyMDIxICBtb3ZlICAgIGEwLHMw CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjZjIDxza2JfZHJvcF9mcmFnbGlzdCszNC83ND4gICA8PT09 PT0KICAgYzogICA4YzgyMDA3NCAgbHcgICAgICB2MCwxMTYoYTApICAgPD09PT09CkNvZGU7ICAw MDAwMDAwMDgwMjRhZjcwIDxza2JfZHJvcF9mcmFnbGlzdCszOC83ND4KICAxMDogICAxMDUxMDAw OSAgYmVxICAgICB2MCxzMSwzOCA8X1BDKzB4Mzg+CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc0IDxz a2JfZHJvcF9mcmFnbGlzdCszYy83ND4KICAxNDogICA4ZTEwMDAwMCAgbHcgICAgICBzMCwwKHMw KQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDAvNzQ+CiAgMTg6 ICAgYzA4MzAwNzQgIGxsICAgICAgdjEsMTE2KGEwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3YyA8 c2tiX2Ryb3BfZnJhZ2xpc3QrNDQvNzQ+CiAgMWM6ICAgMDA3MTEwMjMgIHN1YnUgICAgdjAsdjEs czEKQ29kZTsgIDAwMDAwMDAwODAyNGFmODAgPHNrYl9kcm9wX2ZyYWdsaXN0KzQ4Lzc0PgogIDIw OiAgIGUwODIwMDc0ICBzYyAgICAgIHYwLDExNihhMCkKCktlcm5lbCBwYW5pYzogQWllZSwga2ls bGluZyBpbnRlcnJ1cHQgaGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBu b3QgYmUgcmVsaWFibGUuCg== ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap.oops Content-Disposition: attachment; filename="recent.cap.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDQwMDA0 NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMSA4Yjc4MzU4MCAwMDAwMDAwMCAwNDAwMDQ2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIDgwMzIzYjY4IDAwMDAwMDAwIDgwMzIzZDYwIDdiN2E3 OTc4CiQxNjogODEyYmViMjAgODEyYmViMjAgZmZmZmZmZmYgOGJiMGQ4MDAgODAzYTA4MDQgMDAw MDAwMDAgMDAwMDAwMDIgODAzMjNlMTAKJDI0OiAwMDAwMDAwMCAyYjAwYWM3MCAgICAgICAgICAg ICAgICAgICA4MDMyMjAwMCA4MDMyM2FkMCAwMDAwMjQwMSA4MDJjNDlmOApIaSA6IDAwMDAyMDkx CkxvIDogZDY5MTI4NWUKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDAwMDAwMDAwIDhiYjBkODAwIDgwM2EwODA0IDAwMDAwMDAw IDgxMmJlYjIwIDgwMmM0OWY4IDgwMTA3YzI4CiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA4 MTJiZWIyMCA4MTI0ZmM2OCA4YjZhZjVhMCA4MDNhMDgwMCAwMDAwMDAwNAogODAyNTAwODggMDAw MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgODEyYjY1NjAgODAzYTA4MDAgOGI2YWY1 YTAKIDgwM2EwODAwIDAwMDAwMDAwIDgwMjVjM2UwIDAwMDAwMDAwIDAwMDAwMDAwIDgwMzIzYzE4 IDgwMzY5YmYwIDgwMzRkN2U4CiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1MDM3YyA4MDI5YzNlYyAw MDAwMDAwMCA4Yjc4MzU4MCA4YjZhZjVhMCAwMDAwMDAwZQogOGI2YWY1YTAgLi4uCkNhbGwgVHJh Y2U6ICAgWzw4MDJjNDlmOD5dIFs8ODAxMDdjMjg+XSBbPDgwMjUwMDg4Pl0gWzw4MDI1YzNlMD5d IFs8ODAyNTAzN2M+XQogWzw4MDI5YzNlYz5dIFs8ODAyNTczYTg+XSBbPDgwMjVhNDg0Pl0gWzw4 MDI2YTkwYz5dIFs8ODAyNmE5ZTg+XSBbPDgwMjZhOTBjPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjVh OTQ4Pl0gWzw4MDI2YTkwYz5dIFs8ODAyYTNkOTg+XSBbPDgwMjY3MTMwPl0gWzw4MDI2YThkND5d CiBbPDgwMjZhOTBjPl0gWzw4MDI2NzFjMD5dIFs8ODAyNjcxMzA+XSBbPDgwMjVhOThjPl0gWzw4 MDI5Y2Y1MD5dIFs8ODAyNjcxMzA+XQogWzw4MDI5ZmQwND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3 MTMwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNjVhMjA+XSBbPDgwMjVhNDg0Pl0KIFs8YzAxY2UyYTg+ XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNWE5OGM+XSBbPDgwMjVhOTQ4Pl0gWzw4 MDI2NTdmOD5dCiBbPDgwMjY1NWEwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNTBkNDg+XSBbPDgwMmUw MWY0Pl0gWzw4MDEwN2MyOD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGUwNjAwOWMgIDEwYzAw MDBlICAyNDAzMDAwMSA8OGNjMjAwMDA+IGMwNDUwMDAwICAwMGEzMjAyMyAgZTA0NDAwMDAgIDEw ODBmZmZjICAwMGEzMjAyMwoKCj4+UkE7ICAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nw a3QrMjljLzJiMD4KPj4kMTI7IDAwMDAwMDAwODAzMjNiNjggPGluaXRfdGFza191bmlvbisxYjY4 LzIwMDA+Cj4+JDE0OyAwMDAwMDAwMDgwMzIzZDYwIDxpbml0X3Rhc2tfdW5pb24rMWQ2MC8yMDAw Pgo+PiQyMzsgMDAwMDAwMDA4MDMyM2UxMCA8aW5pdF90YXNrX3VuaW9uKzFlMTAvMjAwMD4KPj4k Mjg7IDAwMDAwMDAwODAzMjIwMDAgPGluaXRfdGFza191bmlvbiswLzIwMDA+Cj4+JDI5OyAwMDAw MDAwMDgwMzIzYWQwIDxpbml0X3Rhc2tfdW5pb24rMWFkMC8yMDAwPgo+PiQzMTsgMDAwMDAwMDA4 MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0YjIw YyA8X19rZnJlZV9za2IrYTQvMTMwPiAgIDw9PT09PQoKVHJhY2U7IDAwMDAwMDAwODAyYzQ5Zjgg PHBhY2tldF9yY3Zfc3BrdCsyOWMvMmIwPgpUcmFjZTsgMDAwMDAwMDA4MDEwN2MyOCA8ZG9fZ2V0 dGltZW9mZGF5KzU4LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNTAwODggPGRldl9xdWV1ZV94bWl0 X25pdCtiYy8xMTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVjM2UwIDxfX2dudV9jb21waWxlZF9jKzcw LzE0Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFmOC8zYjg+ClRy YWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAwMDAwMDAwMDgw MjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAwMDAwMDA4MDI1 YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5p c2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0 cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0Misx MC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJh Y2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAw MDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDJh M2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxp cF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQgPGlwX2Zpbmlz aF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9vdXRw dXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNfYnVpbGQrMC8w PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+ClRyYWNl OyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAwMDAwMDAw ODAyOWNmNTAgPGRlYXRoX2J5X3RpbWVvdXQrM2MvYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMw IDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyOWZkMDQgPGljbXBf cGFja2V0KzY4LzljPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzA2YyA8X19nbnVfY29tcGlsZWRfYysy NmMvMzIwPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+ ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAw MDAwMDAwODAyNjVhMjAgPGlwX3Jjdl9maW5pc2grMjM4LzJhOD4KVHJhY2U7IDAwMDAwMDAwODAy NWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDBjMDFjZTJhOCA8RU5EX09G X0NPREUrM2ZlM2JhYTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5p c2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAw MDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2 NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1NWEwIDxpcF9y Y3YrNTEwLzU3OD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4 PgpUcmFjZTsgMDAwMDAwMDA4MDI1MGQ0OCA8bmV0aWZfcmVjZWl2ZV9za2IrMjcwLzJjMD4KVHJh Y2U7IDAwMDAwMDAwODAyZTAxZjQgPGF1MTAwMF9JUlErMTM0LzFhMD4KVHJhY2U7IDAwMDAwMDAw ODAxMDdjMjggPGRvX2dldHRpbWVvZmRheSs1OC8xMTQ+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YjIw MCA8X19rZnJlZV9za2IrOTgvMTMwPgowMDAwMDAwMCA8X1BDPjoKQ29kZTsgIDAwMDAwMDAwODAy NGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KICAgMDogICA4ZTA2MDA5YyAgbHcgICAgICBhMiwx NTYoczApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjA0IDxfX2tmcmVlX3NrYis5Yy8xMzA+CiAgIDQ6 ICAgMTBjMDAwMGUgIGJlcXogICAgYTIsNDAgPF9QQysweDQwPgpDb2RlOyAgMDAwMDAwMDA4MDI0 YjIwOCA8X19rZnJlZV9za2IrYTAvMTMwPgogICA4OiAgIDI0MDMwMDAxICBsaSAgICAgIHYxLDEK Q29kZTsgIDAwMDAwMDAwODAyNGIyMGMgPF9fa2ZyZWVfc2tiK2E0LzEzMD4gICA8PT09PT0KICAg YzogICA4Y2MyMDAwMCAgbHcgICAgICB2MCwwKGEyKSAgIDw9PT09PQpDb2RlOyAgMDAwMDAwMDA4 MDI0YjIxMCA8X19rZnJlZV9za2IrYTgvMTMwPgogIDEwOiAgIGMwNDUwMDAwICBsbCAgICAgIGEx LDAodjApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjE0IDxfX2tmcmVlX3NrYithYy8xMzA+CiAgMTQ6 ICAgMDBhMzIwMjMgIHN1YnUgICAgYTAsYTEsdjEKQ29kZTsgIDAwMDAwMDAwODAyNGIyMTggPF9f a2ZyZWVfc2tiK2IwLzEzMD4KICAxODogICBlMDQ0MDAwMCAgc2MgICAgICBhMCwwKHYwKQpDb2Rl OyAgMDAwMDAwMDA4MDI0YjIxYyA8X19rZnJlZV9za2IrYjQvMTMwPgogIDFjOiAgIDEwODBmZmZj ICBiZXF6ICAgIGEwLDEwIDxfUEMrMHgxMD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMjAgPF9fa2Zy ZWVfc2tiK2I4LzEzMD4KICAyMDogICAwMGEzMjAyMyAgc3VidSAgICBhMCxhMSx2MQoKS2VybmVs IHBhbmljOiBBaWVlLCBraWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3Vl ZC4gIFJlc3VsdHMgbWF5IG5vdCBiZSByZWxpYWJsZS4K ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_recv.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_recv.oops Content-Disposition: attachment; filename="recent.cap_recv.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMSA4Yjc4MDc2MCAwMDAwMDAwMCAwMDAwMzI2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIGMwMTE1MDAwIDAwMDAxNGI4IDhiOWJmZDI4IDdiN2E3 OTc4CiQxNjogOGI2YjU0NjAgOGI2YjU0NjAgZmZmZmZmZmYgOGI5MGY4MDAgODAzYTA4MDQgMDAw MDAwMDAgMDAwMDAwMDIgOGI5YmZkZDgKJDI0OiAwMDAwMDAwMCAyYWNhZDU1MCAgICAgICAgICAg ICAgICAgICA4YjliZTAwMCA4YjliZmE5OCAwMDAwNDc5ZCA4MDJjNDlmOApIaSA6IDAwMDAyMzYx CkxvIDogNzY1MGYxMDgKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyB2b3Nsb2cgKHBpZDogMTM0LCBzdGFja3Bh Z2U9OGI5YmUwMDApClN0YWNrOiAgICAwMDAwMDAwMCA4YjkwZjgwMCA4MDNhMDgwNCAwMDAwMDAw MCA4YjZiNTQ2MCA4MDJjNDlmOCA4MDEwN2MyOAogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAg OGI2YjU0NjAgODEyNGZjNjggODEyYmVkMDAgODAzYTA4MDAgMDAwMDAwMDQKIDgwMjUwMDg4IDAw MDAwMDAwIDAwMDAwMDAwIDgwMjlkMzgwIDAwMDAwMDAwIDgxMmI2NTYwIDgwM2EwODAwIDgxMmJl ZDAwCiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1YzNlMCA4MDI2YTkwYyAwMDAwMDAwMyAwMDAwMDAw MiA4MDI5YzNhYyA4MDM0ZDdlOAogODAzYTA4MDAgMDAwMDAwMDAgODAyNTAzN2MgODAyOWMzZWMg MDAwMDAwMDAgOGI3ODA3NjAgODEyYmVkMDAgMDAwMDAwMGUKIDgxMmJlZDAwIC4uLgpDYWxsIFRy YWNlOiAgIFs8ODAyYzQ5Zjg+XSBbPDgwMTA3YzI4Pl0gWzw4MDI1MDA4OD5dIFs8ODAyOWQzODA+ XSBbPDgwMjVjM2UwPl0KIFs8ODAyNmE5MGM+XSBbPDgwMjljM2FjPl0gWzw4MDI1MDM3Yz5dIFs8 ODAyOWMzZWM+XSBbPDgwMjU3M2E4Pl0gWzw4MDI1YTQ4ND5dCiBbPDgwMjZhOTBjPl0gWzw4MDI2 YTllOD5dIFs8ODAyNmE5MGM+XSBbPDgwMjVhOThjPl0gWzw4MDI1YTk0OD5dIFs8ODAyNmE5MGM+ XQogWzw4MDJhM2Q5OD5dIFs8ODAyNjcxMzA+XSBbPDgwMjZhOGQ0Pl0gWzw4MDI2YTkwYz5dIFs8 ODAyNjcxYzA+XSBbPDgwMjY3MTMwPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjY3MTMwPl0gWzw4MDI5 ZmQzND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3MTMwPl0gWzw4MDI2NTdmOD5dCiBbPDgwMjY1YTIw Pl0gWzw4MDI1YTQ4ND5dIFs8YzAxY2UyYTg+XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8 ODAyNWE5OGM+XQogWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1NWEwPl0gWzw4MDI2 NTdmOD5dIFs8ODAxMDEzM2M+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5lKTogZ2FyYmFn ZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhlMDYwMDljICAxMGMw MDAwZSAgMjQwMzAwMDEgPDhjYzIwMDAwPiBjMDQ1MDAwMCAgMDBhMzIwMjMgIGUwNDQwMDAwICAx MDgwZmZmYyAgMDBhMzIwMjMKCgo+PlJBOyAgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9z cGt0KzI5Yy8yYjA+Cj4+JDMxOyAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nwa3QrMjlj LzJiMD4KCj4+UEM7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVlX3NrYithNC8xMzA+ICAgPD09 PT09CgpUcmFjZTsgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+ClRy YWNlOyAwMDAwMDAwMDgwMTA3YzI4IDxkb19nZXR0aW1lb2ZkYXkrNTgvMTE0PgpUcmFjZTsgMDAw MDAwMDA4MDI1MDA4OCA8ZGV2X3F1ZXVlX3htaXRfbml0K2JjLzExMD4KVHJhY2U7IDAwMDAwMDAw ODAyOWQzODAgPF9faXBfY29ubnRyYWNrX2NvbmZpcm0rMjM4LzJjOD4KVHJhY2U7IDAwMDAwMDAw ODAyNWMzZTAgPF9fZ251X2NvbXBpbGVkX2MrNzAvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkw YyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI5YzNhYyA8aXBf Y29uZmlybSs0OC80Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFm OC8zYjg+ClRyYWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAw MDAwMDAwMDgwMjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAw MDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBj IDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9m aW5pc2hfb3V0cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZj LzFmOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFj ZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAw MDAwMDA4MDJhM2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgw MjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQg PGlwX2ZpbmlzaF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNf YnVpbGQrMC8wPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAv YTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7 IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAw MDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxf X2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3 YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2gr MTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpU cmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAw MGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2 NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9y Y3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysx NmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy YWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAw MDAwODAyNjU1YTAgPGlwX3Jjdis1MTAvNTc4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBf cmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMTAxMzNjIDxkb19JUlErZjQvMTE4 PgoKQ29kZTsgIDAwMDAwMDAwODAyNGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KMDAwMDAwMDAg PF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRiMjAwIDxfX2tmcmVlX3NrYis5OC8xMzA+CiAgIDA6 ICAgOGUwNjAwOWMgIGx3ICAgICAgYTIsMTU2KHMwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIwNCA8 X19rZnJlZV9za2IrOWMvMTMwPgogICA0OiAgIDEwYzAwMDBlICBiZXF6ICAgIGEyLDQwIDxfUEMr MHg0MD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMDggPF9fa2ZyZWVfc2tiK2EwLzEzMD4KICAgODog ICAyNDAzMDAwMSAgbGkgICAgICB2MSwxCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVl X3NrYithNC8xMzA+ICAgPD09PT09CiAgIGM6ICAgOGNjMjAwMDAgIGx3ICAgICAgdjAsMChhMikg ICA8PT09PT0KQ29kZTsgIDAwMDAwMDAwODAyNGIyMTAgPF9fa2ZyZWVfc2tiK2E4LzEzMD4KICAx MDogICBjMDQ1MDAwMCAgbGwgICAgICBhMSwwKHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIxNCA8 X19rZnJlZV9za2IrYWMvMTMwPgogIDE0OiAgIDAwYTMyMDIzICBzdWJ1ICAgIGEwLGExLHYxCkNv ZGU7ICAwMDAwMDAwMDgwMjRiMjE4IDxfX2tmcmVlX3NrYitiMC8xMzA+CiAgMTg6ICAgZTA0NDAw MDAgIHNjICAgICAgYTAsMCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGIyMWMgPF9fa2ZyZWVfc2ti K2I0LzEzMD4KICAxYzogICAxMDgwZmZmYyAgYmVxeiAgICBhMCwxMCA8X1BDKzB4MTA+CkNvZGU7 ICAwMDAwMDAwMDgwMjRiMjIwIDxfX2tmcmVlX3NrYitiOC8xMzA+CiAgMjA6ICAgMDBhMzIwMjMg IHN1YnUgICAgYTAsYTEsdjEKCktlcm5lbCBwYW5pYzogQWllZSwga2lsbGluZyBpbnRlcnJ1cHQg aGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3QgYmUgcmVsaWFibGUu Cg== ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_send.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_send.oops Content-Disposition: attachment; filename="recent.cap_send.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWM4MWUwMCAwMDAw MzI2MCAwMDAwMzI2MCAwMDAwMDAwMCAwMDAwMDAwMCA4YjM4YjM0MAokOCA6IDAwMDAwMDMwIDgw MmRhMWEwIDAwMDAwMDEwIGJmYmViZGJjIGEzYTJhMWEwIDAwMDAwMDAwIDhhYjc5ZGU4IGE3YTZh NWE0CiQxNjogMDAwMDMyNjAgMDAwMDAwMDEgOGFlYTgyNjAgYzAxNzI5NGMgMDAwMDAwMGYgODAy NGIxNzggYzAxNjdhYjggYzAxNzI5NTAKJDI0OiAwMDAwMDAxMCAwMDQwZTBmMCAgICAgICAgICAg ICAgICAgICA4YWI3ODAwMCA4YWI3OWE2OCBjMDE3MjdkOCA4MDI0YjA5NApIaSA6IDAwMDAwMDAw CkxvIDogMDAwMDAwMGIKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBtZG0td2lwcm8tbm8tZGUgKHBpZDogNDEw LCBzdGFja3BhZ2U9OGFiNzgwMDApClN0YWNrOiAgICA4YWI3OWFkOCA4MDM2OWJmMCAwMDAwMDAw NCA4MDI1YTQ4NCA4YjZiNTQ2MCA4YjZiNTQ2MCA4MDI0YjA5NAogZmZmYmM0NzMgODAyNmE5MGMg ODAzYTA0MDAgODEyYmVhODAgODAzYTA0MDAgOGI2YjU0NjAgOGIzOGIzNjAgODAyNGIwYzQKIDAw MDAwMDAwIDAwMDAwMDAyIDAwMDA0MGQyIDgwMmRhMGUwIDhhYjc5YzU4IDhiNmI1NDYwIDgwMjRi Mjk4IDgxMmI2NDYwCiA4MDNhMDQwMCA4MDNhMDQwMCA4YWI3OWFkOCA4YjZiNTQ2MCBjMDE3MWY1 OCA4MTJiZWJjMCA4MDM5MDZhOCAwMDAwMDAyMAogODAyNGFlMzggOGI2YjU3ODAgOGFhYzQwZjYg OGI0MjhkNjAgMDAwMDAwMDAgODEyYmViYzAgOGFhYzAwMTAgOGFlYTgyNjAKIDAwMDA0MGQyIC4u LgpDYWxsIFRyYWNlOiAgIFs8ODAyNWE0ODQ+XSBbPDgwMjRiMDk0Pl0gWzw4MDI2YTkwYz5dIFs8 ODAyNGIwYzQ+XSBbPDgwMmRhMGUwPl0KIFs8ODAyNGIyOTg+XSBbPGMwMTcxZjU4Pl0gWzw4MDI0 YWUzOD5dIFs8ODAyZDlkODA+XSBbPGMwMTcxZTEwPl0gWzw4MDI2YTkwYz5dCiBbPGMwMTcyNDE0 Pl0gWzxjMDE3NDBlOD5dIFs8ODAyNWE0ODQ+XSBbPDgwMjZhOTBjPl0gWzw4MDI2YTkwYz5dIFs8 ODAyNWE5NDg+XQogWzw4MDJkYTBlMD5dIFs8ODAyNmE5MGM+XSBbPGMwMTc1MWRjPl0gWzw4MDI2 YThkND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhMzBjPl0KIFs8ODAyNmExODQ+XSBbPDgwMjY3MTMw Pl0gWzw4MDI2NzFiMD5dIFs8ODAyNmE3NDQ+XSBbPDgwMjVhOThjPl0gWzw4MDI2NzEzMD5dCiBb PDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4MDI1 YTQ4ND5dIFs8YzAxY2UyYTg+XQogWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVhOThj Pl0gWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5l KTogZ2FyYmFnZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhjNTAw MDA4ICBhYzQwMDAwOCAgMDIwMDIwMjEgPDhjODIwMDc0PiAxMDUxMDAwOSAgOGUxMDAwMDAgIGMw ODMwMDc0ICAwMDcxMTAyMyAgZTA4MjAwNzQKCgo+PlJBOyAgMDAwMDAwMDA4MDI0YjA5NCA8c2ti X3JlbGVhc2VfZGF0YStiMC9iYz4KPj4kOTsgMDAwMDAwMDA4MDJkYTFhMCA8bWVtc2V0X3BhcnRp YWwrMjQvNmM+Cj4+JDIxOyAwMDAwMDAwMDgwMjRiMTc4IDxfX2tmcmVlX3NrYisxMC8xMzA+Cj4+ JDMxOyAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9kYXRhK2IwL2JjPgoKPj5QQzsgIDAw MDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9PT09PQoKVHJhY2U7 IDAwMDAwMDAwODAyNWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI0 YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlw X2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNGIwYzQgPGtmcmVlX3Nr Ym1lbSsyNC9jOD4KVHJhY2U7IDAwMDAwMDAwODAyZGEwZTAgPG1lbXNldCswLzFjPgpUcmFjZTsg MDAwMDAwMDA4MDI0YjI5OCA8c2tiX2Nsb25lKzAvMjUwPgpUcmFjZTsgMDAwMDAwMDBjMDE3MWY1 OCA8RU5EX09GX0NPREUrM2ZkZGY3NTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNGFlMzggPGFs bG9jX3NrYisxNjAvMjYwPgpUcmFjZTsgMDAwMDAwMDA4MDJkOWQ4MCA8bWVtY3B5KzAvND4KVHJh Y2U7IDAwMDAwMDAwYzAxNzFlMTAgPEVORF9PRl9DT0RFKzNmZGRmNjEwLz8/Pz8+ClRyYWNlOyAw MDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAw MGMwMTcyNDE0IDxFTkRfT0ZfQ09ERSszZmRkZmMxNC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDBjMDE3 NDBlOCA8RU5EX09GX0NPREUrM2ZkZTE4ZTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNWE0ODQg PG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291 dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIr MTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy YWNlOyAwMDAwMDAwMDgwMmRhMGUwIDxtZW1zZXQrMC8xYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5 MGMgPGlwX2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwYzAxNzUxZGMgPEVO RF9PRl9DT0RFKzNmZGUyOWRjLz8/Pz8+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOGQ0IDxpcF9maW5p c2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0 cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFnbWVudCszYzgvNTAw PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUwMD4KVHJhY2U7IDAw MDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4 MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhNzQ0 IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hv b2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5p c2grMTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8z MjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJh Y2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAw MDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4 NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09E RSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsx MC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJh Y2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAw MDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4 IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYwIDxza2JfZHJv cF9mcmFnbGlzdCsyOC83ND4KMDAwMDAwMDAgPF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYw IDxza2JfZHJvcF9mcmFnbGlzdCsyOC83ND4KICAgMDogICA4YzUwMDAwOCAgbHcgICAgICBzMCw4 KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2NCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMmMvNzQ+CiAg IDQ6ICAgYWM0MDAwMDggIHN3ICAgICAgemVybyw4KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2 OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzAvNzQ+CiAgIDg6ICAgMDIwMDIwMjEgIG1vdmUgICAgYTAs czAKQ29kZTsgIDAwMDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9 PT09PQogICBjOiAgIDhjODIwMDc0ICBsdyAgICAgIHYwLDExNihhMCkgICA8PT09PT0KQ29kZTsg IDAwMDAwMDAwODAyNGFmNzAgPHNrYl9kcm9wX2ZyYWdsaXN0KzM4Lzc0PgogIDEwOiAgIDEwNTEw MDA5ICBiZXEgICAgIHYwLHMxLDM4IDxfUEMrMHgzOD4KQ29kZTsgIDAwMDAwMDAwODAyNGFmNzQg PHNrYl9kcm9wX2ZyYWdsaXN0KzNjLzc0PgogIDE0OiAgIDhlMTAwMDAwICBsdyAgICAgIHMwLDAo czApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc4IDxza2JfZHJvcF9mcmFnbGlzdCs0MC83ND4KICAx ODogICBjMDgzMDA3NCAgbGwgICAgICB2MSwxMTYoYTApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjdj IDxza2JfZHJvcF9mcmFnbGlzdCs0NC83ND4KICAxYzogICAwMDcxMTAyMyAgc3VidSAgICB2MCx2 MSxzMQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY4MCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDgvNzQ+CiAg MjA6ICAgZTA4MjAwNzQgIHNjICAgICAgdjAsMTE2KGEwKQoKS2VybmVsIHBhbmljOiBBaWVlLCBr aWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3VlZC4gIFJlc3VsdHMgbWF5 IG5vdCBiZSByZWxpYWJsZS4K ------_=_NextPart_001_01C5669D.E951F95B-- From jaegert@us.ibm.com Wed Jun 1 07:00:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 07:00:54 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51E0bXq012794 for ; Wed, 1 Jun 2005 07:00:44 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j51Dxf89024306 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j51DxftR261752 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j51DxfQI017299 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j51DxfnV017282; Wed, 1 Jun 2005 09:59:41 -0400 In-Reply-To: To: James Morris Cc: chrisw@osdl.org, latten@austin.ibm.com, netdev@oss.sgi.com, sds@tycho.nsa.gov, serue@us.ibm.com MIME-Version: 1.0 Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Trent Jaeger Message-ID: Date: Wed, 1 Jun 2005 09:59:40 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/01/2005 09:59:40, Serialize complete at 06/01/2005 09:59:40 Content-Type: multipart/alternative; boundary="=_alternative 004CDF1985257013_=" X-archive-position: 1943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev This is a multipart message in MIME format. --=_alternative 004CDF1985257013_= Content-Type: text/plain; charset="US-ASCII" OK. Thanks for the detailed comments. I will review and get back with comments and mods (probably next week). Regards, Trent. ------------------------------------------------------------ Trent Jaeger IBM T.J. Watson Research Center 19 Skyline Drive, Hawthorne, NY 10532 (914) 784-7225, FAX (914) 784-7225 James Morris 05/31/2005 12:15 AM To: Trent Jaeger/Watson/IBM@IBMUS cc: netdev@oss.sgi.com, , serue@us.ltcfwd.linux.ibm.com, , Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks On Tue, 17 May 2005, jaegert wrote: Ok, my last review in this iteration. > @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr > x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; > x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; > } > + > + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; > + if (sec_ctx != NULL) { > + if (security_xfrm_state_alloc(x, sec_ctx)) > + goto out; You should propagate the return value of security_xfrm_state_alloc() here by assigning it to err. > -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o > +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o What about making nethooks.o (or whatever it'll be called) conditionally compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o) > + * ISSUES: > + * 1. Caching packets, so they are not dropped during negotiation This needs to be done for IPsec in general, not sure what the status is. > + * 2. Emulating a reasonable SO_PEERSEC across machines This may not be too difficult if we limit this to connected TCP sockets. > + * 3. Testing sk_policy setting with context What does this mean? Overall, this looks like a really good approach to the problem. - James -- James Morris --=_alternative 004CDF1985257013_= Content-Type: text/html; charset="US-ASCII"
OK.

Thanks for the detailed comments.  

I will review and get back with comments and mods (probably next week).

Regards,
Trent.
------------------------------------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225


James Morris <jmorris@redhat.com>

05/31/2005 12:15 AM

       
        To:        Trent Jaeger/Watson/IBM@IBMUS
        cc:        netdev@oss.sgi.com, <chrisw@osdl.org>, serue@us.ltcfwd.linux.ibm.com, <latten@austin.ibm.com>, <sds@tycho.nsa.gov>
        Subject:        Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks



On Tue, 17 May 2005, jaegert wrote:
Ok, my last review in this iteration.
> @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr
>                x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime;
>                x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime;
>        }
> +
> +       sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1];
> +       if (sec_ctx != NULL) {
> +               if (security_xfrm_state_alloc(x, sec_ctx))
> +                       goto out;
You should propagate the return value of security_xfrm_state_alloc() here
by assigning it to err.
> -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o
> +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o
What about making nethooks.o (or whatever it'll be called) conditionally
compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o)

> + * ISSUES:
> + *   1. Caching packets, so they are not dropped during negotiation
This needs to be done for IPsec in general, not sure what the status is.
> + *   2. Emulating a reasonable SO_PEERSEC across machines
This may not be too difficult if we limit this to connected TCP sockets.
> + *   3. Testing sk_policy setting with context
What does this mean?

Overall, this looks like a really good approach to the problem.

- James
--
James Morris
<jmorris@redhat.com>


--=_alternative 004CDF1985257013_=-- From kernel@linuxace.com Wed Jun 1 10:01:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 10:01:59 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j51H1sXq026236 for ; Wed, 1 Jun 2005 10:01:54 -0700 Received: (qmail 20132 invoked by uid 0); 1 Jun 2005 17:00:58 -0000 Date: Wed, 1 Jun 2005 10:00:58 -0700 From: Phil Oester To: Herbert Xu Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: 2.6.12-rcx networking oops Message-ID: <20050601170058.GA20112@linuxace.com> References: <20050531224012.GA16789@linuxace.com> <20050601054955.GA2625@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601054955.GA2625@gondor.apana.org.au> User-Agent: Mutt/1.4.1i X-archive-position: 1944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev On Wed, Jun 01, 2005 at 03:49:55PM +1000, Herbert Xu wrote: > This looks like stack overflow. %esi is meant to be "res" which is > a local variable. As you can see, it's pointing below %esp and > threadinfo. Ok, so I enabled DEBUG_STACKOVERFLOW in addition to CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, and got the below today...so maybe it is a slab issue? 0xc0238cdd is in dst_alloc (net/core/dst.c:124). 119 if (ops->gc && atomic_read(&ops->entries) > ops->gc_thresh) { 120 if (ops->gc()) 121 return NULL; 122 } 123 dst = kmem_cache_alloc(ops->kmem_cachep, SLAB_ATOMIC); 0xc013912b is at mm/slab.c:3077. 3072 size = kmem_cache_size(c); 3073 local_irq_restore(flags); 3074 } 3075 3076 return size; 3077 } Phil invalid operand: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00016292 (2.6.12-rc5-git5) EIP is at ksize+0x7b/0x100 eax: c0238cdd ebx: f7ba9c20 ecx: f7babf78 edx: dcc59000 esi: 00000020 edi: 0000e3ba ebp: c0338d98 esp: c0338d88 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0338000 task=c1989b00) Stack: 00000000 04000000 c02d1a00 ffffff97 c0338db0 c0238cdd c0338e58 04000000 00000000 ffffff97 c0338eb4 c0245cb7 00000002 f7b01000 c0338dec c0338df0 f7318ef8 00000000 00000000 00000001 f72dbef8 0000a704 103c243b f27ceec0 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1b0 [] die+0xf9/0x180 [] do_trap+0xa0/0xb0 [] do_invalid_op+0xa9/0xc0 [] error_code+0x4f/0x54 [] dst_alloc+0x2d/0xa0 [] ip_route_input_slow+0x4a7/0x840 [] ip_route_input+0x9a/0x160 [] ip_rcv+0x3b0/0x4d0 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x180/0x4d0 [] e1000_clean+0x40/0xe0 [] net_rx_action+0x90/0x130 [] __do_softirq+0xd4/0xf0 [] do_softirq+0x52/0x70 ======================= [] irq_exit+0x3a/0x40 [] do_IRQ+0x68/0xa0 [] common_interrupt+0x1a/0x20 [] cpu_idle+0x7b/0x80 [] start_secondary+0x73/0x90 [<00000000>] stext+0x3feffd6c/0xc [] 0xc198afb4 Code: 8d 05 0c e2 34 c0 e8 e9 25 15 00 e9 96 dd ff ff 8d 05 0c e2 34 c0 e8 a9 25 15 00 e9 00 e2 ff ff 8d 05 0c e2 34 c0 e8 c9 25 15 00 23 e2 ff ff 8d 05 0c e2 34 c0 e8 89 25 15 00 e9 84 e2 ff ff <0>Kernel panic - not syncing: Fatal exception in interrupt From mmporter@cox.net Wed Jun 1 11:26:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 11:26:39 -0700 (PDT) Received: from fed1rmmtao09.cox.net (fed1rmmtao09.cox.net [68.230.241.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51IQXXq032754 for ; Wed, 1 Jun 2005 11:26:34 -0700 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050601182536.OPJC7275.fed1rmmtao09.cox.net@liberty.homelinux.org>; Wed, 1 Jun 2005 14:25:36 -0400 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA16886; Wed, 1 Jun 2005 11:25:34 -0700 Date: Wed, 1 Jun 2005 11:25:34 -0700 From: Matt Porter To: torvalds@osdl.org, akpm@osdl.org, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: [PATCH][3/3] RapidIO support: net driver over messaging Message-ID: <20050601112534.C16559@cox.net> References: <20050601110836.A16559@cox.net> <20050601111516.B16559@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050601111516.B16559@cox.net>; from mporter@kernel.crashing.org on Wed, Jun 01, 2005 at 11:15:17AM -0700 X-archive-position: 1945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Adds an "Ethernet" driver which sends Ethernet packets over the standard RapidIO messaging. This depends on the core RIO patch for mailbox/doorbell access. Signed-off-by: Matt Porter Index: drivers/net/Kconfig =================================================================== --- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Kconfig (mode:100644) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Kconfig (mode:100644) @@ -2185,6 +2185,20 @@ tristate "iSeries Virtual Ethernet driver support" depends on NETDEVICES && PPC_ISERIES +config RIONET + tristate "RapidIO Ethernet over messaging driver support" + depends on NETDEVICES && RAPIDIO + +config RIONET_TX_SIZE + int "Number of outbound queue entries" + depends on RIONET + default "128" + +config RIONET_RX_SIZE + int "Number of inbound queue entries" + depends on RIONET + default "128" + config FDDI bool "FDDI driver support" depends on NETDEVICES && (PCI || EISA) Index: drivers/net/Makefile =================================================================== --- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Makefile (mode:100644) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Makefile (mode:100644) @@ -58,6 +58,7 @@ obj-$(CONFIG_VIA_RHINE) += via-rhine.o obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o +obj-$(CONFIG_RIONET) += rionet.o # # end link order section Index: drivers/net/rionet.c =================================================================== --- /dev/null (tree:f0bf7810dbe8c4073832d6c3785364084e9523a7) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/rionet.c (mode:100644) @@ -0,0 +1,622 @@ +/* + * rionet - Ethernet driver over RapidIO messaging services + * + * Copyright 2005 MontaVista Software, Inc. + * Matt Porter + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define DRV_NAME "rionet" +#define DRV_VERSION "0.1" +#define DRV_AUTHOR "Matt Porter " +#define DRV_DESC "Ethernet over RapidIO" + +MODULE_AUTHOR(DRV_AUTHOR); +MODULE_DESCRIPTION(DRV_DESC); +MODULE_LICENSE("GPL"); + +#define RIONET_DEFAULT_MSGLEVEL 0 +#define RIONET_DOORBELL_JOIN 0x1000 +#define RIONET_DOORBELL_LEAVE 0x1001 + +#define RIONET_MAILBOX 0 + +#define RIONET_TX_RING_SIZE CONFIG_RIONET_TX_SIZE +#define RIONET_RX_RING_SIZE CONFIG_RIONET_RX_SIZE + +LIST_HEAD(rionet_peers); + +struct rionet_private { + struct rio_mport *mport; + struct sk_buff *rx_skb[RIONET_RX_RING_SIZE]; + struct sk_buff *tx_skb[RIONET_TX_RING_SIZE]; + struct net_device_stats stats; + int rx_slot; + int tx_slot; + int tx_cnt; + int ack_slot; + spinlock_t lock; + u32 msg_enable; +}; + +struct rionet_peer { + struct list_head node; + struct rio_dev *rdev; + struct resource *res; +}; + +static int rionet_check = 0; +static int rionet_capable = 1; +static struct net_device *sndev = NULL; + +/* + * This is a fast lookup table for for translating TX + * Ethernet packets into a destination RIO device. It + * could be made into a hash table to save memory depending + * on system trade-offs. + */ +static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES]; + +#define is_rionet_capable(pef, src_ops, dst_ops) \ + ((pef & RIO_PEF_INB_MBOX) && \ + (pef & RIO_PEF_INB_DOORBELL) && \ + (src_ops & RIO_SRC_OPS_DOORBELL) && \ + (dst_ops & RIO_DST_OPS_DOORBELL)) +#define dev_rionet_capable(dev) \ + is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops) + +#define RIONET_MAC_MATCH(x) (*(u32 *)x == 0x00010001) +#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4)) + +static struct net_device_stats *rionet_stats(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + return &rnet->stats; +} + +static int rionet_rx_clean(struct net_device *ndev) +{ + int i; + int error = 0; + struct rionet_private *rnet = ndev->priv; + void *data; + + i = rnet->rx_slot; + + do { + if (!rnet->rx_skb[i]) { + rnet->stats.rx_dropped++; + continue; + } + + if (!(data = rio_get_inb_message(rnet->mport, RIONET_MAILBOX))) + break; + + rnet->rx_skb[i]->data = data; + skb_put(rnet->rx_skb[i], RIO_MAX_MSG_SIZE); + rnet->rx_skb[i]->dev = sndev; + rnet->rx_skb[i]->protocol = + eth_type_trans(rnet->rx_skb[i], sndev); + error = netif_rx(rnet->rx_skb[i]); + + if (error == NET_RX_DROP) { + rnet->stats.rx_dropped++; + } else if (error == NET_RX_BAD) { + if (netif_msg_rx_err(rnet)) + printk(KERN_WARNING "%s: bad rx packet\n", + DRV_NAME); + rnet->stats.rx_errors++; + } else { + rnet->stats.rx_packets++; + rnet->stats.rx_bytes += RIO_MAX_MSG_SIZE; + } + + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != rnet->rx_slot); + + return i; +} + +static void rionet_rx_fill(struct net_device *ndev, int end) +{ + int i; + struct rionet_private *rnet = ndev->priv; + + i = rnet->rx_slot; + do { + rnet->rx_skb[i] = dev_alloc_skb(RIO_MAX_MSG_SIZE); + + if (!rnet->rx_skb[i]) + break; + + rio_add_inb_buffer(rnet->mport, RIONET_MAILBOX, + rnet->rx_skb[i]->data); + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != end); + + rnet->rx_slot = i; +} + +static int rionet_queue_tx_msg(struct sk_buff *skb, struct net_device *ndev, + struct rio_dev *rdev) +{ + struct rionet_private *rnet = ndev->priv; + + rio_add_outb_message(rnet->mport, rdev, 0, skb->data, skb->len); + rnet->tx_skb[rnet->tx_slot] = skb; + + rnet->stats.tx_packets++; + rnet->stats.tx_bytes += skb->len; + + if (++rnet->tx_cnt == RIONET_TX_RING_SIZE) + netif_stop_queue(ndev); + + if (++rnet->tx_slot == RIONET_TX_RING_SIZE) + rnet->tx_slot = 0; + + if (netif_msg_tx_queued(rnet)) + printk(KERN_INFO "%s: queued skb %8.8x len %8.8x\n", DRV_NAME, + (u32) skb, skb->len); + + return 0; +} + +static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev) +{ + int i; + struct rionet_private *rnet = ndev->priv; + struct ethhdr *eth = (struct ethhdr *)skb->data; + u16 destid; + + spin_lock_irq(&rnet->lock); + + if ((rnet->tx_cnt + 1) > RIONET_TX_RING_SIZE) { + netif_stop_queue(ndev); + spin_unlock_irq(&rnet->lock); + return -EBUSY; + } + + if (eth->h_dest[0] & 0x01) { + /* + * XXX Need to delay queuing if ring max is reached, + * flush additional packets in tx_event() before + * awakening the queue. We can easily exceed ring + * size with a large number of nodes or even a + * small number where the ring is relatively full + * on entrance to hard_start_xmit. + */ + for (i = 0; i < RIO_MAX_ROUTE_ENTRIES; i++) + if (rionet_active[i]) + rionet_queue_tx_msg(skb, ndev, + rionet_active[i]); + } else if (RIONET_MAC_MATCH(eth->h_dest)) { + destid = RIONET_GET_DESTID(eth->h_dest); + if (rionet_active[destid]) + rionet_queue_tx_msg(skb, ndev, rionet_active[destid]); + } + + spin_unlock_irq(&rnet->lock); + + return 0; +} + +static int rionet_set_mac_address(struct net_device *ndev, void *p) +{ + struct sockaddr *addr = p; + + if (!is_valid_ether_addr(addr->sa_data)) + return -EADDRNOTAVAIL; + + memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len); + + return 0; +} + +static int rionet_change_mtu(struct net_device *ndev, int new_mtu) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_change_mtu(): not implemented\n", DRV_NAME); + + return 0; +} + +static void rionet_set_multicast_list(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_set_multicast_list(): not implemented\n", + DRV_NAME); +} + +static void rionet_dbell_event(struct rio_mport *mport, u16 sid, u16 tid, + u16 info) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + struct rionet_peer *peer; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: doorbell sid %4.4x tid %4.4x info %4.4x", + DRV_NAME, sid, tid, info); + if (info == RIONET_DOORBELL_JOIN) { + if (!rionet_active[sid]) { + list_for_each_entry(peer, &rionet_peers, node) { + if (peer->rdev->destid == sid) + rionet_active[sid] = peer->rdev; + } + rio_mport_send_doorbell(mport, sid, + RIONET_DOORBELL_JOIN); + } + } else if (info == RIONET_DOORBELL_LEAVE) { + rionet_active[sid] = NULL; + } else { + if (netif_msg_intr(rnet)) + printk(KERN_WARNING "%s: unhandled doorbell\n", + DRV_NAME); + } +} + +static void rionet_inb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + int n; + struct net_device *ndev = sndev; + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: inbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + spin_lock(&rnet->lock); + if ((n = rionet_rx_clean(ndev)) != rnet->rx_slot) + rionet_rx_fill(ndev, n); + spin_unlock(&rnet->lock); +} + +static void rionet_outb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + + spin_lock(&rnet->lock); + + if (netif_msg_intr(rnet)) + printk(KERN_INFO + "%s: outbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + while (rnet->tx_cnt && (rnet->ack_slot != slot)) { + /* dma unmap single */ + dev_kfree_skb_irq(rnet->tx_skb[rnet->ack_slot]); + rnet->tx_skb[rnet->ack_slot] = NULL; + if (++rnet->ack_slot == RIONET_TX_RING_SIZE) + rnet->ack_slot = 0; + rnet->tx_cnt--; + } + + if (rnet->tx_cnt < RIONET_TX_RING_SIZE) + netif_wake_queue(ndev); + + spin_unlock(&rnet->lock); +} + +static int rionet_open(struct net_device *ndev) +{ + int i, rc = 0; + struct rionet_peer *peer, *tmp; + u32 pwdcsr; + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: open\n", DRV_NAME); + + if ((rc = rio_request_inb_dbell(rnet->mport, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE, + rionet_dbell_event)) < 0) + goto out; + + if ((rc = rio_request_inb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_RX_RING_SIZE, + rionet_inb_msg_event)) < 0) + goto out; + + if ((rc = rio_request_outb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_TX_RING_SIZE, + rionet_outb_msg_event)) < 0) + goto out; + + /* Initialize inbound message ring */ + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + rnet->rx_skb[i] = NULL; + rnet->rx_slot = 0; + rionet_rx_fill(ndev, 0); + + rnet->tx_slot = 0; + rnet->tx_cnt = 0; + rnet->ack_slot = 0; + + spin_lock_init(&rnet->lock); + + rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL; + + netif_carrier_on(ndev); + netif_start_queue(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (!(peer->res = rio_request_outb_dbell(peer->rdev, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE))) + { + printk(KERN_ERR "%s: error requesting doorbells\n", + DRV_NAME); + continue; + } + + /* + * If device has initialized inbound doorbells, + * send a join message + */ + rio_read_config_32(peer->rdev, RIO_WRITE_PORT_CSR, &pwdcsr); + if (pwdcsr & RIO_DOORBELL_AVAIL) + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_JOIN); + } + + out: + return rc; +} + +static int rionet_close(struct net_device *ndev) +{ + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + struct rionet_peer *peer, *tmp; + int i; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: close\n", DRV_NAME); + + netif_stop_queue(ndev); + netif_carrier_off(ndev); + + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + if (rnet->rx_skb[i]) + kfree_skb(rnet->rx_skb[i]); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (rionet_active[peer->rdev->destid]) { + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_LEAVE); + rionet_active[peer->rdev->destid] = NULL; + } + rio_release_outb_dbell(peer->rdev, peer->res); + } + + rio_release_inb_dbell(rnet->mport, RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE); + rio_release_inb_mbox(rnet->mport, RIONET_MAILBOX); + rio_release_outb_mbox(rnet->mport, RIONET_MAILBOX); + + return 0; +} + +static void rionet_remove(struct rio_dev *rdev) +{ + struct net_device *ndev = NULL; + struct rionet_peer *peer, *tmp; + + unregister_netdev(ndev); + kfree(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + list_del(&peer->node); + kfree(peer); + } +} + +static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + return -EOPNOTSUPP; +} + +static void rionet_get_drvinfo(struct net_device *ndev, + struct ethtool_drvinfo *info) +{ + struct rionet_private *rnet = ndev->priv; + + strcpy(info->driver, DRV_NAME); + strcpy(info->version, DRV_VERSION); + strcpy(info->fw_version, "n/a"); + sprintf(info->bus_info, "RIO master port %d", rnet->mport->id); +} + +static u32 rionet_get_msglevel(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + return rnet->msg_enable; +} + +static void rionet_set_msglevel(struct net_device *ndev, u32 value) +{ + struct rionet_private *rnet = ndev->priv; + + rnet->msg_enable = value; +} + +static u32 rionet_get_link(struct net_device *ndev) +{ + return netif_carrier_ok(ndev); +} + +static struct ethtool_ops rionet_ethtool_ops = { + .get_drvinfo = rionet_get_drvinfo, + .get_msglevel = rionet_get_msglevel, + .set_msglevel = rionet_set_msglevel, + .get_link = rionet_get_link, +}; + +static int rionet_setup_netdev(struct rio_mport *mport) +{ + int rc = 0; + struct net_device *ndev = NULL; + struct rionet_private *rnet; + u16 device_id; + + /* Allocate our net_device structure */ + ndev = alloc_etherdev(sizeof(struct rionet_private)); + if (ndev == NULL) { + printk(KERN_INFO "%s: could not allocate ethernet device.\n", + DRV_NAME); + rc = -ENOMEM; + goto out; + } + + /* + * XXX hack, store point a static at ndev so we can get it... + * Perhaps need an array of these that the handler can + * index via the mbox number. + */ + sndev = ndev; + + /* Set up private area */ + rnet = (struct rionet_private *)ndev->priv; + rnet->mport = mport; + + /* Set the default MAC address */ + device_id = rio_local_get_device_id(mport); + ndev->dev_addr[0] = 0x00; + ndev->dev_addr[1] = 0x01; + ndev->dev_addr[2] = 0x00; + ndev->dev_addr[3] = 0x01; + ndev->dev_addr[4] = device_id >> 8; + ndev->dev_addr[5] = device_id & 0xff; + + /* Fill in the driver function table */ + ndev->open = &rionet_open; + ndev->hard_start_xmit = &rionet_start_xmit; + ndev->stop = &rionet_close; + ndev->get_stats = &rionet_stats; + ndev->change_mtu = &rionet_change_mtu; + ndev->set_mac_address = &rionet_set_mac_address; + ndev->set_multicast_list = &rionet_set_multicast_list; + ndev->do_ioctl = &rionet_ioctl; + SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops); + + ndev->mtu = RIO_MAX_MSG_SIZE - 14; + + SET_MODULE_OWNER(ndev); + + rc = register_netdev(ndev); + if (rc != 0) + goto out; + + printk("%s: %s %s Version %s, MAC %02x:%02x:%02x:%02x:%02x:%02x\n", + ndev->name, + DRV_NAME, + DRV_DESC, + DRV_VERSION, + ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2], + ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]); + + out: + return rc; +} + +/* + * XXX Make multi-net safe + */ +static int rionet_probe(struct rio_dev *rdev, const struct rio_device_id *id) +{ + int rc = -ENODEV; + u32 lpef, lsrc_ops, ldst_ops; + struct rionet_peer *peer; + + /* If local device is not rionet capable, give up quickly */ + if (!rionet_capable) + goto out; + + /* + * First time through, make sure local device is rionet + * capable, setup netdev, and set flags so this is skipped + * on later probes + */ + if (!rionet_check) { + rio_local_read_config_32(rdev->net->hport, RIO_PEF_CAR, &lpef); + rio_local_read_config_32(rdev->net->hport, RIO_SRC_OPS_CAR, + &lsrc_ops); + rio_local_read_config_32(rdev->net->hport, RIO_DST_OPS_CAR, + &ldst_ops); + if (!is_rionet_capable(lpef, lsrc_ops, ldst_ops)) { + printk(KERN_ERR + "%s: local device is not network capable\n", + DRV_NAME); + rionet_check = 1; + rionet_capable = 0; + goto out; + } + + rc = rionet_setup_netdev(rdev->net->hport); + rionet_check = 1; + } + + /* + * If the remote device has mailbox/doorbell capabilities, + * add it to the peer list. + */ + if (dev_rionet_capable(rdev)) { + if (!(peer = kmalloc(sizeof(struct rionet_peer), GFP_KERNEL))) { + rc = -ENOMEM; + goto out; + } + peer->rdev = rdev; + list_add_tail(&peer->node, &rionet_peers); + } + + out: + return rc; +} + +static struct rio_device_id rionet_id_table[] = { + {RIO_DEVICE(RIO_ANY_ID, RIO_ANY_ID)} +}; + +static struct rio_driver rionet_driver = { + .name = "rionet", + .id_table = rionet_id_table, + .probe = rionet_probe, + .remove = rionet_remove, +}; + +static int __init rionet_init(void) +{ + return rio_register_driver(&rionet_driver); +} + +static void __exit rionet_exit(void) +{ + rio_unregister_driver(&rionet_driver); +} + +module_init(rionet_init); +module_exit(rionet_exit); From davem@davemloft.net Wed Jun 1 11:56:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 11:56:30 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51IuMXq001813 for ; Wed, 1 Jun 2005 11:56:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdYMW-0003Ku-N6; Wed, 01 Jun 2005 11:54:44 -0700 Date: Wed, 01 Jun 2005 11:54:44 -0700 (PDT) Message-Id: <20050601.115444.68157121.davem@davemloft.net> To: raghunathan.venkatesan@wipro.com Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, linux@der-keiler.de Subject: Re: Unable to handle kernel paging request at virtual address 04000460 From: "David S. Miller" In-Reply-To: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> References: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Please don't ask the community to debug your custom kernel with private VPN driver modules installed. From afleming@freescale.com Wed Jun 1 13:46:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 13:46:40 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51KkZXq010355 for ; Wed, 1 Jun 2005 13:46:36 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j51KouYg020960; Wed, 1 Jun 2005 13:50:56 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51KmgBH016530; Wed, 1 Jun 2005 15:48:42 -0500 (CDT) In-Reply-To: <20050531105939.7486e071@dxpl.pdx.osdl.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 15:45:26 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On May 31, 2005, at 12:59, Stephen Hemminger wrote: > Here are some patches: > * allow phy's to be modules > * use driver owner for ref count > * make local functions static where ever possible I agree with all these. > * get rid of bus read may sleep implication in comment. > since you are holding phy spin lock it better not!! But not this one. The phy_read and phy_write functions are reading from and writing to a bus. It is a reasonable implementation to have the operation block in the bus driver, and be awoken when an interrupt signals the operation is done. All of the phydev spinlocks have been arranged so as to prevent the lock being taken during interrupt time. Unless I've misunderstood spinlocks (it wouldn't be the first time), as long as the lock is never taken in interrupt time, it should be ok to hold the lock, and wait for an interrupt before clearing the lock. Andy Fleming From gwingerde@home.nl Wed Jun 1 13:58:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 13:58:33 -0700 (PDT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51KwRXq011274 for ; Wed, 1 Jun 2005 13:58:29 -0700 Received: from [213.51.128.134] (port=47200 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1DdaHH-0007SM-4Z; Wed, 01 Jun 2005 22:57:27 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([217.123.128.105]:58103 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1DdaHF-0000hZ-Q1; Wed, 01 Jun 2005 22:57:25 +0200 Message-ID: <429E1FAB.6080503@home.nl> Date: Wed, 01 Jun 2005 22:50:51 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [PATCH] ieee80211: Update generic definitions to latest specs. Content-Type: multipart/mixed; boundary="------------020800010603020503020809" X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 1948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020800010603020503020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached patch updates the definitions of the generic ieee80211 stack to the latest versions of the published 802.11x specification suite. Please review and apply. Signed-off-by: Gertjan van Wingerde --------------020800010603020503020809 Content-Type: text/plain; name="ieee80211.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ieee80211.diff" Index: include/net/ieee80211.h =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/include/net/ieee80211.h (mode:100644) +++ uncommitted/include/net/ieee80211.h (mode:100644) @@ -103,7 +103,7 @@ #define MAX_FRAG_THRESHOLD 2346U /* Frame control field constants */ -#define IEEE80211_FCTL_VERS 0x0002 +#define IEEE80211_FCTL_VERS 0x0003 #define IEEE80211_FCTL_FTYPE 0x000c #define IEEE80211_FCTL_STYPE 0x00f0 #define IEEE80211_FCTL_TODS 0x0100 @@ -111,8 +111,8 @@ #define IEEE80211_FCTL_MOREFRAGS 0x0400 #define IEEE80211_FCTL_RETRY 0x0800 #define IEEE80211_FCTL_PM 0x1000 -#define IEEE80211_FCTL_MOREDATA 0x2000 -#define IEEE80211_FCTL_WEP 0x4000 +#define IEEE80211_FCTL_MOREDATA 0x2000 +#define IEEE80211_FCTL_PROTECTEDFRAME 0x4000 #define IEEE80211_FCTL_ORDER 0x8000 #define IEEE80211_FTYPE_MGMT 0x0000 @@ -131,6 +131,7 @@ #define IEEE80211_STYPE_DISASSOC 0x00A0 #define IEEE80211_STYPE_AUTH 0x00B0 #define IEEE80211_STYPE_DEAUTH 0x00C0 +#define IEEE80211_STYPE_ACTION 0x00D0 /* control */ #define IEEE80211_STYPE_PSPOLL 0x00A0 @@ -251,6 +252,7 @@ #define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) +#define WLAN_FC_GET_VERS(fc) ((fc) & IEEE80211_FCTL_VERS) #define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) #define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) @@ -271,6 +273,9 @@ #define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5) #define WLAN_CAPABILITY_PBCC (1<<6) #define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7) +#define WLAN_CAPABILITY_SPECTRUM_MGMT (1<<8) +#define WLAN_CAPABILITY_SHORT_SLOT_TIME (1<<10) +#define WLAN_CAPABILITY_OSSS_OFDM (1<<13) /* Status codes */ #define WLAN_STATUS_SUCCESS 0 @@ -285,9 +290,24 @@ #define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17 #define WLAN_STATUS_ASSOC_DENIED_RATES 18 /* 802.11b */ -#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19 +#define WLAN_STATUS_ASSOC_DENIED_NOSHORTPREAMBLE 19 #define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20 #define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21 +/* 802.11h */ +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22 +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23 +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24 +/* 802.11g */ +#define WLAN_STATUS_ASSOC_DENIED_NOSHORTTIME 25 +#define WLAN_STATUS_ASSOC_DENIED_NODSSSOFDM 26 +/* 802.11i */ +#define WLAN_STATUS_INVALID_IE 40 +#define WLAN_STATUS_INVALID_GROUP_CIPHER 41 +#define WLAN_STATUS_INVALID_PAIRWISE_CIPHER 42 +#define WLAN_STATUS_INVALID_AKMP 43 +#define WLAN_STATUS_UNSUPP_RSN_VERSION 44 +#define WLAN_STATUS_INVALID_RSN_IE_CAP 45 +#define WLAN_STATUS_CIPHER_SUITE_REJECTED 46 /* Reason codes */ #define WLAN_REASON_UNSPECIFIED 1 @@ -299,6 +319,22 @@ #define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7 #define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8 #define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 +/* 802.11h */ +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10 +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11 +/* 802.11i */ +#define WLAN_REASON_INVALID_IE 13 +#define WLAN_REASON_MIC_FAILURE 14 +#define WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT 15 +#define WLAN_REASON_GROUP_KEY_HANDSHAKE_TIMEOUT 16 +#define WLAN_REASON_IE_DIFFERENT 17 +#define WLAN_REASON_INVALID_GROUP_CIPHER 18 +#define WLAN_REASON_INVALID_PAIRWISE_CIPHER 19 +#define WLAN_REASON_INVALID_AKMP 20 +#define WLAN_REASON_UNSUPP_RSN_VERSION 21 +#define WLAN_REASON_INVALID_RSN_IE_CAP 22 +#define WLAN_REASON_IEEE8021X_FAILED 23 +#define WLAN_REASON_CIPHER_SUITE_REJECTED 24 #define IEEE80211_STATMASK_SIGNAL (1<<0) @@ -477,17 +513,32 @@ #define BEACON_PROBE_SSID_ID_POSITION 12 /* Management Frame Information Element Types */ -#define MFIE_TYPE_SSID 0 -#define MFIE_TYPE_RATES 1 -#define MFIE_TYPE_FH_SET 2 -#define MFIE_TYPE_DS_SET 3 -#define MFIE_TYPE_CF_SET 4 -#define MFIE_TYPE_TIM 5 -#define MFIE_TYPE_IBSS_SET 6 -#define MFIE_TYPE_CHALLENGE 16 -#define MFIE_TYPE_RSN 48 -#define MFIE_TYPE_RATES_EX 50 -#define MFIE_TYPE_GENERIC 221 +#define MFIE_TYPE_SSID 0 +#define MFIE_TYPE_RATES 1 +#define MFIE_TYPE_FH_SET 2 +#define MFIE_TYPE_DS_SET 3 +#define MFIE_TYPE_CF_SET 4 +#define MFIE_TYPE_TIM 5 +#define MFIE_TYPE_IBSS_SET 6 +#define MFIE_TYPE_COUNTRY 7 +#define MFIE_TYPE_HOP_PARAMS 8 +#define MFIE_TYPE_HOP_TABLE 9 +#define MFIE_TYPE_REQUEST 10 +#define MFIE_TYPE_CHALLENGE 16 +#define MFIE_TYPE_POWER_CONSTRAINT 32 +#define MFIE_TYPE_POWER_CAPABILITY 33 +#define MFIE_TYPE_TPC_REQUEST 34 +#define MFIE_TYPE_TPC_REPORT 35 +#define MFIE_TYPE_SUPP_CHANNELS 36 +#define MFIE_TYPE_CSA 37 +#define MFIE_TYPE_MEASURE_REQUEST 38 +#define MFIE_TYPE_MEASURE_REPORT 39 +#define MFIE_TYPE_QUIET 40 +#define MFIE_TYPE_IBSS_DFS 41 +#define MFIE_TYPE_ERP_INFO 42 +#define MFIE_TYPE_RSN 48 +#define MFIE_TYPE_RATES_EX 50 +#define MFIE_TYPE_GENERIC 221 struct ieee80211_info_element_hdr { u8 id; Index: net/ieee80211/ieee80211_rx.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_rx.c (mode:100644) +++ uncommitted/net/ieee80211/ieee80211_rx.c (mode:100644) @@ -440,7 +440,7 @@ crypt->ops->decrypt_mpdu == NULL)) crypt = NULL; - if (!crypt && (fc & IEEE80211_FCTL_WEP)) { + if (!crypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME)) { /* This seems to be triggered by some (multicast?) * frames from other than current BSS, so just drop the * frames silently instead of filling system log with @@ -456,7 +456,7 @@ #ifdef NOT_YET if (type != WLAN_FC_TYPE_DATA) { if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH && - fc & IEEE80211_FCTL_WEP && ieee->host_decrypt && + fc & IEEE80211_FCTL_PROTECTEDFRAME && ieee->host_decrypt && (keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0) { printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth " @@ -557,7 +557,7 @@ /* skb: hdr + (possibly fragmented, possibly encrypted) payload */ - if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && (keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0) goto rx_dropped; @@ -565,7 +565,7 @@ /* skb: hdr + (possibly fragmented) plaintext payload */ // PR: FIXME: hostap has additional conditions in the "if" below: - // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + // ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) { int flen; struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr); @@ -621,12 +621,12 @@ /* skb: hdr + (possible reassembled) full MSDU payload; possibly still * encrypted/authenticated */ - if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt)) goto rx_dropped; hdr = (struct ieee80211_hdr *) skb->data; - if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) { + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep) { if (/*ieee->ieee802_1x &&*/ ieee80211_is_eapol_frame(ieee, skb)) { #ifdef CONFIG_IEEE80211_DEBUG @@ -647,7 +647,7 @@ } #ifdef CONFIG_IEEE80211_DEBUG - if (crypt && !(fc & IEEE80211_FCTL_WEP) && + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && ieee80211_is_eapol_frame(ieee, skb)) { struct eapol *eap = (struct eapol *)(skb->data + 24); @@ -656,7 +656,7 @@ } #endif - if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep && + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep && !ieee80211_is_eapol_frame(ieee, skb)) { IEEE80211_DEBUG_DROP( "dropped unencrypted RX data " Index: net/ieee80211/ieee80211_tx.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_tx.c (mode:100644) +++ uncommitted/net/ieee80211/ieee80211_tx.c (mode:100644) @@ -314,7 +314,7 @@ if (encrypt) fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | - IEEE80211_FCTL_WEP; + IEEE80211_FCTL_PROTECTEDFRAME; else fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; Index: drivers/net/wireless/atmel.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/drivers/net/wireless/atmel.c (mode:100644) +++ uncommitted/drivers/net/wireless/atmel.c (mode:100644) @@ -867,7 +867,7 @@ header.duration_id = 0; header.seq_ctl = 0; if (priv->wep_is_on) - frame_ctl |= IEEE80211_FCTL_WEP; + frame_ctl |= IEEE80211_FCTL_PROTECTEDFRAME; if (priv->operating_mode == IW_MODE_ADHOC) { memcpy(&header.addr1, skb->data, 6); memcpy(&header.addr2, dev->dev_addr, 6); @@ -1117,7 +1117,7 @@ /* probe for CRC use here if needed once five packets have arrived with the same crc status, we assume we know what's happening and stop probing */ if (priv->probe_crc) { - if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP)) { + if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME)) { priv->do_rx_crc = probe_crc(priv, rx_packet_loc, msdu_size); } else { priv->do_rx_crc = probe_crc(priv, rx_packet_loc + 24, msdu_size - 24); @@ -1132,7 +1132,7 @@ } /* don't CRC header when WEP in use */ - if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP))) { + if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME))) { crc = crc32_le(0xffffffff, (unsigned char *)&header, 24); } msdu_size -= 24; /* header */ @@ -2677,7 +2677,7 @@ auth.alg = cpu_to_le16(C80211_MGMT_AAN_SHAREDKEY); /* no WEP for authentication frames with TrSeqNo 1 */ if (priv->CurrentAuthentTransactionSeqNum != 1) - header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_WEP); + header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_PROTECTEDFRAME); } else { auth.alg = cpu_to_le16(C80211_MGMT_AAN_OPENSYSTEM); } --------------020800010603020503020809-- From shemminger@osdl.org Wed Jun 1 14:20:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:20:21 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LKIXq012488 for ; Wed, 1 Jun 2005 14:20:19 -0700 Received: from [10.8.0.74] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LJFj9029727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 1 Jun 2005 14:19:16 -0700 Message-ID: <429E2653.6010101@osdl.org> Date: Wed, 01 Jun 2005 14:19:15 -0700 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Andy Fleming wrote: > > On May 31, 2005, at 12:59, Stephen Hemminger wrote: > >> Here are some patches: >> * allow phy's to be modules >> * use driver owner for ref count >> * make local functions static where ever possible > > > I agree with all these. > >> * get rid of bus read may sleep implication in comment. >> since you are holding phy spin lock it better not!! > > > But not this one. The phy_read and phy_write functions are reading > from and writing to a bus. It is a reasonable implementation to have > the operation block in the bus driver, and be awoken when an > interrupt signals the operation is done. All of the phydev spinlocks > have been arranged so as to prevent the lock being taken during > interrupt time. > > Unless I've misunderstood spinlocks (it wouldn't be the first time), > as long as the lock is never taken in interrupt time, it should be ok > to hold the lock, and wait for an interrupt before clearing the lock. The problem is that sleeping is defined in the linux kernel as meaning waiting on a mutual exclusion primitive (like semaphore) that puts the current thread to sleep. It is not legal to sleep with a spinlock held. In the phy_read code you do: spin_lock_bh(&bus->mdio_lock); retval = bus->read(bus, phydev->addr, regnum); spin_unlock_bh(&bus->mdio_lock); If the bus->read function were to do something like start a request and wait on a semaphore, then you would be sleeping with a spin lock held. So bus->read can not sleep! (as sleep is defined in the linux kernel). From mchan@broadcom.com Wed Jun 1 14:32:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:32:36 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LWXXq013485 for ; Wed, 1 Jun 2005 14:32:33 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 01 Jun 2005 14:31:20 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 1 Jun 2005 14:31:18 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBO09844; Wed, 1 Jun 2005 14:31:15 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA04566; Wed, 1 Jun 2005 14:31:15 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 21:31:14 +0000 Received: from rh4 by nt-irva-0741; 01 Jun 2005 13:33:39 -0700 Subject: Re: Locking model for NAPI drivers From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050531.154847.63995530.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> Date: Wed, 01 Jun 2005 13:33:39 -0700 Message-ID: <1117658019.4310.58.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E80F6A21VO4407082-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-31 at 15:48 -0700, David S. Miller wrote: > Once we make this transformation, we need some way to synchronize > with the IRQ handler when shutting down the device or making major > configuration changes to the chip. > > The idea I came up with is a two-bit atomic bitmask. When base > level code wants to quiesce interrupt processing, it takes the > necessary driver spinlocks, sets the "SYNC" bit in the bitmask, > forces and IRQ to be asserted by the tg3 card, then waits for the > COMPLETE bit to get set by the interrupt handler. > During light testing, I found a race condition that caused tg3_irq_quiesce() to spin forever. The race condition is shown below. CPU1 CPU2 tg3_interrupt_tagged() tg3_netif_stop() netif_poll_disable() netif_rx_schedule() will do nothing tg3_full_lock() tg3_irq_quiesce() Because netif_poll_disable() is called, netif_rx_schedule() will do nothing in the interrupt handler. As a result, tg3_poll() will never be called to re-enable interrupts. Since interrupts are disabled, tg3_irq_quiesce() will not be able to set the interrupts and cause the interrupt handler to be called again, and therefore will wait forever. Even adding another call to tg3_irq_sync() at the end of the interrupt handler does not eliminate the race condition. I suppose we can enable interrupts in tg3_irq_quiesce() after setting the SYNC bit. From shemminger@osdl.org Wed Jun 1 14:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:38:41 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LcbXq014435 for ; Wed, 1 Jun 2005 14:38:37 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LbZjA032260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Jun 2005 14:37:35 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j51LbYcg019087; Wed, 1 Jun 2005 14:37:35 -0700 Date: Wed, 1 Jun 2005 14:37:34 -0700 From: Stephen Hemminger To: Gertjan van Wingerde Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. Message-ID: <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> In-Reply-To: <429E1FAB.6080503@home.nl> References: <429E1FAB.6080503@home.nl> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 01 Jun 2005 22:50:51 +0200 Gertjan van Wingerde wrote: > Hi, > > Attached patch updates the definitions of the generic ieee80211 stack to > the latest versions of the published 802.11x specification suite. > Please review and apply. > > Signed-off-by: Gertjan van Wingerde > Could you change the elements that fix to be enum's instead of define's example: /* Management Frame Information Element Types */ enum ieee80211_mfie { MFIE_TYPE_SSID = 0, MFIE_TYPE_RATES = 1, MFIE_TYPE_FH_SET= 2, ... From shemminger@osdl.org Wed Jun 1 14:42:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:42:28 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LgOXq015034 for ; Wed, 1 Jun 2005 14:42:24 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LfNjA032676 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Jun 2005 14:41:24 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j51LfN66019413; Wed, 1 Jun 2005 14:41:23 -0700 Date: Wed, 1 Jun 2005 14:41:23 -0700 From: Stephen Hemminger To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II Message-ID: <20050601144123.2bc11c06@dxpl.pdx.osdl.net> In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 1 Jun 2005 15:45:26 -0500 Andy Fleming wrote: > > On May 31, 2005, at 12:59, Stephen Hemminger wrote: > > > Here are some patches: > > * allow phy's to be modules > > * use driver owner for ref count > > * make local functions static where ever possible > > I agree with all these. > > > * get rid of bus read may sleep implication in comment. > > since you are holding phy spin lock it better not!! > On a different note, I am not sure that using sysfs/kobject bus object is the right thing for this object. Isn't the phy instance really just an kobject whose parent is the network device? I can't see a 1 to N relationship between phy bus and phy objects existing. The main use I can see for being a driver object is to catch suspend/resume, and wouldn't you want that to be tied to the network device. From davem@davemloft.net Wed Jun 1 15:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:23:02 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MMwXq017804 for ; Wed, 1 Jun 2005 15:22:59 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddbag-0004kn-VP; Wed, 01 Jun 2005 15:21:35 -0700 Date: Wed, 01 Jun 2005 15:21:34 -0700 (PDT) Message-Id: <20050601.152134.120445266.davem@davemloft.net> To: mchan@broadcom.com Cc: netdev@oss.sgi.com Subject: Re: Locking model for NAPI drivers From: "David S. Miller" In-Reply-To: <1117658019.4310.58.camel@rh4> References: <20050531.154847.63995530.davem@davemloft.net> <1117658019.4310.58.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev From: "Michael Chan" Date: Wed, 01 Jun 2005 13:33:39 -0700 > I suppose we can enable interrupts in tg3_irq_quiesce() after setting > the SYNC bit. Since the caller shuts down NAPI ->poll(), after setting the SYNC bit we can just check the MAILBOX register, and if a '1' is there just return. Does one need to mask out the upper bits of the regiser in order to avoid seeing the IRQ tag in such a comparison? Another potential problem is if the chip is hung for some reason, and even though an interrupt is asserted it does not send the interrupt. We'd hang in this case as well. Therefore it may be wise to add a timeout to the COMPLETE bit polling loop in order to handle such cases properly. From mchan@broadcom.com Wed Jun 1 15:32:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:32:58 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MWsXq018653 for ; Wed, 1 Jun 2005 15:32:55 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 01 Jun 2005 15:31:50 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 1 Jun 2005 15:31:49 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBP11233; Wed, 1 Jun 2005 15:31:45 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA24578; Wed, 1 Jun 2005 15:31:45 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 22:31:45 +0000 Received: from rh4 by nt-irva-0741; 01 Jun 2005 14:34:10 -0700 Subject: Re: Locking model for NAPI drivers From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050601.152134.120445266.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> <1117658019.4310.58.camel@rh4> <20050601.152134.120445266.davem@davemloft.net> Date: Wed, 01 Jun 2005 14:34:10 -0700 Message-ID: <1117661650.4310.62.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E80E8DC1VO4417184-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Wed, 2005-06-01 at 15:21 -0700, David S. Miller wrote: > From: "Michael Chan" > Date: Wed, 01 Jun 2005 13:33:39 -0700 > > > I suppose we can enable interrupts in tg3_irq_quiesce() after setting > > the SYNC bit. > > Since the caller shuts down NAPI ->poll(), after setting the SYNC bit > we can just check the MAILBOX register, and if a '1' is there just > return. Does one need to mask out the upper bits of the regiser in > order to avoid seeing the IRQ tag in such a comparison? > No, just check for the value 1 since that's the value we use to disable interrupts. The value read back will always be 1 if 1 was previously written to it. From afleming@freescale.com Wed Jun 1 15:38:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:38:03 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MbxXq019309 for ; Wed, 1 Jun 2005 15:37:59 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j51Mf5oC009076; Wed, 1 Jun 2005 15:41:06 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51Me9Xo018231; Wed, 1 Jun 2005 17:40:10 -0500 (CDT) In-Reply-To: <20050601144123.2bc11c06@dxpl.pdx.osdl.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> <20050601144123.2bc11c06@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A2D608A-D818-455B-96F4-ED42413556C0@freescale.com> Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 17:36:54 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Jun 1, 2005, at 16:41, Stephen Hemminger wrote: > On Wed, 1 Jun 2005 15:45:26 -0500 > Andy Fleming wrote: >> >>> * get rid of bus read may sleep implication in comment. >>> since you are holding phy spin lock it better not!! >>> >> >> > > On a different note, I am not sure that using sysfs/kobject bus object > is the right thing for this object. Isn't the phy instance really > just > an kobject whose parent is the network device? I can't see a 1 to N > relationship between phy bus and phy objects existing. Well, the MII Management bus is, in fact, a bus. When a network driver wants to modify a PHY, it must access that bus. Many ethernet controllers have a 1 to 1 relationship, since a typical NIC is a PCI card with 1 ethernet port (meaning one controller, and one PHY). However, many systems have multiple ethernet controllers attached to one bus, which configures multiple PHYs. Currently, these systems have been relying on luck to prevent multiple accesses to the same bus. This tends to work because all of the PHY support is contained within the ethernet driver, so it is easy for such drivers to ensure that only one PHY transaction is done at a time. This system begins to fall apart, though, when the PHY drivers start operating more independently to react to changing PHY state. It really begins to fall apart if you have multiple drivers trying to access a shared bus. For instance, the 8560 ADS board has 2 gigabit ethernet ports controlled by the gianfar driver, and 2 10/100 ports in the CPM subsystem, controlled by the fcc_enet driver. These two drivers each have an access point for the bus, which use different mechanisms (one is a bit bang interface, and one is register based). Using the new abstraction, it is possible for the FCC driver to use the gianfar driver's bus, thus saving code, and reducing complexity. > > The main use I can see for being a driver object is to catch > suspend/resume, > and wouldn't you want that to be tied to the network device. It would be quite easy for the network driver to suspend or resume the PHY and bus objects under the new abstraction. However, if eth0 is suspended, should it suspend the whole bus, and all the PHYs on it? By making the MII bus an independent entity, eth0 can be suspended, and it can choose to suspend its PHY, but eth1 can continue to access its PHY over the bus, since those aren't suspended. From afleming@freescale.com Wed Jun 1 15:43:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:44:01 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MhwXq020018 for ; Wed, 1 Jun 2005 15:43:58 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j51MmPBu017065; Wed, 1 Jun 2005 15:48:25 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51MkCFY019534; Wed, 1 Jun 2005 17:46:12 -0500 (CDT) In-Reply-To: <429E2653.6010101@osdl.org> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> <429E2653.6010101@osdl.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 17:42:56 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Jun 1, 2005, at 16:19, Stephen Hemminger wrote: > Andy Fleming wrote: >> >> But not this one. The phy_read and phy_write functions are >> reading from and writing to a bus. It is a reasonable >> implementation to have the operation block in the bus driver, and >> be awoken when an interrupt signals the operation is done. All >> of the phydev spinlocks have been arranged so as to prevent the >> lock being taken during interrupt time. >> >> Unless I've misunderstood spinlocks (it wouldn't be the first >> time), as long as the lock is never taken in interrupt time, it >> should be ok to hold the lock, and wait for an interrupt before >> clearing the lock. >> > > > The problem is that sleeping is defined in the linux kernel as > meaning waiting on a mutual exclusion > primitive (like semaphore) that puts the current thread to sleep. > It is not legal to sleep with a spinlock held. > In the phy_read code you do: > spin_lock_bh(&bus->mdio_lock); > retval = bus->read(bus, phydev->addr, regnum); > spin_unlock_bh(&bus->mdio_lock); > > If the bus->read function were to do something like start a request > and wait on a semaphore, then > you would be sleeping with a spin lock held. So bus->read can not > sleep! (as sleep is defined in the > linux kernel). Hmm... I understand this reasoning, but I still need a way for a bus read to wait for an interrupt before returning. I suppose I can just have the code spin while it waits, but that seems wrong, somehow. I'm open to any suggestions. From gwingerde@home.nl Wed Jun 1 20:55:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 20:55:50 -0700 (PDT) Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523thXq012188 for ; Wed, 1 Jun 2005 20:55:46 -0700 Received: from [213.51.128.134] (port=59856 helo=smtp3.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1Ddgn8-0007D7-Al; Thu, 02 Jun 2005 05:54:46 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([217.123.128.105]:59933 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1Ddgn6-00071G-DC; Thu, 02 Jun 2005 05:54:44 +0200 Message-ID: <429E8175.7010609@home.nl> Date: Thu, 02 Jun 2005 05:48:05 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. References: <429E1FAB.6080503@home.nl> <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> In-Reply-To: <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 1958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Stephen Hemminger wrote: >On Wed, 01 Jun 2005 22:50:51 +0200 >Gertjan van Wingerde wrote: > > > >>Hi, >> >>Attached patch updates the definitions of the generic ieee80211 stack to >>the latest versions of the published 802.11x specification suite. >>Please review and apply. >> >>Signed-off-by: Gertjan van Wingerde >> >> >> >Could you change the elements that fix to be enum's instead of define's > >example: > >/* Management Frame Information Element Types */ >enum ieee80211_mfie { > MFIE_TYPE_SSID = 0, > MFIE_TYPE_RATES = 1, > MFIE_TYPE_FH_SET= 2, >... > Hi Stephen, Well, my patch is really just an add-on to the existing code. Converting to enums is really a follow-up patch that can be applied on top of this one. I'm happy to produce a patch if everybody agrees. Jeff, any opinions on this? Best regards, Gertjan. From raghunathan.venkatesan@wipro.com Wed Jun 1 20:54:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 20:54:52 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523sjXq012029 for ; Wed, 1 Jun 2005 20:54:48 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id CA4D8205E7; Thu, 2 Jun 2005 09:14:50 +0530 (IST) Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id B055A205E5; Thu, 2 Jun 2005 09:14:50 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 09:23:44 +0530 Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Jun 2005 09:23:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Unable to handle kernel paging request at virtual address 04000460 Date: Thu, 2 Jun 2005 09:20:21 +0530 Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0E461B8@CHN-SNR-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unable to handle kernel paging request at virtual address 04000460 Thread-Index: AcVm23XgN0MUhNi8RfmehJZdjhz+YAASlBxQ From: To: Cc: , , X-OriginalArrivalTime: 02 Jun 2005 03:53:43.0508 (UTC) FILETIME=[AB960140:01C56726] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j523sjXq012029 X-archive-position: 1957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: raghunathan.venkatesan@wipro.com Precedence: bulk X-list: netdev Hi David, I understand that the linux community may not be able to debug it for me. All I require is if people have seen similar problems (the problems we face are w.r.t to kfree_skb and skb_drop_fraglist crashing due to some reason, which could be a Memory Management issue or some thing we are not aware of), then let us know the patches, so that we can try them out here. Thankyou for your response. Regards, Raghu -----Original Message----- From: David S. Miller [mailto:davem@davemloft.net] Sent: Thursday, June 02, 2005 12:25 AM To: Raghunathan Venkatesan (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; linux@der-keiler.de Subject: Re: Unable to handle kernel paging request at virtual address 04000460 Please don't ask the community to debug your custom kernel with private VPN driver modules installed. From herbert@gondor.apana.org.au Thu Jun 2 02:45:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 02:45:22 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529jEXq000794 for ; Thu, 2 Jun 2005 02:45:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdmFD-0007y2-00; Thu, 02 Jun 2005 19:44:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdmFA-0006o5-00; Thu, 02 Jun 2005 19:44:04 +1000 Date: Thu, 2 Jun 2005 19:44:04 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPV4/IPV6] Replace spin_lock_irq with spin_lock_bh Message-ID: <20050602094404.GA10316@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: In light of my recent patch to net/ipv4/udp.c that replaced the spin_lock_irq calls on the receive queue lock with spin_lock_bh, here is a similar patch for all other occurences of spin_lock_irq on receive/error queue locks in IPv4 and IPv6. In these stacks, we know that they can only be entered from user or softirq context. Therefore it's safe to disable BH only. Signed-off-by: Herbert Xu Since this patch simply improves the consistent use of locking primitives rather fixing any real bugs, it should probably go into net-2.6.13. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -360,14 +360,14 @@ int ip_recv_error(struct sock *sk, struc err = copied; /* Reset and regenerate socket error */ - spin_lock_irq(&sk->sk_error_queue.lock); + spin_lock_bh(&sk->sk_error_queue.lock); sk->sk_err = 0; if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) { sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno; - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); sk->sk_error_report(sk); } else - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); out_free_skb: kfree_skb(skb); diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -691,11 +691,11 @@ static int raw_ioctl(struct sock *sk, in struct sk_buff *skb; int amount = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb != NULL) amount = skb->len; - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); return put_user(amount, (int __user *)arg); } diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c --- a/net/ipv6/datagram.c +++ b/net/ipv6/datagram.c @@ -353,14 +353,14 @@ int ipv6_recv_error(struct sock *sk, str err = copied; /* Reset and regenerate socket error */ - spin_lock_irq(&sk->sk_error_queue.lock); + spin_lock_bh(&sk->sk_error_queue.lock); sk->sk_err = 0; if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) { sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno; - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); sk->sk_error_report(sk); } else { - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); } out_free_skb: diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@ -434,12 +434,12 @@ csum_copy_err: /* Clear queue. */ if (flags&MSG_PEEK) { int clear = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); if (skb == skb_peek(&sk->sk_receive_queue)) { __skb_unlink(skb, &sk->sk_receive_queue); clear = 1; } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); if (clear) kfree_skb(skb); } @@ -971,11 +971,11 @@ static int rawv6_ioctl(struct sock *sk, struct sk_buff *skb; int amount = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb != NULL) amount = skb->tail - skb->h.raw; - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); return put_user(amount, (int __user *)arg); } diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -300,12 +300,12 @@ csum_copy_err: /* Clear queue. */ if (flags&MSG_PEEK) { int clear = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); if (skb == skb_peek(&sk->sk_receive_queue)) { __skb_unlink(skb, &sk->sk_receive_queue); clear = 1; } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); if (clear) kfree_skb(skb); } --cWoXeonUoKmBZSoM-- From herbert@gondor.apana.org.au Thu Jun 2 02:56:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 02:56:10 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529u2Xq001566 for ; Thu, 2 Jun 2005 02:56:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdmPm-00084I-00; Thu, 02 Jun 2005 19:55:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdmPj-0007pT-00; Thu, 02 Jun 2005 19:54:59 +1000 Date: Thu, 2 Jun 2005 19:54:59 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [SCTP] Replace spin_lock_irqsave with spin_lock_bh Message-ID: <20050602095459.GA26638@gondor.apana.org.au> References: <20050602094404.GA10316@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20050602094404.GA10316@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch replaces the spin_lock_irqsave call on the receive queue lock in SCTP with spin_lock_bh. Despite the proliferation of spin_lock_irqsave calls in this stack, it is only entered from the IPv4/IPv6 stack and user space. That is, it is never entered from hardirq context. The call in question is only called from recvmsg which means that IRQs aren't disabled. Therefore it is safe to replace it with spin_lock_bh. Signed-off-by: Herbert Xu As before, this should probably only go into net-2.6.13. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4368,15 +4368,11 @@ static struct sk_buff *sctp_skb_recv_dat * However, this function was corrent in any case. 8) */ if (flags & MSG_PEEK) { - unsigned long cpu_flags; - - sctp_spin_lock_irqsave(&sk->sk_receive_queue.lock, - cpu_flags); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb) atomic_inc(&skb->users); - sctp_spin_unlock_irqrestore(&sk->sk_receive_queue.lock, - cpu_flags); + spin_unlock_bh(&sk->sk_receive_queue.lock); } else { skb = skb_dequeue(&sk->sk_receive_queue); } --2oS5YaxWCcQjTEyO-- From jtbbesaa@bipt106.bi.ehu.es Thu Jun 2 03:40:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 03:40:04 -0700 (PDT) Received: from bipt106.bi.ehu.es (bipt106.bi.ehu.es [158.227.67.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52AdsXq003451 for ; Thu, 2 Jun 2005 03:39:59 -0700 Received: from bipt54.bi.ehu.es ([158.227.75.54] helo=ibook.ziberghetto.dhis.org) by bipt106.bi.ehu.es with esmtp (Exim 3.35 #1 (Debian)) id 1Ddn6I-0002Yr-00; Thu, 02 Jun 2005 12:38:58 +0200 Received: by ibook.ziberghetto.dhis.org (Postfix, from userid 1000) id 1D9BB20F1F; Thu, 2 Jun 2005 12:38:26 +0200 (CEST) From: Alfredo Beaumont Sainz Organization: Euskal Herriko Unibertsitatea To: netdev@oss.sgi.com Subject: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 2 Jun 2005 12:38:19 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2076079.6N4Hu5pznk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> X-archive-position: 1961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jtbbesaa@bipt106.bi.ehu.es Precedence: bulk X-list: netdev --nextPart2076079.6N4Hu5pznk Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/10= 00=20 (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I canno= t=20 make them work a Gbps. I've a crossover cable connecting a interface of the= =20 Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps: # /sbin/mii-tool -v eth1: negotiated 100baseTx-FD, link ok product info: vendor 00:08:18, model 25 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD eth2: negotiated 100baseTx-FD, link ok product info: vendor 00:50:43, model 2 rev 5 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control As you can see, there's no 1000 FD advsertising. Forcing it with ethtool ma= kes=20 them lose link connection: # /usr/sbin/ethtool -s eth1 speed 1000 duplex full # /sbin/mii-tool -v eth1: no link product info: vendor 00:08:18, model 25 rev 0 basic mode: autonegotiation enabled basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD eth2: no link product info: vendor 00:50:43, model 2 rev 5 basic mode: autonegotiation enabled basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control After some secs link is recovered, at 100 again, and dmesg shows the follow= ing=20 kernel messages: tg3: eth1: Link is down. e1000: eth2: e1000_watchdog: NIC Link is Down tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is off for TX and off for RX. e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex According to the messages links would be at 1000 but they are not really. T= he=20 same happens when forcing eth2. I'm using kernel version 2.6.11.11 but it also happened with previous versi= on=20 of the kernel. Any hints? Thanks. =2D-=20 Alfredo Beaumont. GPG: http://aintel.bi.ehu.es/~jtbbesaa/jtbbesaa.gpg.asc Elektronika eta Telekomunikazioak Saila (Ingeniaritza Telematikoa) Euskal Herriko Unibertsitatea, Bilbao (Basque Country). http://www.ehu.es --nextPart2076079.6N4Hu5pznk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCnuGh6KTU/EgLc1ERAgOsAJ9Bs8oPJEelifI+GtiP62cMEfl8ZQCfXxc6 e2z/CGhpOy0qWoXNj22/SMQ= =4LuQ -----END PGP SIGNATURE----- --nextPart2076079.6N4Hu5pznk-- From postman@harrier.cohaesio.com Thu Jun 2 04:34:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 04:34:19 -0700 (PDT) Received: from harrier.cohaesio.com (harrier.cohaesio.com [212.97.128.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52BYFXq009978 for ; Thu, 2 Jun 2005 04:34:16 -0700 Received: by harrier.cohaesio.com (Postfix, from userid 88) id 7BF0647; Thu, 2 Jun 2005 13:33:14 +0200 (CEST) X-Original-To: news2mail@news.cohaesio.com Delivered-To: news2mail@news.cohaesio.com From: "Anders K. Pedersen" Subject: Re: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 02 Jun 2005 13:34:09 +0200 Organization: Cohaesio A/S Lines: 13 Message-ID: References: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: harrier.cohaesio.com 1117711993 26359 212.97.128.136 (2 Jun 2005 11:33:13 GMT) X-Complaints-To: newsmaster@news.cohaesio.com X-Accept-Language: en-us, en To: netdev@oss.sgi.com X-archive-position: 1962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akp@cohaesio.com Precedence: bulk X-list: netdev Alfredo Beaumont Sainz wrote: > I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/1000 > (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I cannot > make them work a Gbps. I've a crossover cable connecting a interface of the > Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps: > > # /sbin/mii-tool -v mii-tool does not (yet) support more than 100 Mbit/s, so it will report a 1000 Mbit/s connection as only running 100 Mbit/s. Use ethtool for now. Regards, Anders K. Pedersen From bunk@stusta.de Thu Jun 2 05:16:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 05:16:26 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j52CGMXq011914 for ; Thu, 2 Jun 2005 05:16:23 -0700 Received: (qmail 16519 invoked from network); 2 Jun 2005 12:15:12 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 2 Jun 2005 12:15:12 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 6DB05BB5F8; Thu, 2 Jun 2005 14:15:11 +0200 (CEST) Date: Thu, 2 Jun 2005 14:15:11 +0200 From: Adrian Bunk To: Andrew Morton , shemminger@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages Message-ID: <20050602121511.GE4992@stusta.de> References: <20050601022824.33c8206e.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601022824.33c8206e.akpm@osdl.org> User-Agent: Mutt/1.5.9i X-archive-position: 1963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: >... > Changes since 2.6.12-rc5-mm1: >... > +tcp-tcp_infra.patch >... > Steve Hemminger's TCP enhancements. >... I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages kernel: bic unavailable using TCP reno I have no problem with such a message being shown once - but once should be enough. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From hadi@cyberus.ca Thu Jun 2 05:27:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 05:27:55 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52CRkXq012728 for ; Thu, 2 Jun 2005 05:27:47 -0700 Received: from mail