From owner-freebsd-wireless@freebsd.org Mon Dec 25 02:55:55 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC0CFE92F5A for ; Mon, 25 Dec 2017 02:55:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 388CB72AE0 for ; Mon, 25 Dec 2017 02:55:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id w68so19864544wrc.10 for ; Sun, 24 Dec 2017 18:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y4kz8gigFagf5mrbfaTUesMbyhJ7WXjlQLvVuRDEf38=; b=XOsg49Bxbi9Fw/UOHigXVswy/VduSj6bkyqDRIz9PJ70anAt5vHynGaB1IJR2ywdcM 4eKUZD50v6jj19dYB4ZiBI/M5DXjnzAUOHBsaslCFXvIwT9Oerk4Z/Gh2zC8DaV8QoGh 9Ed/83qVBL9KBfr+ES2I3++urFgfxKVADb3mlG5Y8oabTn3iWR+03qcerjZinV6eFHj/ 0nVyMgRuVDONFPnrSrqSujWeVFin5fvd+H64sgLvVg+Z7D4opKF0U5yhnGHaD9m4WwIU C/aXS9n+uNKzg6h2wbI57G9zJENFvrvDc0DfU/mkxwsSvUf8n3Q8oTCwo/GqXtFKioSY dpIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=y4kz8gigFagf5mrbfaTUesMbyhJ7WXjlQLvVuRDEf38=; b=THtzc/fK/E+BuCZuRE58gGn3TMAkQVE1myiPxUd0JVMFuOwUywVgzqWJAmU6g5IkvG ShslQDKczLzkdqU0g0BQyXXQkCYs1qXD183x+w2rBqJKSPDk6URbpCC2yq3bOo+KzlHg tcm4MS5UfddxK1J3StoN1WrwJQsiszQtc2waJ1F2787ghVtS89mo/vUgdWqriQ56l6MU wCUg3W1sTqjwse6vghpi3skpvL8vOOElgKyR9yxLMnLJSXNoV7VzLwR7qI9hO+W1P07q Fefy2k/IE5tTWsnvGRZVzvj/hhKNBdhhds3aaWaaUZgHjrPQuIXn5b3zzo3vA/Z9mbId GLzg== X-Gm-Message-State: AKGB3mKC0LboowyHRND0c62z0fELSyfTC+W7D6AqZvqt2r8Wvjt5HUNg Dlo9ar3MkeLeDtMEjoqlPSkSX3dK8258uHeGLIFg6g== X-Google-Smtp-Source: ACJfBosG4Jjw2R+oB7RnYo11oH4ahT+deBxWloQ87IkWfx6cKCE7rdHxdom0qsC2rp7aCsZoRiAEgcBPbqHJRkySvQ8= X-Received: by 10.223.177.143 with SMTP id q15mr2819519wra.42.1514170553142; Sun, 24 Dec 2017 18:55:53 -0800 (PST) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.28.213.11 with HTTP; Sun, 24 Dec 2017 18:55:51 -0800 (PST) In-Reply-To: References: From: Adrian Chadd Date: Sun, 24 Dec 2017 18:55:51 -0800 X-Google-Sender-Auth: gU3NT1mpi1yhOeoXyjwEHMw3LLk Message-ID: Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts To: Farhan Khan Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 02:55:55 -0000 Hi, So it looks like the thing that's generating the interrupt isn't being cleared. So, what do the bits in R88EE_HIMR mean? What about HIRME? Let's figure out which it is. Also, is it something in C2H (the target to host event channel) that's not being handled? -adrian On 21 December 2017 at 14:43, Farhan Khan wrote: > Hi, > > As I wrote a few weeks back, I am working on the extension to rtwn(4) to add > RTL8188EE support. At the moment, I am working on the Rx code, which handles > interrupts. After the interrupt is triggered, the code goes into the Rx routine > and delivers "junk data" in a continuous loop. It seems that the interrupt code > is **constantly** called - enough that the load average is frequently above 1.0. > > I suspect the issue is giving the WiFi driver an acknowledgement of some sort, > but I am not certain. I attempted to copy Linux's interrupt code as best as > possible, but cannot determine if the error is within my code. > > Here is a verbose explanation of what I believe Linux is doing and what I am > doing on FreeBSD. > > -----Linux code works as follows----- > > 1. The IRQ trigger calls the function _rtl_pci_interrupt > (drivers/net/wireless/realtek/rtlwifi/pci.c) > 2. This calls disable_interrupt, which for rtl8188ee is > rtl88ee_disable_interrupt. This function writes IMR_DISABLED (0x0) to > REG_HIMR (0xb0) and REG_HIMRE (0xb8). > 3. Next _rtl_pci_interrupt calls interrupt_recognized(), a function pointer to > rtl88ee_interrupt_recognized(), which: > * Reads from REG_HISR (0xb4), stores the value in 'inta', ANDs that value by > 0x200084ff, then writes that value back to the same register. > * Reads from REG_HISRE (0xbc), stores the value in 'intb', ANDs that value by > 0x100, then writes that value back to the same register. > Then the function returns returns. > > 4. Back in _rtl_pci_interrupt if 'inta' is 0 and 'intb' is 0xffff, the code will > skip step 5, goto to "done" and execute enable_interrupt code > (rtl88ee_enable_interrupt) > > 5. If bit(0) is set to 1, this is an Rx interrupt and will run > _rtl_pci_rx_interrupt(). From my review of the code, from here the Linux > driver will read from the DMA memory and send the frame to the ieee80211 > layer. I only found 1 additional read instruction related to the power value, > but nothing else is changed. > > 6. Here is the "done" portion, that happens no matter what, but is jumped to > immediately as referenced above. It will call enable_interrupt(), a function > pointer to rtl88ee_enable_Interrupt(), which will: > a. Write 0x200084ff to REG_HIMR (0xb0) > b. Write 0x100 to REG_HIMRE (0xb8) > c. Write 0 to to REG_C2HEVT_CLEAR (0x01AF, A register having to do with C2H > firmware) > d. Write 0xc0 to REG_HSIMR (0x58 , I know this value from printf'ing it) > > This is what I identified from reviewing from the Linux code. > > -----My FreeBSD Code----- > > My code is located here: > https://github.com/khanzf/freebsd/tree/rx_not_working/sys/dev/rtwn/. > > 1. The IRQ trigger calls the function rtwn_pci_intr() > (sys/dev/rtwn/pci/rtwn_pci_rx.c) > 2. The equivalent of Linux's line 2 and 3 is in rtwn_classify_intr, which is a > pointer to r88ee_enable_intr located in sys/dev/rtwn/rtl8188e/pci/r88ee_rx. > This write's 0x0 to REG_HIMR (0xb0) and REG_HIMRE (0xb8) > 3. Continuing, the same function: > * Reads from ISR_MINE (same as REG_HISR, 0xb4), ANDs the value by 0x200084ff, > store it in 'status'. Then I write the value back to the same register. > * Read from REG_HISRE (0xbc), AND the value by 0x100, store it in 'statusb'. > Write this value back to the same register. > * Since this is an Rx register, the 'ret' value is AND'd by RTWN_PCI_INTR_RX. > > 4. In the Linux code, if 'status' is 0x0 and 'statusb' is 0xFFFF, it will goto > to "done". On FreeBSD, it simply does not set any bits on the 'ret' value and > the function returns 0, going back to rtwn_pci_intr. > > 5. Returning to rtwn_pci_intr(), if the 'ret' (now 'status') has > RTWN_PCI_INTR_RX flag on, it executes rtwn_pci_tx_done(), which will read the > DMA memory and send the frame to the ieee80211 layer. The execution will skip > step 5 if 'ret' was 0 (the RTWN_PCI_INTR_RX flag was never set). This returns > execution back to rtwn_pci_intr(). > > 6. rtwn_pci_intr() concludes by running rtwn_pci_enable_intr(). This is similar > to Linux's enable_interrupt(), it does the following: > a. Write 0x200084f to R88EE_HIMR (0xb0) > b. Write 0x100 to R88EE_HIMRE (0xb8) > c. Write 0x0 to REG_C2HEVT_CLEAR (0x01AF) > d. Write 0xc0 to REG_HSIMR > > --------- > > To me, it appears that I did a complete 1-to-1 copy of the Linux code. However, > in my case the driver is receiving constant interrupts without stopping. I am > not certain what I am missing or what is different. Could it be that something > outside of this particular code path was not properly set. If so, what might > that be? > > Please advise. > Thank you, > > -- > Farhan Khan > PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Tue Dec 26 20:10:59 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2193DEAC701 for ; Tue, 26 Dec 2017 20:10:59 +0000 (UTC) (envelope-from kevin@jiazuo.cc) Received: from mail139-36.mail.alibaba.com (mail139-36.mail.alibaba.com [198.11.139.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7677653D9 for ; Tue, 26 Dec 2017 20:10:57 +0000 (UTC) (envelope-from kevin@jiazuo.cc) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.11956|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03278; MF=kevin@jiazuo.cc; NM=1; PH=DW; RN=1; RT=1; SR=0; TI=W4_5135885_0A93263F_1514318960576_o7001c1519; Received: from WS-web (kevin@jiazuo.cc[W4_5135885_0A93263F_1514318960576_o7001c1519]) by e01l04446.eu6 at Wed, 27 Dec 2017 04:10:45 +0800 Date: Wed, 27 Dec 2017 04:10:45 +0800 From: "kevin" To: "freebsd-wireless" Reply-To: "kevin" Message-ID: <234dd0df-76a5-474a-9e7f-8d0d4ef36b48.kevin@jiazuo.cc> Subject: =?UTF-8?B?UHJvYmxlbTogcnVubmluZyBpd20gODI2NSBmYWlsZWQgb24gQ1VSUkVOVC4=?= X-Mailer: [Alimail-Mailagent revision 286] MIME-Version: 1.0 x-aliyun-mail-creator: W4_5135885_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTNfMikgQXBwbGVXZWJLaXQvNjA0LjQuNyAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4yIFNhZmFyaS82MDQuNC43La Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 20:10:59 -0000 SGksCkkndmUgaW5zdGFsbGVkIDEyLUNVUlJFTlQgb24gYSBYMSBjYXJib24gMjAxNywgwqB3aXRo IEludGVsIER1YWwgQmFuZCBXaXJlbGVzcyBBQyA4MjY1LCBidXQgZmFpbGVkIHdoZW4gcnVubmlu ZyB3cGFfc3VwcGxpY2FudCwKaGVyZSBhcmUgZnVsbCBkZXRhaWxzOgoKcm9vdCMgaWZjb25maWcg d2xhbjAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXdsYW4w OiBmbGFncz04ODAyPEJST0FEQ0FTVCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1 MDDCoCDCoCBldGhlciBmODo5NDpjMjoyZDo3ODpiZcKgIMKgIGh3YWRkciBmODo5NDpjMjoyZDo3 ODpiZcKgIMKgIG5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktM T0NBTD7CoCDCoCBtZWRpYTogSUVFRSA4MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3NlbGVj dCAoYXV0b3NlbGVjdCnCoCDCoCBzdGF0dXM6IG5vIGNhcnJpZXLCoCDCoCBzc2lkICIiIGNoYW5u ZWwgMSAoMjQxMiBNSHogMTFiKcKgIMKgIGF1dGhtb2RlIE9QRU4gcHJpdmFjeSBPRkYgdHhwb3dl ciAwIGJtaXNzIDEwIHNjYW52YWxpZCA2MCB3bWXCoCDCoCBncm91cHM6IHdsYW7CoAoKcm9vdEAg c2VydmljZSBuZXRpZiByZXN0YXJ0LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0uLi5EZXN0cm95ZWQgd2xhbig0KSBpbnRlcmZhY2VzOiB3bGFuMC5pZmNvbmZp Zzogbm8gY2hhbm5lbHMgY2FsY3VsYXRlZFN0YXJ0aW5nIHdwYV9zdXBwbGljYW50Li9ldGMvcmMu ZC93cGFfc3VwcGxpY2FudDogV0FSTklORzogZmFpbGVkIHRvIHN0YXJ0IHdwYV9zdXBwbGljYW50 U3RhcnRpbmcgTmV0d29yazogbG8wIGVtMCB3bGFuMC4uLi4KCnJvb3QjIHdwYV9zdXBwbGljYW50 IC1pIHdsYW4wIC1jIC9ldGMvd3BhX3N1cHBsaWNhbnQuY29uZi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tU3VjY2Vzc2Z1bGx5IGluaXRpYWxpemVkIHdwYV9z dXBwbGljYW50aW9jdGxbU0lPQ1M4MDIxMSwgb3A9OTgsIGFyZ19sZW49MzJdOiBJbnZhbGlkIGFy Z3VtZW50ZmFpbGVkIHRvIElFRUU4MDIxMV9JT0NfREVWQ0FQUzogSW52YWxpZCBhcmd1bWVudHds YW4wOiBGYWlsZWQgdG8gaW5pdGlhbGl6ZSBkcml2ZXIgaW50ZXJmYWNlRUxPT1A6IHJlbWFpbmlu ZyBzb2NrZXQ6IHNvY2s9NCBlbG9vcF9kYXRhPTB4ODAxYzJmMDAwIHVzZXJfZGF0YT0weDgwMWMx ODAwMCBoYW5kbGVyPTB4NDI0YjMwCgpyb290IyBkbWVzZyAtYSB8IGdyZXAgLWkgaXdtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1pd20wOiA8SW50ZWwoUikg RHVhbCBCYW5kIFdpcmVsZXNzIEFDIDgyNjU+IG1lbSAweGVjMTAwMDAwLTB4ZWMxMDFmZmYgYXQg ZGV2aWNlIDAuMCBvbiBwY2kyaXdtMDogaHcgcmV2IDB4MjMwLCBmdyB2ZXIgMjIuMzYxNDc2LjAs IGFkZHJlc3MgZjg6OTQ6YzI6MmQ6Nzg6YmUKCg== From owner-freebsd-wireless@freebsd.org Tue Dec 26 20:19:56 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BFCEEACE1F for ; Tue, 26 Dec 2017 20:19:56 +0000 (UTC) (envelope-from kevinn4901@163.com) Received: from m13-90.163.com (m13-90.163.com [220.181.13.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3F45C658E2 for ; Tue, 26 Dec 2017 20:19:54 +0000 (UTC) (envelope-from kevinn4901@163.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=+YTnl 2TS7C5GaZ/2BoHVgVqU0MPCbEth2BPhB8yTaJk=; b=fuAICj+z8Z0gUxu3LlWS+ 5cKHz+kOJv7aIMNJTPCc6BXJ0861gSIu78D4y4WJnWB8HZR0qLHiw0KnY3VnK9ln azpJvaQ1o/DWsLDg9fTOuid7dALtx2tRmLCJhSnWP8Cx+GCU1OBGHH69grpdGfkX qjU3KQY1EzFnM+yIfctzPE= Received: from kevinn4901$163.com ( [115.196.118.23] ) by ajax-webmail-wmsvr90 (Coremail) ; Wed, 27 Dec 2017 04:04:27 +0800 (CST) X-Originating-IP: [115.196.118.23] Date: Wed, 27 Dec 2017 04:04:27 +0800 (CST) From: kv163 To: freebsd-wireless@freebsd.org Subject: problem: running iwm 8265 failed on CURRENT. X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160729(86883.8884) Copyright (c) 2002-2017 www.mailtech.cn 163com X-CM-CTRLDATA: dP0bUmZvb3Rlcl9odG09NTQ5MDo1Ng== MIME-Version: 1.0 Message-ID: <3ea42b84.278.160946d1f45.Coremail.kevinn4901@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: WsGowACnr8NLq0JaY_4nAA--.62166W X-CM-SenderInfo: pnhyx0rquziii6rwjhhfrp/1tbiowu6+FUMC9WDXQAAsz X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 20:19:56 -0000 SGksCgoKSSd2ZSBpbnN0YWxsZWQgMTItQ1VSUkVOVCBvbiBhIFgxIGNhcmJvbiAyMDE3LCAgd2l0 aCBJbnRlbCBEdWFsIEJhbmQgV2lyZWxlc3MgQUMgODI2NSwgYnV0IGZhaWxlZCB3aGVuIHJ1bm5p bmcgd3BhX3N1cHBsaWNhbnQsCmhlcmUgYXJlIGZ1bGwgZGV0YWlsczoKCgpyb290IyBpZmNvbmZp ZyB3bGFuMAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp3 bGFuMDogZmxhZ3M9ODgwMjxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10 dSAxNTAwCiAgICBldGhlciBmODo5NDpjMjoyZDo3ODpiZQogICAgaHdhZGRyIGY4Ojk0OmMyOjJk Ojc4OmJlCiAgICBuZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5L TE9DQUw+CiAgICBtZWRpYTogSUVFRSA4MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3NlbGVj dCAoYXV0b3NlbGVjdCkKICAgIHN0YXR1czogbm8gY2FycmllcgogICAgc3NpZCAiIiBjaGFubmVs IDEgKDI0MTIgTUh6IDExYikKICAgIGF1dGhtb2RlIE9QRU4gcHJpdmFjeSBPRkYgdHhwb3dlciAw IGJtaXNzIDEwIHNjYW52YWxpZCA2MCB3bWUKICAgIGdyb3Vwczogd2xhbiAKCgoKCnJvb3RAIHNl cnZpY2UgbmV0aWYgcmVzdGFydAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQouLi4KRGVzdHJveWVkIHdsYW4oNCkgaW50ZXJmYWNlczogd2xhbjAuCmlmY29u ZmlnOiBubyBjaGFubmVscyBjYWxjdWxhdGVkClN0YXJ0aW5nIHdwYV9zdXBwbGljYW50LgovZXRj L3JjLmQvd3BhX3N1cHBsaWNhbnQ6IFdBUk5JTkc6IGZhaWxlZCB0byBzdGFydCB3cGFfc3VwcGxp Y2FudApTdGFydGluZyBOZXR3b3JrOiBsbzAgZW0wIHdsYW4wLgouLi4KCgoKCnJvb3QjIHdwYV9z dXBwbGljYW50IC1pIHdsYW4wIC1jIC9ldGMvd3BhX3N1cHBsaWNhbnQuY29uZgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpTdWNjZXNzZnVsbHkgaW5pdGlh bGl6ZWQgd3BhX3N1cHBsaWNhbnQKaW9jdGxbU0lPQ1M4MDIxMSwgb3A9OTgsIGFyZ19sZW49MzJd OiBJbnZhbGlkIGFyZ3VtZW50CmZhaWxlZCB0byBJRUVFODAyMTFfSU9DX0RFVkNBUFM6IEludmFs aWQgYXJndW1lbnQKd2xhbjA6IEZhaWxlZCB0byBpbml0aWFsaXplIGRyaXZlciBpbnRlcmZhY2UK RUxPT1A6IHJlbWFpbmluZyBzb2NrZXQ6IHNvY2s9NCBlbG9vcF9kYXRhPTB4ODAxYzJmMDAwIHVz ZXJfZGF0YT0weDgwMWMxODAwMCBoYW5kbGVyPTB4NDI0YjMwCgoKCgpyb290IyBkbWVzZyAtYSB8 IGdyZXAgLWkgaXdtCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCml3bTA6IDxJbnRlbChSKSBEdWFsIEJhbmQgV2lyZWxlc3MgQUMgODI2NT4gbWVtIDB4ZWMx MDAwMDAtMHhlYzEwMWZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKaXdtMDogaHcgcmV2IDB4MjMw LCBmdyB2ZXIgMjIuMzYxNDc2LjAsIGFkZHJlc3MgZjg6OTQ6YzI6MmQ6Nzg6YmUKCg== From owner-freebsd-wireless@freebsd.org Wed Dec 27 04:05:49 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F7B8EA06F4 for ; Wed, 27 Dec 2017 04:05:49 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34BB47622B; Wed, 27 Dec 2017 04:05:49 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-yb0-x229.google.com with SMTP id w1so13515047ybe.10; Tue, 26 Dec 2017 20:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1S5pl1GZWhstiQm9/w5pJU//+XqsZUWw6Oligy3o1tA=; b=IPnF7PR8aF1JOK+yB+gqOWwJsEoTke2Qc4M4FCFhoEgQDqzhGZEnQDD+D7as7nxcjy Owoj84LweIpYhSS3nOxBv3sm9ydj0eyU8DWAP2C9++6Xyjeb5/r2b9SiZ/I1CxZYaiQP 2f9iEFpwWJNxEK36+JKlrYIs9JlBl2TaaSbybjvwd6KdhJ/Av+hRmXJLEESPXXk/TXc6 G7wKILh3fsc/r3cLPeAlohqBojG/jMEKJfyBzIYa87qghTTdZELJipSul000/Nlr/R4I B3Kd0BWBPPxe7v5hKLPgq0g6yIGcqMpxhszpigPry/RZBufGpZNjBmbJy0N383mnObxr 7mQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1S5pl1GZWhstiQm9/w5pJU//+XqsZUWw6Oligy3o1tA=; b=SZsW5rXI3dp42YXOilByEIH7Y3nMVSfwaCTtwKTQrC51bfVTGrN/nUEodA/PpR3JtN MPzyx3ZgowEroTD32Sc3nASQcatu0L46tDtKlys2aF9laAquQYGJ3YUfY3gsAxvS2Fe5 NWiDSrcWzGB87D5DiBTpyX3dM2MNPsQypdwOdw3ioJtkoEU8IQUX5d38xHJMBrI/t/Ur lPgU8BeF2/o/mkfG5jp/2+iZz1D+P5BN3R0/jymBrYmnAH0PFuqb+BPfQnZI4IwS9AEG HtSTYrhM5Qv5I1ckm5myjrPCTWnZKqvxzhzGsmDX0h0RChVvtDMqSvMGG+I0lJ/uoAFE 54vg== X-Gm-Message-State: AKGB3mJkpnmldPtBVdhIGaXeqyIC28YOqWR7KpazjplqljmMfAYBPx5x oeOG4f6SAxX+tJAxVESkw4ABz+Zlxkiv23xhaWWMyg== X-Google-Smtp-Source: ACJfBos6/V3CmGdcKD3LZsSZog2lmptoe9zaAX5HADhBPSwQ7jXRYv8iOnwspmJOc5e8J0g3uZhjBBiy00SIRzvXIgo= X-Received: by 10.37.212.69 with SMTP id m66mr6295392ybf.158.1514347548027; Tue, 26 Dec 2017 20:05:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.131.194 with HTTP; Tue, 26 Dec 2017 20:05:27 -0800 (PST) In-Reply-To: References: From: Farhan Khan Date: Tue, 26 Dec 2017 23:05:27 -0500 Message-ID: Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts To: Adrian Chadd Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 04:05:49 -0000 Hi Adrian, > So, what do the bits in R88EE_HIMR mean? What about HIRME? Let's > figure out which it is. Unfortunately, I do not know what these values are regarding. My speculation is that R88EE_HIMR and HIMRE are how you notify the device to clear the interrupt. On the Linux source, they are both in a function called rtl88ee_disable_interrupt. The Linux documentation puts them in a struct called rtl_var_map and labels this section as"reg map". It is not clear to me what that means. It could be the C2H, but I commented out the FW loading code entirely, but this issue remains. I am going to re-review the initialization code. Perhaps the issue lays there. Its a challenge, because the Linux and FreeBSD structure of the code is not 1-to-1. -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE On Sun, Dec 24, 2017 at 9:55 PM, Adrian Chadd wrote: > Hi, > > So it looks like the thing that's generating the interrupt isn't being > cleared. > > So, what do the bits in R88EE_HIMR mean? What about HIRME? Let's > figure out which it is. > > Also, is it something in C2H (the target to host event channel) that's > not being handled? > > > > -adrian > > > > On 21 December 2017 at 14:43, Farhan Khan wrote: > > Hi, > > > > As I wrote a few weeks back, I am working on the extension to rtwn(4) to > add > > RTL8188EE support. At the moment, I am working on the Rx code, which > handles > > interrupts. After the interrupt is triggered, the code goes into the Rx > routine > > and delivers "junk data" in a continuous loop. It seems that the > interrupt code > > is **constantly** called - enough that the load average is frequently > above 1.0. > > > > I suspect the issue is giving the WiFi driver an acknowledgement of some > sort, > > but I am not certain. I attempted to copy Linux's interrupt code as best > as > > possible, but cannot determine if the error is within my code. > > > > Here is a verbose explanation of what I believe Linux is doing and what > I am > > doing on FreeBSD. > > > > -----Linux code works as follows----- > > > > 1. The IRQ trigger calls the function _rtl_pci_interrupt > > (drivers/net/wireless/realtek/rtlwifi/pci.c) > > 2. This calls disable_interrupt, which for rtl8188ee is > > rtl88ee_disable_interrupt. This function writes IMR_DISABLED (0x0) to > > REG_HIMR (0xb0) and REG_HIMRE (0xb8). > > 3. Next _rtl_pci_interrupt calls interrupt_recognized(), a function > pointer to > > rtl88ee_interrupt_recognized(), which: > > * Reads from REG_HISR (0xb4), stores the value in 'inta', ANDs that > value by > > 0x200084ff, then writes that value back to the same register. > > * Reads from REG_HISRE (0xbc), stores the value in 'intb', ANDs that > value by > > 0x100, then writes that value back to the same register. > > Then the function returns returns. > > > > 4. Back in _rtl_pci_interrupt if 'inta' is 0 and 'intb' is 0xffff, the > code will > > skip step 5, goto to "done" and execute enable_interrupt code > > (rtl88ee_enable_interrupt) > > > > 5. If bit(0) is set to 1, this is an Rx interrupt and will run > > _rtl_pci_rx_interrupt(). From my review of the code, from here the > Linux > > driver will read from the DMA memory and send the frame to the > ieee80211 > > layer. I only found 1 additional read instruction related to the > power value, > > but nothing else is changed. > > > > 6. Here is the "done" portion, that happens no matter what, but is > jumped to > > immediately as referenced above. It will call enable_interrupt(), a > function > > pointer to rtl88ee_enable_Interrupt(), which will: > > a. Write 0x200084ff to REG_HIMR (0xb0) > > b. Write 0x100 to REG_HIMRE (0xb8) > > c. Write 0 to to REG_C2HEVT_CLEAR (0x01AF, A register having to do > with C2H > > firmware) > > d. Write 0xc0 to REG_HSIMR (0x58 , I know this value from printf'ing > it) > > > > This is what I identified from reviewing from the Linux code. > > > > -----My FreeBSD Code----- > > > > My code is located here: > > https://github.com/khanzf/freebsd/tree/rx_not_working/sys/dev/rtwn/. > > > > 1. The IRQ trigger calls the function rtwn_pci_intr() > > (sys/dev/rtwn/pci/rtwn_pci_rx.c) > > 2. The equivalent of Linux's line 2 and 3 is in rtwn_classify_intr, > which is a > > pointer to r88ee_enable_intr located in sys/dev/rtwn/rtl8188e/pci/r88e > e_rx. > > This write's 0x0 to REG_HIMR (0xb0) and REG_HIMRE (0xb8) > > 3. Continuing, the same function: > > * Reads from ISR_MINE (same as REG_HISR, 0xb4), ANDs the value by > 0x200084ff, > > store it in 'status'. Then I write the value back to the same > register. > > * Read from REG_HISRE (0xbc), AND the value by 0x100, store it in > 'statusb'. > > Write this value back to the same register. > > * Since this is an Rx register, the 'ret' value is AND'd by > RTWN_PCI_INTR_RX. > > > > 4. In the Linux code, if 'status' is 0x0 and 'statusb' is 0xFFFF, it > will goto > > to "done". On FreeBSD, it simply does not set any bits on the 'ret' > value and > > the function returns 0, going back to rtwn_pci_intr. > > > > 5. Returning to rtwn_pci_intr(), if the 'ret' (now 'status') has > > RTWN_PCI_INTR_RX flag on, it executes rtwn_pci_tx_done(), which will > read the > > DMA memory and send the frame to the ieee80211 layer. The execution > will skip > > step 5 if 'ret' was 0 (the RTWN_PCI_INTR_RX flag was never set). This > returns > > execution back to rtwn_pci_intr(). > > > > 6. rtwn_pci_intr() concludes by running rtwn_pci_enable_intr(). This is > similar > > to Linux's enable_interrupt(), it does the following: > > a. Write 0x200084f to R88EE_HIMR (0xb0) > > b. Write 0x100 to R88EE_HIMRE (0xb8) > > c. Write 0x0 to REG_C2HEVT_CLEAR (0x01AF) > > d. Write 0xc0 to REG_HSIMR > > > > --------- > > > > To me, it appears that I did a complete 1-to-1 copy of the Linux code. > However, > > in my case the driver is receiving constant interrupts without stopping. > I am > > not certain what I am missing or what is different. Could it be that > something > > outside of this particular code path was not properly set. If so, what > might > > that be? > > > > Please advise. > > Thank you, > > > > -- > > Farhan Khan > > PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE > > _______________________________________________ > > freebsd-wireless@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@ > freebsd.org" > From owner-freebsd-wireless@freebsd.org Thu Dec 28 09:28:57 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC18EE8363F for ; Thu, 28 Dec 2017 09:28:57 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F65573398 for ; Thu, 28 Dec 2017 09:28:57 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id y78so39051829lfd.1 for ; Thu, 28 Dec 2017 01:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=136+nzz1dy1Cp98poGiJ0A1QJO91NxDUQM6W46NxPJo=; b=l7b9fxBqy2SXODzfdZWBnO3jSQ5hF8u0mmMwiKOw4q3bO96oqoUijcZtkYVyLyYlEV ipP34ss6f3E2mM7Uf8Ju2+9ZTtnSGVCXmgG4NTedZSg4tFFYqY2ac57dfrItVfjh0Mef dqiebbiRe4DC4RkU9IQZWV56EP4FjztdgTdmi3bYhXB79IAhGhRZ7YUomgNdqwl8FSmZ LR82UCJBOD3Icwly0vNs+3P3SPwES9YOSFFp4NY0SeJJaVPm4P6CbzvsAnb1I8USstOZ aBI4vv1hcpnYwkiKtctWPtO0a2ZMhxC0zHWis4FEQD9fCo8bW5oNeTAD2NIW9nQVZx6s A7Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=136+nzz1dy1Cp98poGiJ0A1QJO91NxDUQM6W46NxPJo=; b=L1/Gjp6RaXVehc223PVk2bw7HaGZwerqNBihB62ZbcLzPhMrZUKBGnK4pm9PhbnqK3 T/ow34wgVRv13Hd108rVkhZFL+2SXtQeoyEi0H5smhZk1kM23UwH6D8xEyc+aQcRNpTj FLpC1NBK2L23ZMcZQbU0yFOExWqQyy+c1jIDO7m8Tbs26XOXQ4etYBROCx9pJTszx54R iz6Fb9zLythHgmm6wFDcRIjDHKAKAmFc1Uc8Pg0w+6OlizKQRdw6gqIMwu5Na49KNFqr N+HwWXbbW159eraxhnhc2EhL45mJJNYfJ8M7CEcZz8YKK7AcGIh4xmIsmj2tIH8O067P j2hQ== X-Gm-Message-State: AKGB3mImNbSF1XbrbN414FVPa2V7O2SDdvQ3dRhlEcyz9z9WLksxRZus Bk/6axW0NUSWA7direbrVYY= X-Google-Smtp-Source: ACJfBotu08ZRwWSCuJu9IJ+Fq0ExQ9g/4DnUEtXZ8BOjQxek+0ALJhB93Jl394JWKososx+TKUMglQ== X-Received: by 10.25.143.71 with SMTP id r68mr15845357lfd.85.1514453335544; Thu, 28 Dec 2017 01:28:55 -0800 (PST) Received: from localhost (46-133-212-82.dialup.umc.net.ua. [46.133.212.82]) by smtp.gmail.com with ESMTPSA id t17sm6539064lfi.33.2017.12.28.01.28.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 28 Dec 2017 01:28:54 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Farhan Khan" Cc: freebsd-wireless@freebsd.org Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts References: Date: Thu, 28 Dec 2017 11:28:47 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 09:28:58 -0000 Hi, there are some issues that may cause wrong interrupt handling: 1) IMR register bits - they were taken from 92c (and they are not compatible - for example, RXFOVW seems to be moved to the ext register) 2) Try to ACK (write back) all bits, not masked ones (like it is done for 92c) 2017-12-22 0:43 GMT+02:00, Farhan Khan : >> Hi, >> >> As I wrote a few weeks back, I am working on the extension to rtwn(4) to >> add >> RTL8188EE support. At the moment, I am working on the Rx code, which >> handles >> interrupts. After the interrupt is triggered, the code goes into the Rx >> routine >> and delivers "junk data" in a continuous loop. It seems that the >> interrupt >> code >> is **constantly** called - enough that the load average is frequently >> above >> 1.0. >> >> I suspect the issue is giving the WiFi driver an acknowledgement of some >> sort, >> but I am not certain. I attempted to copy Linux's interrupt code as >> best as >> possible, but cannot determine if the error is within my code. >> >> Here is a verbose explanation of what I believe Linux is doing and what >> I >> am >> doing on FreeBSD. >> >> -----Linux code works as follows----- >> >> 1. The IRQ trigger calls the function _rtl_pci_interrupt >> (drivers/net/wireless/realtek/rtlwifi/pci.c) >> 2. This calls disable_interrupt, which for rtl8188ee is >> rtl88ee_disable_interrupt. This function writes IMR_DISABLED (0x0) to >> REG_HIMR (0xb0) and REG_HIMRE (0xb8). >> 3. Next _rtl_pci_interrupt calls interrupt_recognized(), a function >> pointer >> to >> rtl88ee_interrupt_recognized(), which: >> * Reads from REG_HISR (0xb4), stores the value in 'inta', ANDs that >> value >> by >> 0x200084ff, then writes that value back to the same register. >> * Reads from REG_HISRE (0xbc), stores the value in 'intb', ANDs that >> value by >> 0x100, then writes that value back to the same register. >> Then the function returns returns. >> >> 4. Back in _rtl_pci_interrupt if 'inta' is 0 and 'intb' is 0xffff, the >> code >> will >> skip step 5, goto to "done" and execute enable_interrupt code >> (rtl88ee_enable_interrupt) >> >> 5. If bit(0) is set to 1, this is an Rx interrupt and will run >> _rtl_pci_rx_interrupt(). From my review of the code, from here the >> Linux >> driver will read from the DMA memory and send the frame to the >> ieee80211 >> layer. I only found 1 additional read instruction related to the >> power >> value, >> but nothing else is changed. >> >> 6. Here is the "done" portion, that happens no matter what, but is >> jumped >> to >> immediately as referenced above. It will call enable_interrupt(), a >> function >> pointer to rtl88ee_enable_Interrupt(), which will: >> a. Write 0x200084ff to REG_HIMR (0xb0) >> b. Write 0x100 to REG_HIMRE (0xb8) >> c. Write 0 to to REG_C2HEVT_CLEAR (0x01AF, A register having to do >> with >> C2H >> firmware) >> d. Write 0xc0 to REG_HSIMR (0x58 , I know this value from printf'ing >> it) >> >> This is what I identified from reviewing from the Linux code. >> >> -----My FreeBSD Code----- >> >> My code is located here: >> https://github.com/khanzf/freebsd/tree/rx_not_working/sys/dev/rtwn/. >> >> 1. The IRQ trigger calls the function rtwn_pci_intr() >> (sys/dev/rtwn/pci/rtwn_pci_rx.c) >> 2. The equivalent of Linux's line 2 and 3 is in rtwn_classify_intr, >> which is >> a >> pointer to r88ee_enable_intr located in >> sys/dev/rtwn/rtl8188e/pci/r88ee_rx. >> This write's 0x0 to REG_HIMR (0xb0) and REG_HIMRE (0xb8) >> 3. Continuing, the same function: >> * Reads from ISR_MINE (same as REG_HISR, 0xb4), ANDs the value by >> 0x200084ff, >> store it in 'status'. Then I write the value back to the same >> register. >> * Read from REG_HISRE (0xbc), AND the value by 0x100, store it in >> 'statusb'. >> Write this value back to the same register. >> * Since this is an Rx register, the 'ret' value is AND'd by >> RTWN_PCI_INTR_RX. >> >> 4. In the Linux code, if 'status' is 0x0 and 'statusb' is 0xFFFF, it >> will >> goto >> to "done". On FreeBSD, it simply does not set any bits on the 'ret' >> value >> and >> the function returns 0, going back to rtwn_pci_intr. >> >> 5. Returning to rtwn_pci_intr(), if the 'ret' (now 'status') has >> RTWN_PCI_INTR_RX flag on, it executes rtwn_pci_tx_done(), which will >> read >> the >> DMA memory and send the frame to the ieee80211 layer. The execution >> will >> skip >> step 5 if 'ret' was 0 (the RTWN_PCI_INTR_RX flag was never set). This >> returns >> execution back to rtwn_pci_intr(). >> >> 6. rtwn_pci_intr() concludes by running rtwn_pci_enable_intr(). This is >> similar >> to Linux's enable_interrupt(), it does the following: >> a. Write 0x200084f to R88EE_HIMR (0xb0) >> b. Write 0x100 to R88EE_HIMRE (0xb8) >> c. Write 0x0 to REG_C2HEVT_CLEAR (0x01AF) >> d. Write 0xc0 to REG_HSIMR >> >> --------- >> >> To me, it appears that I did a complete 1-to-1 copy of the Linux code. >> However, >> in my case the driver is receiving constant interrupts without >> stopping. I >> am >> not certain what I am missing or what is different. Could it be that >> something >> outside of this particular code path was not properly set. If so, what >> might >> that be? >> >> Please advise. >> Thank you, >> >> -- >> Farhan Khan >> PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to >> "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Thu Dec 28 20:22:46 2017 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A312AEB21C5 for ; Thu, 28 Dec 2017 20:22:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D0BE6950D for ; Thu, 28 Dec 2017 20:22:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id r205so8846136ywb.3 for ; Thu, 28 Dec 2017 12:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lGKUYBae1pl7fyKidsJ9x7r/8JHMFx25+UF45cRknrQ=; b=JBUac/6mjs2qr+DwVeLAMtSlwINtSnrBmLr3ax/i7jizLPaguJa/33Mmfu+WnYC8lC zJ9qerz3ZuYSC2Bwj/4/M4FT65xX5wplWbdAr419YTxlIPxEKzuZFznfiriLnIFlLPrp WPsimrScJIAGbxrI+8nEjh5VjWuRMYSZ3O4rskB1Tay+BskABoZ8cqWVOV1x9m8BbPsu aNFXTJ9wNMEwcx28VRG01MeSSnmTG8kb8+JWbxlMO5gufD84yiFwQOWpvLj4Qk0DI6Dv gDJnmXtQ2Zf+AWnRSl9SymxfhG42tYQI1+LRkYAWRrpEy3UJAEZ4Gp3Qy1+BH8hZG7+X 9ZyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lGKUYBae1pl7fyKidsJ9x7r/8JHMFx25+UF45cRknrQ=; b=HQREwVw2LOXCGyRkwm+MQT4qigI+hyI3aGLqVdFz5gH9recYQ9ZnNZp23b3OLcMMtH x3citFjXqG5D7UOD74Bmm1rMRH+Zm+poj18ZvFTw/D1FbDwIVjZcfBq3HbYw7H1qDu6M N6ITkA9bwd4qHOWTtyj3P6ypiWr04zexz7kFV62zfuzFFEYqPq3Dz+5vZ/UT276Ugy64 wE/1hLjiGc4Q+dhBFrZ4KE6ucV8winUohsSAHs7BVP6f5E5uwdKmMdxXfNz+BDxbIqm6 oGl0sEHrQEMl9fsyNU7n0Uaj6CtHbgwWA3B0gAKHE5olyGpwzONw1aOz0bEXaMM9bfHO oSRQ== X-Gm-Message-State: AKGB3mLy42ez5bZCUl9tiT5M1tvQeFLk8KNtEG7PscUgf3L8Hl90PWgd TwFYCllLeBjvadxPyIfPjEY0N9/HoD79SMpo5Kg= X-Google-Smtp-Source: ACJfBotkC/Sc/A/yCglOh8W0sTHWkZbqXCmlyaV2E3FlWQK1VJcK1o+AZZZvWJCPLcq58IianJpvHB7zIO68UJFEzA8= X-Received: by 10.13.215.76 with SMTP id z73mr22031527ywd.213.1514492565161; Thu, 28 Dec 2017 12:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.131.194 with HTTP; Thu, 28 Dec 2017 12:22:24 -0800 (PST) In-Reply-To: References: From: Farhan Khan Date: Thu, 28 Dec 2017 15:22:24 -0500 Message-ID: Subject: Re: rtwn(4) extension rtl8188ee receiving constantly interrupts To: Andriy Voskoboinyk Cc: freebsd-wireless@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 20:22:46 -0000 Hi Andriy, I attempted to re-write all bits back, but the result is the same. Strange. Perhaps the initialization code is wrong somewhere? I will give it another review. -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE On Thu, Dec 28, 2017 at 4:28 AM, Andriy Voskoboinyk wrote: > Hi, > > there are some issues that may cause wrong interrupt handling: > > 1) IMR register bits - they were taken from 92c > (and they are not compatible - for example, RXFOVW seems to be moved > to the ext register) > > 2) Try to ACK (write back) all bits, > not masked ones (like it is done for 92c) > > > > 2017-12-22 0:43 GMT+02:00, Farhan Khan : > >> Hi, >>> >>> As I wrote a few weeks back, I am working on the extension to rtwn(4) to >>> add >>> RTL8188EE support. At the moment, I am working on the Rx code, which >>> handles >>> interrupts. After the interrupt is triggered, the code goes into the Rx >>> routine >>> and delivers "junk data" in a continuous loop. It seems that the >>> interrupt >>> code >>> is **constantly** called - enough that the load average is frequently >>> above >>> 1.0. >>> >>> I suspect the issue is giving the WiFi driver an acknowledgement of some >>> sort, >>> but I am not certain. I attempted to copy Linux's interrupt code as best >>> as >>> possible, but cannot determine if the error is within my code. >>> >>> Here is a verbose explanation of what I believe Linux is doing and what I >>> am >>> doing on FreeBSD. >>> >>> -----Linux code works as follows----- >>> >>> 1. The IRQ trigger calls the function _rtl_pci_interrupt >>> (drivers/net/wireless/realtek/rtlwifi/pci.c) >>> 2. This calls disable_interrupt, which for rtl8188ee is >>> rtl88ee_disable_interrupt. This function writes IMR_DISABLED (0x0) to >>> REG_HIMR (0xb0) and REG_HIMRE (0xb8). >>> 3. Next _rtl_pci_interrupt calls interrupt_recognized(), a function >>> pointer >>> to >>> rtl88ee_interrupt_recognized(), which: >>> * Reads from REG_HISR (0xb4), stores the value in 'inta', ANDs that >>> value >>> by >>> 0x200084ff, then writes that value back to the same register. >>> * Reads from REG_HISRE (0xbc), stores the value in 'intb', ANDs that >>> value by >>> 0x100, then writes that value back to the same register. >>> Then the function returns returns. >>> >>> 4. Back in _rtl_pci_interrupt if 'inta' is 0 and 'intb' is 0xffff, the >>> code >>> will >>> skip step 5, goto to "done" and execute enable_interrupt code >>> (rtl88ee_enable_interrupt) >>> >>> 5. If bit(0) is set to 1, this is an Rx interrupt and will run >>> _rtl_pci_rx_interrupt(). From my review of the code, from here the >>> Linux >>> driver will read from the DMA memory and send the frame to the >>> ieee80211 >>> layer. I only found 1 additional read instruction related to the power >>> value, >>> but nothing else is changed. >>> >>> 6. Here is the "done" portion, that happens no matter what, but is jumped >>> to >>> immediately as referenced above. It will call enable_interrupt(), a >>> function >>> pointer to rtl88ee_enable_Interrupt(), which will: >>> a. Write 0x200084ff to REG_HIMR (0xb0) >>> b. Write 0x100 to REG_HIMRE (0xb8) >>> c. Write 0 to to REG_C2HEVT_CLEAR (0x01AF, A register having to do >>> with >>> C2H >>> firmware) >>> d. Write 0xc0 to REG_HSIMR (0x58 , I know this value from printf'ing >>> it) >>> >>> This is what I identified from reviewing from the Linux code. >>> >>> -----My FreeBSD Code----- >>> >>> My code is located here: >>> https://github.com/khanzf/freebsd/tree/rx_not_working/sys/dev/rtwn/. >>> >>> 1. The IRQ trigger calls the function rtwn_pci_intr() >>> (sys/dev/rtwn/pci/rtwn_pci_rx.c) >>> 2. The equivalent of Linux's line 2 and 3 is in rtwn_classify_intr, >>> which is >>> a >>> pointer to r88ee_enable_intr located in >>> sys/dev/rtwn/rtl8188e/pci/r88ee_rx. >>> This write's 0x0 to REG_HIMR (0xb0) and REG_HIMRE (0xb8) >>> 3. Continuing, the same function: >>> * Reads from ISR_MINE (same as REG_HISR, 0xb4), ANDs the value by >>> 0x200084ff, >>> store it in 'status'. Then I write the value back to the same >>> register. >>> * Read from REG_HISRE (0xbc), AND the value by 0x100, store it in >>> 'statusb'. >>> Write this value back to the same register. >>> * Since this is an Rx register, the 'ret' value is AND'd by >>> RTWN_PCI_INTR_RX. >>> >>> 4. In the Linux code, if 'status' is 0x0 and 'statusb' is 0xFFFF, it will >>> goto >>> to "done". On FreeBSD, it simply does not set any bits on the 'ret' >>> value >>> and >>> the function returns 0, going back to rtwn_pci_intr. >>> >>> 5. Returning to rtwn_pci_intr(), if the 'ret' (now 'status') has >>> RTWN_PCI_INTR_RX flag on, it executes rtwn_pci_tx_done(), which will >>> read >>> the >>> DMA memory and send the frame to the ieee80211 layer. The execution >>> will >>> skip >>> step 5 if 'ret' was 0 (the RTWN_PCI_INTR_RX flag was never set). This >>> returns >>> execution back to rtwn_pci_intr(). >>> >>> 6. rtwn_pci_intr() concludes by running rtwn_pci_enable_intr(). This is >>> similar >>> to Linux's enable_interrupt(), it does the following: >>> a. Write 0x200084f to R88EE_HIMR (0xb0) >>> b. Write 0x100 to R88EE_HIMRE (0xb8) >>> c. Write 0x0 to REG_C2HEVT_CLEAR (0x01AF) >>> d. Write 0xc0 to REG_HSIMR >>> >>> --------- >>> >>> To me, it appears that I did a complete 1-to-1 copy of the Linux code. >>> However, >>> in my case the driver is receiving constant interrupts without stopping. >>> I >>> am >>> not certain what I am missing or what is different. Could it be that >>> something >>> outside of this particular code path was not properly set. If so, what >>> might >>> that be? >>> >>> Please advise. >>> Thank you, >>> >>> -- >>> Farhan Khan >>> PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@ >>> freebsd.org" >>> >>