Re: FreeBSD Wifi support for 802.11n Atheros AR9271 chip
I apologize for the late reply. I sort of got this started a bit ago, but have otherwise been occupied since. However, this is something I am interested in pursuing. After a few discussions in #freebsd-wifi on EFnet and reading the athn code on NetBSD/OpenBSD, I have a few thoughts. The listed devices have four interfaces, Data Tx, Data Rx, Interrupt Rx and Interrupt Tx, and share the same read/write code, so the basics are similar enough. There are some shared interfaces between FreeBSD's ath and athn, so it might be worth creating a generic ath_usb driver that loads a HAL for device-specific interfaces. My approach was to start with ath_usb, then try to isolate from athn could be in separates HAL per device. I would be interested in restarting this in the future. Last I recall, my code was kernel panicking and I could not figure out why - then $LIFE got in the way. Is anyone else working on this? Questions: A. Is this the right approach? Please offer guidance B. For those more experienced in the hardware aspects, do the terms WMI CMD ring a bell? I am getting this from a function titled "athn_usb_wmi_xcmd", which is called by the read() function. Thanks On Mon, Feb 3, 2020, at 12:21 AM, Thomas Mueller wrote: > > Dear FreeBSD Developer, > > > I have been following your to-do list through the site: > > > https://wiki.freebsd.org/AdrianChadd and > > https://wiki.freebsd.org/WiFi/80211ac > > > And I envisioned that I specialize in Qualcomm Atheros, so I would like > > to expect to port the AR9271 802.11n 150Mpbs 2GHz 1x1: 1 Wireless USB 2.0 > > chipset from this > > list https://man.openbsd.org/athn.4 that already exists on openBSD for > > freeBSD? > > > Chipset Spectrum TxR:S Bus > > AR5008-2NG (AR5416+AR2122) 2GHz 2x2:2 PCI/CardBus > > AR5008-3NG (AR5416+AR2133) 2GHz 3x3:2 PCI/CardBus > > AR5008-2NX (AR5416+AR5122) 2GHz/5GHz 2x2:2 PCI/CardBus > > AR5008-3NX (AR5416+AR5133) 2GHz/5GHz 3x3:2 PCI/CardBus > > AR5008E-2NG (AR5418+AR2122) 2GHz 2x2:2 PCIe > > AR5008E-3NG (AR5418+AR2133) 2GHz 3x3:2 PCIe > > AR5008E-2NX (AR5418+AR5122) 2GHz/5GHz 2x2:2 PCIe > > AR5008E-3NX (AR5418+AR5133) 2GHz/5GHz 3x3:2 PCIe > > AR9001-2NG (AR9160+AR9103) 2GHz 2x2:2 PCI > > AR9001-3NG (AR9160+AR9103) 2GHz 3x3:2 PCI > > AR9001-3NX2 (AR9160+AR9106) 2GHz/5GHz 3x3:2 PCI > > AR9220 2GHz/5GHz 2x2:2 PCI > > AR9223 2GHz 2x2:2 PCI > > AR9280 2GHz/5GHz 2x2:2 PCIe > > AR9280+AR7010 2GHz/5GHz 2x2:2 USB 2.0 > > AR9281 2GHz 1x2:2 PCIe > > AR9285 2GHz 1x1:1 PCIe > > AR9271 2GHz 1x1:1 USB 2.0 > > AR2427 2GHz 1x1:1 PCIe > > AR9227 2GHz 2x2:2 PCI > > AR9287 2GHz 2x2:2 PCIe > > AR9287+AR7010 2GHz 2x2:2 USB 2.0 > > > I'm waiting for a return. > > Best regards. > > Cads > > Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. > > I have a wireless Atheros AR9271 chip , USB or acts like USB, on an MSI > MPOWER motherboard dating to May 2013. > > FreeBSD has no driver for this; I was able to use Hiro H50191 USB wireless > adapter, driver rsu, though it sometimes drops the connection especially when > I have it running for a long time. > > Currently on NetBSD, there is an athn driver, but booting hangs unless I > disable athn. > > Previously on NetBSD, most of the time it would fail to load the firmware, > but I have had some times where I was actually able to get an internet > connection with this wireless adapter. > > Last experience I have with OpenBSD is 5.4, from > liveusb-openbsd.sourceforge.net, now far outdated. This OpenBSD had both rsu > and athn drivers, but neither one could load the firmware. > > You could try to port from either NetBSD or OpenBSD. > > On NetBSD I use re driver for Ethernet Realtek 811E/8168. > > Tom > > ___ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" > -- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: wireless coordination and who's working on what?
Hi all, I am working on another project which might be a few months, but would be interested in picking up a driver that is of lower priority. Ashish, I have two (maybe 3) of those cards from different vendors. I would not mind testing any code you produce. -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE On Tue, Jan 8, 2019 at 2:29 PM Adrian Chadd wrote: > > Hi! > > If you can put some code up then we can poke at it together and see how to > get the firmware load and USB framework bits into if_ath(4). > > You don't want to load it via userland; you really want the driver to load > it at attach time and if it wants to power things fully down off or not. > (You can do a reset command over USB to reset the chip back to "wait for > firmware" which is nice for things like low power modes.) > > > -a > > > On Tue, 8 Jan 2019 at 02:12, Ashish Gupta wrote: > > > Hi, > > > > I'm trying to add USB glue to the ath driver in order to support Atheros > > USB cards (I'm working with the AR9271 chip specifically). > > > > The code for downloading firmware to the card, similar to uathload, is > > ready but untested. I'm trying to wrap my head around the existing driver > > (thanks Adrian!) and will add register read / write methods next to > > initialize the chip. > > > > On Mon, 7 Jan 2019, 10:04 Shawn Webb > > > > On Mon, Jan 07, 2019 at 08:57:40AM -0600, Kyle Evans wrote: > > > > On Mon, Jan 7, 2019 at 8:47 AM Bjoern A. Zeeb wrote: > > > > > > > > > > Hi, > > > > > > > > > > I???ve been and am involved in two projects over the last 6 months > > > > > related to FreeBSD wireless. > > > > > I know there are some out there like me working on this or that; > > some > > > > > known better some less. > > > > > > > > > > I???d love to start coordinating efforts and get an overview on > > who???s > > > > > got his hands dirty in what and who has plans for other ???todos???. > > > > > > > > > > > > > I've got "try fixing up mesh" on my TODO list. I have four Carambola 2 > > > > nodes imaged for it so that I can do testing under a couple of more > > > > interesting topologies, it's mostly a matter of finding time and > > > > putting together a couple of 'console servers' for them. > > > > > > I would absolutely love working mesh support. That would drastically > > > help some of the human rights efforts I'm watching and helping. > > > > > > If you need someone to help test experimental code, please ping me. I > > > have a lab specifically for this work. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder and Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal:+1 443-546-8752 > > > Tor+XMPP+OTR:latt...@is.a.hacker.sx > > > GPG Key ID: 0x6A84658F52456EEE > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > > > > ___ > > freebsd-wireless@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org > > " > > > ___ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
rtwn(4) dropping frames, inconsistently receiving data
Hi all,
Update and soliciting advice on my efforts to get rtl8188ee on FreeBSD.
High-level summary: The Rx interrupt handler checks the Rx ring to
determine if it meets a condition prior to running rtwn_pci_rx_frame().
If it meets the condition, which I suspect is due to the device not yet
sending over the data, it will exit rtwn_pci_rx_done() before
"processing" the frame any further. This results is dropped packets
and/or data arriving in bursts with long delays between them.
Verbose explanation:
The driver now receives interrupts while in STA mode. This means I see
nearby APs when I run "ifconfig wlan0 scan". Great! But these APs/beacon
frames are inconsistently picked up the AP. tcpdump(8) shows busts of
traffic with large gaps in between. Sometimes a beacon that I see in
tcpdump(8) does not show up in the scan cache.
Digging deeper, dtrace(1) and printf(1) debugging reveal that:
1. The device is sending interrupts
2. The interrupts are correctly interpreted as Rx, resulting in calling
rtwn_pci_rx_done()
Here's the problem:
From here, the Rx interrupt code checks the current Rx ring if the
"rxdw0" value has the RTWN_RXDW0_OWN bit set. If so, it will break,
resulting in the frame not being processed. Otherwise, it will run
rtwn_pci_rx_frame(), which I understand is what processes the frame (ie,
reads beacon frames, updates the scan cache) and terminates.
See the following code from rtwn_pci_tx.c.
static void
rtwn_pci_rx_done(struct rtwn_softc *sc)
{
struct rtwn_pci_softc *pc = RTWN_PCI_SOFTC(sc);
struct rtwn_rx_ring *ring = >rx_ring;
bus_dmamap_sync(ring->desc_dmat, ring->desc_map,
BUS_DMASYNC_POSTREAD);
for (;;) {
struct rtwn_rx_stat_pci *rx_desc = >desc[ring->cur];
if (le32toh(rx_desc->rxdw0) & RTWN_RXDW0_OWN)
break;
rtwn_pci_rx_frame(sc, rx_desc, ring->cur);
if (!(sc->sc_flags & RTWN_RUNNING))
return;
ring->cur = (ring->cur + 1) % RTWN_PCI_RX_LIST_COUNT;
}
}
I noticed that the majority of the time, and specifically when the
"ifconfig wlan0 scan" fails to return anything, the if-condition just
above returns true, resulting in the for-loop breaking.
My question is, what does checking the RTWN_RXDW0_OWN bit mean? Why is
it breaking? Why is data arriving in bursts rather than continuously?
Linux Commentary:
The commentary in the Linux equivalent, _rtl_pci_rx_interrupt located in
drivers/net/wireless/realtek/rtlwifi/pci.c, suggests that this is
because the device has not filled out the Rx rings yet:
/* wait data to be filled by hardware */
Later down the comment says:
/* Reaching this point means: data is filled already
...
*/
If this is the case, what needs to happen for the device to send data?
Why is there a disconnect between the driver interrupt and DMA data?
What driver-side configuration issues may be causing this?
Ideas? Would hate to be stuck again for a few months :)
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-unsubscr...@freebsd.org"
Re: Where do monitor mode and STA mode begin to differ?
On Sat, Aug 4, 2018 at 6:48 PM, Adrian Chadd wrote: > hi! > > So, net80211 itself shouldn't really differ that much for this particular > issue. There may be some functions that aren't called in monitor mode (like > sta_join) but you're not yet there.s > > I'd look at the difference in the driver VAP setup and the newstate function > for different operating modes. If RX works in monitor mode but it's not > working in scanning mode then I'd look at how the hardware is programmed in > STA versus monitor mode. Eg, there may not be a BSS Mask programmed in for > monitor mode, or it's programmed to something like "all bits." > > > > -adrian > > > On Sat, 4 Aug 2018 at 15:32, Farhan Khan wrote: >> >> Hi all, >> >> Is there anything in net80211(4)'s initialization that is different >> between STA and monitor mode, specially around Rx? >> >> Short explanation: My extension to rtwn(4)'s monitor mode works, I can >> see arbitrary frames with tcpdump, but STA mode does not receive >> anything except the probe requests it sends out itself. Every 30 >> seconds in STA mode I get this: "rtwn0: device timeout" and the device >> re-initializes. >> >> I suspect this is due to it not receiving any frames. What might be >> initializing differently depending on if its STA or Monitor mode? If I >> can find where that is, I might be able to make an adjustment. I do >> not see anything that stands out in rtwn(4)'s init sequence, but I'll >> give it another look. Is there anything in net80211(4) that happens >> different based on the mode of the vap? >> >> Verbose explanation: As Adrian suggested on IRC, I went through >> rtwn_scan_start and rtwn_scan_end. This matched the Linux code. All >> these lines did, however, was adjust the Rx filter to receive >> beacons/probes from any BSSID, then uses ieee80211's probe functions >> to send out probe requests for whatever the VAP's ssid is set to. >> >> Running "tcpdump -ni wlan0 -y IEEE802_11_RADIO" **only** shows probes >> from what the device is sending and dtrace probes do not show the >> net80211(4) functions you would expect to happen to classify the >> frame. On a separate device, I monitored for frames and saw the Probe >> requests and responses to and from a test AP I setup, followed by an >> empty probe requests, which is exactly what >> ieee80211_swscan_probe_curchan() does. So Tx works. Great! >> >> rtwn(4) performs filter initialization in rtwn_rxfilter_init(). I >> checked that code to see if anything was being filtered that should >> not and nothing stood out to me. I unfiltered everything using >> rtwn_write_2(sc, R92C-RXFLTMAP0/1/2, 0x), and #IFDEF 0'd out the >> entire function. Same result. I should also note that >> rtwn_rxfilter_init() is used by every rtwn(4) device and is probably >> standard for this Realtek series. >> >> This suggests to me that somewhere during the initialization STA >> fails. Again, I will look through rtwn(4)'s init sequence, but is >> there anything in ieee80211(4) that might be different depending on if >> its in monitor mode or STA mode? >> >> And if you don't know, can you kindly guide me to what net80211(4) >> function first discriminates between the device mode? >> >> Thank you and I apologize for the long email. >> >> -- >> 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-unsubscr...@freebsd.org" Hi Adrian, To follow-up on this, nothing uniquely stuck out to me as in rtwn_newstate. I ended up being swiching around rtwn_newstate() and rtwn_monitor_newstate() and I still was not able to receive frames while in STA mode. I'm stuck, I do not know how to proceed. I have traced the code, but do not see a differences. What else happens when you switch the device into STA mode? Thanks, -- 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-unsubscr...@freebsd.org"
Where do monitor mode and STA mode begin to differ?
Hi all, Is there anything in net80211(4)'s initialization that is different between STA and monitor mode, specially around Rx? Short explanation: My extension to rtwn(4)'s monitor mode works, I can see arbitrary frames with tcpdump, but STA mode does not receive anything except the probe requests it sends out itself. Every 30 seconds in STA mode I get this: "rtwn0: device timeout" and the device re-initializes. I suspect this is due to it not receiving any frames. What might be initializing differently depending on if its STA or Monitor mode? If I can find where that is, I might be able to make an adjustment. I do not see anything that stands out in rtwn(4)'s init sequence, but I'll give it another look. Is there anything in net80211(4) that happens different based on the mode of the vap? Verbose explanation: As Adrian suggested on IRC, I went through rtwn_scan_start and rtwn_scan_end. This matched the Linux code. All these lines did, however, was adjust the Rx filter to receive beacons/probes from any BSSID, then uses ieee80211's probe functions to send out probe requests for whatever the VAP's ssid is set to. Running "tcpdump -ni wlan0 -y IEEE802_11_RADIO" **only** shows probes from what the device is sending and dtrace probes do not show the net80211(4) functions you would expect to happen to classify the frame. On a separate device, I monitored for frames and saw the Probe requests and responses to and from a test AP I setup, followed by an empty probe requests, which is exactly what ieee80211_swscan_probe_curchan() does. So Tx works. Great! rtwn(4) performs filter initialization in rtwn_rxfilter_init(). I checked that code to see if anything was being filtered that should not and nothing stood out to me. I unfiltered everything using rtwn_write_2(sc, R92C-RXFLTMAP0/1/2, 0x), and #IFDEF 0'd out the entire function. Same result. I should also note that rtwn_rxfilter_init() is used by every rtwn(4) device and is probably standard for this Realtek series. This suggests to me that somewhere during the initialization STA fails. Again, I will look through rtwn(4)'s init sequence, but is there anything in ieee80211(4) that might be different depending on if its in monitor mode or STA mode? And if you don't know, can you kindly guide me to what net80211(4) function first discriminates between the device mode? Thank you and I apologize for the long email. -- 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-unsubscr...@freebsd.org"
What is the ieee80211_scanner variable?
Hi all, What is "ieee80211_scanner *scanners", as defined in ieee80211_scan.c and how is it set? I am trying to figure out why my driver does not produce any results when I run "ifconfig wlan0 scan". I traced the ioctl that ifconfig(8) sends up to ieee80211_start_scan(). Here it will run ieee80211_scanner_get(), which appears to check if the "scanners" variable is set to not-NULL, and if so, return that value. Back in ieee80211_start_scan() if the value is NULL, it will return 0. The surrounding debug printf message suggests that this means the card is not able to scan. Where is this value set? What is it? It seems to be defined within net80211(4) and not at the driver-level? Am I missing something? Please explain. Thanks, -- 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-unsubscr...@freebsd.org"
Re: Where is rtwn(4) scan failing
On Fri, Jul 6, 2018 at 5:35 PM, Farhan Khan wrote: > Hi Kevin, Andriy, et al, > > As you know, I am working on expanding rtwn(4) to include the > rtl8188ee driver. It appears that net80211(4) performs a scan before > associating to a BSS, so I am working on scanning. When I run > `ifconfig wlan0 scan`, sta_pick_bss() returns immediately without any > listed networks suggesting that whatever happens in the driver is > failing. > > It appears that the scanning method begins at rtwn_scan_start(). Using > dtrace and manually tracing the source, I identified that the kernel > executes the following non-net80211(4) methods: > > * rtwn_raw_xmit > * r92c_fill_tx_desc_raw > * r88ee_tx_setup_macid > * r88ee_tx_setup_hwseq > * rtwn_pci_tx_start_frame > * r92ce_copy_tx_desc > * r92ce_tx_postsetup > * r92ce_dump_tx_desc > > First, can you please provide a conceptual overview of what is > happening in these functions? > > Second, I am not certain which (or more than one?) are failing to > function properly with the new driver. Any ideas? > > As you know, I am using the Linux rtlwifi code as documentation, but > their code is extremely difficult to read. I suspect that FreeBSD's > r92c_fill_tx_desc_raw is Linux's rtl92ce_tx_fill_desc, but as I said, > the Linux code is extremely difficult to trace through. The rtl8188ee > equivalent is rtl88ee_tx_fill_desc. I only noticed 1 difference thus > far which I do not understand yet. > > I suspect somewhere a value is set to 0x1f which should be 0x3f or > something of this nature. I was stuck on Rx for around some 6 months > and while eventually got it, it would be nice to be a little more > efficient with Tx :) > > Again, any assistance is greatly appreciated. > Thank you! > -- > Farhan Khan > PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE Hi all, I am still stuck on this and have made no progress in the past few weeks. Does anyone have any ideas? I could really use some assistance and have not heard anything back from anyone. "ifconfig wlan0 scan" immediately returns with no scan results. Where might the issues reside? Please please provide guidance. Thanks -- 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-unsubscr...@freebsd.org"
Where is rtwn(4) scan failing
Hi Kevin, Andriy, et al, As you know, I am working on expanding rtwn(4) to include the rtl8188ee driver. It appears that net80211(4) performs a scan before associating to a BSS, so I am working on scanning. When I run `ifconfig wlan0 scan`, sta_pick_bss() returns immediately without any listed networks suggesting that whatever happens in the driver is failing. It appears that the scanning method begins at rtwn_scan_start(). Using dtrace and manually tracing the source, I identified that the kernel executes the following non-net80211(4) methods: * rtwn_raw_xmit * r92c_fill_tx_desc_raw * r88ee_tx_setup_macid * r88ee_tx_setup_hwseq * rtwn_pci_tx_start_frame * r92ce_copy_tx_desc * r92ce_tx_postsetup * r92ce_dump_tx_desc First, can you please provide a conceptual overview of what is happening in these functions? Second, I am not certain which (or more than one?) are failing to function properly with the new driver. Any ideas? As you know, I am using the Linux rtlwifi code as documentation, but their code is extremely difficult to read. I suspect that FreeBSD's r92c_fill_tx_desc_raw is Linux's rtl92ce_tx_fill_desc, but as I said, the Linux code is extremely difficult to trace through. The rtl8188ee equivalent is rtl88ee_tx_fill_desc. I only noticed 1 difference thus far which I do not understand yet. I suspect somewhere a value is set to 0x1f which should be 0x3f or something of this nature. I was stuck on Rx for around some 6 months and while eventually got it, it would be nice to be a little more efficient with Tx :) Again, any assistance is greatly appreciated. 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-unsubscr...@freebsd.org"
ifconfig scan returns no results - tracing rtwn(4)'s scanning execution flow
Hi all, I'm having trouble tracing the scanning code. My extension to rtl8188ee currently returns immediately after running 'ifconfig wlan0 scan' without any identified BSSes. I am not yet certain why and am trying to figure out why. I suspect something is immediately failing and immediately returning. However, my tracing the code makes it appear circular and I am not certain where ieee80211(9) reaches into the kernel to perform the scan. My understanding of process flow: * ieee80211_swscan_attach queues a task for scan_curchan_task. * scan_curchan_task runs ic->ic_set_channel (733) and then immediately scans the channel with ic->ic_scan_curchan (line 745) in ieee80211_scan_sw.c. * ic->ic_scan_curchan is a pointer to to rtwn_scan_curchan() in if_rtwn.c (line 287). * rtwn_scan_curchan() almost immediately runs sc->sc_scan_curchan(), which is itself a pointer to ic->ic_scan_curchan. That's circular. Where did I go wrong? If rtwn(4)'s scanning is performed by the kernel, where does it reach into the kernel? I am trying to figure out where the failure in the lack of results from "ifconfig wlan0 scan" originates from. (Oh, lest anyone asks, I have at least 3 WiFi APs immediatley by the test laptop specifically for this test :) 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-unsubscr...@freebsd.org"
Getting started with association (sta) mode
Hi all, I am looking to get started with associating my wifi card with a test access point I created and am wondering where/how to get started. My first approach is to set that ssid and then bring the card up. I am trying to figure out what is the first thing that would/should occur and perhaps examine those methods as implemented by rtwn, and see what I need to modify/update. Thanks! -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EEHi ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Ignoring R92C_C2H_EVT_DEBUG patch
Quick patch to rtwn's signal handling.
Ignoring R92C_C2H_EVT_DEBUG interrupts rtl8188ee sends debugging
interrupts a few times a second, which contain no information.
Linux's rtl8723ae also ignores this signal.
Currently, rtl8188ee prints endless C2H unhandled reports to the
kernel messages, such as this:
rtwn0: r92c_handle_c2h_task: C2H report 0 (len 0) was not handled
rtwn0: r92c_handle_c2h_task: C2H report 0 (len 0) was not handled
rtwn0: r92c_handle_c2h_task: C2H report 0 (len 0) was not handled
.
My associated git commit is located here:
https://gitlab.com/farhankhan/freebsd/commit/9f9ff4bd883a88788376876fb09bac017dbb13e2
==
diff --git a/sys/dev/rtwn/rtl8192c/r92c_fw.c b/sys/dev/rtwn/rtl8192c/r92c_fw.c
index 0791990a0c00..14e517636c14 100644
--- a/sys/dev/rtwn/rtl8192c/r92c_fw.c
+++ b/sys/dev/rtwn/rtl8192c/r92c_fw.c
@@ -477,6 +477,8 @@ r92c_handle_c2h_task(struct rtwn_softc *sc, union
sec_param *data)
__func__, i, sizeof(buf)));
switch (id) {
+ case R92C_C2H_EVT_DEBUG:
+ break;
case R92C_C2H_EVT_TX_REPORT:
r92c_ratectl_tx_complete(sc, (uint8_t *)buf, len);
break;
==
Thanks
--
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-unsubscr...@freebsd.org"
Re: RTL8188EE monitor mode patch
On Wed, Jun 6, 2018 at 8:11 PM, Farhan Khan wrote:
> Hi all,
>
> First ever patch submission, quite nervous. I have attached the diff
> to this email. This is for the Realtek rtl8188ee PCI driver. Currently
> only works in monitor mode and will receive wireless frames. I am very
> interested in moving forward with getting read/write working.
>
> Known bugs:
> * Unloading the driver without bringing it down will result in a
> kernel panic. This appears to be an issue with the firmware running
> C2H code, and then attempting to write back to memory that was freed
> by the kernel.
> * Bringing the interface down, then back up will cause frames to
> arrive in spurts or not at all. This behavior only seemed to start
> after git commit 960c0f3d880f9767027c05614f2184ce4b93fa99. One
> solution is to revert sys/dev/rtwn/pci/* to the previous state and the
> issue appears to stop.
>
> You will notice what appear to be a lot of hard-coded register values.
> This is because I am basing this off of the Linux driver, and Realtek
> does not provide any documentation on how their driver works.
>
> My git repository is here: https://github.com/khanzf/freebsd
>
> Please let me know if there are any bugs or problems that need to be
remediated.
> Thank you,
> --
> Farhan Khan
> PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
Sincere apologies, I sent it as an attachment, not just the text. Please
see below.
diff --git a/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu
b/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu
new file mode 100644
index 000..68df43ca99d
--- /dev/null
+++ b/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu
@@ -0,0 +1,253 @@
+begin 644 rtwn-rtl8188eefw.fw
+MX8@0``@0)2%6L"L``*($```"134`
+MP58`
+MH01X@!;F"'`+PJ_F,.$#1!CVTJ\(V>WJB]`BY0S_(R2!^`\(
+M"+\$!'\`>('F,.3R`.4,PY]0(`4,=(@E#/CF_::!".:N#+X#`G3_S?CH;6#@
+M".;`X(#VY0S3GT`GY0PDB?CFK@R^`P)T__T8YLWXY8%M8`;0X/88@/7E#"2(
+MR/85#(#3Y0PC)('X?P3"K^8PX`,0X@Q_`##A!S#C!'\(5/14?,;2KU2`0@(BF@70#8`;_"';_W_M_!.1X@/8(]@C?^GB!=C"01<5T`9/`X.23P.!#B0%U
+MBF!UC'G2C-*O(@/OTY0#0`-__R)T@2\O^.8@Y?3"K^9$,/;2KZX,[L.?4"$.
+M=(@N^.;Y".88O@,"=/_][6E@"0GG&1GW"0F`\Q86@-KNTY]`!`6!!8'NTY]`
+M(G2(+O@(YOGNM0P"J8$8!@;F_>UI8`D9&><)"?<9@/,>@-GO)(CXY@3X[R\$
+MD$7%D_8([R^3]G\`(N_3E`-``W__(N\C)('XYC#E],*OYE2,]M*OY0RU!PIT
+MB"_XYO6!`D)-4"YTB2_XYK\#`G3__1CF^72(+_C[YOSI;&`(J`7G]AT9@/2H
+M`Z8%'^4,M0?C?P`B=(DO^.;]&(8!#W2(+_BF`0B&!.4,M0<"K('M;&`(#0FH
+M!>;W@/3E#+4'WHF!?P`B[].4`T`#?_\B[R,D@?C"K^8PY04PX`+2Y-+BQM*O
+M?P`PX@$/`D),C_#D__[E#",D@/C"J3#W#7\(YF`++?9@,%`N@`!@J$"XY).C^N23H_CDDZ/(Q8+(RL6#RO"CR,6"
+MR,K%@\K?Z=[G@+X`08&7`$&!F`!!@:0`43172EK3I_51(R'JT[?U82,AZM/']7$C(>4Y'O(L#@P/#`@\""P-!U
+MT`#``,`!P`+``\`$P`7`!L`'D`'$=%;P=$:C\!)C(N5!,.0$?P*1)^5#,.`"
+MT?3E0S#A`Q)-N^5#,.(#$DX*Y4,PXP,28W_E0S#D`O,PY0+QWN5#,.8"
+M\8OE1##A`M'J=%8$D`'$\'1_#0!]``70!-`#T`+0`=``T-#0@M"#T/#0
+MX#*0@.?@8`,23H0BD($*X&`/Y/"0!5/@1`+PD`7\X`3PY/^0@.?@8'F0@*/@
+M9`%P<9"`YN#$5`]@)"3^8`,$3U'9"`\."`#>3U'9"`\.!U\`.D
+M)/[_D(#OX"\23O.0`5=T!?"0@.K@(.(#$DK`(I"`H^"T`1.0@.?@8`V0@.O@
+M5/[P5`=P`O(I"`Z>#_?0$"2L20@*/@9`%P)9"`Y^!@'Y`!5^3PD`$\=`+P
+MD(#DX%3[\)"`Z^!4_?!4!W`"\:8BD("CX+0!%I"`Y^!@$)"`YN!4#V0"8`,"
+M:DH23CTBP.#`\,"#P(+`T'70`,``P`'``L`#P`3`!<``>0`<1T_/!T1Z/P
+M$F-/Y4DPX0(1E.5),.(#$F.AY4DPXP,28]WE2C#@`Q)D&>5*,.0#$F2XY4PP
+MX05_`Q)$)^5,,.0"$9[E3##E`Q)DSN5,,.8#$F5D=/P$D`'$\'1'H_#0!]`&
+MT`70!-`#T`+0`=``T-#0@M"#T/#0X#*0@.?@8`,2:OLBL2J0@.W@%)`%<_!]
+M`G\"46.0@0'@,.`MD("CX+0!)I"!I.`$\."T"@N0@0/@!/#DD(\)"!`^#_
+MD($"X+4'!>2C\!'D(N3_CU.0!!W@8!B0!2+@]59T__#Q\;\!`C%0@9O@D`0E\)"!G.!@#G0/+_6"Y#3\]8/@1(#PKP5T""_U@N0T_/6#Y/!T
+M"2_U@N0T_/6#X%3P\'0A+?6"Y#3\]8/@5/?PK@2O!=#0DJ\B=#TO^.9-_O9T
+M,"_U@N0T`?6#[O`BD`$V='CPHW0"\'UX_U%C?0)_`U%CD`8*X$0'\)"`\J/@
+MD`58\)"`H^"T`120@.7@5/OPD(#JX"#B#7T!?P2`#)"`Y>!$!/`B?0%_!-,0
+MKP'#P-"0@:'M\)"`ZN"0@:+PD(#DX/[$$Q-4`S#@`H$6[L03$Q-4`3#@`H$6
+MD(/YO<`*!%N]P`F&-)/YP`F'&)/Y@223\<`*!`23\8`*!%NZT#@*1EI"!
+MHN!P!'\!D;Z0@:+@M`8"D7"0@:+@M`0.D(/]@!1)I@H`"\5>0@:+@9`A@
+M`H$6$F:'@1:0@:+@<`1_`9&^D(+0&`I%PD(+0.!Y$;OP$"D9:0@:+@
+M9`Q@`H$6D1OO9`%@`H$6D=B!%I"!HN"T#@>1&[\!`I&6D(+0&`I%PD(
+MX+0,!Y$;OP$"D=B0@:+@9`1P7!)HU.]D`7!4L0Z`4)"!HN"T#@>1&[\!`I&6
+MD(+0&`I%PD(+0,!Y$;OP$"D=B0@:+@<`1_`9&^D(+0$)IQ(`5
+MD(+0,#I"`Y>#_$
RTL8188EE monitor mode patch
Hi all,
First ever patch submission, quite nervous. I have attached the diff
to this email. This is for the Realtek rtl8188ee PCI driver. Currently
only works in monitor mode and will receive wireless frames. I am very
interested in moving forward with getting read/write working.
Known bugs:
* Unloading the driver without bringing it down will result in a
kernel panic. This appears to be an issue with the firmware running
C2H code, and then attempting to write back to memory that was freed
by the kernel.
* Bringing the interface down, then back up will cause frames to
arrive in spurts or not at all. This behavior only seemed to start
after git commit 960c0f3d880f9767027c05614f2184ce4b93fa99. One
solution is to revert sys/dev/rtwn/pci/* to the previous state and the
issue appears to stop.
You will notice what appear to be a lot of hard-coded register values.
This is because I am basing this off of the Linux driver, and Realtek
does not provide any documentation on how their driver works.
My git repository is here: https://github.com/khanzf/freebsd
Please let me know if there are any bugs or problems that need to be remediated.
Thank you,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
diff --git a/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu b/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu
new file mode 100644
index 000..68df43ca99d
--- /dev/null
+++ b/sys/contrib/dev/rtwn/rtwn-rtl8188eefw.fw.uu
@@ -0,0 +1,253 @@
+begin 644 rtwn-rtl8188eefw.fw
+MX8@0``@0)2%6L"L``*($```"134`
+MP58`
+MH01X@!;F"'`+PJ_F,.$#1!CVTJ\(V>WJB]`BY0S_(R2!^`\(
+M"+\$!'\`>('F,.3R`.4,PY]0(`4,=(@E#/CF_::!".:N#+X#`G3_S?CH;6#@
+M".;`X(#VY0S3GT`GY0PDB?CFK@R^`P)T__T8YLWXY8%M8`;0X/88@/7E#"2(
+MR/85#(#3Y0PC)('X?P3"K^8PX`,0X@Q_`##A!S#C!'\(5/14?,;2KU2`0@(BF@70#8`;_"';_W_M_!.1X@/8(]@C?^GB!=C"01<5T`9/`X.23P.!#B0%U
+MBF!UC'G2C-*O(@/OTY0#0`-__R)T@2\O^.8@Y?3"K^9$,/;2KZX,[L.?4"$.
+M=(@N^.;Y".88O@,"=/_][6E@"0GG&1GW"0F`\Q86@-KNTY]`!`6!!8'NTY]`
+M(G2(+O@(YOGNM0P"J8$8!@;F_>UI8`D9&><)"?<9@/,>@-GO)(CXY@3X[R\$
+MD$7%D_8([R^3]G\`(N_3E`-``W__(N\C)('XYC#E],*OYE2,]M*OY0RU!PIT
+MB"_XYO6!`D)-4"YTB2_XYK\#`G3__1CF^72(+_C[YOSI;&`(J`7G]AT9@/2H
+M`Z8%'^4,M0?C?P`B=(DO^.;]&(8!#W2(+_BF`0B&!.4,M0<"K('M;&`(#0FH
+M!>;W@/3E#+4'WHF!?P`B[].4`T`#?_\B[R,D@?C"K^8PY04PX`+2Y-+BQM*O
+M?P`PX@$/`D),C_#D__[E#",D@/C"J3#W#7\(YF`++?9@,%`N@`!@J$"XY).C^N23H_CDDZ/(Q8+(RL6#RO"CR,6"
+MR,K%@\K?Z=[G@+X`08&7`$&!F`!!@:0`43172EK3I_51(R'JT[?U82,AZM/']7$C(>4Y'O(L#@P/#`@\""P-!U
+MT`#``,`!P`+``\`$P`7`!L`'D`'$=%;P=$:C\!)C(N5!,.0$?P*1)^5#,.`"
+MT?3E0S#A`Q)-N^5#,.(#$DX*Y4,PXP,28W_E0S#D`O,PY0+QWN5#,.8"
+M\8OE1##A`M'J=%8$D`'$\'1_#0!]``70!-`#T`+0`=``T-#0@M"#T/#0
+MX#*0@.?@8`,23H0BD($*X&`/Y/"0!5/@1`+PD`7\X`3PY/^0@.?@8'F0@*/@
+M9`%P<9"`YN#$5`]@)"3^8`,$3U'9"`\."`#>3U'9"`\.!U\`.D
+M)/[_D(#OX"\23O.0`5=T!?"0@.K@(.(#$DK`(I"`H^"T`1.0@.?@8`V0@.O@
+M5/[P5`=P`O(I"`Z>#_?0$"2L20@*/@9`%P)9"`Y^!@'Y`!5^3PD`$\=`+P
+MD(#DX%3[\)"`Z^!4_?!4!W`"\:8BD("CX+0!%I"`Y^!@$)"`YN!4#V0"8`,"
+M:DH23CTBP.#`\,"#P(+`T'70`,``P`'``L`#P`3`!<``>0`<1T_/!T1Z/P
+M$F-/Y4DPX0(1E.5),.(#$F.AY4DPXP,28]WE2C#@`Q)D&>5*,.0#$F2XY4PP
+MX05_`Q)$)^5,,.0"$9[E3##E`Q)DSN5,,.8#$F5D=/P$D`'$\'1'H_#0!]`&
+MT`70!-`#T`+0`=``T-#0@M"#T/#0X#*0@.?@8`,2:OLBL2J0@.W@%)`%<_!]
+M`G\"46.0@0'@,.`MD("CX+0!)I"!I.`$\."T"@N0@0/@!/#DD(\)"!`^#_
+MD($"X+4'!>2C\!'D(N3_CU.0!!W@8!B0!2+@]59T__#Q\;\!`C%0@9O@D`0E\)"!G.!@#G0/+_6"Y#3\]8/@1(#PKP5T""_U@N0T_/6#Y/!T
+M"2_U@N0T_/6#X%3P\'0A+?6"Y#3\]8/@5/?PK@2O!=#0DJ\B=#TO^.9-_O9T
+M,"_U@N0T`?6#[O`BD`$V='CPHW0"\'UX_U%C?0)_`U%CD`8*X$0'\)"`\J/@
+MD`58\)"`H^"T`120@.7@5/OPD(#JX"#B#7T!?P2`#)"`Y>!$!/`B?0%_!-,0
+MKP'#P-"0@:'M\)"`ZN"0@:+PD(#DX/[$$Q-4`S#@`H$6[L03$Q-4`3#@`H$6
+MD(/YO<`*!%N]P`F&-)/YP`F'&)/Y@223\<`*!`23\8`*!%NZT#@*1EI"!
+MHN!P!'\!D;Z0@:+@M`8"D7"0@:+@M`0.D(/]@!1)I@H`"\5>0@:+@9`A@
+M`H$6$F:'@1:0@:+@<`1_`9&^D(+0&`I%PD(+0.!Y$;OP$"D9:0@:+@
+M9`Q@`H$6D1OO9`%@`H$6D=B!%I"!HN"T#@>1&[\!`I&6D(+0&`I%PD(
+MX+0,!Y$;OP$"D=B0@:+@9`1P7!)HU.]D`7!4L0Z`4)"!HN"T#@>1&[\!`I&6
+MD(+0&`I%PD(+0,!Y$;OP$"D=B0@:+@<`1_`9&^D(+0$)IQ(`5
+MD(+0,#I"`Y>#_$Q-4/S#@`O'GT-"2KR+Q:N]D`6`(D`=`'P@#V0@.3@
+M_Q,3$U0?,.`(D`=`+P@"COQ%0/,.`(D`=`3P@!F0@.G@TY0$0`B0`;AT
+M"/"`")`!N.3P?P$BD`=`+P?P`BD(#EX)`&!"#@#.!$0/"0@.IT!/"`"N!4
+M?_"0@.IT#/"0!2+D\"*0@.7@PQ,@X`B0@.IT#/"`$9`&!.
C2H interrupt causing kernel panics
Hi all, I have a kernel panic question. When I load my module with the firmware and turn it on (ifconfig wlan0 up) it will start receiving C2H interrupts. Great. But I noticed that if I unload the module *without* running "ifconfig wlan0 down", it will trigger a kernel panic. It appears this is caused by a C2H interrupt function still running after the module is unloaded. If I bring the interface down, I have no problems. Am I missing something here? Is there a proper way to disable C2H interrupts? Thanks, -- 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-unsubscr...@freebsd.org"
Handling C2H debug interrupt on rtwn(8)
Hi all, I have a question regarding catching an unhandled C2H event interrupt. rtwn(4) receives C2H interrupts from the device. One type is R92C_C2H_EVT_DEBUG as defined in sys/dev/rtwn/rtl8192c/r92c_fw_cmd.h as 0. Interrupts are handled in r92c_handle_c2h_task() in sys/dev/rtwn/rtl8192c/r92c_fw.c line 479. I noticed that rtl8188ee (driver in development) sends R92C_C2H_EVT_DEBUG, but they are not handled, resulting in the 'default' case, which is to print a warning into the kernel messages buffer. As a result, I am seeing a ton of warning messages across my terminal 1-2 times a second. This is not a problem for me in development, but would problematic for any user of the driver, as it would fill up the kernel messages buffer very quickly. I reviewed Linux's equivalent code and found that rtl8723ae is the only one of the rtlwifi drivers that checks C2H_EVT_HOST_CLOSE (also defined as 0), and immediately just does a 'return'. Would it be correct for me to imitate this behavior, check for the same C2H message type, and immediately issue a 'break'? I did so in my dev repository here: https://github.com/khanzf/rtl8188ee/commit/b9dd37c8f40af1bda1ec8d82fdaa051840b85e75 . Thanks! -- 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-unsubscr...@freebsd.org"
rtwn(4) crash dump and kgdb output
Hi all, I discussed this in the IRC channel but I was not certain what the actual issue may be. When I load the firmware, unload the driver, and reload it, in part of the process I clear a register bit, then set it. When I set it again, it causes the kernel to panic. I am not certain what is causing this. The following is my kgdb output. I see the error message "Fatal trap 9: general protection fault while in kernel mode", but I do not see where or why. Anyone have any suggestions on how I could continue to identify the issue? Thanks, # sudo kgdb /usr/lib/debug//boot/kernel/kernel.debug /var/crash/vmcore.last GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. Unread portion of the kernel message buffer: kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer= 0x20:0x80ae16f0 stack pointer= 0x28:0xfe00259ca850 frame pointer= 0x28:0xfe00259ca8c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process= 11 (idle: cpu0) trap number= 9 panic: general protection fault cpuid = 0 time = 1524097207 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00259ca560 vpanic() at vpanic+0x18d/frame 0xfe00259ca5c0 panic() at panic+0x43/frame 0xfe00259ca620 trap_fatal() at trap_fatal+0x352/frame 0xfe00259ca670 trap() at trap+0x6d/frame 0xfe00259ca780 calltrap() at calltrap+0x8/frame 0xfe00259ca780 --- trap 0x9, rip = 0x80ae16f0, rsp = 0xfe00259ca850, rbp = 0xfe00259ca8c0 --- callout_process() at callout_process+0x120/frame 0xfe00259ca8c0 handleevents() at handleevents+0x1a5/frame 0xfe00259ca900 timercb() at timercb+0x254/frame 0xfe00259ca950 lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfe00259ca990 timerint_u() at timerint_u+0x96/frame 0xfe00259caaa0 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfe00259caac0 cpu_idle() at cpu_idle+0x8f/frame 0xfe00259caae0 sched_idletd() at sched_idletd+0x40a/frame 0xfe00259cabb0 fork_exit() at fork_exit+0x84/frame 0xfe00259cabf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00259cabf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 5m36s Dumping 436 out of 3952 MB:..4%..12%..23%..34%..41%..52%..63%..74%..81%..92% __curthread () at ./machine/pcpu.h:230 230./machine/pcpu.h: No such file or directory. (kgdb) bt #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:347 #2 0x80ac9312 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #3 0x80ac98dd in vpanic (fmt=, ap=0xfe00259ca600) at /usr/src/sys/kern/kern_shutdown.c:812 #4 0x80ac9923 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:739 #5 0x80f7deb2 in trap_fatal (frame=0xfe00259ca790, eva=0) at /usr/src/sys/amd64/amd64/trap.c:819 #6 0x80f7d48d in trap (frame=0xfe00259ca790) at /usr/src/sys/amd64/amd64/trap.c:199 #7 #8 callout_process (now=1442651863143) at /usr/src/sys/kern/kern_timeout.c:488 #9 0x810ad265 in handleevents (now=1442651863143, fake=0) at /usr/src/sys/kern/kern_clocksource.c:213 #10 0x810ad964 in timercb (et=0x81d07208 , arg=) at /usr/src/sys/kern/kern_clocksource.c:353 #11 0x810eb9f7 in lapic_handle_timer (frame=0xfe00259ca9a0) at /usr/src/sys/x86/x86/local_apic.c:1305 #12 0x80f5b6f0 in timerint_u () at /usr/src/sys/amd64/amd64/apic_vector.S:132 #13 0x in ?? () -- 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-unsubscr...@freebsd.org"
Starting Station mode for rtwn(4)'s rtl8188ee
Hi all, As discussed in the IRC channel, I finally got the rtwn(4) rtl8188ee device to start receiving frames in Monitor mode. As Adrian suggested, I would like to proceed to Station mode, but I am not certain where to start. My question is, what are the first steps that switching to Station mode does? What net80211 methods that reach into the driver should I target? I can eventually find out through tracing net80211, dtrace(1) and printfs, and probably will anyways, but it would save a lot of time if someone could give me some pointers (pun intended). 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-unsubscr...@freebsd.org"
Last attempts at rtwn(4)'s rtl8188ee driver
Hi all, I have been trying to work on rtwn(4) for a little more than a year and a half with very limited success. The device does not receive any interrupts whatsoever and thus Rx fails. (Exception: it seems to receive a null interrupt once every hour when idle). When I run "tcpdump -ni wlan0 -y IEEE802_11_RADIO", FreeBSD will execute rtwn_set_promisc(), but fail to receive anything. The device works on Linux, so this is not a hardware issue. I have exhausted my options and have literally no what what the problem is. My code is located here: https://github.com/khanzf/rtl8188ee Does anyone have any ideas what the failure may be? Specifically: A) Is my initialization code even correct? If not, where is it wrong? B) Why is the device not receiving Rx interrupts? Unless anyone can determine *exactly* where the issue lays, I will be very regrettably abandoning this project that I have spent a considerable amount of personal time one. Thanks and my apologies to send this upsetting email. -- 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-unsubscr...@freebsd.org"
Re: rtwn(4) extension rtl8188ee receiving constantly interrupts
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 <s3er...@gmail.com> 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 <kha...@gmail.com>: > >> 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 0x, 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
Re: rtwn(4) extension rtl8188ee receiving constantly interrupts
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 <adr...@freebsd.org> 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 <kha...@gmail.com> 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 0x, 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'
rtwn card not delivering interrupts from beacon frames
Hi all, As discussed, I am working on the rtwn rtl8188ee driver. Per Adrian's advice, I am focusing on having the card reading beacon frames. I am running the following tcpdump line, which works on another machine with an rtwn card. # tcpdump -y IEEE802_11_RADIO -i wlan0 -e -s 256 type mgt Unfortunately, my card still does not receive beacon frames. Per IRC conversations, this information is delivered to the driver via an interrupt. I retracted my sc_init_intr code and found that the interrupt register was incorrectly set, so I updated them per the Linux driver and started having sc_classify_intr trigger very slowly (1-2 a minute), rather than with every beacon frame from a nearby Access Point. The 'status' was set to 0x, so it immediately exited. What might this mean? I am stuck and not certain why I am not receiving more beacon frames. I have retraced the code, but am not finding what I might have left out. Any ideas? I can show code if requested. Been on this driver for a little more than a year now and would like to start making progress. :/ Thank you, Farhan ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
ieee80211 scan function starting point
Hi all, I am trying to get the "ifconfig wlan0 list scan" command to display local access points. I am fairly certain I have the "up" part working (loading firmware, turning it on) but the scan portion does not yet. I am trying to identify what functions I might have missed with dtrace, but I do not know where to start off and the probes are too rapid to identify where it starts when I run the "ifconfig" command. I am fairly certain it originates in ieee80211 and kicks that off to the driver, but I cannot easily identify where. Does anyone know where? Thank you. Farhan ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Identify cause of ieee80211_get_counter
Hi everyone. I am working through the driver, and running into some ieee80211_get_counter()'s. Per sys/net80211/ieee80211.c, the comment says "Add underlying device errors to vap errors", which implies that it will only trigger when an error occurs. Is there a way to identify what the cause of the function call is? I ran dtrace against "fbt:kernel:ieee80211_get_counter:entry" with a stack() trace as follows: CPU IDFUNCTION:NAME 3 17127 ieee80211_get_counter:entry kernel`if_data_copy+0xa1 kernel`sysctl_rtsock+0x2b6 kernel`sysctl_root_handler_locked+0x7b kernel`sysctl_root+0x1c6 kernel`userland_sysctl+0x148 kernel`sys___sysctl+0x5f kernel`amd64_syscall+0x79b kernel`0x80ed07bb Is there an efficient way to identify what the cause of the error is? 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-unsubscr...@freebsd.org"
Re: C2H on rtwn not handled
Hi Andriy, Just to be clear, this would mean that in my sc_post_init, I should not utilize callout_reset, which utilizes r92c_handle_c2h_report, correct? This appears to be how rtl If so, how do I know when a C2H event arrives? (I am not too familiar with C2H or how it works yet). As always, thank you very much. On 10/29/2017 07:46 PM, Andriy Voskoboinyk wrote: Sun, 29 Oct 2017 08:34:21 +0200 було написано Farhan Khan <kha...@gmail.com>: Hi, You should not use polling for RTL8188EE - it was mainly used for RTL8192C* (since there is no documented way to get events from it) and can be enabled on RTL881(1,2)A (but just is not needed here). Look into rtwn/rtl8188e/r88e_rx.c - I think you can call r88e_ratectl_tx_complete() and/or r88e_handle_c2h_report() indirectly from rtwn_pci_intr() when C2H event arrives. Hi all, I am trying to extend the rtwn driver to add RTL8188EE support. I am still getting this error whenever I enable the WiFi card: rtwn0: r92c_handle_c2h_task: C2H report 0 (len 0) was not handled From my reading of the code, it appears that the driver is trying to read a status-value from the card, but it fails to return a valid result. Is there something that I need to do to initialize this? If so, what exactly? This appears to be a firmware-specific routine and I have enabled the firmware. I have been on this for an extended period of time and am stuck :( 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-unsubscr...@freebsd.org" ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
C2H on rtwn not handled
Hi all, I am trying to extend the rtwn driver to add RTL8188EE support. I am still getting this error whenever I enable the WiFi card: rtwn0: r92c_handle_c2h_task: C2H report 0 (len 0) was not handled From my reading of the code, it appears that the driver is trying to read a status-value from the card, but it fails to return a valid result. Is there something that I need to do to initialize this? If so, what exactly? This appears to be a firmware-specific routine and I have enabled the firmware. I have been on this for an extended period of time and am stuck :( 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-unsubscr...@freebsd.org"
Re: Register Address Size Mismatch
Thank you! That is in the Linux driver here: http://src.illumos.org/source/xref/linux-master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c#_rtl8188e_config_rf_reg As a matter of completion, is this information publicly available such as in a chipset document or something you came across from reading the driver code? I am currently essentially doing replay without fully understanding how the device works. On 10/01/2017 03:12 PM, Andriy Voskoboinyk wrote: > Do you mean 0xFFE address? In vendor driver such 'addresses' are used > for delay between writes (50 ms for RTL8812A). > >> The issue is in the assignment, not the write/read part. rtwn_rf_prog >> wants a * uint8_t list, whereas the register size from Linux is a >> uint32_t (but can cleanly fit into a uint16_t and might just be the >> default register size on Linux). How do I reconcile those two? I hope I >> was clearer there. >> >> The first column are the Linux registers in question: >> http://src.illumos.org/source/xref/linux-master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/table.c#316 >> >> >> Thank you for your continued assistance. >> >> On 10/01/2017 06:30 AM, Andriy Voskoboinyk wrote: >>> Hi, >>> >>> RF registers are using indirect addressing; you should use >>> rtwn_rf_write() / rtwn_rf_read() instead. >>> >>> >>>> I am working on porting over a Linux Realtek driver to FreeBSD. I ran >>>> into a register-size issue. >>>> >>>> FreeBSD's PCI-write function is defined as follows: >>>> rtwn_pci_write_4(struct rtwn_softc *sc, uint16_t addr) >>>> >>>> Notice that the second parameter is of type uint16_t. >>>> >>>> During initialization, the rtwn driver uses the rtwn_rf_prog structure >>>> to write a pre-defined list of data to a pre-defined list of registers. >>>> The structure to hold both lists is defined here: >>>> http://src.illumos.org/source/xref/freebsd-head/sys/dev/rtwn/if_rtwnreg.h#150. >>>> >>>> >>>> Notice how the second parameter 'reg' is a uint8_t. >>>> >>>> The rtwn_pci_write_4's addr is uint16_t, the rtwn_rf_prog's addr is a >>>> uint8_t. How would I reconcile this type mismatch? Additionally, the >>>> Linux version of this block of code has all register values as a >>>> uint32_t. It is not a matter of a cast, because some values definitely >>>> use more than 1 byte (ie 0xFFE). >>>> >>>> Suggestions on how to reconcile and resolve this issue? >>>> >>>> Thanks! >>>> Farhan Khan >>>> ___ >>>> freebsd-wireless@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>> To unsubscribe, send any mail to >>>> "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Register Address Size Mismatch
The issue is in the assignment, not the write/read part. rtwn_rf_prog wants a * uint8_t list, whereas the register size from Linux is a uint32_t (but can cleanly fit into a uint16_t and might just be the default register size on Linux). How do I reconcile those two? I hope I was clearer there. The first column are the Linux registers in question: http://src.illumos.org/source/xref/linux-master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/table.c#316 Thank you for your continued assistance. On 10/01/2017 06:30 AM, Andriy Voskoboinyk wrote: > Hi, > > RF registers are using indirect addressing; you should use > rtwn_rf_write() / rtwn_rf_read() instead. > > >> I am working on porting over a Linux Realtek driver to FreeBSD. I ran >> into a register-size issue. >> >> FreeBSD's PCI-write function is defined as follows: >> rtwn_pci_write_4(struct rtwn_softc *sc, uint16_t addr) >> >> Notice that the second parameter is of type uint16_t. >> >> During initialization, the rtwn driver uses the rtwn_rf_prog structure >> to write a pre-defined list of data to a pre-defined list of registers. >> The structure to hold both lists is defined here: >> http://src.illumos.org/source/xref/freebsd-head/sys/dev/rtwn/if_rtwnreg.h#150. >> >> Notice how the second parameter 'reg' is a uint8_t. >> >> The rtwn_pci_write_4's addr is uint16_t, the rtwn_rf_prog's addr is a >> uint8_t. How would I reconcile this type mismatch? Additionally, the >> Linux version of this block of code has all register values as a >> uint32_t. It is not a matter of a cast, because some values definitely >> use more than 1 byte (ie 0xFFE). >> >> Suggestions on how to reconcile and resolve this issue? >> >> Thanks! >> Farhan Khan >> ___ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to >> "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Register Address Size Mismatch
I am working on porting over a Linux Realtek driver to FreeBSD. I ran into a register-size issue. FreeBSD's PCI-write function is defined as follows: rtwn_pci_write_4(struct rtwn_softc *sc, uint16_t addr) Notice that the second parameter is of type uint16_t. During initialization, the rtwn driver uses the rtwn_rf_prog structure to write a pre-defined list of data to a pre-defined list of registers. The structure to hold both lists is defined here: http://src.illumos.org/source/xref/freebsd-head/sys/dev/rtwn/if_rtwnreg.h#150. Notice how the second parameter 'reg' is a uint8_t. The rtwn_pci_write_4's addr is uint16_t, the rtwn_rf_prog's addr is a uint8_t. How would I reconcile this type mismatch? Additionally, the Linux version of this block of code has all register values as a uint32_t. It is not a matter of a cast, because some values definitely use more than 1 byte (ie 0xFFE). Suggestions on how to reconcile and resolve this issue? Thanks! Farhan Khan ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
rtwn0: timeout waiting for firmware readiness
Hi all, I am trying to add support for RTL8188EE for rtwn(4). I am trying to load the firmware, but getting this error: rtwn0: timeout waiting for firmware readiness This error occurs at https://github.com/khanzf/freebsd/blob/firmware/sys/dev/rtwn/if_rtwn_fw.c#L285. Up to that point there do not appear to be any errors. I am trying to mirror the code from Linux's code here: https://github.com/lwfinger/rtlwifi_new/blob/master/rtl8188ee/fw.c#L170. I do not know what is causing this issue. Any ideas? Note: The #if 0 condition in 176 to 216 is the driver's default, the else-condition is what I ported over from Linux. I have been switching back and forth, but it does not change the issue. (Pardon my dev-code, its quite messy) -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Adding wifi source code
Thomas, I was planning on also porting over the Atheros AR9271 driver from NetBSD (athn(4) /usr/src/sys/dev/usb/if_athn_usb.c), but not until I finish the current device I am working on. It might not be for a while though. There is likely a lot of shared code with ath(4) on FreeBSD (/usr/src/sys/dev/athn). NetBSD seems to separate all code between USB and PCI, whereas FreeBSD combines drivers. Let me know if I can help out, as I already own this device and would be willing to test out code or troubleshoot with you. I am currently working on another driver from Linux to FreeBSD. The core concepts are the same, but a lot of code is in different order. FreeBSD drivers have an attach function that assign function pointers to the softc struct. The Linux equivalent is in DRIVERNAME_ops. In my case, this: http://src.illumos.org/source/xref/linux-master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c#224 . Hope this helps. But yes, would love to work on AR9271! -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA On Fri, Sep 1, 2017 at 5:25 PM, Thomas Mueller <mueller6...@twc.com> wrote: > from Tecno Linux: > > > Hello, I have the source code of my wireless driver i extract it from the > > linux kernel how can i compile that source code or i have another option > my > > wireless driver is a realtek rtl8723be wifi > > I have similar question, but the source code is from NetBSD and the > wireless chip is Atheros AR9271. > > I also have similar question regarding Ethernet Realtek 8111E re driver, > works in NetBSD but not FreeBSD (11.1-STABLE and HEAD) on computer in > question. > > Is there online handbook/documentation on writing device drivers or > porting from Linux or NetBSD? > > Tom > > ___ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org > " > ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
ieee80211_waitfor_parent hangs forever
Hi all, I traced back where my driver-in-development hangs when I issue "ifconfig wlan0 up", and it hangs on ieee80211_waitfor_parent(), specifically: ieee80211_draintask(ic, >ic_parent_task); Reference: http://src.illumos.org/source/xref/freebsd-head/sys/net80211/ieee80211_proto.c#1406 I am not familiar with the source just yet, What does this function do? And, what is ic_parent_task? It appears that Andriy reported this same issue here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208860 but I did not see a resolution. Thanks! -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Why is rtwn module detaching?
Following up on this from earlier: I am trying to extend the sys/dev/rtwn/rtl8188e driver to support PCI. Linux calls this rtl8188ee. Right now, my code loads, reads the ROM, and will create an interface with: ifconfig wlan0 create wlandev rtwn0 But when I assign an IP address, it immediately detaches. I have not been able to figure out why this is happening and I cannot continue developing this driver, despite a few weeks of tracing the code. Some clues: I found that rtwn_parent() will trigger rtwn_stop() if ic->ic_nrunning is less than 0. That value is incremented in ieee80211_start_locked() and decremented in ieee80211_stop_locked(). I used stack_print(9), which show that ieee80211_stop_locked() is executed at least 4 times, but the trace's originate with a device_detach() in the first place. What is causing that in the first place? So, why is my driver unloading? Because ic->ic_nrunning is less than 0. Why is ic->ic_nrunning less than 0? Because something is calling ieee80211_stop_locked(). I have no direction on what the issue may be and have been just searching for an extended period now. Any assistance would be highly appreciated. Thank you, -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA On Mon, Aug 7, 2017 at 7:15 PM, Adrian Chadd <adrian.ch...@gmail.com> wrote: > For reference, we chatted on IRC. > > I think it's the NIC disappearing because giving it an iP brings it > link 'up' and something in the 'up' path is causing the firmware to > crash and the NIC to disappear. > > which bus is it on btw? eg, you could try 'devctl rescan pcib3' if > it's on pcib3.. > > -adrian > > On 5 August 2017 at 19:43, Farhan Khan <kha...@gmail.com> wrote: > > Hi all, > > > > I am slowly struggling through writing my Wifi first driver, which is an > > extension to the current rtwn driver. I have reached another hurdle that > > I'm stuck on. > > > > I bring up my wifi driver as follows: > > > > # kldload rtwn && kldload rtwn_pci > > # sudo ifconfig wlan0 create wlandev rtwn0 > > # sudo ifconfig wlan0 1.1.1.1 > > > > The third line causes the rtwn0 device to detach (and pci0 device, which > > requires a reboot and is quite frustrating). > > > > I traced through the code to find why it is detaching and found that in > > rtwn_parent() (sys/dev/rtwn/if_rtwn.c), it checks the ic->ic_nrunning > (from > > struct ieee80211com). If that value is less than or equal to 0, it will > > cause the rtwn driver to stop. This appears to be a common control > > structure used by other drivers as well. > > > > Unfortunately, I have not been able to determine where ic->ic_nrunning is > > modified anywhere in the kernel. In fact, the only references I found > from > > my searches was checking the ic_nrunning value, not setting it. > > > > Does anyone know where this is being set? Without determining this, I > > cannot why my driver is unloading. I suspect that I failed to set the > > appropriate 802.11 values in my own code, causing the base 802.11 code to > > mark it as "off" or malfunctioning but I am not certain. > > > > Please advise. > > Thank you, > > -- > > Farhan Khan > > PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA > > ___ > > 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" > ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Why is rtwn module detaching?
Hi all, I am slowly struggling through writing my Wifi first driver, which is an extension to the current rtwn driver. I have reached another hurdle that I'm stuck on. I bring up my wifi driver as follows: # kldload rtwn && kldload rtwn_pci # sudo ifconfig wlan0 create wlandev rtwn0 # sudo ifconfig wlan0 1.1.1.1 The third line causes the rtwn0 device to detach (and pci0 device, which requires a reboot and is quite frustrating). I traced through the code to find why it is detaching and found that in rtwn_parent() (sys/dev/rtwn/if_rtwn.c), it checks the ic->ic_nrunning (from struct ieee80211com). If that value is less than or equal to 0, it will cause the rtwn driver to stop. This appears to be a common control structure used by other drivers as well. Unfortunately, I have not been able to determine where ic->ic_nrunning is modified anywhere in the kernel. In fact, the only references I found from my searches was checking the ic_nrunning value, not setting it. Does anyone know where this is being set? Without determining this, I cannot why my driver is unloading. I suspect that I failed to set the appropriate 802.11 values in my own code, causing the base 802.11 code to mark it as "off" or malfunctioning but I am not certain. Please advise. Thank you, -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Trouble writing rtl8188ee driver
That was it!!! Thank you! Wow! I have been on this for weeks now! My debugging output displays as follows: id: 8129 hpon: Render How? clk:0 rf_board_option:0 rf_feature_option: 0 rf_bt_setting: 10 Version:0 customer_id:0 rf_antenna_option: 2 MAC Address:40:49:f:a9:b7:61 vid:10ec did:8179 svid: 103c smid: 197d Board type: 0 Regulatory: 0 However, your email might change my direction to just extend the rtl8188e code and add the PCI bits. This is my first time hacking the kernel and I hope to contribute back. Thanks again! -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA On Sat, Mar 18, 2017 at 7:28 PM, Andriy Voskoboinyk <s3er...@gmail.com> wrote: > Sat, 18 Mar 2017 22:21:51 +0200 було написано Farhan Khan < > kha...@gmail.com>: > > Hi, > > there is no need to create an additional rtl8188ee[e] directories / files; > AFAIK, rtl8188ee is just a PCI-E version of rtl8188e chipset (and rtl8188eu > is an USB-based version); you should just separate pci / usb code inside > rtl8188e directory (most of it will be the same; you can use rtl8192c as an > example (but you should use rtl8188eu as an template - they are somewhat > different)) > > About this particular bug: you don't have RTWN_FLAG_EXT_HDR set > (non-rtl8192c > chipsets may contain an 'extended header' in encoded ROM image; it is > generally used to extend maximum ROM image size over 128 bytes) > > Hi team, >> >> I'm toothe from the IRC channel. I hope you all are doing well :) Let me >> tell you where I am in writing my code. In short, I am stuck and need >> asisstance. >> >> I created a copy of the rtl8192c code, and placed it here: >> https://github.com/khanzf/freebsd/tree/master/sys/dev/rtwn/rtl8188ee >> >> I zero'd out all functions and went one-by-one to replace them as >> necessary. The section of code that I am stuck at is reading the >> EEPROM/ROM >> from the chip. I backed into the ROM image for the first 222 bytes by >> using >> the Linux source as documentation and created this: ( >> https://github.com/khanzf/freebsd/blob/master/sys/dev/rtwn/ >> rtl8188ee/r88ee_rom_image.h#L56) >> When >> I read from the ROM, I basically get 500~ bytes of 0xFF - the first 10 or >> so are set properly, suggesting that I am reading from the right memory >> segment. Specifically, the first 2 bytes are 0x8129, which is accurate per >> the Linux driver. But why is everything else coming up as 0xFF's? >> >> I delved into how FreeBSD's rtwn and Linux's rtl8188ee drivers work. The >> efuse code is very similiar, of course, but I do not understand the >> reasoning for what is occurring. The main difference I found, so far, was >> that the Linux driver will read from EFUSE_CTRL + an offset (1, 2 or 3), >> whereas the FreeBSD driver does not use an offset. >> >> This is where I am stuck. I would easily just change the code over to add >> the offset on the FreeBSD code, but it is in sys/dev/rtwn/if_rtwn_efuse.c, >> which is used by multiple drivers. >> >> I am unsure what is wrong or how to diagnose it. Can you please provide me >> some guidance? I have been stuck on this same issue for a little more than >> a month. >> >> Thank you! >> >> -- >> Farhan Khan >> PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA >> ___ >> 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" >> > ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Trouble writing rtl8188ee driver
Hi team, I'm toothe from the IRC channel. I hope you all are doing well :) Let me tell you where I am in writing my code. In short, I am stuck and need asisstance. I created a copy of the rtl8192c code, and placed it here: https://github.com/khanzf/freebsd/tree/master/sys/dev/rtwn/rtl8188ee I zero'd out all functions and went one-by-one to replace them as necessary. The section of code that I am stuck at is reading the EEPROM/ROM from the chip. I backed into the ROM image for the first 222 bytes by using the Linux source as documentation and created this: ( https://github.com/khanzf/freebsd/blob/master/sys/dev/rtwn/rtl8188ee/r88ee_rom_image.h#L56) When I read from the ROM, I basically get 500~ bytes of 0xFF - the first 10 or so are set properly, suggesting that I am reading from the right memory segment. Specifically, the first 2 bytes are 0x8129, which is accurate per the Linux driver. But why is everything else coming up as 0xFF's? I delved into how FreeBSD's rtwn and Linux's rtl8188ee drivers work. The efuse code is very similiar, of course, but I do not understand the reasoning for what is occurring. The main difference I found, so far, was that the Linux driver will read from EFUSE_CTRL + an offset (1, 2 or 3), whereas the FreeBSD driver does not use an offset. This is where I am stuck. I would easily just change the code over to add the offset on the FreeBSD code, but it is in sys/dev/rtwn/if_rtwn_efuse.c, which is used by multiple drivers. I am unsure what is wrong or how to diagnose it. Can you please provide me some guidance? I have been stuck on this same issue for a little more than a month. Thank you! -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
RTL8188ee code
Hi Adrian (et al?), I am toothe from IRC. The name came about because I had a tooth ache when I came up with it and I have this odd habit of putting 'e' at the end of words. As discussed, I would love tow rite the rtl8188ee driver for FreeBSD. There already exists a Linux driver, so I am basing my code off of that. The probe is simple enough, but I do not know what to do with the attach function. Is there a general order of events? My code is here: https://www.gitlab.com/farhankhan/rtl8188ee/tree/master Thanks and I look forward to working on this. -- Farhan Khan ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
