From owner-freebsd-drivers@FreeBSD.ORG Sun Feb 8 18:01:16 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E9B71065670 for ; Sun, 8 Feb 2009 18:01:16 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id E43C58FC19 for ; Sun, 8 Feb 2009 18:01:15 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so384148ywt.13 for ; Sun, 08 Feb 2009 10:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=LJm0XtJHXSf+p4If/HX/ORfDlZBUHC8aiAKcF3ZxLf0=; b=C1Eg4H+gjGpjbqgUf3pyAhUj4yxapZWYU2ueqWeRNkVfbVBrfYAAPZMwRiql4eGtBq UYDYvMDSBu3GE4SVWEN6mX0BGQm7xBy6/8ejLkjneywZ8DODRciRZfqBvFJ5TizcRIUj EfM+by47hRbcoaSVWLETNbUXD5SBneXsYPc9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; b=ZiLDXO1G+0whYodQiCC9movkJho7FHGUanmD0FGzVSko93NqNNa+2sMIGKe9T12jNX lW6uDBtXGCUZvaRTsYapW9srwifI/yC+Dq4467987DlUq3wbbxdV4ym4lxYBtex2GPaN HpcHBoxziltDfoYenycBF3yzjHrIziSMON4SY= Received: by 10.100.214.15 with SMTP id m15mr1025940ang.44.1234114691336; Sun, 08 Feb 2009 09:38:11 -0800 (PST) Received: from CORONA ([24.174.5.175]) by mx.google.com with ESMTPS id b29sm8803554ana.51.2009.02.08.09.38.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 09:38:10 -0800 (PST) Date: Sun, 8 Feb 2009 11:32:02 -0600 From: Jason Harmening To: freebsd-drivers@freebsd.org Message-ID: <20090208113202.6d591589@CORONA> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: PCI-Express interrupt issues X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 18:01:16 -0000 Hi All, I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've recently encountered some issues w/ interrupt handling, specifically on PCI-Express systems, and I was hoping someone would be able to help me. Issue #1: The cx88 driver has split interrupt handling between filters and ithreads since filters became available w/ 7.0. For the past year, the filters have been set up to return FILTER_SCHEDULE_THREAD if the status register indicates an interrupt, FILTER_STRAY otherwise. Everything has worked fine. However, I recently stumbled across some documentation indicating that FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified the cx88 driver to do that instead, and that's where things turned strange: On machine #1, which uses a VIA K8T800 chipset, everything still worked fine. On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt handlers were no longer invoked. It's as though the bus driver saw FILTER_HANDLED in the bitmask and assumed the interrupt was already processed without checking to see if an ithread should be scheduled. What's interesting is that the only significant difference between the K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 supports PCI-Express, while the K8T800 is PCI-only. Issue #2: We're working on adding support for a newer generation of PCI-Express cx88 devices, which support message signaled interrupts. When MSIs are enabled for these boards, the interrupts seem to simply stop firing after the first several. During transfers across the cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be transferred successfully, which means the I2C transfer interrupts are working for those bytes. But after that the passive thread will timeout waiting to be signaled by the interrupt handler. The I2C interrupts are handled entirely in their own filter (no ithread here), and they can occur with high frequency (e.g. several hundred per second for large firmware loads). We don't see anything in the system log indicating that an interrupt storm is detected or that throttling is coming into play here. If we revert to legacy INTx interrupts, everything works fine. All other transfer logic is identical between the legacy and MSI cases. The MSI behavior is identical between machine #2 w/ the K8T890 and a third machine w/ an nForce4. We haven't been able to try it anywhere else yet. I'm hoping someone will be able to shed some light on these issues--neither one is a real emergency, but they're both kind of troubling. Thanks, Jason From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 9 15:04:08 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310021065672; Mon, 9 Feb 2009 15:04:08 +0000 (UTC) (envelope-from freebsddog@hotmail.com) Received: from bay0-omc2-s23.bay0.hotmail.com (bay0-omc2-s23.bay0.hotmail.com [65.54.246.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0810D8FC23; Mon, 9 Feb 2009 15:04:07 +0000 (UTC) (envelope-from freebsddog@hotmail.com) Received: from BAY134-W39 ([65.55.139.74]) by bay0-omc2-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 07:04:07 -0800 Message-ID: X-Originating-IP: [88.86.33.236] From: Jim Andersson To: Date: Mon, 9 Feb 2009 16:04:07 +0100 Importance: Normal In-Reply-To: <20090128103926.GA82455@freebsd.weongyo.org> References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2009 15:04:07.0867 (UTC) FILETIME=[A80318B0:01C98AC7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-drivers@freebsd.org Subject: RE: 8187SE driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 15:04:09 -0000 DQoNCg0KPiBGcm9tOiB3ZW9uZ3lvLmplb25nQGdtYWlsLmNvbQ0KPiBEYXRlOiBXZWQsIDI4IEph biAyMDA5IDE5OjM5OjI2ICswOTAwDQo+IFRvOiBmcmVlYnNkZG9nQGhvdG1haWwuY29tDQo+IEND OiBmcmVlYnNkLWRyaXZlcnNAZnJlZWJzZC5vcmcNCj4gU3ViamVjdDogUmU6IEZXOiA4MTg3U0Ug ZHJpdmVyDQo+IA0KPiBPbiBUdWUsIEphbiAyNywgMjAwOSBhdCAwMjoyMzozM1BNICswMTAwLCBK aW0gQW5kZXJzc29uIHdyb3RlOg0KPiA+IA0KPiA+IEZyb206IGZyZWVic2Rkb2dAaG90bWFpbC5j b20NCj4gPiBUbzogd2Vvbmd5b0BmcmVlYnNkLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiA4MTg3U0Ug ZHJpdmVyDQo+ID4gRGF0ZTogVHVlLCAyNyBKYW4gMjAwOSAxNDoyMjoxNSArMDEwMA0KPiA+IA0K PiA+ID4gRnJvbTogd2Vvbmd5by5qZW9uZ0BnbWFpbC5jb20NCj4gPiA+IERhdGU6IE1vbiwgMTkg SmFuIDIwMDkgMTk6MTY6MjMgKzA5MDANCj4gPiA+IFRvOiBmcmVlYnNkZG9nQGhvdG1haWwuY29t DQo+ID4gPiBDQzogZnJlZWJzZC1kcml2ZXJzQGZyZWVic2Qub3JnDQo+ID4gPiBTdWJqZWN0OiBS ZTogODE4N1NFIGRyaXZlcg0KPiA+ID4gDQo+ID4gPiBPbiBTYXQsIEphbiAxNywgMjAwOSBhdCAw NDoxNjo0M1BNICswMTAwLCBKaW0gQW5kZXJzc29uIHdyb3RlOg0KPiA+ID4gPiANCj4gPiA+ID4g PiBGcm9tOiB3ZW9uZ3lvLmplb25nQGdtYWlsLmNvbQ0KPiA+ID4gPiA+IERhdGU6IEZyaSwgMTYg SmFuIDIwMDkgMTM6MDQ6MjYgKzA5MDANCj4gPiA+ID4gPiBUbzogZnJlZWJzZGRvZ0Bob3RtYWls LmNvbQ0KPiA+ID4gPiA+IENDOiBmcmVlYnNkLWRyaXZlcnNAZnJlZWJzZC5vcmcNCj4gPiA+ID4g PiBTdWJqZWN0OiBSZTogODE4N1NFIGRyaXZlcg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IE9uIFRo dSwgSmFuIDE1LCAyMDA5IGF0IDExOjQ4OjMyQU0gKzAxMDAsIEppbSBBbmRlcnNzb24gd3JvdGU6 DQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IEhpIQ0KPiA+ID4gPiA+ID4gIA0KPiA+ID4gPiA+ ID4gSXMgdGhlcmUgYW55IGNoYW5jZSBvZiBnZXR0aW5nIG15IHdpcmVsZXNzIGNhcmQgcnVubmlu ZyBpbg0KPiA+ID4gPiA+ID4gQ1VSUkVOVC4gTGludXggc2F5cyBpdO+/vXMgYSBSZWFsdGVrIDgx ODdTRSB3aXJlbGVzcyBuZXR3b3JrDQo+ID4gPiA+ID4gPiBjYXJkLiBJIGhhdmUgc2VlbiBzb21l IGRyaXZlciBmb3Igb3RoZXIgODE4NyBjYXJkcywgaXMgaXQNCj4gPiA+ID4gPiA+IHBvc3NpYmxl IHRvIGZvcmNlIHN1Y2ggZHJpdmVyIHRvIHRyeSBpZGVudGlmeSB0aGUgY2FyZD8NCj4gPiA+ID4g PiA+ICANCj4gPiA+ID4gPiA+ICANCj4gPiA+ID4gPiA+IEhlcmUgaXMgdGhlIG91dHB1dCBvZiBw Y2ljb25mIC1sdiBpbiBteSBGcmVlQlNEDQo+ID4gPiA+ID4gPiBDVVJSRU5UOm5vbmUxQHBjaTA6 MTowOjA6IGNsYXNzPTB4MDI4MDAwIGNhcmQ9MHg4MTk5MTBlYw0KPiA+ID4gPiA+ID4gY2hpcD0w eDgxOTkxMGVjIHJldj0weDIyIGhkcj0weDAwdmVuZG9yID0gJ1JlYWx0ZWsNCj4gPiA+ID4gPiA+ IFNlbWljb25kdWN0b3InY2xhc3MgPSBuZXR3b3JrIC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJ IHRoaW5rIGEgdGhpbmcgeW91IGNhbiB0cnkgaXMgdGhhdCwgTkRJU3VsYXRvciB1c2luZyBuZGlz KDQpLiAgQUZBSUsNCj4gPiA+ID4gPiB0aGVyZSdzIG5vIHN1cHBvcnQgZm9yIDgxODdTRSBkcml2 ZXIgdW50aWwgbm93Lg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IHJlZ2FyZHMsDQo+ID4gPiA+ID4g V2Vvbmd5byBKZW9uZw0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gSSB0cmllZCBuZGlz dWxhdG9yIGJ1dCBpdCBkaWRuwrR0IHdvcmsuIEkgdXNlZCB0aGUgSU5GIGFuZCB0aGUgU1lTDQo+ ID4gPiA+IGZpbGUgZm9yIFdpbmRvd3MgWHAuIEkgZXZlbiB0cmllZCBpbmNsdWRpbmcgYSBjYXQg ZmlsZS4NCj4gPiA+ID4gQWx0aG91Z2ggb25lIHRoaW5nIGNoYW5nZWQsIHRoZSBjYXJkIGlzIG5v IGxvbmdlciBsaXN0ZWQgd2hlbiBpDQo+ID4gPiA+IHR5cGUgcGNpY29uZiAtbHYuIER1bm5vIGlm IHRoYXTCtHMgZ29vZCBvciBiYWQ/DQo+ID4gPiANCj4gPiA+IEl0IGxvb2tzIGl0J3MgYSBiYWQg bmV3cy4gIENvdWxkIHlvdSBwbGVhc2Ugc2hvdyBtZSBkbWVzZydzIG91cHV0IGFuZA0KPiA+ID4g c3RlcHMgeW91IGZvbGxvd2VkPw0KPiA+ID4gDQo+ID4gPiByZWdhcmRzLA0KPiA+ID4gV2Vvbmd5 byBKZW9uZw0KPiA+ID4gDQo+ID4gDQo+ID4gQXMgZmFyIGFzIEkgY2FuIHNlZSB0aGUgb25seSB0 aGluZyBpbiBkbWVzZyByZWdhcmRpbmcgdGhpcyBjYXJkIGlzOg0KPiA+IA0KPiA+IHBjaTE6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIzDQo+ID4gcGNpMTogPG5ldHdvcms+IGF0IGRldmljZSAwLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkNCj4gPiANCj4gPiBXaGF0IEkgZGlkIHdhcyB0aGlzOiBJIHVz ZWQgbXkgd2luZG93cyB4cCBkcml2ZXJzIGZvciB0aGUgY2FyZCB0aGF0IEkNCj4gPiByZWNpZXZl ZCB3aXRoIHRoZSBjb21wdXRlci4gSSB1c2VkIHRoZSAuc3lzIGFuZCB0aGUgaW5mIGZpbGUuIFRo ZQ0KPiA+IGRyaXZlciBsb2FkcyBnb29kIGJ1dCBubyBpbnRlcmZhY2UgaXMgc2hvd24uIElzIHRo ZSBzb21ld2F5IHRvIGZvcmNlDQo+ID4gdGhlIGRyaXZlciB0byBhdHRhY2ggdG8gcGNpMiBzb21l aG93Pw0KPiANCj4gTm9ybWFsbHkgaWYgaXQgd29ya3Mgd2VsbCB0aGUgZGV2aWNlIHNob3VsZCBi ZSBkZXRlY3RlZCBhdXRvbWF0aWNhbGx5DQo+IGFuZCBzaG91bGQgc2hvdyBzb21lIG1lc3NhZ2Vz IHJlbGF0ZWQgd2l0aCBuZGlzKDQpLiAgSXQgbG9va3MgdGhlcmUgYXJlDQo+IGFub3RoZXIgcHJv YmxlbXMgaW4geW91ciBjYXNlLiAgQlRXIHRoZXJlJ3Mgbm8gd2F5IHRvIGZvcmNlIHRoZSBkcml2 ZXINCj4gdG8gYXR0YWNoLg0KPiANCj4gPiBPciBpcyB0aGVyZSBzb21lIHdheSB0byB1c2UgYSBs aW51eCBkcml2ZXI/IExpbnV4IHNheXMgaXRzIGEgcmVhbHRlaw0KPiA+IDgxODdTRS4NCj4gDQo+ IE5vIHdheSB0byB1c2UgdGhlIGxpbnV4IGRyaXZlci4NCj4gDQo+IHJlZ2FyZHMsDQo+IFdlb25n eW8gSmVvbmcNCj4gDQoNCkl0IHNlZW1zIHRoZXJlIGhhcyBiZWVuIGEgcmVjZW50IHJlbGVhc2Ug b2YgYSBkcml2ZXIgZm9yIE1BQy9PU1ggYWNjb3JkaW5nIHRvIHRoaXMgcGFnZTogaHR0cDovL2Zv cnVtcy5tc2l3aW5kLm5ldC9tYWMvZ3JlYXQtbmV3cy1yZWdhcmRpbmctcnRsODE4N3NlLXdpZmkt bW9kdWxlLXQzOTg2Lmh0bWwNCg0KcGVyaGFwcyBJIGNhbiBwZXJzdWFkZSB0aGVtIGludG8gcmVt YWtpbmcgYSBmcmVlYnNkIGRyaXZlciwgRGFyd2luIGlzIG5vdCB0aGF0IGZhciBmcm9tIEJTRCBy aWdodD8gOy0pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTbnlnZ2EgdGlsbCBkaW5hIGJpbGRlciBzbmFiYnQsIGVu a2VsdCBvY2ggZ3JhdGlzIG1lZCBQaG90b0dhbGxlcnkNCmh0dHA6Ly9kb3dubG9hZC5saXZlLmNv bS9waG90b2dhbGxlcnk= From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 9 15:53:32 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A78106566C for ; Mon, 9 Feb 2009 15:53:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7548FC1F for ; Mon, 9 Feb 2009 15:53:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id D2AAC46B2C; Mon, 9 Feb 2009 10:53:31 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n19FrPvC004537; Mon, 9 Feb 2009 10:53:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Mon, 9 Feb 2009 09:46:46 -0500 User-Agent: KMail/1.9.7 References: <20090208113202.6d591589@CORONA> In-Reply-To: <20090208113202.6d591589@CORONA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090946.46917.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 09 Feb 2009 10:53:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8968/Mon Feb 9 10:06:24 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jason Harmening Subject: Re: PCI-Express interrupt issues X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 15:53:36 -0000 On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: > Hi All, > > I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've > recently encountered some issues w/ interrupt handling, specifically on > PCI-Express systems, and I was hoping someone would be able to help me. > > Issue #1: > > The cx88 driver has split interrupt handling between filters and > ithreads since filters became available w/ 7.0. For the past year, the > filters have been set up to return FILTER_SCHEDULE_THREAD if the status > register indicates an interrupt, FILTER_STRAY otherwise. Everything > has worked fine. > > However, I recently stumbled across some documentation indicating that > FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter > should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified > the cx88 driver to do that instead, and that's where things turned > strange: > > On machine #1, which uses a VIA K8T800 chipset, everything still worked > fine. > > On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt > handlers were no longer invoked. It's as though the bus driver saw > FILTER_HANDLED in the bitmask and assumed the interrupt was already > processed without checking to see if an ithread should be scheduled. > What's interesting is that the only significant difference between the > K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 > supports PCI-Express, while the K8T800 is PCI-only. Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in the kernel? If you don't, then your ithread will never be called if you have a filter (actually, the bus_setup_intr() should fail in that case if you specify both). > Issue #2: > > We're working on adding support for a newer generation of PCI-Express > cx88 devices, which support message signaled interrupts. > When MSIs are enabled for these boards, the interrupts seem to simply > stop firing after the first several. During transfers across the > cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be > transferred successfully, which means the I2C transfer interrupts are > working for those bytes. But after that the passive thread will timeout > waiting to be signaled by the interrupt handler. The I2C interrupts > are handled entirely in their own filter (no ithread here), and they can > occur with high frequency (e.g. several hundred per second for large > firmware loads). We don't see anything in the system log indicating > that an interrupt storm is detected or that throttling is coming into > play here. > > If we revert to legacy INTx interrupts, everything works fine. All > other transfer logic is identical between the legacy and MSI cases. > The MSI behavior is identical between machine #2 w/ the K8T890 and a > third machine w/ an nForce4. We haven't been able to try it anywhere > else yet. > > > I'm hoping someone will be able to shed some light on these > issues--neither one is a real emergency, but they're both kind of > troubling. The only thing I can think of is perhaps a hardware bug. MSI interrupts are edge triggered while INTx are level. However, if a device implements MSI by "listening" to the level-triggered interrupt and sending a message when the level changes and it ever has a bug where it fails to send a message, then it won't recover. FreeBSD doesn't do any masking of interrupts for MSI, it just installs the handler in the IDT and calls it for every interrupt. Thus, if you are not seeing interrupts it is likely not an issue with FreeBSD itself, but an issue in the hardware (or possibly the driver if your interrupt handler doesn't fully ACK something perhaps). -- John Baldwin From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 9 16:11:27 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A391D106566B for ; Mon, 9 Feb 2009 16:11:27 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-qy0-f17.google.com (mail-qy0-f17.google.com [209.85.221.17]) by mx1.freebsd.org (Postfix) with ESMTP id 33C7C8FC0A for ; Mon, 9 Feb 2009 16:11:27 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by qyk10 with SMTP id 10so3637892qyk.19 for ; Mon, 09 Feb 2009 08:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CEnrp+OsScjpqngqP9eu2sEFEjG5DFJfL1cLtJIbY5I=; b=kGYzT4IrWaZ9L6TSrLtczwCBETWI6TMGC6Z3nVExgfN7WSkeEmetdaCW8uIKOk9GPF Kr+dGT8EDFlt15FpbAXvcMG5JOkO9a0H6JwwbucACf1PSF6i2nYemIQTWRndICNPtnNn xV9JeuzHmDZTRLsojzkn3DXrc25W7QCDYyk1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bDKHsCi/EwEMVi+5Aurd7p6NvHDYuhp3g89PzEUEuW0v65mp17+b0R+PnXH/1PQFoS YST1motc/bE7aztvpbS2AAXs63tvaxtlU0gdnPsqs1kY8CuoBq0m+3iNNVltZX4BIYuX 1lcFeFRyGq5sTwhF+1byI8n2c4rIc9c1lZLzU= MIME-Version: 1.0 Received: by 10.229.85.12 with SMTP id m12mr362049qcl.98.1234195880568; Mon, 09 Feb 2009 08:11:20 -0800 (PST) In-Reply-To: <200902090946.46917.jhb@freebsd.org> References: <20090208113202.6d591589@CORONA> <200902090946.46917.jhb@freebsd.org> Date: Mon, 9 Feb 2009 10:11:20 -0600 Message-ID: <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> From: Jason Harmening To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: PCI-Express interrupt issues X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 16:11:28 -0000 On Mon, Feb 9, 2009 at 8:46 AM, John Baldwin wrote: > On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: >> Hi All, >> >> I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've >> recently encountered some issues w/ interrupt handling, specifically on >> PCI-Express systems, and I was hoping someone would be able to help me. >> >> Issue #1: >> >> The cx88 driver has split interrupt handling between filters and >> ithreads since filters became available w/ 7.0. For the past year, the >> filters have been set up to return FILTER_SCHEDULE_THREAD if the status >> register indicates an interrupt, FILTER_STRAY otherwise. Everything >> has worked fine. >> >> However, I recently stumbled across some documentation indicating that >> FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter >> should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified >> the cx88 driver to do that instead, and that's where things turned >> strange: >> >> On machine #1, which uses a VIA K8T800 chipset, everything still worked >> fine. >> >> On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt >> handlers were no longer invoked. It's as though the bus driver saw >> FILTER_HANDLED in the bitmask and assumed the interrupt was already >> processed without checking to see if an ithread should be scheduled. >> What's interesting is that the only significant difference between the >> K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 >> supports PCI-Express, while the K8T800 is PCI-only. > > Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in > the kernel? If you don't, then your ithread will never be called if you have > a filter (actually, the bus_setup_intr() should fail in that case if you > specify both). All machines are running 7.1-STABLE. Filters are enabled across the board, and reverting to just returning FILTER_SCHEDULE_THREAD fixes the issue. > >> Issue #2: >> >> We're working on adding support for a newer generation of PCI-Express >> cx88 devices, which support message signaled interrupts. >> When MSIs are enabled for these boards, the interrupts seem to simply >> stop firing after the first several. During transfers across the >> cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be >> transferred successfully, which means the I2C transfer interrupts are >> working for those bytes. But after that the passive thread will timeout >> waiting to be signaled by the interrupt handler. The I2C interrupts >> are handled entirely in their own filter (no ithread here), and they can >> occur with high frequency (e.g. several hundred per second for large >> firmware loads). We don't see anything in the system log indicating >> that an interrupt storm is detected or that throttling is coming into >> play here. >> >> If we revert to legacy INTx interrupts, everything works fine. All >> other transfer logic is identical between the legacy and MSI cases. >> The MSI behavior is identical between machine #2 w/ the K8T890 and a >> third machine w/ an nForce4. We haven't been able to try it anywhere >> else yet. >> >> >> I'm hoping someone will be able to shed some light on these >> issues--neither one is a real emergency, but they're both kind of >> troubling. > > The only thing I can think of is perhaps a hardware bug. MSI interrupts are > edge triggered while INTx are level. However, if a device implements MSI > by "listening" to the level-triggered interrupt and sending a message when > the level changes and it ever has a bug where it fails to send a message, > then it won't recover. FreeBSD doesn't do any masking of interrupts for MSI, > it just installs the handler in the IDT and calls it for every interrupt. > Thus, if you are not seeing interrupts it is likely not an issue with FreeBSD > itself, but an issue in the hardware (or possibly the driver if your > interrupt handler doesn't fully ACK something perhaps). With this hardware, failing to ACK would just cause a storm, which we'd see w/ INTx as well. But you are right about the possibility of a hardware issue--the particular piece we're testing right now has some other known issues as well. There's a linux driver that seems to work OK w/ MSIs, but they don't actually use hardware I2C and don't use interrupts there. This issue just needs more testing w/ more hardware, and we have a device hint to enable/disable MSIs anyway. > > -- > John Baldwin > From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 9 16:12:13 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79151065674 for ; Mon, 9 Feb 2009 16:12:13 +0000 (UTC) (envelope-from cyril.elkaim@free.fr) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3954C8FC17 for ; Mon, 9 Feb 2009 16:12:11 +0000 (UTC) (envelope-from cyril.elkaim@free.fr) Received: from wmproxy1-g27.free.fr (wmproxy1-g27.free.fr [212.27.42.91]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 1F73B2C8E7 for ; Mon, 9 Feb 2009 16:52:10 +0100 (CET) Received: from zimbra10-e2.priv.proxad.net (zimbra10-e2.priv.proxad.net [172.20.243.160]) by wmproxy1-g27.free.fr (Postfix) with ESMTP id 0C4AE5E6CA for ; Mon, 9 Feb 2009 18:03:27 +0100 (CET) Date: Mon, 9 Feb 2009 16:52:08 +0100 (CET) From: cyril.elkaim@free.fr To: freebsd drivers Message-ID: <124214240.637761234194728394.JavaMail.root@zimbra10-e2.priv.proxad.net> In-Reply-To: <1306049302.637521234194665378.JavaMail.root@zimbra10-e2.priv.proxad.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19661_670433207.1234194728393" X-Originating-IP: [172.20.243.42] X-Mailer: Zimbra 5.0.11_GA_2627.UBUNTU8_64 (ZimbraWebClient - [unknown] (Linux)/5.0.11_GA_2627.UBUNTU8_64) Subject: patch aoe for freebsd 7 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 16:12:14 -0000 ------=_Part_19661_670433207.1234194728393 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello there, Here you'll find an attached patch to compile the coraid aoe driver with freebsd 7. I'm not able to validate this driver myself, so if somebody can test it I will be very grateful. thanks, Cyril Elkaim ------=_Part_19661_670433207.1234194728393 Content-Type: text/x-patch; name=aoe7.patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=aoe7.patch diff -u dev/aoe/Makefile aoe7/Makefile --- dev/aoe/Makefile 2006-05-24 21:48:07.000000000 +0200 +++ aoe7/Makefile 2009-02-09 15:43:18.000000000 +0100 @@ -3,5 +3,6 @@ KMOD= aoe SRCS= aoecmd.c aoedev.c aoenet.c aoeblk.c aoemain.c CFLAGS+= -DFORCE_NETWORK_HOOK -I../.. +EXPORT_SYMS= YES .include diff -u dev/aoe/aoeblk.c aoe7/aoeblk.c --- dev/aoe/aoeblk.c 2006-05-25 19:19:23.000000000 +0200 +++ aoe7/aoeblk.c 2009-02-09 14:46:41.000000000 +0100 @@ -27,6 +27,8 @@ * * $FreeBSD: src/sys/dev/aoe/aoeblk.c,v 1.23.2.5 2004/09/22 16:50:41 ?? Exp $ */ +#include +__FBSDID("$FreeBSD: src/sys/dev/aoe/aoeblk.c,v 1.23.2.5 2004/09/22 16:50:41 ?? Exp $"); /* * aoeblk.c diff -u dev/aoe/aoecmd.c aoe7/aoecmd.c --- dev/aoe/aoecmd.c 2006-05-25 19:13:09.000000000 +0200 +++ aoe7/aoecmd.c 2009-02-09 13:00:16.000000000 +0100 @@ -449,6 +449,17 @@ return (n); } +static u_long +lhget48(u_char *p) +{ + u_long n; + + n = lhget32(p+2); + n <<= 16; + n |= lhget16(p); + return (n); +} + static void ataid_complete(struct aoedev *d, char *id) @@ -460,7 +471,7 @@ n = lhget16(id + (83<<1)); /* Command set supported. */ if (n & (1<<10)) { /* Lba48 */ atomic_set_32(&d->ad_flags, DEVFL_EXT); - d->ad_nsectors = lhget32(id + (100<<1)); /* n lba48 sectors. */ + d->ad_nsectors = lhget48(id + (100<<1)); /* n lba48 sectors. */ } else { atomic_clear_32(&d->ad_flags, DEVFL_EXT); d->ad_nsectors = lhget32(id + (60<<1)); /* n lba28 sectors. */ diff -u dev/aoe/aoenet.c aoe7/aoenet.c --- dev/aoe/aoenet.c 2006-05-25 18:10:11.000000000 +0200 +++ aoe7/aoenet.c 2009-02-09 15:38:05.000000000 +0100 @@ -48,6 +48,8 @@ #include #include #include +#include +#include #include #include @@ -77,8 +79,10 @@ #define NECODES (sizeof(aoe_errlist) / sizeof(char *) - 1) #if (__FreeBSD_version < 600000) #define IFPADDR(ifp) (((struct arpcom *) (ifp))->ac_enaddr) +#elif (__FreeBSD_version < 700000) +#define IFPADDR(ifp) IFP2ENADDR(ifp) #else -#define IFPADDR(ifp) IFP2ENADDR(ifp) +#define IFPADDR(ifp) IF_LLADDR(ifp) #endif #define IFLISTSZ 1024 @@ -96,7 +100,7 @@ #include #define IDX(c) ((u_char)(c) / LONG_BIT) #define BIT(c) ((u_long)1 << ((u_char)(c) % LONG_BIT)) - + static size_t strspn(const char *s, const char *charset) { @@ -275,7 +279,7 @@ TAILQ_FOREACH(ifp, &ifnet, if_link) { if (!is_aoe_netif(ifp)) continue; - memcpy(h->ah_src, IFPADDR(ifp), sizeof(h->ah_src)); + memcpy(h->ah_src, (u_char *)IFPADDR(ifp), sizeof(h->ah_src)); m = m_copypacket(m0, M_DONTWAIT); if (m == NULL) { IPRINTK("m_copypacket failure\n"); @@ -291,7 +295,7 @@ u_char * aoenet_enaddr(struct ifnet *ifp) { - return (IFPADDR(ifp)); + return (u_char *)(IFPADDR(ifp)); } u_int ------=_Part_19661_670433207.1234194728393-- From owner-freebsd-drivers@FreeBSD.ORG Mon Feb 9 17:56:48 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28D1B10656F9 for ; Mon, 9 Feb 2009 17:56:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC30A8FC0C for ; Mon, 9 Feb 2009 17:56:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 7E00B46B1A; Mon, 9 Feb 2009 12:56:47 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n19HuN2u005367; Mon, 9 Feb 2009 12:56:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Jason Harmening Date: Mon, 9 Feb 2009 12:54:06 -0500 User-Agent: KMail/1.9.7 References: <20090208113202.6d591589@CORONA> <200902090946.46917.jhb@freebsd.org> <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> In-Reply-To: <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902091254.06917.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 09 Feb 2009 12:56:41 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8968/Mon Feb 9 10:06:24 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-drivers@freebsd.org Subject: Re: PCI-Express interrupt issues X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:56:48 -0000 On Monday 09 February 2009 11:11:20 am Jason Harmening wrote: > On Mon, Feb 9, 2009 at 8:46 AM, John Baldwin wrote: > > On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: > >> Hi All, > >> > >> I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've > >> recently encountered some issues w/ interrupt handling, specifically on > >> PCI-Express systems, and I was hoping someone would be able to help me. > >> > >> Issue #1: > >> > >> The cx88 driver has split interrupt handling between filters and > >> ithreads since filters became available w/ 7.0. For the past year, the > >> filters have been set up to return FILTER_SCHEDULE_THREAD if the status > >> register indicates an interrupt, FILTER_STRAY otherwise. Everything > >> has worked fine. > >> > >> However, I recently stumbled across some documentation indicating that > >> FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter > >> should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified > >> the cx88 driver to do that instead, and that's where things turned > >> strange: > >> > >> On machine #1, which uses a VIA K8T800 chipset, everything still worked > >> fine. > >> > >> On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt > >> handlers were no longer invoked. It's as though the bus driver saw > >> FILTER_HANDLED in the bitmask and assumed the interrupt was already > >> processed without checking to see if an ithread should be scheduled. > >> What's interesting is that the only significant difference between the > >> K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 > >> supports PCI-Express, while the K8T800 is PCI-only. > > > > Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in > > the kernel? If you don't, then your ithread will never be called if you have > > a filter (actually, the bus_setup_intr() should fail in that case if you > > specify both). > > All machines are running 7.1-STABLE. Filters are enabled across the > board, and reverting to just returning FILTER_SCHEDULE_THREAD fixes > the issue. Do you see a dedicated interrupt thread for your device in top/ps? It should be 'intr: pcm0' (or whatever the device name is). -- John Baldwin From owner-freebsd-drivers@FreeBSD.ORG Tue Feb 10 12:31:29 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0AA9106575C for ; Tue, 10 Feb 2009 12:31:29 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id A23398FC19 for ; Tue, 10 Feb 2009 12:31:29 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2464812rvf.43 for ; Tue, 10 Feb 2009 04:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent:organization :x-operation-sytem; bh=TDq50o6xwD5YABsmGrCsVsPeGcRTHlOmkRZn7VTlX+M=; b=oZNrFjmNW8/GnLqrhwWROVSKTHZn9Ud4STIF5W1IGRn7QiA2rQSVJOCyPXxy96Yx8w +u2CmXvufE+sg8uqP5PO24gPF+YAOvtmEeR7AqJSLz87OW6Ws0hd4oMNMeQRdu0v0mVb NESOPLgz3W2Y/wV1miLylq12Y3i9uHpWQbxDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent:organization :x-operation-sytem; b=LSMV/JtMq2YW+twRv5HpApSgi5UTupvnFpbz6EBf3R9H3G1U7jRj3yORTn8qHRrwri 7laNG+EzDaqTuHbwuhGd3iTpQT1hKmznU9t2S93BD7Lc5BfoZef+jjtILLFMkcjbV6S2 k6tMxVOk3YQkh1G8IkKCl7Mj6SBsNZht3t4CE= Received: by 10.141.29.14 with SMTP id g14mr324991rvj.232.1234269089441; Tue, 10 Feb 2009 04:31:29 -0800 (PST) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id b8sm18810530rvf.1.2009.02.10.04.31.26 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Feb 2009 04:31:28 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Tue, 10 Feb 2009 21:31:15 +0900 From: Weongyo Jeong Date: Tue, 10 Feb 2009 21:31:15 +0900 To: Jim Andersson Message-ID: <20090210123115.GA65828@weongyo.cdnetworks.kr> Mail-Followup-To: Jim Andersson , freebsd-drivers@freebsd.org References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-drivers@freebsd.org Subject: Re: 8187SE driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 12:31:30 -0000 On Mon, Feb 09, 2009 at 04:04:07PM +0100, Jim Andersson wrote: > > > From: weongyo.jeong@gmail.com > > Date: Wed, 28 Jan 2009 19:39:26 +0900 > > To: freebsddog@hotmail.com > > CC: freebsd-drivers@freebsd.org > > Subject: Re: FW: 8187SE driver > > > > On Tue, Jan 27, 2009 at 02:23:33PM +0100, Jim Andersson wrote: > > > > > > From: freebsddog@hotmail.com > > > To: weongyo@freebsd.org > > > Subject: RE: 8187SE driver > > > Date: Tue, 27 Jan 2009 14:22:15 +0100 > > > > > > > From: weongyo.jeong@gmail.com > > > > Date: Mon, 19 Jan 2009 19:16:23 +0900 > > > > To: freebsddog@hotmail.com > > > > CC: freebsd-drivers@freebsd.org > > > > Subject: Re: 8187SE driver > > > > > > > > On Sat, Jan 17, 2009 at 04:16:43PM +0100, Jim Andersson wrote: > > > > > > > > > > > From: weongyo.jeong@gmail.com > > > > > > Date: Fri, 16 Jan 2009 13:04:26 +0900 > > > > > > To: freebsddog@hotmail.com > > > > > > CC: freebsd-drivers@freebsd.org > > > > > > Subject: Re: 8187SE driver > > > > > > > > > > > > On Thu, Jan 15, 2009 at 11:48:32AM +0100, Jim Andersson wrote: > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > Is there any chance of getting my wireless card running in > > > > > > > CURRENT. Linux says it???s a Realtek 8187SE wireless network > > > > > > > card. I have seen some driver for other 8187 cards, is it > > > > > > > possible to force such driver to try identify the card? > > > > > > > > > > > > > > > > > > > > > Here is the output of pciconf -lv in my FreeBSD > > > > > > > CURRENT:none1@pci0:1:0:0: class=0x028000 card=0x819910ec > > > > > > > chip=0x819910ec rev=0x22 hdr=0x00vendor = 'Realtek > > > > > > > Semiconductor'class = network . > > > > > > > > > > > > I think a thing you can try is that, NDISulator using ndis(4). AFAIK > > > > > > there's no support for 8187SE driver until now. > > > > > > > > > > > > regards, > > > > > > Weongyo Jeong > > > > > > > > > > > > > > > > I tried ndisulator but it didnīt work. I used the INF and the SYS > > > > > file for Windows Xp. I even tried including a cat file. > > > > > Although one thing changed, the card is no longer listed when i > > > > > type pciconf -lv. Dunno if thatīs good or bad? > > > > > > > > It looks it's a bad news. Could you please show me dmesg's ouput and > > > > steps you followed? > > > > > > > > regards, > > > > Weongyo Jeong > > > > > > > > > > As far as I can see the only thing in dmesg regarding this card is: > > > > > > pci1: on pcib3 > > > pci1: at device 0.0 (no driver attached) > > > > > > What I did was this: I used my windows xp drivers for the card that I > > > recieved with the computer. I used the .sys and the inf file. The > > > driver loads good but no interface is shown. Is the someway to force > > > the driver to attach to pci2 somehow? > > > > Normally if it works well the device should be detected automatically > > and should show some messages related with ndis(4). It looks there are > > another problems in your case. BTW there's no way to force the driver > > to attach. > > > > > Or is there some way to use a linux driver? Linux says its a realtek > > > 8187SE. > > > > No way to use the linux driver. > > > > regards, > > Weongyo Jeong > > > > It seems there has been a recent release of a driver for MAC/OSX > according to this page: > > http://forums.msiwind.net/mac/great-news-regarding-rtl8187se-wifi-module-t3986.html > > perhaps I can persuade them into remaking a freebsd driver, Darwin is > not that far from BSD right? ;-) Yes. I think if we can see sources for MAC/OSX it'd could be portable to FreeBSD according to the license. However I tried to download a driver URL to see whether it includes sources. All I found was `Installer87se.pkg'; I can't mount .pkg file because I don't have a laptop Mac OS installed temporarily. regards, Weongyo Jeong From owner-freebsd-drivers@FreeBSD.ORG Thu Feb 12 13:18:12 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341B81065736; Thu, 12 Feb 2009 13:18:12 +0000 (UTC) (envelope-from freebsddog@hotmail.com) Received: from bay0-omc2-s30.bay0.hotmail.com (bay0-omc2-s30.bay0.hotmail.com [65.54.246.166]) by mx1.freebsd.org (Postfix) with ESMTP id 14CE08FC17; Thu, 12 Feb 2009 13:18:11 +0000 (UTC) (envelope-from freebsddog@hotmail.com) Received: from BAY134-W53 ([65.55.139.88]) by bay0-omc2-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 05:18:11 -0800 Message-ID: X-Originating-IP: [79.102.133.178] From: Jim Andersson To: Date: Thu, 12 Feb 2009 14:18:11 +0100 Importance: Normal In-Reply-To: <20090210123115.GA65828@weongyo.cdnetworks.kr> References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> <20090210123115.GA65828@weongyo.cdnetworks.kr> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2009 13:18:11.0788 (UTC) FILETIME=[5ABBA8C0:01C98D14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-drivers@freebsd.org Subject: RE: 8187SE driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:18:14 -0000 > From: weongyo.jeong@gmail.com > Date: Tue=2C 10 Feb 2009 21:31:15 +0900 > To: freebsddog@hotmail.com > CC: freebsd-drivers@freebsd.org > Subject: Re: 8187SE driver >=20 > On Mon=2C Feb 09=2C 2009 at 04:04:07PM +0100=2C Jim Andersson wrote: > >=20 > > > From: weongyo.jeong@gmail.com > > > Date: Wed=2C 28 Jan 2009 19:39:26 +0900 > > > To: freebsddog@hotmail.com > > > CC: freebsd-drivers@freebsd.org > > > Subject: Re: FW: 8187SE driver > > >=20 > > > On Tue=2C Jan 27=2C 2009 at 02:23:33PM +0100=2C Jim Andersson wrote: > > > >=20 > > > > From: freebsddog@hotmail.com > > > > To: weongyo@freebsd.org > > > > Subject: RE: 8187SE driver > > > > Date: Tue=2C 27 Jan 2009 14:22:15 +0100 > > > >=20 > > > > > From: weongyo.jeong@gmail.com > > > > > Date: Mon=2C 19 Jan 2009 19:16:23 +0900 > > > > > To: freebsddog@hotmail.com > > > > > CC: freebsd-drivers@freebsd.org > > > > > Subject: Re: 8187SE driver > > > > >=20 > > > > > On Sat=2C Jan 17=2C 2009 at 04:16:43PM +0100=2C Jim Andersson wro= te: > > > > > >=20 > > > > > > > From: weongyo.jeong@gmail.com > > > > > > > Date: Fri=2C 16 Jan 2009 13:04:26 +0900 > > > > > > > To: freebsddog@hotmail.com > > > > > > > CC: freebsd-drivers@freebsd.org > > > > > > > Subject: Re: 8187SE driver > > > > > > >=20 > > > > > > > On Thu=2C Jan 15=2C 2009 at 11:48:32AM +0100=2C Jim Andersson= wrote: > > > > > > > >=20 > > > > > > > > Hi! > > > > > > > > =20 > > > > > > > > Is there any chance of getting my wireless card running in > > > > > > > > CURRENT. Linux says it???s a Realtek 8187SE wireless networ= k > > > > > > > > card. I have seen some driver for other 8187 cards=2C is it > > > > > > > > possible to force such driver to try identify the card? > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > Here is the output of pciconf -lv in my FreeBSD > > > > > > > > CURRENT:none1@pci0:1:0:0: class=3D0x028000 card=3D0x819910e= c > > > > > > > > chip=3D0x819910ec rev=3D0x22 hdr=3D0x00vendor =3D 'Realtek > > > > > > > > Semiconductor'class =3D network . > > > > > > >=20 > > > > > > > I think a thing you can try is that=2C NDISulator using ndis(= 4). AFAIK > > > > > > > there's no support for 8187SE driver until now. > > > > > > >=20 > > > > > > > regards=2C > > > > > > > Weongyo Jeong > > > > > > >=20 > > > > > >=20 > > > > > > I tried ndisulator but it didn=B4t work. I used the INF and the= SYS > > > > > > file for Windows Xp. I even tried including a cat file. > > > > > > Although one thing changed=2C the card is no longer listed when= i > > > > > > type pciconf -lv. Dunno if that=B4s good or bad? > > > > >=20 > > > > > It looks it's a bad news. Could you please show me dmesg's ouput= and > > > > > steps you followed? > > > > >=20 > > > > > regards=2C > > > > > Weongyo Jeong > > > > >=20 > > > >=20 > > > > As far as I can see the only thing in dmesg regarding this card is: > > > >=20 > > > > pci1: on pcib3 > > > > pci1: at device 0.0 (no driver attached) > > > >=20 > > > > What I did was this: I used my windows xp drivers for the card that= I > > > > recieved with the computer. I used the .sys and the inf file. The > > > > driver loads good but no interface is shown. Is the someway to forc= e > > > > the driver to attach to pci2 somehow? > > >=20 > > > Normally if it works well the device should be detected automatically > > > and should show some messages related with ndis(4). It looks there a= re > > > another problems in your case. BTW there's no way to force the drive= r > > > to attach. > > >=20 > > > > Or is there some way to use a linux driver? Linux says its a realte= k > > > > 8187SE. > > >=20 > > > No way to use the linux driver. > > >=20 > > > regards=2C > > > Weongyo Jeong > > >=20 > >=20 > > It seems there has been a recent release of a driver for MAC/OSX > > according to this page: > > > > http://forums.msiwind.net/mac/great-news-regarding-rtl8187se-wifi-mod= ule-t3986.html > >=20 > > perhaps I can persuade them into remaking a freebsd driver=2C Darwin is > > not that far from BSD right? =3B-) >=20 > Yes. I think if we can see sources for MAC/OSX it'd could be portable > to FreeBSD according to the license. >=20 > However I tried to download a driver URL to see whether it includes > sources. All I found was `Installer87se.pkg'=3B I can't mount .pkg file > because I don't have a laptop Mac OS installed temporarily. >=20 > regards=2C > Weongyo Jeong >=20 great I have contacted them to see if we can look at the source code dunno = what they feel about that :-) _________________________________________________________________ 25 GB gratis lagring p=E5 n=E4tet - Skaffa SkyDrive nu! http://skydrive.live.com =